Saturday, December 30, 2006


Joe McKendrick has an interesting post on opportunity areas for SOA. One in particular I would like to expand on. Here is his quote:

An effective, functioning service-oriented architecture requires governance, and the ability to share services across multiple business units and enterprises. It’s easy to build Web services. You could build 10 of them in an afternoon. But, then you end up with a JBOWS architecture (Just a Bunch of Web Services), which will grow into a different sort of SOA — a Spaghetti-Oriented Architecture. SOA requires orchestration between the services and governance. This is an opportunity for those proposing or offering governance tools and methodologies as a way to clean up a growing tangle of point-to-point services.

I have a very difficult time when talking with developers about this topic. Most developers I speak with are very creative. They like to write code and there is a strong since of ownership. There is really no faulting them for this. These are traits normally seen as good in an individual developer. However when taken in the Enterprise context, they can be a harmful factor. These code warriors are very distrustful of third party solutions that have to be intermixed with their own solutions. Things come up like: Unnecessary hops, transaction overhead, more failure points, span of control, I can do it better myself, etc.

These are all valid concerns. However as we move into the SOA world, the role of the intelligent intermediary is crucial. Having each developer write their own policy management implementation, their own content based router, their own security handler, their own orchestration engine seems to make little sense. What about the governance aspect around service registration and usage? How do you know who is using what and in what context? Where is the latest version of the interface spec?

My position is without the intelligent intermediary (Both tools and people) in the SOA infrastructure, you will end up with the same brittle architecture that is represented so well in the traditional spaghetti diagrams. However the impact to the enterprise will be far greater than before.

Here is a simple example of the problem. Let's say I create a nice interface into my trouble ticketing system. The trouble ticket vendor is following the Web Services trend so they expose their API via Web Services. I pass along the interface definition (The WSDL) to the team that commissioned my work. All is well and good.

The team being the sharing type (stop laughing) decides to share the WSDL with anyone who asks. And they tell two friends and they tell two friends and so on and so on. I now have a lot of very different uses of the original interface of which I know about only one.

So now let's say the original team now comes back and wants a modification or it's time to upgrade the trouble ticketing system or there is a planned outage/maintenance. Who do I notify? How critical are the other applications that are using the interface? What context are they using it in? How do we regression test all that stuff we don't know about? This isn't some code someone has checked out and incorporated into their own. This is a live running interface. The impact is immediate.

The intermediary is critical in helping establish the governance for SOA. It plays many roles and may consist of multiple products. It may also be played in part by people. Web Services Management, ESB's, Registry/Repositories, Policy Enforcement, Governance, XML Appliances are all things that make up what I consider the intelligent intermediary. Without governance (both runtime and design time), a Service Oriented Architecture is doomed to repeat the past.

This probably seems obvious to most but in practice it is more difficult than one would think.

Friday, December 29, 2006

XPath Query

One minor annoyance while working with Celtix (not really a Celtix issue) was a content based routing test. One thing you find out when working with open-source projects is that they can be made up of many open-source projects. I had the following issue with an XPath query.

This query:

//urn:CustomerAccount/urn1:accountdescription = 'yoda'

Is really not the same as this query:

//*:CustomerAccount/*:accountdescription = 'yoda'

In Celtix ESB land, this last query (which is a valid XPath query) throws an error. It turns out the XML parser they are using does not support wildcards like this. Instead it will match any prefix as long as the prefix is presence. In other words, urn1:CustomerAccount and urn:CustomerAccount will both match the query. That's cool once you know it, but it is annoying when you don't. Dom4j is the culprit. No relation to Celtix but used in Mule which is used in the Celtix ESB.

You just have to do a little family tree tracing when using open-source solutions.

Wednesday, December 20, 2006

JAX-WS, WSDL and Tools

I've mentioned that I'm looking at Celtix's Open-Source ESB. One thing you notice right off the bat is the incorporation of the new JAX-WS standard. Annotations in particular make it much easier to expose an existing java service as a web service or create a new one as a web service.

Here is an example -

Interface Definition

package pgn.objects.wsdl.full.devservices.customerrequest.ver1;

import javax.jws.WebParam.Mode;
import javax.jws.WebParam;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding.Style;
import javax.jws.soap.SOAPBinding;
import javax.jws.WebMethod;
import javax.jws.WebResult;

* This class was generated by the CXF 2.0-M1-IONA
* Wed Dec 13 15:45:39 EST 2006
* Generated source version: 2.0-M1-IONA

@WebService(wsdlLocation = "file:/C:/IONA/samples/service_creation/customerinfo/wsdl/
customerrequestver1.wsdl", targetNamespace = "urn:pgn:objects:wsdl:full:devservices:customerrequest:ver1", name = "customerrequestPT")
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE, use = SOAPBinding.Use.LITERAL, style = SOAPBinding.Style.DOCUMENT)

