RE: service / agent terminology

Me too!

I would also like to add that using email as a transport for business
documents to a web service makes a lot of sense - especially as:
1. The majority of the businesses in the world can't afford the
communications or adminstrative cost of an "always on" HTTP server.
2. Business interactions are often, by their very nature, one message at a
time with delays of several minutes if not hours or longer, between the
sending of a message and the generation of its response (I nearly said
asynchronous!)

I suppose I'm suggesting that *one* of the valid use cases for a web service
is one where at least part of the service is performed by a human being.

Do these ideas fit into our architecture.

David

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Thursday, February 20, 2003 3:24 PM
To: Scott Vorthmann; www-ws-arch@w3.org
Subject: RE: service / agent terminology



Big +1

arkin

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Scott Vorthmann
> Sent: Thursday, February 20, 2003 2:23 PM
> To: www-ws-arch@w3.org
> Subject: service / agent terminology
> 
> 
> 
> 
> I'm somewhat concerned about the direction of today's discussion 
> of terminology.
> 
> I agree with David B that there's a lot of baggage around 
> "service" as a provider.  However, that baggage is not imposed by 
> abstract WSDL... rather it accrues by the common usage of 
> request-reply as the prevalent operation signature.  I'd like to 
> lose the baggage.
> 
> WSDL got many things "right", in my view, and the inclusion of 
> "out" and "out-in" operation signatures is one of them.  This 
> lets me define an entity that has a clear boundary of 
> identifiable, typed communication endpoints... I'd like to call 
> that entity a service, even if its only interaction with the 
> outside world is periodic publishing of time and temp (on an 
> appropriate transport).
> 
> Providing a service need not imply reactive communication... 
> services can be proactive as well.  This means that "provider" 
> need not imply "responder".
> 
> HTTP tunnel-vision has made a similar discussion on the 
> Description group somewhat long and animated, apparently.  I 
> think we have a great opportunity to define an architecture that 
> extends beyond existing Web transport protocols to communation 
> protocols in general.  (Will I now be skewered by REST 
> proponents?)  I hope our charter does not preclude that.
> 
> Scott
> -- 
> Scott Vorthmann                    mailto:scottv@tibco.com
> Senior Architect                     mailto:scottv1@imcingular.com
>                                               office: 919 969 6513
> TIBCO Extensibility                  mobile: 919 593 2349
> TIBCO Software, Inc.               http://www.tibco.com

Received on Sunday, 23 February 2003 18:56:36 UTC