>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)
