RE: [ebxml-dev] ebMS TR&P tags

[Dick Brooks <dick@tech-comm.com>]

Title: RE: [ebxml-dev] ebMS TR&P tags

Dipan,

 

See responses inline bounded by <db> </db>.

 

Dick Brooks
Systrends, Inc
7855 South River Parkway, Suite 111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714
 

-----Original Message-----
From: Anarkat, Dipan [mailto:DAnarkat@uc-council.org]
Sent: Thursday, March 14, 2002 7:55 AM
To: 'Dick Brooks'; 'Martin W Sachs'; Ebxml-Dev (E-mail)
Cc: david@drummondgroup.com
Subject: RE: [ebxml-dev] ebMS TR&P tags

<snip>

That's the role of Manifest/Reference, the Reference element provides pointers to the

"call parameters" for this Service/Action.

 

The payload is passed to the Service/Action as a set of parameters and this completes the "call frame".

</snip>

 

    Compared to an RPC call (.....my understanding)

        # The ebXML MSH represents an RPC server

        # The service represents the interface

        # The action represents a function in the interface

        # the payload represents the paramaters passed to this function call

   

    Now if only the payload gets passed to the service/action, of what use is the 'Manifest' which may also reference resources not included in the payload? 

 

<db>

 

It's true that a Reference "could" use "pass by reference" semantics, as you describe above. However, the spec emphasizes "pass by value" semantics where the call "parameters" are contained in the message payload container. There are lots of nasty little security issues when you start talking about "pass by reference" semantics.

 

</db>

 

    Besides, for individual payload content the manifest lists the schemas required for validation processing. Wouldnt this be required to be passed on to the 'service/action' that actually processes the message? This implies that after the MSH has processed the TRP information, it must pass the payload and at-the-least the Mainfest (if not the entire ebXML message) information to the 'Service/Action', right?

 

<db>

 

Yes an MSH is required to "interface" with real working code at some point, how that happens is entirely up to the implementer. An MSH may "preprocess" a payload (e.g. decrypt) before passing the payload to a service/action.

 

</db>

 

    Also, this is what the ebXML spec says for Manifest :

 

  The purpose of the Manifest is:

·          to make it easier to directly extract a particular payload associated with this ebXML Message,

·          to allow an application to determine whether it can process the payload without having to parse it.

Now if the Manifest has been included in the header-container section (to be processed by the MSH), what does it do with the manifest information?

<db>

I think you may be confusing SOAP:Header with ebXML header document.

The Manifest element resides in the SOAP:Body element of an ebXML header document. Reference elements within the Manifest element "point to" data needed by a service/action. The data is located in the message payload container when using "pass by value".

Reference elements can also "point to" external data in a "pass by reference" approach, however the ebXML spec doesn't specify "how" to implement pass by reference. As I mentioned earlier, there are lots of security issues to address with "pass by reference".

</db>

 Thanks

+ dipan

   

-----Original Message-----
From: Dick Brooks [mailto:dick@tech-comm.com]
Sent: Wednesday, March 13, 2002 9:23 PM
To: Anarkat, Dipan; 'Martin W Sachs'; Ebxml-Dev (E-mail)
Cc: david@drummondgroup.com
Subject: RE: [ebxml-dev] ebMS TR&P tags

Dipan,

 

ebXML doesn't "prescribe" how to implement service/type and action. I like to think of ebXML MS using object oriented concepts, so here is how I see it.

 

Let's start with Service:

 

I think of "Service" as the "Object" identifier. It serves as an identifier for a high level class of object, for example:

 

- OrderProcessing

- PaymentProcessing

 

There are a couple of uses for the "type" attribute.

 

The type attribute can be used to describe the technology used (e.g. CORBA, DCOM) to instantiate the Object/Service. For example, suppose there was a  service called "OrderProcessing", type could specify the "distributed object technology", for example:

 

<Service type="DCOM">OrderProcessing</Service>

or

<Service type="CORBA">OrderProcessing</Service>

 

