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

-----Original Message-----

From: Martin Sachs
[mailto:]

Sent: Wednesday, June 04, 2003 8:09 PM

To: Jacques Durand

Cc: 

Subject: Re: [ebxml-msg] RE: "application" vs
MSH

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

 

*************************************

Martin Sachs

standards architect

Cyclone Commerce