[bt-spec] Call on messaging issues today, nowish

[Alastair Green <alastair.green@choreology.com>]

Hi Jim,

As discussed, we can have a discussion about this at 15.00 GMT (16.00 BST, 11.00
EDT) today? It looks like we're hitting similar issues in implementation, and it
would be useful to exchange notes, so we can come up with a clean presentation
of the issues to the wider committee.

I'd like to patch Alex in as well -- he just mailed me to say he'd be available
for this.

PS if anyone else on the list wants to join in, just mail me over the next hour
or so and I'll patch you in too. We'll put out some kind of notes on the
discussion to this spec list.

Alastair

"WEBBER,JIM (HP-UnitedKingdom,ex1)" wrote:

> 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
>
begin:vcard 
n:Green;Alastair
tel;cell:+44 795 841 2107
tel;fax:+44 207 670 1785
tel;work:+44 207 670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard