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