Re: prototype proposal update

[Christopher Ferris <chris.ferris@East.Sun.COM>]

Some comments below.

Cheers,

Chris

srh@us.ibm.com wrote:
> 
> Nick, good job on the demo doc.
> Here are some quick points:
> 

<snip/>

> 
> Industry (verticals, but a better term) Migration points to an ebXML
> Transport Infrastructure:
> 
> 1) Industries would drop any industry-defined message type, such as that
> indicated
> by the "RQ" at the end of the original OTA <v1.CustProfileUpdateRQ> tag,
> and
> express this in the ebXML MessageType element. Note that OTA maintains
> using it's industry-specific approach to versioning the OTA intention.

Yuch! Possibly, something we would need to consider as 
a value-add of ebXML is a specific versioning scheme
which makes sense (possibly, from the Architecture
or Core WG). Explore the potential maintenance
nightmare which would (IMO) be caused by a versioning
of the OTA vocabulary. One would have to update reams of code
to consume a v2.Xxxx because all of the $%^&^%$ tag names
have changed! Yikes, that sounds like built-in/hidden future 
consulting fees if I ever did see such a thing;-)

NB. that SOAP v1.1 doesn't address versioning either
other than to stipulate that if the namespace is not
as specified, it must be a different version;-)

Our work should incorporate as an architectural
principal the inevitability of subsequent versions
and a migration strategy from one to the next with
minimal impact on systems implementing a predecessor.

> 2) Industries would load the ebXML payload with the remaining industry
> content. This
> would mean dropping any industry-defined 'method or intention' and message
> type, such as the
> OTA <v1.CustProfileUpdateRQ> tag since this is to be defined in the ebXML
> header.

Possibly, but not necessarily. Again, this seems a rather
contrived approach to encoding intent. Does OTA parse
the tag value for the appended 'RQ' to drive certain
processing behavior? Wouldn't a specific element or
attribute have been more convenient?

> 3) Other infrastructure information accomodated by the ebXML Transport
> level defined
> by an industry such as the TimeStamp attribute
> from the original OTA top document element.........
> <OTA_v1 Timestamp="2000-04-25 12:54:55.0" EchoToken="228722"
> Target="Production" GeoCode="+4256-1482">
> should be removed (given the same semantic as the ebXML Transport) and
> expressed
> into the ebXML Transport headers. The OTA EchoToken is in the same
> situation
> because we can accomodate this in ebXML with the MID field that expresses
> the
> associated message Note we are not showing these in the demo.

I never would have guessed that EchoToken represented
a MessageID;-)

> 4) An Industry may need to maintain information important to the industry
> once
> defined in perhaps a top industry root element with in ebXML payload. The
> examples
> in the case of OTA are the the GeoCode and Target attributes on the
> original OTA_v1 top tag.
> These are now expressed within *what has now become the OTA payload top
> tag* :
> <OTA_v1 Target="Production" GeoCode="+4256-1482">.
> Note that the TimeStamp and EchoToken are removed since the ebXML Transport
> supports
> the same semantics.

I was looking at RosettaNet again which also has an element
in its preamble header indicating the mode (test/production):

	<GlobalUsageCode>	

I think that we should support this directly in the ebXML
message headers as well. It would serve the purpose for 
enabling a test of an exchange between partners to ensure
compatibility, etc.

> 
> A prime selling point that is evident in the demo of the ebXML Transport
> (not complete for all of ebXML):
> 
> + The ebXML Transport level provides a cross-industry approach for defining
> infrastructure
> constructs commonly defined by, or being defined by, industry-specific
> efforts. The ebXML
> Transport can free industry-level efforts from addressing
> infrastructure-level constructs for
> needed for commercial-level messaging.

Precisely! This is the message which ebXML Marketing should
be repeating ad-nauseum to anyone who will listen. Of course,
we need to make it a reality (or close to it) so that the
various verticals will adopt it as their own. We need
to be able to demonstrate that we're on track to deliver
something within the timeframes they require (yesterday).

> 
> Nick, I can speek to the detail in Brussels if needed.
> 
> Scott R. Hinkelman
> Senior Software Engineer
> XML/Java Solutions/Standards
> Architecture and Development
> IBM Austin
> Office: 512-823-8097 TieLine: 793-8097
> Home: 512-930-5675, Cell: 512-940-0519
> srh@us.ibm.com
> Fax: 512-838-1074