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

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

Chris,

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

Thanks,

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: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Thursday, March 14, 2002 8: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.

<db>
I agree with your analysis that using type in the manner I described exposes
implementation details of the backend systems. I also agree that using
Service/Action as an index into a table is a completely reasonable and
viable implementation of a ebXML MSH.

The approach I described, using the type attribute to help "instantiate" an
object, allows implementers to take advantage of existing infrastructure
"mapping tables" within COM/CORBA/DCE etc.

With regard to the assertion:
  "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?"

Regardless of what the type attribute contains or how it's used, I'm
assuming that an implementer must provide a client with ALL the information
needed to invoke a service. The information may be provided via WSDL, CPP, a
telephone call or any number of other options.

When an implementer provides a specific value for the "type" attribute it's
just like any other value (e.g. Service and  Action). The server implementer
is telling the client they must provide this information in the ebXML
header, along with all the other information to invoke a particular
service/action.

The client really doesn't have intimate knowledge of "how" a service is
implemented, they only know they must provide a specific value in the type
attribute when they invoke a particular service. How the "type" information
is interpreted/used by the server is a function of the server, regardless of
what information is contained in the "type" attribute.

For example, suppose I offer a service called "moneytransfer" with a type of
"international" and an action of "credit". As the server implementer I
should be able to map this information anyway I wish, for example, using a
table as you described, to a real piece of "working code". If the server
implementer decides to take advantage of the type attribute to indicate that
the service "moneytransfer" is a type="CORBA" then they are allowed to use
it this way as well and this eliminates the need for a separate ebXML
mapping table. They are simply taking advantage of the CORBA naming service
for this purpose, ref: ftp://ftp.omg.org/pub/docs/formal/97-12-10.pdf.

</db>

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

<db>
Again, the "interpretation" of "type" is at the discretion of the server
implementer.  It all depends on "how" they want to perform the mapping.
IMHO, specifying the type="CORBA" or type="com.systrends.Software" is an
efficient way to take advantage of existing infrastructure mapping systems
so implementers don't have to create their own ebxml mapping table.
<db>
>
>
>
>
> 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/>