MHonArc v2.4.5 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ebxml-msg] RE: "application" vs MSH
Jacques,
I agree that defining the interaction between the MSH and the level above
it by a contract is the right approach. That should eliminate the issues
that usually arise when an attempt is made to define an
"interface" between adjacent layers (what language, does it
constrain implementations, etc.?). The contract has to cover all aspects
of the interaction and to ensure that it also guarantees interoperability
between the "applications" of the MSH at two communicating
parties.
I do have a feeling, however, that middleware vendors would prefer
to see a specific standardized interface so that one implementation of
the code that interacts with the MSH would work with all vendors'
MSH's.
Regards,
Marty
At 11:01 PM 6/5/2003 -0700, Jacques Durand wrote:
Marty
and Matt:
By stating "out-of-scope
of ebMS", I was merely making the most consensual statement, which
does not
necessarily reflects the
opinion of its author :)
As a minimum, I believe we need
a more explicit - even if abstract - definition of
"application" in ebMS because it is a pervasive
and recurrent notion throughout
the spec (and an important one), as my little summary shows.
Beyond that, the question of
where the description of a standard "interface" or
"contract" app-MSH should reside,
is open. But agree it should be
specified somewhere, if only in an implementation guideline.
(I do believe however that it
falls under this TC .)
Note that the
"interface" approach is just one option - or maybe the most
concrete one.
I usually prefer to talk of
"contract", which includes the behavioral aspect of the parties
when using an interface
(and which actually could be
described without an interface, focusing again on the protocol and
exchanged data,
this time between app and
MSH...)
An interface in the traditional
sense would in addition serve an obvious architectural and software
portability purpose,
but I'd prefer to see if we
could flesh out the "contract" first, independently (which is
already informally described throughout ebMS).
An interface has the issue of
being hard to dissociate from specific languages - but maybe I am not
imaginative
enough here when it comes to
abstracting it. Also , some implementation
may want to use innovative ways
to communicate between app and MSH - e.g. a publish-subscribe
model...
If interface there is, should
it be language indepdt - e.g. WSDL-based?
These are just some issues to
look into.
Marty has a point that
ultimately app-to-app interoperability is the goal, and that again
requires an end-to-end contract.
So looks like I already have a
foot into Matt's subcommittee...
Jacques