OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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...
-----Original Message-----
From: Martin Sachs [mailto:msachs@cyclonecommerce.com]
Sent: Wednesday, June 04, 2003 8:09 PM
To: Jacques Durand
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] RE: "application" vs MSH


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.


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


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]