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

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

Dipan,

Exactly!

Cheers,

Chris

Anarkat, Dipan wrote:

> Chris,
>         I concur ! Exposing the implementation details will not result 
> in a loosely coupled system, which IMHO is not desirable in the design 
> of distributed systems.
> 
>         So, if I am not wrong, there would be a mapping feature provided 
> by the MSH software vendors, implementation details of which is left to 
> the vendor !? If thats true, then the designer of the 'service/action' 
> (standards bodies) should understand 'Service/Action' as being a logical 
> internal routing end point, right?
> 
> Thanks
> 
> + dipan
> 
> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: Thursday, March 14, 2002 9:35 AM
> To: Dick Brooks
> Cc: Anarkat, Dipan; 'Martin W Sachs'; Ebxml-Dev (E-mail);
> david@drummondgroup.com
> Subject: Re: [ebxml-dev] ebMS TR&P tags
> 
> 
> 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/>
>