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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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

Subject: Re: Comments and Suggestions - 0.9a


Regarding service and action:  I haven't read the latest Specification
Schema Specification yet but based on prior discussions, here are my views
on the terms in question:

Service should identify the set of business transactions belonging to one
party, equivalent to one of the action menus in tpaML.  I had the
impression that BusinessTransactionActivity was part of a single Business

Action in the TRP spec was originally intended to identify an action in the
tpaML sense.  As of the Boston F2F, that's a Business Transaction.

        Suggestion: Provide a small inline example for a combination
   > Service/Action element combo.

   That we'll most certainly do!
Let's be sure to keep the TRP and TP specs consistent.



Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com

Christopher Ferris <chris.ferris@east.sun.com> on 01/10/2001 09:25:30 PM

To:   Michael Joya <mike.joya@xmlglobal.com>
cc:   ebxml-transport@lists.ebxml.org, Farrukh Najmi
Subject:  Re: Comments and Suggestions - 0.9a


Thanks for taking the time to review the spec!
Please see my comments/responses below. Your comments will be
formally addressed and tracked separately. My comments are
my own personal views, not necessarily those of the team;-)



Michael Joya wrote:
> lines 496-499:
>     CPAId element: What values go in this element during an anonymous
> query? Before you obtain CPA or CPPs from a registry, you have to be
> able to query the registry. To query the registry, you need a CPAId.
> This circular dependency infers predetermined knowledge before online
> contact. Anonymous messages are the starting point of an important
> bootstrap/discovery process and should be addressed.

I'm not convinced that there is a circular dependency. Nowhere, is it
stated that the only way that a CPP may be accessed is via ebXML MS.
To bootstrap, a registry could advertise it's CPP via any number
of perfectly valid means, such as:
     UDDI registry
     sent around in a "start-up" CDROM

As to the value of the CPAId, we've been discussing this during our
face2face meetings, but have yet to come to a consensus opinion. It is
our objective to do so before we conclude our meetings and reflect this
in the resultant draft of the spec.

It isn't clear to me that there needs to be a definitive scheme for
the value of CPAId. I have always felt that one scheme would be the
UUID (or preferebly, an URI) of the CPA as registered in the ebXML RegRep.
I've been a strong advocate for an URI serving as the value to be used,
such that there is uniqueness of the CPAId. Others have advocated that
the CPAId be merely a unique string with the context of the two
parties... While it is clear that this could be the case, it leaves
things too loosy-goosy for my tastes and provides no guidance or
constraints as to how the uniqueness property is achieved.

Another approach that I've put forth is the notion that the
initiating party determines the value of the CPAId created, scoped
to their domainname (where they can define their own namespace).

Needless to say, I don't believe that it is TR&P's place to constrain or
define the scheme, we can only participate in suggesting appropriate
schemes that might be adopted. RegRep would be the likely candidate
to define a RegRep UUID (or URI) scheme.

>    Suggestion: Predefine an 'anonymous' CPAId to allow for discovery.

This isn't possible, IMHO. A CPA declares the technical details of
EACH party and it defines a specific business process binding to
said technical details. This includes endpoint URIs for the supported
transport protocol, security details such as certificates used for
digitally signing and authentication, etc. that cannot be "annonymized".
A CPA template might be employed, but IMHO, that's what a CPP is.
I think it likely that the Registry will need to provide an alternate
means of obtaining its CPP than via ebXML MS. HTTP URL would seem
the most likely candidate.

> I recommend a text node value of "anonymousQuery" within a CPAId to
> represent a blank-slate CPA for guest users and bootstrap capability.

I'm not sure that I follow. How would you intend this to work?

> You may have reason to use a URI instead. Ideally there should be a
> pre-defined CPP document(s) outlining the required capabilities of a
> client using guest access, but in the absence of a hard CPA schema, a
> placeholder CPAId would do.

Yes, this is closer to where I think that we're headed...

> lines 514-519:
>      Service element: Again, what are the valid range of values. Is this
> range of values ebxml-defined, implementor-defined or
> application-defined? If I wish to use a type attribute instead, what is
> the valid range of arguments to this attribute value?

In an ebXML context, the Service would identify a
(I think that's the current term from BPM) and the Action would identify
the Request or Response (I'm not sure that I have the names of these
The value of the Service and Action should be guided by the CPA that
governs the

My own preference for the value of Service and Action would be an Xpointer
(possibly abstract with an implied context of the CPA identified by the
that "points to" a specific BusinessTransactionActivity in a given BP,
either included within a CPA or referenced through an URI of the BPM.

>     Suggestion: Dictate that all application and/or implementor defined
> services use URIs to ensure global uniqueness. Services that are
> ebxml-defined should have reserved type attribute values, ie:
> type="registry".

If the Service is an URI, the "type" need not be declared as the
default "type" is "uriReference". I fully concur that the value of
Service should be an URI. I strongly recommend that this be adopted
by ebXML for precisely the reasons you cite and many others.

>     Suggestion: Provide a small inline example for a combination
> Service/Action element combo.

That we'll most certainly do!

> lines 661-675:
>     Multihop Transmission 1 example: If I understand this correctly, (A)
> wants to send a message to (C) through (B). (A) does not specify (C)'s
> receiverURI at any point in transmission1. How does (B) obtain (C)'s
> receiverURI? Is it a requirement of the MSH Layer in (B) to map the <To>
> field from the header into a <ReceiverUri> for transmission2? (B) seems
> to obtain this data out of thin air.

ebXML Message Service specification doesn't define how an intermediary
obtains this information. That is strictly implementation dependent.
It would seem to me that an intermediary node in a multi-hop would have
some mapping between the PartyId in the To element and a receiverURI.
Again, how it gets this, and how it achieves this mapping is outside the
scope of the ebXML Message Service specification. Our scope is limited
to enabling intermediary node capability as per the requirements
we identified at the outset of ebXML.

>     I still do not see the overrall value of multihop messaging other
> than for proxy purposes. Is this the only purpose?

It is one, but not the sole purpose. Value-add intermediaries are
another, providing any manner of value-add from reliability/robustness
to businesss value-add.

>     Suggestion: Either dictate where party B should obtain the
> ReceiverURI from (note: this is Not an implementation detail; A and B
> are seperate parties!), or allow A to communicate it to B in
> transmission1.

We haven't and do not plan on addressing directed multiple hops
(where the initiating party prescribes the route to be taken). Nor
will we dictate or constrain an implementation as to how it effects
this manner of mapping (from To to ReceiverURI).

> line 765:
>     default value given for codeContext attribute: There is nothing
> wrong with this line! Hurray for default values!
>     Suggestion: more lines like this!
>     The underlying theme here is that each data element given in the
> specification that does not lend itself to an arbitrary range of values
> SHOULD have at least one of:
>   a) a default value
>   b) an acceptable range, pattern, or 'source' of values to choose from
>   c) a reference to a specification outlining valid values
>      Also helpful would be mention of which role, (ebxml, msh-server,
> msh-client, application-service, application-client) is to validate and
> which is to provide. This is not always clear except for in examples.
> - mikej

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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC