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

["Frank G. Pitt" <frankp@softed.com>]

OK, I may be getting the wrong idea of what ebXML is supposed to be used for
here, so I apologize if I'm completely missing the point, or if I'm tramping
on anyone's toes, but from my point of view as a consultant working in this
field and a professional educator who trains architects...

> > The BP metamodel assumes the need for long-running
> > conversations.  So does TR&P, and (maybe) Architecture.
> > However, the responsibility for defining the software
> > that manages these conversations is not clear.
>
> This is within the scope of software vendor architect.
> maintaining state (and an audit trail) are both mandated by
> tech Arch.  It is core functionality for an ebXML application.
> We are not designing the application at this time.

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.

"We need to maintain state and have audit trails", even with use cases, is a
user-level requirement, for determining conformance we need more.

> > ebXML TR&P specifies in diagrams an Integration System
> > where Business Rules and Document Choreography from
> > Business Process Modeling are supposed to take place.
> > However, this Integration System is then declared out-of-scope
> > for TR&P.
>
> Again - we are not designing the software.  Just the ebXML
> specification.  An SV will then look at possible use
> case scenarios that it must comply with in order to be ebXML
> compliant and build the app.

A use case is far too high a level for determining conformance.

I agree an actual design or implementation may be too low a level for
defining compliance(though reference implementations are a good part of any
standard as well). But there needs to be more than just use cases.

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.

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.

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

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

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

As you say, the core functionality is transaction processing and audit
trails, and they are not data elements, but processes.

> We will provide the architecture for constructing
> these messages (TRP) and the architecture for
> referencing repository objects (Tech arch/reg rep) and the
> business methods that dictate the necessity for each
> message (BPM),  but we do not specify what mechanism must be used
> to maintain state and archiving of these messages.

No, but you _should_ be specifying the mechanism used to _query_ state, and
_retrieve_ messages from archives.

Otherwise, what necessary function is ebXML performing that will make people
want to use it?

As I said, you don't need registries & repositories to use XML in B2B data
transfers, so that's not a driver.

For ebXML to be at all useful it needs to define things such as the means
used to determine if a particular message is part of a long transaction,
what part of the sequence it is in, how a long transaction is able to
determine it's current state, etc.

> The SV's can implement that at point of deployment.
> This is because there are several different models
> for ebXML adoption.  Not everyone will have their own ebXML app.
> Some may use an ASP type model for all their
> invoicing only (partial adoption).

Whether you need a long transaction or not is not really the point, the
point is interoperability. It's just that long transactions need more
support to ensure interoperability.

Take two vendors who both support long transactions, how do you guarantee
that any particular ebXML-conformant long transaction will work on either
vendors system ?

For that matter, how do you guarantee that a single, atomic transaction will
work on either system ?

_That's_ where we need the standards.

The data format problem is already solved by XML itself, what ebXML  needs
is a means of specifying interoperability in the transactional layer,
otherwise it's pointless, as raw XML streams and EJB's will provide a better
chance of interoperability.

Perhaps ebXML is not supposed to be designed for this purpose but I was
kinda hoping it was.

If you've already covered all this in a document somewhere I haven't seen
yet, or ebXML is not meant to handle all this, I apologize for the waste of
bandwidth.

Frankie


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