Jacques noted a need for
accomodating
3- Header fields: ebMS header mapping or
profiling of AS2 headers & system identifiers (AS-From...)
Tim mentioned one
approach:
For endpoint resolution (AS-To, AS-From, MessageId,
etc), was thinking along the lines of what WS-Addressing provides, and honestly
I'm not sure how ebMS 3.0 incorporates WS-Addressing
AS4-To
AS4-From
and so on could be HTTP
entity headers as in AS2. (But that is not in the spirit of WS-* in that
message metadata foi them is to be scrunched into the message bodyparts in
various ways. ebMS follows this pattern.)
I don’t think that
WS-Addressing is relevant for AS4 identifiers, however. These party identifiers
are logical identifiers of parties by values such as DUNS numbers that are used
in the X12 EDI world, for example. Corresponding WS-Addressing values tend to be
EPRs (or just URIs, er, IRIs).
If these Froms and Tos
were mapped into what is available in ebMS 3, however, I would say
that
AS4-To corresponds to
the ebMS To field
AS4-To corresponds to
the ebMS From field.
<JD> more precisely,
eb:To/eb:PartyId and eb:From/eb:PartyId. (if AS4-To maps to eb:To, that means it maps to a complex element like
partyid+role . I guess could be done using composed AS2-name -
e.g. a quoted name of the form "partyId role").
Service, Action, and
Role correspond with no current metadata values in the EDIINT AS1 2 3
versions.
Message-ID Need
to consider what that is used for. RM functionality (like duplicate checking) or
MDN/NRReceipt functionality.
Conversation-Id in ebMS
has no corresponding value in EDIINT AS1,2,3.
AS4-Version etc. also
will need some discussion.