A Single Sign-on implementation

If you are looking to implement a Single Signon implementation, then a worthwhile library to look at would be OpenSAML 2.0. The 2.0 library is well written and much more intuitive to use compared to its predecessor - OpenSAML 1.0. I recently implemented a SAML 1.1 solution using the 2.0 library on Weblogic 8.1. The library by default is for the Java 1.5 platform, however using Retroweaver, one can use it for Java 1.4 (since Weblogic 8.1 does not work with Java 1.5). The SAML Browser/Artifact profile is pretty easy to understand and implement with the library and good ol' Wikipedia gives an easy explanation of the steps needed to get the communication going. However, I would recommend that you read through the OASIS SAMLBind document to get a better understanding of implementation details.

I used Xfire (v1.2.6) to implement the Artifact Resolution Service at the IdP that the Service provider invokes once it receives the artifact posted to it. Since the OpenSAML library works with the raw xml document, one needs to configure xfire to prevent marshalling of the incoming xml to java POJOs. XFire has a cool way to work with raw xml documents, using a binding called as Message Binding. So the xfire service interface looks like:

public XMLStreamReader invoke(Document samlRequest) throws Exception

and the OpenSAML library can then work with the DOM document using the XMLObjectBuilderFactory request factory.

Some quirks here - while returning the response, I had to return an object of type XMLStreamReader - I used W3CDOMStreamReader to convert to this type. Also, for getting SOAP faults correctly, the interface definition of the service had to throw the base "Exception"class and not a specific exception type.

While the implementation does add a bit of added complexity through the use of XFire, it works out pretty well and allows one to use these excellent libraries -XFire & OpenSAML 2.0 - together to leverage the best of both.

The solution is on its way into production this week - fingers crossed....:).

SOA - how does one discover services??

Lately in the SOA yahoo group, I was involved in a discussion about what one would consider a successful SOA implementation. Given that SOA really has to be considered from a business perspective, there are very few case studies out there that provide details about the business specifics of implementation. These case studies only talk about the integration of various systems. Very disappointing and frustrating for people to learn from.

A successful implementation of Business SOA really has to outline and give details about the process of service discovery (business services more specifically) and how an organization goes about outlining the Service architecture map that helps it to zoom in on those services that provide strategic /tactical advantage versus ones that are more utility services and could probably be bought. KPIs around these business services would then help the organization measure the benefits of these business services in the strictest sense in line with its strategies.

So, as I research on SOA, those interesting case studies elude me - however the best source of material I've come across has been from Steve Jones (CTO, CapGemini). In general though, service discovery comes very close to the methodology of discovering domain objects in an enterprise wide system. As Steve has eloquently put - services tend to be around functional nouns, so "Order Management" is a good example, it will have capabilities that are the verbs "newOrder","createDispatch", etc and it will have priorities for its operation e.g. availability, response times, dispatch sizes etc.

It definitely seems like OO design, however this discovery has to be top-down, with business folks heavily involved throughout service discovery. Most organizations struggle with that, but maybe there's light at the end of the tunnel as the industry gets a better understanding and feel for SOA and what such undertakings really require an organization to do.