Re: FW: Conversations, or BP alignment with TR&P and Architecture

[Duane Nickull <duane@xmlglobal.com>]

"Frank G. Pitt" wrote:

>>That's all very well, but if ebXML does not define some semantics, and a

> protocol, or at least a message format, specifically for operations involved
> in maintaining state and audit trails, we'd better hope that its not core
> functionality of the architecture, as these functions will almost certainly
> not be interoperable between implementations.>>

That is not what the core competency of ebXML does.  Please read the Technical
Architecture Draft specification. (lates version 0.6 - 0.7 pending)

> <SNI>Part of creating an architecture is validating that the architecture will
>
> work for the core functionality. This may mean more than just carrying out
> design of an example application, it may involve deep prototypes as
> well.</SNIP>

Agreed.  I have been pushing for this since day one.

> If maintaining state and audit trails are core functionality, then these
> should be validated by designs and implementations that work within the
> defined architecture, before the architecture is stabilized.

Maintaining state with a transaction has been mentioned, abliet briefly, in the
ebXML requirementts document.  It is very easy to archive messages and be able
to return state.  Once again,   BPM will mandate a state function for it's
business use case scenarios.  Technical Architecture is primarily concerned with
the "meat and potatos" or interoperability and being able to dynamically
decompose a message.

> <SNIP>Don't fall into the trap of thinking that low level implementations are
> necessarily not part of an architecture.</SNIP>

Don;t worry - we won't.  I plan on building a working app.

> > The layer we are focused on right now is the data element layer.
> > The transactional layer is built upon that.  i.e. - for the process
> > "Purchase Order",  there may be 5 messages required.
>
> It's fine to focus on data for the moment, but I'd argue that process
> semantics are more important in a system such as this that is supposed to be
> dynamic.
>
> Data is data, as long as we have a format for transporting it and
> structuring it ( which we have in XML ), that's all we need as far as data
> is concerned. To be frank, you can implement B2B XML data transfer without
> the overhead of an ebXML repository or registry. All you need is a web
> server and the existing XML usage of URI's for discovering DTD's & Schemas.

Not at all.   If you want to be able to dynamically accept and act on data from
ad hoc trading partners who are using XML vocabularies you are not familiar
with,  simply using XML is not enough.  The process semantics are just a
important but they need to be built over a layer that can understand the data
objects.   On other words,  we can;t say "A Purchase Order requires "A" + "B" +
"C" when we don't have the underlying mechanism to recognize "A" + "B" + "C".
Both are core!

> <SNIP>Repositories and registries are basically "nice to have", but
> fundamentally
> unnecessary for B2B data transfer via XML.</SNIP>

Not in ebXML.   Agreed they are not necessary when you know and have agreed on a
common vocabulary.   When you don;t have that prior agreement,  they are one way
to reference objects and object groupings ;-)

Please read the Tech Arch Spec.  I would invite your input into our spec.   Are
you palnning on attendin the ebXML in August in SF?

Duane Nickull



=======================================================================
= This is ebxml-architecture, the general mailing list for the ebXML  =
= Architecture project team. The owner of this list is                =
= owner-ebxml-architecture@oasis-open.org                             =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-architecture                                 =
= 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-architecture myname@company.com              =
=======================================================================