RE: [ebxml-cppa] RE: [ebxml-msg] RE: [ebxml-cppa] RE: [ebxml-msg] HL7 ORG: Fw: Issues with Web services transport

Pim,

 

Excellent level of details and summary.

 

We're also using CPAs internally to facilitate routing - so the
central ebMS receives all in-bound traffic - but then routes the
particular message type to the corresponding internal applications and
their ebMS server for onward processing.

 

Similarly on outbound - it receives the message from the internal
system via ebMS - looks up the partner CPA and then delivers to
that persons endpoint.  This is easily managed using the CPAid
value in the message headers and the action types.

 

This works well when application servers are on separate servers
and need to work with the central firewall and external routing
server(s).

 

DW

"The way to be is to do" - Confucius (551-472
B.C.)

-------- Original Message --------
Subject: RE:
[ebxml-cppa] RE: [ebxml-msg] RE: [ebxml-cppa] RE:
[ebxml-msg] HL7
ORG: Fw: Issues with Web services transport
From: "Pim van der Eijk"
<>
Date: Wed, January 17, 2007
2:41 pm
To: "'David RR Webber (XML)'" <>
Cc:
<>,
<>

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)