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.

Wednesday, August 17, 2005
« DasBlog 1.8 upgrade successful! | Main | .NET Security Resources from the PAG »

I saw a couple of pattern implementations coming across on Microsoft Download and tracked them back to two very, very interesting articles by John Evdmon :

1) Service Patterns and Anti-Patterns

“This paper, the first of a multi-paper series, provides some fundamental principles for designing and implementing Web services. The paper starts with a brief review of SOA concepts and leads up to a detailed discussion of several patterns and anti-patterns that developers can leverage when building Web services today. Guidance in this paper is applicable to any programming language or platform for which Web services can be developed and deployed.”

Some items in this article really resonated with me such as “Avoid blurring the line between public and private data representations.” and “Service consumers must map their data representations to the schema used by the service. Some consumers may find mapping to a service's schema to be a lossy process.”, as we were just today having a discussion internally about Data Models in SOA and how it is very important to understand the differences between Service Level Data Models and Internal Data Models. Especially as to how in an SOA implemented using web services, there has to be a data translation that occurs between the Internal Data Model and the Service Level one both the Provider and the Consumer sides.

I do have issues with the assertion that if  you “…comply with the WS-I Basic Profile [it will enable the service] to be consumed by any platform or programming language that supports Web services.”  My problem with this statement is comes from painful experience gained while working with today’s SOAP toolkits to build inter-operable web services.  The reality is that WS-I improves the possibility of Interop by mandating how specific artifacts such as a WSDL should be structured, but WS-I punts when it comes to XML Schema. They basically say that the SOAP toolkit should support the approved XML Schema standard and leaves it at that.

The problem here is that no SOAP toolkit has full support for the entire XML Schema standard, so when it comes to implementation specifics there is often the possibility that an schema artifact that is supported in one toolkit may not be supported in another. An example is support for substitution groups which exists in Apache Axis but does not exist in .NET. There are examples that go in the other direction as well. Check out my earlier summary of a SOAPBuilder’s discussion if you wish to know more about this..

I do love that fact that the article advocates Top Down / WSDL First web service development (… just keep the above caveat in mind when you are designing your message schema).

The associated code for the patterns mentioned in the article can be found at:

 

2) Service Versioning

“This paper is the second in a multi-paper series focusing on service design principles. This paper surveys some fundamental guidelines for versioning schemas and Web services. Six specific principles for versioning Web services are identified.”

Hmm.. I need to think a bit more about this…. This is also something that is of great interest to me and is something that is being actively worked on in my space as well.. I did note that some of the Message Versioning recommendations seem to tie in very nicely with the “XML Schema best practices” document from HP.

8/17/2005 11:20 PM Eastern Daylight Time  |  Comments [0]  |  Disclaimer  |  Permalink   
Comments are closed.