RE: XML Gave A War, But Nobody Came

["Rik Drummond" <drummond@onramp.net>]

none of the existing internet transport systems offer "business quality
messaging". the basic functionality for this may be found at bqm.org. the
tr&p group is implementing this functionality more or less. it is a
functionality many large business require to implement ec..... regards, rik

-----Original Message-----
From: owner-ebxml@lists.oasis-open.org
[mailto:owner-ebxml@lists.oasis-open.org]On Behalf Of David Burdett
Sent: Friday, June 02, 2000 1:15 PM
To: lms@wwnet.com; Robert Dakin
Cc: ebXML@lists.oasis-open.org; mel@wwnet.com
Subject: RE: XML Gave A War, But Nobody Came


Just a small addition to what Lisa said, which I agree with by the way.
Specifically, Lisa said:

>>> Strictly from a structure perspective, a message is probably made up of
three components:  Header, Detail and Summary.<<<

We mustn't forget the envelope.

Before you send someone a letter you put it in an envelope and then post it.
What Transport Routing and Packaging group is doing is to design an
electronic envelope in which to put the "message" (we call it a document
rather than a message so we need to sort out our terminology!). We also
specify how an electronic postal system should work so that you know that
your message will get to its destination securely and safely, and if there's
a problem, you're told about it.

IMHO, I really think what ebXML is doing hangs together.

David

-----Original Message-----
From: Lisa M. Shreve [mailto:lms@wwnet.com]
Sent: Friday, June 02, 2000 10:03 AM
To: Robert Dakin
Cc: ebXML@lists.oasis-open.org; mel@wwnet.com
Subject: Re: XML Gave A War, But Nobody Came


Robert,

I'd like to agree with much of what you have said, with some additions.

> >[snipped]
> >
> >Therefore, why not spend our collective efforts on developing a common
> >framework/infrastructure that will support interoperability of any and
all
> >variants? That's much more achievable than developing a single common
> >document format and then getting the world to adopt it.
>
> Having lurked for some time, I am venturing from my bunker to say
> a few words.
>
> I would have thought that he natural OO approach would be  to
> think of a PO (or whatever) as a class and develop a tree of PO's.
> The root of the tree would comprise a common subset of data
> and functionality, and descendent classes would elaborate parent
> classes to satisfy real application contexts.
> Root classes would most naturally belong in Core Components.
>
> I had assumed that an OO approach to EC would include this idea,
> extending to multi-transaction scenarios - but I have
> not seen much evidence of this way of thinking in recent ebXML
> material.  Please correct me if I have missed something.
>
> By exploiting polymorphism and inheritance it should be
> relatively easy to construct software components that handle
> any of a subtree of PO's or whatever and achieve interoperability
> between them.
>

>From the perspective of one person from Core Components PT,

As the Project Team Leader for CC, I'd like to repeat again what we have
been
saying from the start  ... we recognize that the last thing the world needs
is
yet another PO!

That said, what can we do?  Well, we sure know quite a bit about what
doesn't
work!  Independent industry development leads to a proliferation of
incompatible messages, and makes interoperabililty unnecessarily complex &
expensive!  One size fits all business usages [process] and all industries
messages, leads to very large, complex, semanticall vague and very costly
implementations.

OK, what do we do?  Well, we can build a framework, capitalizing on levels
of
stability where we can achieve core object "standardization" and provide an
extention methodology for all the "customization" necessary for real world
implementation.  And, very simply put, what we are doing in Core Components.

How might that look ******* my own personal theory ******

First, our levels of stability, starting on the data side with the core
Message.  That message has two characteristics:  Structure and content.
Strictly from a structure perspective, this message is probably made up of
three components:  Header, Detail and Summary.  Header contains information
that is relevent to the entire message:  Document References and the Role
Players [simple case = requester/responder pair, complex cases involve
agents
and brokers for requester/responder].  The Detail section could have a
variety
of structures:  flat, flat loop, hierarchical loops, etc.  From a content
standpoint, there are a limited number of  conceptual or abstract classes
which
repeat through out messages:  Requester, Responder, goods, packaging,
payment,
etc.  Then, at the lowest level, there are other *stable* core elements,
such
as name, address, quantity, amount, etc.

Now on the process side of the house, clearly there is a core business
process
for PROCUREMENT ... and in that procurement process there are a series of
core
messages, ORDER, ORDER ACK, ORDER CHANGE, ORDER CHANGE ACK, ADVANCE SHIP
NOTICE, etc.  These Core messages, within this business process, probably
have
an abstract description, based on Content abstract classes:  Role Players,
Document References, Goods, Pricing, etc.  What we will find is that there
is
significant content overlap amongst these messages, which is exactly what we
want.

Now, when JOE INDUSTRY wants to build "JOE INDUSTRY PROCUREMENT PROCESS",
they
start with the CORE Procurement business process, and then begin to subclass
the process [using the meta model as a guide], and those messages such as
the
Core ORDER message, and for each high level abstract class, given the set of
stable low level core elements, each industry can build the industry
specific
components such as Joe Industry Goods descriptions.  Some abstract elements
of
the message should not be industry specific, such as payment details, which
may
occur in multiple formats, but not as many as one for each industry.

Next, context.  Based on some handful [small number] of contextual clues
[business process, industry, etc.] combined with an organization scheme, one
can predict [deterministic] which Goods descriptions, Requester/Responder
descriptions, etc., apply to any specific message object.

What do we have now, 1) an architecture which supports industry specific
needs,
2) an infrastructure which encourages reuse, 3) concise messages which do
not
depend on additional "implementation guides", 4) reusable components, at a
variety of levels, which are semantically consistent [one way to say one
thing], and 5) extensibility which facilitates the reuse process with a
mechanism to add to or reduce existing sub-components.  Obviously, having a
registry/repository which facilitates sharing, reuse, and organization will
be
of tremendous value!

On the subject of how this aids the SME, I hope the answer is obvious ...
one
way to say one semantic thing, concise messages, and an infrastructure for
organization, etc., aid application developers to incorporate ecommerce into
applications ... shrink wapped solutions become feasable.

I doubt that anything that is done in ebXML can impact the ability to "duct
tape" ebXML to legacy systems, however, the very same qualities that make
shrinkwrapped applications feasible, result in the availablility of
semantically stable middleware that can be "duct taped" to legacy
applications.

Regardless of the level of technological sophistication, in the end we all
depend on implementors/industries/standards developers to assume a mentality
of
compliance, and recognize the cost of non-conformance to the community at
large.  Standards built need to be considered a "neutral" representation,
not
an image in existing internal systems.  As long as we can concatenate,
parse,
cross reference, bridge, etc., to and from the standard without violating
semantic integrity, there should never be a reason to modify the core.

All this said, this is one persons vision.  Until the project teams are
allowed
to complete their work, we won't be able to determine if this theory of
"stability points" is any better than other guesses.  So, I'd like to
propose
that we call an end to this theoretical discussion, until technical research
tells us how we put the pieces together to solve this problem.

I have tried to put this in business terms, and have tried to stay away from
jargon, but if this message needs to be made clearer, I propose that this
discussion be taken over by marketing, and moved to the marketing and
awareness
project team.

Thank you,

lms


=======================================================================
= This is ebXML, the general mailing list for the ebXML committee     =
= The owner of this list is owner-ebxml@oasis-open.org                =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml                                              =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml myname@company.com                           =
=======================================================================