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
- From: Jacques Durand <JDurand@fsw.fujitsu.com>
- To: "'Martin Sachs'" <msachs@cyclonecommerce.com>, "'matt@mac-kenzie.net'" <matt@mac-kenzie.net>
- Date: Thu, 5 Jun 2003 23:01:07 -0700
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
Jacques,
You have provided an
excellent discussion of "application" is it relates to the MSH.
I have
one concern: You say: "This contract may be realized via an abstract
interface between MSH and application, which is outside the scope of
ebMS." I agree that the message service team has made that abstract
interface outside the scope of ebMS. My concern is that it is not in
anyone's scope. Without a proper specification of that interface as a
standard, there is no guarantee of interoperability between the software
components above the MSH at two communicating parties. There is no
guarantee that the statements that you have extracted from the MSH
specification form a complete or proper definition of that interface.
Only a concerted effort to produce a complete specification of that interface
has a chance of providing confidence that the definition is
complete.
Regards,
Marty
At 01:11 PM 6/4/2003 -0700, Jacques
Durand wrote:
Some attempt to
clarify the notion of "application" in ebMS,
as
discussed last time. See attached...
Jacques
You may leave a Technical Committee
at any time by visiting http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/members/leave_workgroup.php
*************************************
Martin
Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]