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

[Christopher Ferris <chris.ferris@sun.com>]

Dick,

Some comments below.

Cheers,

Chris

Dick Brooks wrote:

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


Interesting, but why would you put this in the message itself,
imposing a requirement that the sender have some intimate
knowledge of the recipient's implementation as opposed to
having the receiver do a mapping locally from some abstract
name to some local implementation specific information?

The spec recommends that the value of the Service element be
a URI. This doesn't necessarily mean a URL (although that
is certainly a possible aproach). A URN could be used (gee,
I REALLY wish that the reg/rep folk would adopt a URN scheme
for stuff in the registry that would qualify an assigned UUID!)

to identify a defined service. Another approach that could

apply would be to identify the URI of a WSDL or other description
of the service.

Note also that by exposing implementation specific details
such as this means that any changes to the "backoffice" implementation
would need to result in changes to the agreement making the
system a little more fragile than it needs to be (IMO).

If the mapping is handled by the receiver, then it is free to
change the implementation of the functionality without
needing to inform all of its partners that they need to update
their CPA or other configuration information or their
messages will go unprocessed.


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


Sure, but again, why expose this?


>  
> 
>  
> 
> 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 
> <http://www.systrends.com/>>
> Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714
>  
> 
<snip/>