[xsd-users] wsdl support - slightly off-topic question

[Balasubramanyam, Shivakumar]

Boris,

Yes. You are right.

I agree, having some1 else provide the transport is a way for a
disciplined layering of software. I also do not think providing
solutions for already existing open source products also does not really
help.

In this case, there is no decent product out there for a WSDL to C++
compiler. If you have decided to use WSDL as an interface, then please
refer to this spec which provides the specification for WSDL to C++
http://www.omg.org/docs/ptc/06-08-01.pdf

I would also urge to take a look at the sca specifications for software
architecture for reference.
http://www.osoa.org/download/attachments/35/SCA_ClientAndImplementationM
odel_Cpp-V100.pdf?version=2


IMO, the interface definition could be thought of three components,

1. Data Representation [XSD. Application data definition] 
2. Interface Definition [WSDL. Has the RPC invocation info]
3. Service Definition [WSDL. Provides the Service Implementation info.
Like XMLApplicationData/SOAP/HTTP or XML2BinApplicationData/SOAP/HTTP
etc.]

The software components would be,

1. Data binding layer [XSD to C++ using one of the serialization formats
like XML,XDR,etc with existing XSD]
2. RPC specification [SOAP, RMI, JMS, HTTP, etc]
3. Transport Layer [HTTP, TCP, JMS/TCP, UDP, shared memory, etc]

The reason I have JMS and HTTP in both 2 and 3 is basically that the RPC
information could be encoded in the properties layer provided by these
application protocols.

I would be interested in brainstorming and providing any
support/contribution in these areas.

Thanks,
Shiva 

-----Original Message-----
From: Boris Kolpackov [mailto:boris at codesynthesis.com] 
Sent: Tuesday, August 05, 2008 12:01 PM
To: Balasubramanyam, Shivakumar
Cc: Rizzuto, Raymond; xsd-users at codesynthesis.com
Subject: Re: [xsd-users] wsdl support - slightly off-topic question

Hi Shiva,

Thanks for providing your feedback.

Balasubramanyam, Shivakumar <sbalasub at qualcomm.com> writes:

> gSOAP is very specific to SOAP protocol which is what you are 
> specifically looking for. As you pointed out, gsoap provides one 
> feature worth noting, RPC invocation when compared to XSD. However, 
> gSOAP is not a true WSDL product for the reasons that WSDL provides 
> multiple RPC protocols like JMS binding, http binding which gSOAP does

> not provide and rightfully not expected as well. The issue however is 
> that once you change the RPC, all your client code now needs to be 
> ripped off. So gSOAP is not for a forward looking application user.

Let me see if I understood your idea right. What you seem to want is to
decouple the stub/servant (stub is a client-side class used to make an
invocation and servant is a server-side class used to receive an
invocation, using CORBA terminology) from the protocol/transport. This
way the WSDL compiler generates data types for messages along with
stubs/skeletons for the services which can be "attached" to any
underlying messaging/RPC protocol (e.g., SOAP, etc) and transport (e.g.,
HTTP, raw TCP, etc).

If that's what you are looking for then I was also thinking along these
lines. In fact, at least at the beginning, we may not even provide the
transport implementation. Instead, the user can use existing (or custom)
libraries, for example, libculr on the client side and apache web server
on the server side for the HTTP transport.

Boris