public interface CustomerrequestPT {

@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
@WebResult(targetNamespace = "urn:pgn:objects:xmlschema:messagetypes:devservices:
customerrequest:ver1", partName = "CreateCustomerResponse", name = "CreateCustomerResponse")
@WebMethod(operationName = "getCustomerRequest")
public pgn.objects.xmlschema.messagetypes.devservices.
CustomerResponseType getCustomerRequest(
@WebParam(targetNamespace = "urn:pgn:objects:xmlschema:messagetypes:devservices:
customerrequest:ver1", partName = "CreateCustomerRequest", name = "CreateCustomerRequest")
CustomerRequestType createCustomerRequest

The annotations defined the communication style and structure that match what is in the WSDL.

An excerpt of the implementation of the Interface
package pgn.objects.wsdl.full.devservices.customerrequest.ver1;

import pgn.objects.wsdl.full.devservices.customerrequest.ver1.
import pgn.objects.xmlschema.messagetypes.devservices.
import pgn.objects.xmlschema.messagetypes.devservices.
import java.util.*;

@javax.jws.WebService(serviceName ="CustomerRequest", portName = "customerrequestPort", endpointInterface ="pgn.objects.wsdl.full.devservices.customerrequest.ver1.CustomerrequestPT", targetNamespace ="urn:pgn:objects:wsdl:full:devservices:customerrequest:ver1") = "")

public class Customer extends Thread implements
CustomerrequestPT {
CustomerRequestType requesttype;
CustomerAccountType accountinfo;
String programname;
Notice the two annotations. That's really it for exposing this as a Web Service. Now for the important part. The interface was auto generated by some of the bundled tools in the Celtix distribution. It is important to note that the implementation interface was generated from the WSDL (which was written first) and not vice versa.

Joe Mckendrick points out that tools can make it easy to generate your interface definition (WSDL) from an existing implementation. I think the generally accepted best practice is to develop the WSDL and XML Schemas first. Hopefully following that approach will lead to a less brittle interface that has the right granularity. It should also help reduce the potential number of interoperability issues that can arise from auto-generation of Web Services from existing code.

As far as Celtix goes, if you are looking for an Open-Source ESB to mess around with, I have found Celtix's to be straight forward to work with so far. I haven't really done anything over than some content based routing tests and fail-over routing.

Monday, December 18, 2006


Fuzzy put the tag on me so here I go with five things most folks don't know about me:

-I was a Captain in the US Army National Guard for 8 years. I commanded a M1 Tank company as my last assignment. I even jumped out of working airplanes. Now I write software, sure they go together. :)

-I was a history major in college (East Carolina University - Go Pirates). I took a Fortran class with punch cards and hated it. Now I write software.

-I lost the conference championship singles tennis match my senior year of high school after going undefeated during the season. Still #$% me off when I think about. But I choked in that match.

-I was a horrible student but I really enjoyed High School and College.

-My favorite thing to do is watch the new Dr. Who with my eight year daughter. Actually any with the family is on the fav list. We have a great time together.

Okay for the victims, I'm tagging Mark Carlson, Nathan Lee, Todd Biske, Scott Mark, Sam Lowe.

Friday, December 15, 2006

Open SOA Collaboration

Sure it sounds good but unless Microsoft is playing it won't matter. It's a sad fact but Microsoft is a pretty dominate player in corporate US. This will go the way any other thing goes that doesn't include them.

Friday, December 08, 2006

Celtix ESB

Iona released their latest version of Celtix Enterprise ESB as an open-source offering. I've been toying around with this product a bit. I was impressed at the initial install and configuration. It worked right out of the box which can be a bit unusual for open-source products.

The thing I liked the most is the lightweight nature of the product and the ease of configuration. In particular I liked the routing functions, content-based, fail-over etc. They have several good samples included with the product to get you started. The documentation is not bad for an open-source product although the configuration files that drive most of the functionality could use a bit more documentation.

I'm not sure I would deploy this as a main ESB solution but it might be a good addition to an existing infrastructure. Particularly where you might want to deploy some lightweight distributed components. Overall a very good effort. I'll post more on it as I dive deeper into it.

Monday, December 04, 2006

Web Services ''Reuse'' is Number One Driver For SOA @ SOA WEB SERVICES JOURNAL

Here is another study on reuse and SOA. The main point of the article is that reuse is the number one benefit in adopting a SOA strategy. Of course the research is sponsored by a vendor whose product happens to be...yes that's right a registry and repository. The study goes on to say that most don't have a registry or repository. Surprise! No not really.

Do you think the lack of a registry is holding back reuse? Not me. I think complex business logic is difficult (if not impossible) to reuse. There are probably some enterprise wide services, but not a lot, that have the potential for reuse. Most services I suspect will not be in the enterprise category but more specific to lines of business.

Of course the other factor is the type of business you are in and the types of IT systems you use. SOA is not a cookie cutter approach but unique to each business. Ther e is no one size fits all in my opinion.