Hello,
Some thoughts on intermediaries.
The CPA is about configurations for business partners,
so there should be CPAs with "intermediaries" if those are organization that
provide added business semantic value, i.e. if they are business
partners. Examples: market places or publish-subscribe services
(such as the emergency management TC is defining in the CAP protocol).
This could be expressed by an ebBP multiparty
business collaboration involving (at least) three partner
roles and (at least) two sets of BTAs and (at least) two corresponding
CPAs. The intermediary has a PartyId. From the ebMS point of view this
is not different from a peer-to-peer connection. The CPAs would
also be regular CPAs. No additional functionality to be standardized or
supported in products.
If an intermediary has some technical function value
only, it is not a party in any business sense. There would be no role for
the intermediary at ebBP level. Examples: simple store-and-forward
re-routing intermediaries or for supporting functions like logging, time
stamping or ebBP choreography observer intermediaries. Perhaps also
technical functions like encrypting, signing/sealing. At least some of
these intermediaries would need to have at least some understanding of ebXML
headers (beyond SOAP intermediaries or HTTP proxies).
EbXML technical intermediaries would not need to
have any PartyId. There would need to be an end-to-end CPA for each flow,
but all the next-hop related features (URL, TLS client
and server certificates) are determined by the intermediary rather than the
partner. Commercial-off-the-shelf ebMS 2.0 products that support CPA
2.0 can be "tricked" to support this model today and easily if both partners
load slightly different CPAs (with these next-hop parameters of the trading
partner replaced by the parameters of the intermediary).
The (technical) intermediary needs to know, minimally,
for each connected partner, how to map the PartyID to a URL and its transport
security features. In CPA, different actions (from different partners, CPAIds)
can be mapped to different URLs and even different security features such as
certificates. A reasonable simplification for the technical intermediary
seems to be to use a single URL and transport certificates for all
traffic from the intermediary. There are various commercial and
custom ebXML Messaging v2.0 products that support this model today in production
systems.
How should the intermediary handle reliability
and SyncReplyMode?
For reliability, it could:
- never supply ebMS2 nextMSH acknowledgments (the
simplest one), and pass through any acknowledgments coming (ultimately) from the
true recipient; or
- always supply them if requested (requires a bit more
ebMS functionality but not much); or
- allow configuration whether or not to
expect/supply them based on From/PartyID, CPAId, To/PartyId, Service/Action.
For SyncReplyMode, it could:
- assume all messaging is asynchronous, so it can
always close any connection after storing the incoming message for
transmission;
- be configurable to be either asynchronous or
synchronous, for acknowledgments, signals and/or responses, based on
From/PartyID, CPAId, To/PartyId, Service/Action. It this case it would need to
know how long to keep connections open and have more complex error
handling.
In both cases, all options other than the
first requires a configuration mechanisms potentially as complex as CPA
(for all pairs of trading partners and other intermediaries using the
intermediary). At least my experience suggests it is reasonable to
simplify this to the simplest solution. Again, there are various products
that support this today.
To summarize, with technical (non-business partner)
intermediaries regular CPAs can be used end-to-end, except that their "next
hop" related information needs to be tweaked to support the intermediary.
CPA could introduce a native "intermediary" concept, but the business case is
not very strong. Intermediary configuration can be (and is) simplified to
quite simple mechanisms that are only dependent on connected trading partner,
not on the ultimate partner or business process related
parameters.
Pim
N.B. The above uses some ebMS2/CPA2 jargon for
SyncReplyMode which may or may not map to
ebMS3.
Pim van der Eijk
OASIS European
Representative
Email:
Mobile: +31 6
22502011
OASIS Symposium:
"eBusiness and Open Standards:
Understanding the Facts, Fiction, and
Future"
15-18 April 2007 San Diego, CA USA
http://www.oasis-open.org/events/symposium/
From: David RR Webber (XML)
[mailto:]
Sent: 17 January 2007 15:52
To:
Durand,Jacques R.
Cc: ; Dale Moberg;
Subject: [ebxml-cppa] RE: [ebxml-msg]
RE: [ebxml-cppa] RE: [ebxml-msg] HL7 ORG: Fw: Issues with Web services
transport
Dale / Jacques,
Yes - this is all good.
I did look at the original postings and outcomes from Chris' Ferris
deliberations on all this back in 2000/2001 - and the issue with encrypted
payloads with digital signatures.
So the v2.x does have some support for intermediary delivery by using the
CPA - and what I'm suggesting is a very simple base case - with limited
handling derived from the partner ID and message type checking only - and then
onward routing to explicit endpoint ports accordingly. So the intermediary
can acts as an aggregator - and then drop deliver to exact locations based on
ID/type and the CPA between the aggregator and the external partner.
Anyway - this all sounds encouraging. What I'll do is report back and
ask them to review the deliberations to this point - and then we can look at
specific use cases with them and review those together. Seems like we
should be able to provide a base implementation model to handle 80:20 processing
for them to at least get started.
Thanks, DW
"The way to be is to do" - Confucius (551-472
B.C.)
--------
Original Message --------
Subject: [ebxml-msg] RE: [ebxml-cppa] RE:
[ebxml-msg] HL7 ORG: Fw:
Issues with Web services transport
From:
"Durand, Jacques R." <>
Date: Tue, January 16,
2007 11:44 pm
To: "Dale Moberg" <>,
<>,
<>
Cc:
<>
>Jacques’s case can be construed as a
termination of the ebMS message and then followed by an internal integration
using SOAP. This
>functionality is add-on functionality of a
MSH (which is almost always found in real implementations of a
MSH).
Right - this is a case of an "ultimate MSH" still
acting as SOAP intermediary when there are other SOAP nodes behind that are
not supposed to understand ebMS (e.g. WS endpoints). So still a simple
case w/r to CPA (no MSH intermediary per say) as I guess the CPA would not
apply to these ultimate SOAP nodes (correct me,
Dale)
I have not mentioned the other way to deal with the
HL7 application-level intermediation, which is to use an MSH as intermediary
forwarding to another MSH. We are gathering reqs for these scenarios which
clearly will lead to introducing a new messaging role (not in core V3) in the
messaging model - e.g. "intermediating" in addition to sending and receiving.
It appears that a CPA would be needed for such an
intermediary.
Jacques
From: Dale Moberg
[mailto:]
Sent: Tuesday, January 16, 2007 7:56
PM
To: ; Durand, Jacques R.;
Cc:
Subject: RE: [ebxml-cppa] RE:
[ebxml-msg] HL7 ORG: Fw: Issues with Web services
transport
Hi
David,
If the forwarding and
routing amount to distinct ebXML conversations, then the situation is really
two ebXML messages between two pairs of participants, call them A and B and B
and C. Then CPAs exist for each of the two
conversations.
If there are
additional requirements (such as A’s signature has to be transferred to C),
then WSS would allow a lot of new combinations in ebMS 3 that are not
mentioned in ebMS 2.0. But CPP/CPA are still between the source and
destination parties of an ebMS messaging
conversation.
So far ebMS 3.0 has
not specified exactly what to do with SOAP intermediaries. Nor is there
agreement as to whether there is a need for ebXML intermediaries with
distinctive behavior. You can always have SOAP intermediaries, but it is not
clear that there will be specific ebMS MEPs involving them. I think we have
some proposed requirements to consider in this area but we have deferred
consideration until we get some core ebMS 3.0 profiles
completed.
Jacques’s case can be
construed as a termination of the ebMS message and then followed by an
internal integration using SOAP. This functionality is add-on functionality of
a MSH (which is almost always found in real implementations of a
MSH).
Dale
From: David
RR Webber [mailto:]
Sent: Tuesday, January 16, 2007 7:23
PM
To: 'Durand, Jacques R.';
Cc:
Subject: [ebxml-cppa] RE: [ebxml-msg] HL7
ORG: Fw: Issues with Web services
transport
Jacques,
This most
helpful. I believe your answers goes a long way to addressing this for
IHE/XDS.
One further
question before I forward this to them.
At NIH we are
using multiple CPAs in situations where forwarding and routing is occurring –
therefore – the intermediary has a CPA in place between the originator and
themselves as well as the CPA between the recipient and NIH. Clearly
this allows for additional controls and aspects about the transport to be
contained in these additional CPA(s) and then accessed by CPAid in the
envelope.
Does this
potentially offer additional configuration options for the intermediary?
My sense is probably “Yes”?
Thanks,
DW
From:
Durand, Jacques R. [mailto:]
Sent: Tuesday, January 16, 2007 4:53
PM
To: David RR Webber (XML);
Cc:
Subject: RE: [ebxml-msg] HL7 ORG: Fw:
Issues with Web services transport
The document is
interesting as it clearly raises the issue of application-level intermediation
(contrasting the "service application" with the "worker applications"), for
which the SOAP model is only a foundation - and a simplistic one w/r to
routing - yet one that should be leveraged.
It shows the need to
represent and process differently what we could call "application
meta-data" and application data, the former being intended for the
intermediary (more horizontal SOAP headers, e.g. WSA, are probably too
low-level here).
An analogy could
be the use of "topics" in the publish-subscribe
model.
> Does anything in ebMS V3.0
mitigate this?
So I'd say that ebMS3
does (much) better than ebMS2 on this. Both distinguish app meta-data in form
of business header elements - including payload manifest - distinct from
payload parts, helping an (unspecified) forwarding function. But when
the "worker application" is wrapped as a Web service deployed on the
back-end (as it typically would in an SOA model) the ebMS V3 model is much
friendlier to the needed conversion into a service invocation: in V3 the ebMS
header being just a SOAP header bloc like any, and leaving the SOAP body free
for business payload, can be stripped from the SOAP message by the MSH acting
as intermediary. What remains can just be a plain Web service invocation,
ready as is to forward (you would never guess it has been an ebMS message...).
We have prototyped this at Fujitsu. One issue with ebMS2 is the SOAP body used
by the ebMS header, forcing payloads in attachments, and hard to deal
with when using end-to-end security (with V3, you could even have
security headers that the MSH would not touch,if intended to ultimate
destination - V3 Part 2 will be more explicit on this).
The paper also makes
a very sound observation regarding cases where the application needs to know
authentication credentials as context to its processing ("is this request to
this service allowed for this type of client?"). You typically want to deal
with this before the request hits the application service or server
supporting it, yet this kind of application-level authorization (which is
closer to access control) is out of infrastructure scope in the
current Web service security model (WS-Security) - and current WSS
implementations do not seem to facilitate this. Clearly the application-level
intermediation pattern is key to supporting this. I believe a decent support
has been proposed in V3 in the "message authorization" section which still
leverages WS-Security as much as possible.
Jacques
From: David
RR Webber (XML) [mailto:]
Sent: Thursday, January 11, 2007 7:51
AM
To: ebxml-cppa
Cc:
Subject: [ebxml-msg] HL7 ORG: Fw: Issues
with Web services transport
Importance:
High
Does
ebXML CPA address some of these issues? I believe it
might.
Could
CPA's between participants provide the missing information - or enough for
common uses?
Does
anything in ebMS V3.0 mitigate this?
I also
think that the idea we've been working on in BCM/ebSOA/BP of a pan-ebxml
context mechanism - could also be a next peice - so a shared context could be
retained across participants - that summarizes the salient information needed
to deliver correctly.
Please
let me know so I can reply back the HL7 list with our
considerations?
I'm
seeing this notion of an Uber-WS infrastructure gaining ground - so you call
that Uber-API - and then delivery occurs in the dialect for a
partner.
Of
course I beleive ebXML provides a B2B superset here that plain WSDL clearly is
not able to match.
Thanks,
DW
"The way to be is to do" - Confucius (551-472
B.C.)
To:
************************************************
To access the Archives of this or other lists or change
your list settings and information, go to: http:
//www.hl7.org/listservice(See attached file: Issues with Web Services as a
Message Transport Dec 11 2006 R1.pdf)
