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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml message

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


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



[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