RE: ebXML metamodel write-up

[Bob Haugen <linkage@interaccess.com>]

Christian,

Thank you for your expansive reply.  I am continuing, although
you said you could not reply before San Jose, because these
are important issues and maybe others will chime in.

Christian Huemer wrote:

>> What would "consistent results" mean across all scenarios?

>so in order that a software can query company x's model in the repository,
>it must be ensured that the software gets what it expects in the repository.
>this means that company x's model must be conform to the meta model (and
>not only to a part of the meta model). to ensure that the model is a valid
>instance of the meta model, i prefer a methodology which tells me exactly
>how to create valid artifacts (or instances to the meta model).

In order to do that, it would be necessary to constrain artifacts
a great deal more than TMWG N90 does.  The Edifecs metamodel
that was presented at TMWG by Jim Clark goes a lot deeper,
especially in the Patterns section.  If those get accepted by
TMWG and are available to ebXML-BP, they will help a lot.
If this is what you mean (that the current metamodel must
be developed much more deeply, and patterns and templates
created to guide modelers) then I fully agree.

>bp team was created to ensure that the business processes to be stored
>in the repository follow an agreed methodology leading to consistent 
>results. this methodology should start from understanding the business
>domain, over the requirements definition to a design that could be used
>by software developers for creating shrink-wrapped software. 
>this is why tmwg has chosen to customize the rational unified process to use
>a methodology which uses UML as language throughout the process and is
>therefore easier to go from one step to the next. 

I have no problem with what TMWG did, but it is not nearly constrained
enough to produce consistent software designs for business collaboration.
As I said, Jim Clark's presentation started down the right path, in my
opinion.

>what i see so far in ebxml bp team is that this team mainly concentrates
>on the business processes (without the data). the data part is left
>to the cc team. this reminds me of good old edi. bp modeling should
>guarantee that all the necessary data structures for the communication
>are detected. therefore, we prefer oo-technology.

I prefer oo-technology, too, but we are collaborating with the cc team
and I think that our work will converge nicely.

>> And what methodology is proven to give consistent results for all
>> scenarios under any conditions?
 
>this methodology should be identified by bp team ...

I think it needs to be a collaboration of bp and cc teams.
Some of this collaboration should start to emerge in San Jose.
This is a big job.  I watched the TMWG modelers, all experts,
take the better part of two days revising a simple model
that they had designed before. 

I don't think consistency will be possible without conformance
tests, plus reusable patterns of all sizes, plus reusable components, 
plus metamodel, plus methodology.  And they all need to be
consistent with each other, and of course everything started
in parallel.  The more TMWG and ebXML can adopt from Edifecs 
and other similar sources, the faster we can go.

>> I am not trying to defend the perfection of the BP metamodel
>> here, just trying to get you to ground your statements.  I was
>> involved in the discussions that gave rise to Karsten's statements 
>> about selectively using parts (but not all) of the metamodel.

>sorry, i have really a problem when splitting the meta model and allowing
>to instantiate only a part of the meta model. bob, i understand that
>REA can help me in identifying the high-level business processes. but
>what does it help to the over all goal, if i only instantiate the REA
>relevant parts of the meta model. so what i want bp team to show how
>e.g. REA contributes to the overall goal. how is the knowledge gained
>from following the REA methodology used/transformed in a design phase.

REA is not a methodology - some parts of the REA ontology are
included in the Resources and Contracts package of the BP metamodel.
When I think of using parts of the metamodel as a software developer
designing software to be used with ebXML, I would not start with the 
REA elements.  

Starting from the simplest to the most complex:
1. Sending a simple document: either use a pre-defined document
    or assemble core components.
    Use the TR&P specs, with a simple ACK.
    All I need of the BP metamodel is BusinessMessage and its
    immediate collaborating classes.

2. If I need something more complex, like commercial transactions 
    using an Offer-Acceptance pattern:
    now I need software at each end that implements something
    like the Edifecs' Commercial Transaction patterns (which would
    be related to the BusinessTransaction in the V2.0 BP metamodel,
    or BusinessCollaborationComposite with TransactionRules in
    the latest revision.  I also need something like the Edifecs
    Commercial Transaction State Chart to code from to get
    consistent programs.  People are not going to be able to
    create these programs from scratch in a consistent way
    by starting with raw UML and N90.

3. If I needed to create new core components, they would be classified
    under BP metamodel classes like EconomicResourceType,
    EconomicContract, Commitment, and EconomicEvent.
    We probably need some new classifications like Location
    and Quantification for core components.  These classifications
    would be used as stereotypes in UML diagrams for core components,
    and also as keywords to store component definitions in repositories.

4.  If I need long conversations like Order-Fulfillment-Payment, now the
     Resources and Contracts classes and their relationships come
     into their own.  We can create generic patterns (similar to the
     Edifecs ones) for common long conversations that will guide
     software developers and business modelers in getting more 
     consistent results.  I think that really consistent results
     will require standardized conformance tests.

>> I thought the statements were aimed at business users of
>> ebXML who had limited goals.  

>i think here is the great misunderstanding: what means limited goals?
>for me a ambitious goal is to store the own models. a limited goal is
>to accept the models from somebody else. so in the second case i do
>not perform any modelling at all.

That is one definition of limited goals; however, there are also limited
goals in creating ones' own models, which I tried to outline above.
Here is limit is in the complexity of business collaborations -
in other words, are you just trying to send a document,
or really synchronize the business processes at each end.
The big payoffs are in syncing the processes, but if we 
insist that everyone start there when all they want to do
is send a document, what do you think will happen?

>looking forward to discussions in san jose - since i will not be
>able to answer any replies until the meeting.

I understand.  I wanted to write a reply to continue the conversation
with others if possible.  See you there.

P.S. I am writing another document to sketch out classifications
for core components and a starter list of patterns.  It should 
go out Monday 7/31 AM.

-Bob Haugen