RE : RE : Proposal for Describing Web Services that Refer to Other Web Services: R085

Amy, it'd be interesting that you submit your point of view to the ws-arch
mailing list. They have lengthy discussions about what a Web Service is,
including the use or not of URIs to identify services and interface or
binding definitions, but most definitions seem to take for granted that the
"Web" in Web Services is more than marketing talk and actually mean the use
of standard, open protocols, and a total independance between client and
server implementations. Your point of view seems to be that if a service as
a standard definition (IDL for example), it is a Web Service.

JP


 	 	 Soamaï	
 	 Jean-Philippe Moresmau - CTO-Directeur Technique	
 	 1025 rue Henri Becquerel - 34036 Montpellier cedex 01 - FRANCE	
 	 Tél : +33(0)4 99 52 65 43 - Mob : +33(0)6 72 75 21 27	
 	 Std : +33 (0)1 46 08 69 00 - Fax : +33(0) 67 65 56 20	
 	 www.soamai.com	


-----Message d'origine-----
De : Amelia A.Lewis [mailto:alewis@tibco.com] 
Envoyé : lundi 28 avril 2003 22:29
À : Anne Thomas Manes
Cc : jean-philippe.moresmau@soamai.com; distobj@acm.org; www-ws-desc@w3.org
Objet : Re: RE : Proposal for Describing Web Services that Refer to Other
Web Services: R085


Dear Anne,

On Mon, 28 Apr 2003 13:19:23 -0400
"Anne Thomas Manes" <anne@manes.net> wrote:
> Question: How does a .NET client access said EJB service? Although 
> WSIF

It doesn't.

This isn't because of gratuitous incompatibility between Sun's Java and MS's
.Net, for a change.  It's because of gratuitous incompatibility between JMS
implementations.

If I'm runing TIBCO's JMS implementation, and someone publishes a service
based on Websphere using IBM's MQSeries implementation, I can't use the
service.  At least, I can't unless I install the MQSeries client so that I
can understand the service.

JMS is not a protocol; it's an API.  There are dozens of incompatible wire
formats.  The only defined means of accessing a JMS service deployed using a
particular implementation is by using the same implementation.

> turns any service into the equivalent of a Web service for Java 
> clients, that doesn't in turn make those same services "Web services"
> -- because .NET doesn't have the equivalent of WSIF. (This is the 
> biggest issue I have with JSR-109 -- which says that a Web service 
> client needs to access a Web service via JNDI. I don't think that 
> qualifies as a Web service.)

I don't know the JSR.  If it says that a web service description must be
retrieved via JNDI, I'd agree with you.

I think it is perfectly possible, however, to define a "web service" (a very
ambiguous term, I'm afraid) which runs something completely proprietary, so
long as the binding and the WSDL extensions have been published.  This may
involve much stricter constraints than "you must understand the pgm URI
scheme and the PGM protocol associated with it". 
It may give as address information the JNDI hashtable entries (including a
base uri and a query string, plus other more or less opaque information),
and require that clients understand the syntax of the complex address type,
*and* be able to run Java bytecode, *and* have the appropriate
implementation available, and then to perform a particular algorithm in
order to retrieve the thing that might be described with a simple URI using
HTTP or PGM.  As long as the service is described, and its content is
described, it fits under the broad umbrella of web services.

For JMS, specifically, the service is only going to be accessible using the
same implementation that is deployed in the service, using java bytecodes,
after performing a lookup in a JNDI repository based on information placed
into the description.  It would be a lot easier if the vendors (or even the
spec writers for JMS) had agreed upon a URI scheme, but they didn't ... they
didn't even agree upon a common wire protocol, so JMS is only accessible
through the JMS API (in standard fashion, that is; various vendors have URI
schemes, access via C++ and other languages (possibly including C# in .Net),
and so on).

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Tuesday, 29 April 2003 03:59:48 UTC