OASIS ebXML Messaging Services TC

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

  • 1.  RE: [ebxml-msg] RE: "application" vs MSH

    Posted 06-07-2003 01:22
     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