RE: [ebxml-cppa] Intermediaries

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Title: Message

Brian and Suresh,

 

Some of us had hoped that the intermediary problem would eventually sort  

out so that either intermediaries were just other participants in the collaboration,

and were initial sources or final sinks of messages or they were just part of the

infrastructure and so would not show up as modelled in a BPSS instance any more than a 

router, caching proxy, or relay MTA would show up. The parties showing up in BPSS instances

can of course each have a CPP and can (pairwise) have CPAs. We have not conclusively

established any use case for a multiparty CPA at the moment (that is, a use case that

can't instead be captured by means of pairwise CPAs among collaboration participants).

 

However, it appears there is going to be SOAP intermediaries, and since messaging

is layered on SOAP we will have to at least deal with SOAP intermediaries. It has not been decided

what, if anything, is needed for SOAP intermediaries. So far we have only some information

items pertaining to agreements to use either final MSH acks or to use "nextMSH" acks

as found in the 2.0 spec.

 

I do agree with you that there may well be some intermediaries that do receive a message

and forward it  on (at least reuse the messageId) that

provide some "service" that might fall outside of typical business

roles. A notarized timestamp service seems a plausible example. 

However, BPSS might fold these into a separate subprocess in a BPSS instance

and so subsume it under a bilateral CPA agreement.

 

If the messages change "To" "From" "CpaID" & "MessageId" values in the ebXML header, then

clearly we would prefer to view this as a multiparty BPSS situation.

 

It is when these values do not change as the message passes through a system,

 that we currently remain undecided how best to map

current CPAs to the situation.

 

We are waiting on use cases being defined, the BPSS treatments proposed, and

then we will take up, what if anything, CPPA needs to provide for configurations.

We also need to see what the w3c SOAP specification does for intermediaries,

and what ebXML Messaging will build upon those adornments...

 

That is how I would assess the current state of discussion within the CPPA TC. Dale

-----Original Message-----
From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
Sent: Tuesday, June 11, 2002 12:22 PM
To: 'Dale Moberg'; Tony Fletcher; Martin W Sachs; ebxml-cppa@lists.oasis-open.org
Cc: Kartha, Neelakantan
Subject: [ebxml-cppa] Intermediaries

Dale et al,

 

There was some discussion on the definition of "intermediary" on the CPPA mailing list some time in the past.

If somebody could post a summary of the consensus, it would help me much.

 

I have the following ideas on intermediary FWIW - and hopefully the TC consensus is not wildly different!

I am trying to present this in the form of a taxonomy, but pardon me if it doesn't exactly look formal.

First I define a "technical intermediary," and then contrast with "business intermediary"

 

Technical Intermediary:

 

1. Intermediary is not at the transport (==OSI application protocol layer - e.g. http, smtp, ftp) layer,

and it is at the message layer or service layer. In particular,  an intermediary MUST parse the ebXML (SOAP) message.

However, an intermediary will not change the messageId. 

 

[Brian] It is very important that the "technical" intermediary not disturb the contents of the business-level payload (e.g. the business documents).

 

2. Intermediaries could exhibit different behaviors w.r.t. the message

    - relay/proxy intermediary - relays the received message with no changes to the received message. 

 

[Brian] This is the e-marketplace/portal concept supported by commpanies like Commerce One.  This is a minimum requirement for supporting intermediaries.

 

    e.g, caching intermediaries

    - security intermediaries (that change the security attributes of the message)

    e.g, signer, encryptor/decryptor, etc.

[Brian] For what purpose is an intermediary signing or encrypting/decrypting documents?  Is the intermediary providing the business of encrypting on behalf of someone else?

 

     - processing intermediaries (that process the message and change the message - but will not change the messageId)

 

[Brian] This is not a technical intermediary.  If you are processing the messaging, you are providing some kind of business service, even if it is something as simple as "translate and forward."

 

3. Intermediaries can also be classified based on whether they have a CPP or not. 

 

[Brian] How is this useful beyond telling me that an intermediary has papers or it doesn't.

 

Thus,  I have defined above two axes of definition for intermediaries based on (a) effect on a message (b) existence of profile

Perhaps there are more axes?

 

Business Intermediary:

 

Now, if we think about business intermediaries, how do they differ from above?

Couple of examples:

    - Shipping agent: This is a business intermediary that has a CPP, but it is not a technical intermediary. Because

    shipping agent will change the messageId, it is not a technical intermediary.

    - Notary - a notary may have a CPP, but could also be a technical intermediary, because a notary may simply

    add its signature on a message that it receives.

 

[Brian] These business intermediaries are just business services and should have CPPs and CPAs.  The processes that they support will be defined by business process specifications (e.g. BPSS instances).  By using the term intermediary, there is an implication that they do their business and then forward the result to someone else.  There are different ways that the collaborative business process can be modeled to support this.