Attended a WSO2 practical SOA workshop yesterday. It was quite good. Quick summary.
WS02 http://wso2.com is an open source middleware company. One of its main offerings is a product suite called WS02 Carbon which is conceptually similar to something like Oracle Fusion. It consists of number of individual middleware products such as ESB, Services Application Server, Business Process Server, Business Rules Server, Governance Registry etc…
One good thing about WS02 product suite is that is built from ground up, it is componentized and it’s well integrated. That is one of the advantages over other commercial offerings as lots of their individual products have been put together by acquisition and made (or forced) to work together.
I have had a bit of experience with middleware products from different vendors both commercial and open source such as Oracle Fusion suite (BPEL, ESB, Rules Engine, Mediator etc…), IBM (WebSpere ESB, WebSphere Process Server, Message Broker etc…), JBOSS (jBMP, ESB) and can confirm that open source offering such as WS02 are truly lean products compared to their commercial competition. Being open source based they are lean in development, methodology, delivery, governance as well as licensing. From my experience quality of the open source products is also generally higher. Less is more. To be fair commercial offerings often provide better tooling, training, documentation and support.
Number and calibre of WSO2 customers is also impressive. It consist of some globally recognised companies mostly in Europe and US (this seems to be the common trend for open source and WSO2 is currently working on creating a bigger footprint in Australia).
Workshop presenters were very knowledgeable and honest about SOA. They presented some real life industry examples of good and bad SOA implementations. Just because companies use the SOA middleware and know SOA theory does not mean they always know how to apply it correctly. Not entirely their fault as there could be number of constraints on their designs such as legacy, political, financial etc…. It comes down to basic principles of minimizing data dependencies, low coupling and using the right technology (middleware tool) for the given problem. Creating a “sane” granularity of the services, equally well balanced message model and separating the domain model from the message model. More coarse grained service and more abstract message model will produce more robust and stable service.
All in all, with complimentary pen, notebook, poster, lunch and coffee a day well spent!
