Re: Comments and Suggestions - 0.9a

[Christopher Ferris <chris.ferris@east.sun.com>]

Marty,

Please see below.

Cheers,

Chris

Martin W Sachs wrote:
> 
> Chris
> 
> 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
> Transaction.

I believe that these represent the same concept. I could be mistaken...

> 
> 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.

Of that, I'm not so certain. We should review these thoughts with the BPM
team.

> 
> Regarding:
>         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.

Yes indeed!

> 
> Regards,
> Marty
> 
> *************************************************************************************
> 
> 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
>       <Farrukh.Najmi@east.sun.com>
> Subject:  Re: Comments and Suggestions - 0.9a
> 
> Michael,
> 
> 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;-)
> 
> Cheers,
> 
> Chris
> 
> 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
>      HTTP URL
>      sent around in a "start-up" CDROM
>      whatever...
> 
> 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
> BusinessTransactionActivity
> (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
> correct).
> The value of the Service and Action should be guided by the CPA that
> governs the
> message.
> 
> 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
> CPAId)
> 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
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;One Network Drive;Burlington;Ma;01803-0903;USA
version:2.1
email;internet:chris.ferris@east.sun.com
title:Senior Staff Engineer
fn:Christopher Ferris
end:vcard