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)
