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)
