Sunday, June 19, 2005

Should we abandon WSDL?

I came across this write up recently.

"Philosophically contract-first is a good idea because it elevates the exchange of business documents to be the primary artefact around which systems are built. Modelling such exchanges leads to integration at a high level and should in turn lead to solutions which are suitably loosely coupled.

However, pragmatically contract-first is hamstrung by the contract languages which Web Services practitioners have at their disposal. WSDL is cumbersome and provides the wrong set of abstractions, while WS-BPEL is heavyweight and relies on WSDL. Given the prevailing conditions, contract first is fraught with difficulty when contract languages are brittle and unwieldy.

Using WSDL as the contract language for contract-first development may require some creativity at best. At worst the contract language will constrain the underlying service implementation resulting not so much with a robust Service-Oriented Architecture but a rather limp RPC-ish one. If that is the case, then it makes sense to drop WSDL in favour of some other contract language whether that is SSDL, BPEL, or simply schemas and natural language descriptions of message exchanges. Ultimately it boils down to the fact that the services are there to support the business and the contract language must be able to capture business interactions. A contract language should enable rather than constrain business protocols: the tail, after all, does not wag the dog."

Having said this I must look into SSDL, when I first started down the path of integrating hotel systems for chains I was doing it using XML over HTTP using MSMQ as asyn layer. Things were simple before we had SOAP, WSDL and WS-I, does anyone remember ebXML looks like it may have died a natural death.

Going by SSDL we should just have schemas and use SOAP to transport it without the constraints of WSDL....hmm not a bad idea eh..........


Cisco Readies XML Devices, Software AON (Application-Oriented Networking)

CISCO is coming out with new XML Router, the reason this excites me is due to this factor.,1759,1826721,00.asp
"Cisco is using Tarari's programmable chip to perform low-level tasks such as checking XML signatures and verifying XML schemas. But Cisco's AON developers have also created a substantial amount of technology, including agents that work with the chip and handle tasks such as XML message transformation, which makes it possible to exchange XML messages between two systems that use different XML schemas."

This will mean we can have a router behind our firewall which will inspect every xml stream coming it and validate it against corporate schema repository. If not valid will discard it, otherwise route it appropriately. This implies we will have schema's for our web services, most of us who use contract first approach will nod our heads and say yeah (we are prepared for this world). Others I will leave to search Google and find out what I mean.

In addition by verifying XML signature on the chip and doing XSLT transformation we have taken the processor intensive task out of software and relegated it to the hardware making the messaging sub-system that much more faster.

In the past week or so I have been playing around and reading up on the CISCO call manager which allows one to send XML messages to the CISCO IP telephone, now with AON possibilities are limitless and I am exited :-)

Ohh well I am a nerd..................