OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: MSG and CPPA modularity and the SyncReply issue


Yes, Dale, I agree with everything you said.  But this does not answer how we
can have different messages over the same transport (HTTP?) to the same address
where some are async and some are sync.  What you describe is a default
behavior.  If I normally send sync, how can I change and send large files async?
I guess we can ignore this use case if no one else thinks this is valid.  This
functionality was important recently on AS2-EDIINT.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Tuesday, August 21, 2001 6:53 PM
To: David Fischer; Martin W Sachs
Cc: ebXML Msg; ebxml-cppa@lists.oasis-open.org
Subject: MSG and CPPA modularity and the SyncReply issue



David Fischer says:

"How can SyncReply be used without a CPA?"

Dale Moberg replies:

Using CPPs and CPAs pertains to a way of
publishing, discovering, negotiating and
exchanging information for setting up
BP collaborations. The contents of these
infosets are determined
by what parameters should be publicized,
and what parameters need values settled,
in order to implement a given BP among the
participants.

The MSG spec contains assumptions about what
a MSH needs to have in the way of configuration
information for its interface with the other
participants for given BPs. These include
security parameters, URLs, and so on. These
assumptions are part of the MSG spec, not the
CPPA spec. (Of course, the CPPA spec
pays special attention to assumptions about
these elements so that it will at least be
able to facilitate exchange of values agreed
upon for these for given participants in a given
BP.)

Now just as you don't have headers about
what signature algorithm (RSA-SHA1 for example)
is to be used by 2 participants for a PO PO-ACK
conversation, you don't necessarily need to have
a header saying that the participants conduct
this BP using SOAP with attachments over HTTP,
and the response comes back on the same connection
as the request is sent. Just because a MSG implementation
may not export, import, or negotiate CPPs and CPAs,
does not mean that the information that would have been in
the CPA has to be in the header!

We need to understand why it needs to be in the header,
when it suffices that the MSH track, for a given
receiver, sender, and BP, what transport and security
and packaging options are to be applied. I think
that you must concede that there will be such information
the MSH "knows" and makes use of, so the issue is
why the SyncReply info cannot be part of this configuration
knowledge and instead needs to be repeated over and over
in each header of messages exchanged between receiver
and sender...


David continues:
"I know of several in-work implementations and I don't know of any which
are
implementing CPPA (I'm sure someone out there must be).  This does not
mean they
won't.  CPPA is generally seen as a second level of implementation over
Messaging.  Messaging is the base.  Once Messaging is in place, then we
add
CPPA, Registries, etc.  We have to support non-CPA implementations -- at
least
for now.  (One vendor actually suggested leaving CPAid blank for now
since it is
not needed -- except that the Schema specifies non-empty-string ;-)"


Fine, just make certain that when they
build a MSH that they have a place
to "look up" the transport and security details for
their response that is needed to service the request
part of the received BP.
They can look this up using any index/key
they wish to use, and
are not required to use CPAId as either
index or primary key.
And while they are looking up those details,
please ask them to check whether a synchronous
mode of reply is there in the details or whether
a URI for asynch is there instead!!

That is how SyncReply can be done without a CPA!



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC