Philip Rieck

Phil in .net

gSOAP 2.3.8, and you do care.

From Dave Bettin - gSOAP 2.3.8:

We are pleased to announce the gSOAP 2.3.8 stable release for C and C++ Web services: ** Support for ANSI C and C++, including STL and templates
** Full support for SOAP 1.1 and 1.2
** Full support for WSDL 1.1 (WSDL document import and generation)
** Proven interoperability (including all SOAP encoding types, SOAP sparse arrays, bitmasks, and Schema simpleTypes and complexTypes)

Why do you care about a C++ soap library on sourceforge, oh ASP.net blogger?  Indigo will work with this. This will work with Indigo .  With IBM proving interoperability with MS, with BEA working on full interoperability, and with open source actively producing specification-compliant libraries, this means that producing truely interoperable services is within your grasp - and in fact may be very easy to grab.  As your services are easier to consume and consumable by more people and technologies, the value of those services goes up.  And producing value is what it's all about (note that I didn't say revenue - value).

So cheer when Java has a library implementing advanced WS-* standards.  Cheer when open source libraries are produced that can generate and consume services... Don't dispair that that asp.net loses value when other technologies can do the same thing - being able to interoperate adds value, and makes asp.net and .net in general an easier choice for the enterprise.  This means that your boss will be more receptive when you contend that .net wins in other areas and should become your tool of choice.

 

Comments

Frans Bouma said:

Do not make the mistake to confuse SOAP with the actual format the data is in. SOAP is the transporter protocol, it's not the format the data being transported is formatted in, which is really the important issue when it comes about making your services able to consume other services' data.
# November 1, 2003 5:44 AM

Philip Rieck said:

If you read the post, you'll see that gSOAP:
1) supports soap - so our services can "talk" (you can't communicate without the protocol)
2) supports all soap encoding types - so our services can use a common language
3) supports wsdl - so our services can describe our grammar.

With these simple rules, I can use Indigo to work with it (hopefully over tcp/http or another "built in" transport protocol - but I can always use another if I write the support). At the very least, I can drop to the connector level and send messages, but most likely it will be much easier.
# November 1, 2003 8:34 AM