[OASIS Issue Tracker] (EBXMLMSG-48) P-Mode search recommendation

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://tools.oasis-open.org/issues/browse/EBXMLMSG-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36932#comment-36932 ] 

Pim van der Eijk commented on EBXMLMSG-48:
------------------------------------------

Below is some information on how I have approached the equivalent of this in ebMS2,  and some discussion on how this could be mapped to ebMS3.

In ebMS2 in combination with CPA2, it was possible to find "action bindings" (the counterpart of PModes) using a look-up table based on:

<FromPartyID, FromPartyIDType, ToPartyID, ToPartyIDType, Service, ServiceType, Action, CPAId>

I can't remember if CPA2 required this lookup table to return a single action binding (I think it doesn't),  but in my practical experience this is a common (and quite reasonable) assumption, that is assumed in some ebMS3/CPA2 library code that I've implemented and has been used in production for years. 

Some of the type values are optional,  so the table should have special values for actions and messages that don't have them.

A CPA2 action binding has an identifier attribute, which is equivalent to the "pmode" attribute.  But in ebMS2, this identifier was never included in messages (unlike ebMS3 where the "pmode" attribute is optional).  

A CPA2 CPAId is always present in ebMS2 messages. CPAId is equivalent to AgreementRef.  Unlike CPAId in ebMS3, in ebMS3 AgreementRef is optional.  Unlike ebMS2,  ebMS3 has an optional "type" attribute on AgreementRef.

So for ebMS3,  we could have a lookup of PModes based on:

<FromPartyID, FromPartyIDType, ToPartyID, ToPartyIDType, Service, ServiceType, Action, AgreementRef, AgreementRefType, Pmode>

As with CPA2, we could require this to always return a single Pmode.  If the value of Pmode is unique in a set of configured Pmode, the lookup could be simpler and based on:

<PMode>

If the message does not have a Pmode,  we could do a lookup based on:

<FromPartyID, FromPartyIDType, ToPartyID, ToPartyIDType, Service, ServiceType, Action, AgreementRef, AgreementRefType>

This could match a PMode that has a pmode identifier, but where this value is not shared between sender and receiver.  So this would be more like a wildcard search.  I think it is very reasonable to require this search to return just a single Pmode.

If there is no AgreementRef, the lookup could be based on 

<FromPartyID, FromPartyIDType, ToPartyID, ToPartyIDType, Service, ServiceType, Action>

Again,  I think it is reasonable to require this to return just a single PMode.    If there are multiple agreements for the same set of tuple, the sending MSH should include the agreementref to disambiguate.

It gets complicated because ebMS3 Core, appendix D, talks about "optional" PMode parameters, such as PMode.Initiator.Party.  A related complication is that some products may have ways to dynamically infer PModes.






> P-Mode search recommendation
> ----------------------------
>
>                 Key: EBXMLMSG-48
>                 URL: https://tools.oasis-open.org/issues/browse/EBXMLMSG-48
>             Project: OASIS ebXML Messaging Services TC
>          Issue Type: Improvement
>          Components: Core Spec
>            Reporter: Theo Kramer
>
> P-Mode search is not defined and different systems may behave differently
> As an example P-Modes may be identified in multiple ways. Eg.
> 1  Using the @pmode in the agreementref - although optional this imo is the most simple approach
> 2  combination of to/from/service/action - this would fail on mismatch and would return EBMS:0010.
> 3  combination of to/from/agreementref - ditto
> 4  Just agreementref
> 5   combination of from/MPC for pulls
> and finally
> 6   just MPC for pulls



--
This message was sent by Atlassian JIRA
(v6.1.1#6155)