ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerd Aschemann <>
Date Mon, 24 Jul 2000 13:40:48 GMT
(My background are some years of experience with CORBA with ORBacus,
MICO, COPE ... please keep this in mind.)

I was looking for a high level description for SOAP services, ideally
I would like to have some sort of IDL. The only available tool I found
was NASSL and I gave it a try. Now I have some questions and comments
on it.

0. There are some bugs and very few documentation on NASSL. I would
   really appreciate to have it in source in a short term ... How
   about the efforts here?

1. I would like to distinguish between the interface and the
   implementation in a better way. An IDL compiler usually generates
   several files:
     - an "interface" file
     - a client stub which implements the interface (NASSL: proxy)
     - a server skeleton which implements the interface as an abstract
     - optionally some compilers generate some sort of an
       implementation template which is a starting point for the
       implementation class. The implementation is usually provided by
       the developer as an extension of the abstract skeleton class.

   NASSL currently generates me a proxy (IDL: Stub) and a "dummy
   implementation" for the server side. I would prefer to have an
   (Java) "interface" instead which can be implemented by me, and
   maybe optionally the kind of template as a starting point for the

   I would like to have an NASSL-interface X and a generated Java
   "interface X" and a self implemented "class XImpl implements X", or a
   generated "abstract class _XImplBase implements X" plus a "class
   XImpl extends _XImplBase" ... (the latter currently doesn't make
   much sense, but maybe in the future).
2. How about Java namespaces? Is it possible to have the generated
   classes/interfaces/proxies to be in a Java package, eg.,

3. For the proxy/to find the service it would be nice to have some
   sort of IOR ... I understand two things:

   - We don't (yet) have object references (see the spec and the mails
     from Michi Henning for a discussion on this).
   - But: We do have some sort of "service reference", a URL-URN pair,
     derived from the providerDef (deployment descriptor).

   This information is hard coded into the proxy class. Wouldn't it be
   a good idea to have some sort of a "SOAPService" class which
   contains such information and to have the proxy constructors (or
   additional proxy constructors) which can be initialized with such
   an object. See also the next point ...

4. On the first look it seems reasonable to encapsulate all
   information about a service within one file. This is OK if one only
   wants to provide a few implementations or to deploy the service a
   few times. But consider a scenario where we have a single interface
   and only one or two implementations, say one in Java and one in
   Perl, but many many many deployments. This is the case for us (I am
   consulting for a company): we describe and implement an interface
   and sell the product several times where each customer deploys it
   one or more times.

   So maybe it would be a good idea to separate the specifications a
   little bit more with some well defined relationships among them,
   eg., the provider definition including or refering to an
   implementation definition. The implementation definition could
   refer to an interface definition. Think of it as some sort of
   component description like CORBA components or EJB where you also
   have different roles (developers, assemblers, system
   administrators) with respective descriptions.

5. Finally there are some major bugs in the NASSL implementation, eg.,
   if the .nsl contains an interface:

 <nsl:interfaceDef name="DBQuery">

   and an implementation descriptor:

 <nsl:implements interface="DBXQuery"/>

   The compiler will not generate Proxies and "dummy implementations".
   It will not even report an error. But it will generate "wrong"
   DeploymentDescriptors ...

6. It would be nice to extend NASSL to also generate Perl code.

So again: To get the source would be great!


View raw message