My blog has moved and can now be found at http://blog.aniljohn.com

No action is needed on your part if you are already subscribed to this blog via e-mail or its syndication feed.

Saturday, 08 October 2005
« Security Engineering / Secure Developmen... | Main | XSDObjectGen 1.4.2 Released »

Platform and technology agnostic exchange of messages such that they can be utilized from any language or platform. That is the promise of integration via web-services.  The contract-first style of development is a web-service development style that will improve the chance of interoperability when the technologies and platforms on both ends of the wire are different.

My environment happens to be very heterogeneous and, as such, the web-services that I develop MUST interop with other SOAP stacks.   My normal design and development style is pretty straight forward:

  • Design the message schema for the web service. 
    I tend to use XMLSpy a whole lot in this phase.  The interesting thing is that there are many different ways to define XML Schemas and the design choice can seriously impact the generation of implementation classes in the technology of your choice.  There are different schema design styles such as the Russian Doll, Venetian Blind and Garden of Eden that can be followed. There are also some guidelines for XML Schema design that will tend to improve web services interoperability. I tend to be a fan of the the Garden of Eden style for web services.
  • Generate a WS-I Basic Profile compliant WSDL from the message schema.
    While I occasionally do use a wrench, I am not a plumber. Hand generating WSDL is a dark and mysterious art prone to many pitfalls.  Generating WS-I Basic Profile compliant WSDL by hand and tweaking it is simply voodoo!  As such, I rely on tooling to help me in this.  My particular tool of choice here is WSCF from my friend Christian Weyer. He has versions that work from the command line, as a Visual Studio.NET plug-in, or as an Eclipse plug-in. So whether or not I am on the .NET or Java platform, I am covered. After I am done with the generation, I bring the WSDL into XMLSpy for any minor tweaking or corrections as well as to make sure that the WSDL validates.
  • Generate the Service Stub
    If I am using Apache Axis, I use WSDL2Java for this purpose.  If I am on the .NET platform, I use a combination of WSCF and XSDObjectGen.  I first generate my implementation classes using XSDObjectGen by pointing them to the message schema. Then I generate the shell for the web service methods using WSCF and then hook it up to the Data Types that are generated by XSDObjectGen.  Some folks may question why I do this, when WSCF can generate the data types as well. There are a couple of answers, with the most relevant being that I simply find it easier to work with code that is generated by XSDObjectGen.
  • Generate the Client Proxy
    Use WSDL2Java if using Apache Axis to generate your client proxy.  On the .NET platform, I use WSDL.exe to generate the client proxy BUT I go into the proxy class and comment out all of the data types.  I actually use XSDObjectGen to generate the data types from the XSD files and hook it up to the proxy class for the same reasons that I noted above in the Service stub generation. I do not use WSCF here for another reason, which is that it seems to enforce the Pascal casing for generated type names even if the XSD is using camel casing. I prefer to keep the casing consistent between my XSD and Code.
  • Unit Tests to Verify Interop
    Trust but Verify!  Since I am building Interoperable web services, I do not want my consumers to discover issues with my services. To that end, I make sure that I write unit tests in platforms and technologies at both ends of the wire to verify interoperability. i.e. If I am writing a .NET web service and I am expecting that my consumers are going to be .NET and Apache Axis based, I make sure I write unit tests in both .NET and with Java/Axis to exercise the service.  I would do the same if I was deploying an Axis based web service.
Monday, 10 October 2005 17:33:15 (Eastern Daylight Time, UTC-04:00)
Hey sugar :) You say you want to have your schema and code in-sync when it comes to casing. OK, so you really are fine to violate the .NET Framework guidelines then?
Anyway, would you like to see a switch for the casing...?
I never received feednack for this from you ;)
Monday, 10 October 2005 22:22:34 (Eastern Daylight Time, UTC-04:00)
Ha! Knew I'd get a rise out you with that one, Christian.. First though, my apologies, I should've pinged you directly first with this comment. Will do so next time.

To answer your question, yes, I am fine with violating the .NET Framework guidelines :-)

The issue that I am running into is the following. Take a look at the Schema design guidelines here @ http://devresource.hp.com/drc/resources/xmlSchemaBestPractices.jsp#identifiers. The recommendation there is "If you are creating an XML schema from scratch, use lower camel case, i.e., "applePearOrange" as that is the most widespread form of XML document in use today (e.g., XHTML, XML Schema, XSLT, etc.)."

So, yes, I would like to see a user selectable switch.
Anil John
Comments are closed.