OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [bt-spec] Messaging issues


Alastair,

Firstly I'm pretty happy about that fact that someone else has thought of
exactly the same set of issues that I have been thinking of, it re-assures
me that I probably wasn't off at a tanget (or perhaps that fools seldom
differ :-).

I'd narrow down the options that you present to one of the two, being either
"normal" SOAP RPC where we define a number of endpoints corresponding to the
operations that an actor can perform, or to just having each BTP actor
expose (over SOAP RPC) a method which takes an arbitrary BTP message and
does the right thing with it.

I think there are two (conflicting) points to be made here:

1. A "fuller" interface is more akin to what people are used to in Web
Services as they stand, and hence may not discourage take up. A single
"invoke" method might be overwhelming.

2. The single "invoke" method is simpler than a fuller method from an
interface point of view, and under the covers allows us to just dump BTP
messages wholesale into SOAP messages.

My view on this is that the API will abstract all of this anyway, so what it
comes down to is how we view all of our vendor implementations
interoperating in the Web Services world. Personally I would not like to
differentiate a BTP Web Service from a Stock Ticker Web Service insofar as
they should exhibit similar behaviour to a consumer, and thus SOAP RPC with
a fuller interface would probably be the way I would jump, if pushed.

The benefit of going this way is that as allied technologies such as WSDL
come to maturity (and WSDL is now coming to maturity and will be taken up by
the Web Services community) we can offer WSDL interfaces for BTP services
(and even individual actors) with relatively little cost. Furthermore,
having standard interfaces will help in our interoperability, whereas the
more coarse approach of passing around messages and leaving it up to the
service to decide what to do with them will make tracking down
interoperability bugs much harder. Note that I'm not going to pursue WSDL
adoption like Savas did (though long term I think it will creep into our
scope), but I think making our stuff have the same look-and-feel as other
Web Services is a winner, or at least not a loser.

Jim
--
Dr. James Webber
Hewlett-Packard Arjuna Lab
http://www.arjuna.com
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC