This Blog Has Moved

I've moved this blog to my own domain. Here's the new URL:

http://tieuluu.com/blog

Widget Wars: OpenSocial vs. OpenAjax vs. W3C Widgets

The popularity of widgets these days has brought to attention the need for interoperability, i.e. for widgets developed for one site or platform to be able to run in other sites and widgets developed by different people to be able to work with each other. So much so that I know of at least 3 somewhat competing specifications for widgets. There's the gadget portion of the OpenSocial specs which was adopted from the Google Gadgets work. Then there's OpenAjax which is more broadly focused on Ajax interoperability but has a lot of pieces geared towards widget interoperability. And finally there's the W3C's Widgets 1.0 Family of Specifications. Based on a preliminary analysis, the OpenAjax specs appear to be the most comprehensive for widget interoperability issues but OpenSocial seems to have gained more adoption. The W3C work appears to be moving very slowly (no surprise) and it's unclear to me how much adoption they have. Right now my preference is the OpenAjax specs based on how comprehensive it is but admittedly I have not done a thorough analysis and comparison of the three. Plus, a spec that is too comprehensive may not always be a good thing, e.g. tends to be more complex and may be trying to standardize more than what's necessary. Stay tuned, I'll post a more thorough analysis once I've had more time to parse through each of them in more detail.

Why All SOAs Need ESBs

I've recently asked one of my developers to research some integration and middleware technologies for a project we're working on. After spending a couple days on this, he said to me "these things are all part of ESBs now". I.e. all the integration and middleware vendors have pretty much taken these capabilities and bundled them into their ESB platforms. "Oh you need a message bus? That's part of our ESB now." "Oh you need this adapter? That's included in our ESB." In most cases when you're implementing an SOA, you will need some piece of middleware or integration technology. With just about every vendor making these things part of their ESB suites, you're probably gonna end up getting an ESB even if you don't need a whole freakin' ESB. That's why all SOAs need ESBs (regardless of whether or not you really need them)!

Web Service Message Level Implementations

If you're like me and prefer working with the raw XML in your web service implementations instead of dealing with the mess of generated data binding code, this article will show you how to do so using JAX-WS and XPath. In this example, we use this approach to implement a WS-Notification consumer service that receives WSDM-based messages for monitoring the health and performance of services.

JAX-WS has the Provider interface that you can implement to get access to the raw XML message. You have the choice of implementing Provider<Source>, Provider<DataSource>, or Provider<SOAPMessage>. We'll be using the Provider<Source> in this example. The invoke(Source) method is what gets called to process a service request. We'll break down the implementation of that method step-by-step.

First we send the source through a Transformer to get a DOM tree that we can use for XPath processing:

DOMResult dom = new DOMResult();
Transformer trans = TransformerFactory.newInstance().newTransformer();
trans.transform(source, dom);

Next, we instantiate an XPathFactory and create an XPath that we'll use to process the DOM tree against. The third line calls the setNamespaceContext() method and uses a custom class I created that provides a mapping of namespace URI's to prefixes and vice-versa. You can find more information on how to implement such a class here. We need this because we'll be using namespace prefixes in our expressions.

XPathFactory xpf = XPathFactory.newInstance();
XPath xp = xpf.newXPath();
xp.setNamespaceContext(MyNamespaceContext.getInstance());

Now we'll process our first expression to extract the NotificationMessage elements from the message, passing in the XPath expression for the NotificationMessage and our DOM tree to evaluate the expression against. A WS-Notification message may contain multiple NotificationMessages so we get a NodeList in return.

NodeList resultList = (NodeList)xp.evaluate("/wsnt:Notify/wsnt:NotificationMessage", dom.getNode(), XPathConstants.NODESET);

Then we'll iterate through each item in the NodeList, i.e. each NotificationMessage, and process another expression against it to extract the ResourceId element and print it out.

String exprPrefix = "";
int len = resultList.getLength();
for (int i=1;i<=len;i++) {      
   String expr1 = "/wsnt:Notify/wsnt:NotificationMessage[" + i
       + "]" + "/wsnt:Message/muws1:ManagementEvent"
       + "/muws1:SourceComponent/muws1:ResourceId";      
   String resourceId = xp.evaluate(expr1, dom.getNode());      
   System.out.println("Resource ID: " + resourceId);
}  

The entire source code listing can be found here. You'll notice that the class has the following two annotations:

@WebServiceProvider()
@ServiceMode(value=Service.Mode.PAYLOAD)

The first one tells JAX-WS that this class is a Provider endpoint. The second one says that we only want to work with the message at the payload level, i.e. we don't need to access the message headers. In addition to these annotations, we have to customize the WSDL to mark the port as a Provider interface. This can be done by embedding the customizations directly within the WSDL or through a separate customization file. We'll do it using a separate provider-customize.xml file--you can find this file here.

Service Reuse

The more I think about the phrase "service reuse" or any other variation of it, the more I don't like it. I feel like it's making me think about services from a perspective that is too technical and too low-level. Reuse is something you want to achieve with code but you shouldn't be thinking about services as just code. When you're designing and building your services, you need to think about it from a much higher and more business-oriented perspective. You shouldn't be building a service because you think it's a great piece of code that other applications may be able to reuse. You build a service because it represents some significant capability of your organization that needs to be offered up to other units within the organization or external partners so that the business can operate more effectively. It's about sharing business capabilities and information, not reusing software. When you keep this in mind, you'll be more likely to build services that end up getting "more reuse" because you're providing valuable business capabilities or information that others need to use.

Extending Reuse to the Last Mile

While services make it easier to share your data and functionality, some developer still has to write the code to consume your service and present the results to the end user. In many cases, that code to consume and present a visualization of the service can be reused by other applications. This has already exploded on the Web with Facebook widgets, embeddable YouTube videos, blog traffic counters, etc., so what I'm talking about here is nothing new.

However, within the enterprise the use of shared UI widgets is still not very prevalent. This is problematic because it still leaves the creation of useful applications out of those shared enterprise services within the hands of IT. This really does not make the enterprise that much more agile at delivering useful capabilities to the end users. Real agility is achieved when end users can create those capabilities themselves by building lightweight micro-apps that are composed of various shared widgets for consuming and visualizing those enterprise services. These micro-apps can themselves be packaged up as widgets so that they can be reused within other apps.

So the next thing to do after you're done building those enterprise services is to start building some UI widgets for those services so that you end up with a portfolio of widgets that can be shared alongside your portfolio of services. This will extend the ability to share (or reuse) those services all the way to the end user, i.e. the last mile. You can think of this as sort of a "widgets-based architecture" that is built on top of your services-based architecture.

Don't Go Cheap With the Service Interfaces

Vendors need to realize that in this day and age service interfaces for their products should be a core feature. Unfortunately many vendors view them as secondary requirements and thus don't invest the necessary resources into their development. Often they are built in as an afterthought and usually by some junior developer on the team. The results are poorly designed service interfaces into the products with inadequate levels of functionality and poor usability. If I'm going to buy a piece of enterprise software, I'm not looking only at what functionality it provides, but also how well it will integrate into my existing environment. Vendors that get this will win the sales, vendors that don't will fall to the wayside.