Type is not limited to describing a technology, it can also be used to indicate a package name (if it's a local service for example), e.g. "com.systrends.Software", for example:

 

<Service type="com.systrends.Software">OrderProcessing</Service>

or

<Service type="com.systrends.Software">ServiceRequest</Service>

 

 

I think of Action as the method to invoke. For example with a service of:

 

<Service type="com.systrends.Software">OrderProcessing</Service>

 

one might expect to see an Action of:

 

<Action>Sale</Action>

or

<Action>VoidSale</Action>

 

With a Service of:

 

<Service type="com.systrends.Software">ServiceRequest</Service>

 

you might expect to see Actions of:

 

<Action>InstallationRequest</Action>

or

<Action>InstallationComplete</Action>

 

You might be wondering, if Service, Type and Action are synonymous with Object, Package/Technology and Method, where are the parameters to the Actions/methods?

 

That's the role of Manifest/Reference, the Reference element provides pointers to the

"call parameters" for this Service/Action.

 

The payload is passed to the Service/Action as a set of parameters and this completes the "call frame".

 

Note: there's a lot I didn't go into in this "object oriented" view of ebXML, such as object persistence, passing object pointers, etc. ebXML is not a true "distributed object system" so these things are not defined. Object oriented concepts have helped me design protocols and systems using ebXML's MS and I thought it might help you also.

 

That's my view of how ebXML MS works.

 

<Service type="BusinessProfessional">Valediction</Service>

<Action>Regards</Action>

 

Dick Brooks
Systrends, Inc
7855 South River Parkway, Suite 111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714
 

-----Original Message-----
From: Anarkat, Dipan [mailto:DAnarkat@uc-council.org]
Sent: Wednesday, March 13, 2002 6:38 PM
To: 'Martin W Sachs'; Ebxml-Dev (E-mail)
Cc: 'david@drummondgroup.com'
Subject: RE: [ebxml-dev] ebMS TR&P tags

Martin,
        with reference to #2,3 and 4
        As I understand, the value for 'Service' is an identifier for a 'logical' endpoint that processes the business message contained in the payload and this is specified by standards organizations or individuals who define the business process standards. Now to actually process the payload the 'logical' endpoint will have to be mapped to a physical endpoint like, for example, a web-service, EAI app, Java servlet etc, and the entire message then routed internally to the physical service. Is this the way it works?

        If this is true, then the ebXML MSH software will have to be configured with the mapping information for every 'Service/Action' pair to the physical service, right?

Also, after the header-container is processed, what gets passed/routed to the 'Service/Action' ? :
        # the entire ebXML Message
        # the payload only

Also, what is the rationale for identifying and defining values for 'Service', 'Type' and 'Action'?

Thanks

Dipan Anarkat
Systems Analyst, Standards Development
Uniform Code Council, Inc.
Tel: (609)-620-4509
http://www.uc-council.org/

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Thursday, December 06, 2001 3:05 PM
To: Anarkat, Dipan
Subject: Re: [ebxml-dev] ebMS TR&P tags

#1:  CPAId is a pointer to the runtime state information for this CPA.
Various levels of middleware reference various information there.
#2, 3, and 4 are indeed used for routing from the receiving MSH to the
correct software input point.  Details are left to the implementer.

Regards,
Marty

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

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************

"Anarkat, Dipan" <DAnarkat@uc-council.org> on 12/06/2001 02:27:54 PM

To:    "Ebxml-Dev (E-mail)" <ebxml-dev@lists.ebxml.org>
cc:
Subject:    [ebxml-dev] ebMS TR&P tags

Hi,
    Can anyone provide explanation on how the following tags are processed
by the ebXML B2B app with an inbound ('To' MSH) and outbound ('From' MSH)
message ?

#1    eb:MessageHeader/eb:CPAId
#2    eb:MessageHeader/eb:Service
#3    eb:MessageHeader/eb:Service/@type
#4    eb:MessageHeader/eb:Action

Also is #2 and #3  and #4 used for further routing of the recieved message
,
on arrival at the destination ?

Pardon me, but the explanation provided in the ebMS TR&P 1.0 specification
is not helpful.

Thanks

Dipan Anarkat
Uniform Code Council, Inc.
Tel: (609)-620-4509
http://www.uc-council.org/

----------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>