W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2003

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

From: Amelia A. Lewis <alewis@tibco.com>
Date: Mon, 28 Apr 2003 16:29:09 -0400
To: "Anne Thomas Manes" <anne@manes.net>
Cc: jean-philippe.moresmau@soamai.com, distobj@acm.org, www-ws-desc@w3.org
Message-Id: <20030428162909.3b7da990.alewis@tibco.com>

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 Monday, 28 April 2003 16:29:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:23 GMT