Now here’s the strange thing: with all the concerns that go into design of components at all levels (from the enterprise architect down to the developers of the different components), one of the most overlooked things in SOA component building is the handling of cross-component error handling.

Error handling concerns

The fact that error handling is often the lowest-priority concern is doubly weird if you consider that cross-component error handling is the same concern as core functionality messaging. In both cases there are the same sets of concerns, both with regards to communication with external components and interaction between the component’s internal implementation and the communication layer. Some typical concerns that development teams have to deal with are:

Error message definition

Just as SOA components require clear definitions of the messages that will be exchanged with client components for mainline communication, clear definitions must also be given of messages that carry error information.

Error communication behavior definition

Just as mainline communication behavior between SOA components must be clearly and formally defined, so must similar definitions be given for when a component can send an error message in response to a request for operation.

Projecting exception types from the domain language onto error types from the communication language

In the case of error handling, this is one half of a problem that also exists for mainline communication. In mainline communication request messages must be projected onto domain model types and domain model types must be projected onto communication language types when the component returns a response. In the case of error handling of course there is no concept of request projection since nobody requests an error; however, the analog with projecting a domain model type onto a response communication message remains.

Maintaining component independence

This concern actually affects a component more as a consumer of other services than as a publisher of services. Maintaining component independence is related to avoiding domain models leaking over into foreign components (as Eric Evans puts it). In the case of messaging it means not building your domain model so that it is a mere copy of a foreign component’s communication model. In the more specific case of error handling it relates to not linking error handling too closely to the definition of errors used by foreign components. Instead, as with mainline messages, foreign component-generated errors should be projected onto the local domain model’s concept of errors or exceptions.

Balancing error handling strategies

Another concern in error handling (in addition to the ones mentioned above, which occur in all message processing systems) is introduced when communication layers introduce their own concept of error handling. A typical example of this is the WSDL/SOAP combination with its SOAPFault concept of error messaging. These built-in mechanisms can be very convenient in that they dictate an error handling strategy and leave you nothing to think about in your design. Not to mention that standardization is very valuable in these systems: it introduces an error handling strategy that everybody can agree to. However, there is also an inherent risk that these standardized error handling mechanisms will hardlink your component to a particular communication layer or framework (especially if the mechanism is allowed to leak through into the component’s inner domain model).

It is clear that each project must find a way to balance concerns in cross-component error handling strategy. Several strategies exist and must be considered:

Ignoring the communication layer’s mechanism

Doubtlessly the simplest strategy is to ignore the communication layer’s error handling mechanism. Instead one of several possible alternatives must then be considered. A simple alternative might be not communicating errors across components ever (this might for example be an enterprise policy) but allowing “empty” responses instead. Or else a project might define its own error reporting as part of regular messaging, creating either/or responses (i.e. responses that contain either a regular response or an error).

The upside of this strategy is its simplicity, plus the fact that it is guaranteed to keep the component implementation separate from the communication layer. However, client components (especially third-party ones) are not likely to appreciate the divergence from standardized mechanisms — making this a strategy that is only suitable for components that are for internal use only.

Using the communication layer’s mechanism

This strategy is more or less the other extreme of ignoring the communication layer’s mechanism. The choice here is to take the mechanism (and its reflection in the implementation language) and incorporate that throughout the component’s implementation. For example, a Java project might elect to use AxisFaults throughout the project instead of project-specific exception types.

Again, the upside of this strategy is its simplicity, plus its guaranteed interoperability with the communication layer. However, the component is now hardlinked to the communication layer. This is not necessarily a bad thing: there are projects and components whose purpose in life is linked to a single communication layer. A custom integration layer for different SOAP web services for instance might want to use SOAP Faults and related types for error handling (since it is technically part of the domain). In general though, this strategy will limit the component implementation’s future flexibility.

Mapping internal error handling to communication layer error handling

The final option seeks to combine the best of both worlds, separating the internal domain model from the specifics of the communication layer and allowing the two to touch only through a translation layer. This strategy also allows the internal component implementation to be linked to several different communication layers. For example, a component implementation might report errors using java.lang.Exceptions. Different translations might translate these exceptions into SOAP Faults for a SOAP web service publishing, a JMS exception for JMS and a specific error page for a RESTful service.

Architecturally this probably sounds like the go-to strategy for all situations. And factually this is probably the option that most projects will want to use, since relatively few projects want to be hardlinked to the communication layer. However, it is more work to implement, especially if the projection of domain errors onto the communication layer is not simple to implement.

Conclusion

Error handling is one of the most overlooked topics in the design and implementation of SOA components. However, it is at least as important as the design and implementation of mainline messaging and functionality, for the same reasons. And like mainline functionality, error handling requires some careful forethought and weighing of options. Different strategies are available, each with its own characteristics with regards to implementation difficulty and ease of use. Projects must consider very carefully which strategy fits project goals and expected future usage patterns.

MOOSE?

The term MOOSE comes from Forrester. Executives often look at IT spend as a black box and compare it as a percent to overall revenue. Maintenance and operating the IT organization, systems, and equipment (MOOSE) takes approximately 70% of IT budgets (Forrester: the October 18, 2005, “Defining The MOOSE In The IT Room” report.). The remaining 30% comprises investments to support business growth, to cut business cost, and to cut the cost of IT MOOSE.

Macro-economics conditions shaping the CIO´s job currenlty. The reality is that any business at any time may need to shift its executive focus toward running lean.

The question is how will SOA and BPM help the CIO Invest more in New and Improved Capabilities to support business growth and therefore to Reduce the Cost of Business and above all Cost of IT MOOSE. Seriously, I doubt that we can hold our claim that SOA and BPM are bringing the CIO those benefits. Besides the argument of Cost saving, we also hear the arguments for Business Agility and Compliancy. I will not go into Compliancy and connected to it Security, it´s to broad for this blog but Agility is also something to think somewhat more on.

SOA has lost his meaning

Burton Group VP and Research Director Anne Thomas Manes recently said,

“I’ve talked to many companies that have implemented stunningly beautiful SOA infrastructures that support managed communications using virtualized proxies and dynamic bindings,” says Manes.

“They’ve deployed the best technology the industry has to offer – including registries, repositories, SOA management, XML gateways, and even the occasional ESB. Many have set up knowledge bases, best practices, guidance frameworks, and governance processes. And yet these SOA initiatives invariably stall out.”

Well maybe these companies should have spend less time installing software and building frameworks and more time understanding what business processes could be impacted by removing poor interfaces or eliminating bottlenecks or providing needed information faster.

So what happened to our simple view of SOA? How many services do I need to be able to talk of a SOA? Do I need an ESB, Governance tool, Registry to be SOA compliant? Or is just enough to have Just a bunch of Webservices (JABOWS) with a ping function to see if the Services are still alive? What happened is that software vendors have hijacked the SOA term for their marketing needs, analysts have created new categories with accompanying revenue streams and many consulting firms have turned SOA into big-bang infrastructure projects. With all the vendor hype SOA has lost its meaning and in many cases has lead to exorbitant costs with little or no business value.

What About Agility?

Max J. Pucher have some interesting thoughts on it, which are in line with my thoughts when it comes to BPM and Agility as you could read in my blog-item on “What does Route Planning has to do with Business Process Management?”

As much as some business management theorists might disagree, a business is not a machine but a complex adaptive system because it consists of people and has people as customers. We need to understand that it is not the process that shapes the business by shaping what people do; it is the people that shape the process and that in turn shape the business.

Agility is a human skill and will never be a software property. The more software is used to replace people and the more processes and decisions are automated the less agile businesses will become.

Max mention in his blog an example coming from M. Hammer which is a comparison with an American football team. While the coach trains with the team possible plays (processes) he does not step out on the field and controls the game. A player (process owner) called the ‘offense coordinator’ dynamically selects and positions players for each offense. Players all have very different roles like workers in business. They are trained by special ‘position coaches.’ Offense coordinators and position coaches draw from their extensive experience to shape the team to dynamically react to any opponent. It is this teamwork between coaches, coordinators and players that we need to achieve in daily business operations. Strict process management or vertical applications are unable to provide that. What a business would need is a software system that can learn to act as an ‘offense coordinator’ and ‘position coach’ from its user’s experience. It assigns work to user roles and supports these in how to act in the current play without restricting their ability to shape the play.

Using the football team comparison offers another insight. While the team is given the freedom to play the game as it sees fit, it still has to follow the rules of the game. The same is true for business. Therefore it is essential to understand that user role coordination and coaching does not replace or interfere with the (business) rules that make up the game. Rules are rigid by design, coordination and coaching cannot be.

But the conclusion must be a business is what it does, despite what the CEO or organization department wants and what is modeled in a BPM tool either using a SOA or not.

Call for Innovation

Let us stop reinventing the wheel as correctly pointed out by Ben. My goal is to fullfill the one of the 7 challenges pointed out by Gartner this week in Las Vegas. Let us improve developer productivity with a factor 100 and let us do this with in our mind that its the (business) people that shape the process and they should be helped and not hindered.

Kind Regards

Freddie van Rijswijk

The first thing…

The first thing that happened is that I moved to my new project and found myself in a discussion about dealing with the consequences of earlier choices about how to deal with the overall application domain in the context of an application that will exist of a number of different, independent components composed using Web Services. As you will have already guessed, my new project is trying to implement a SOA (with service components that will later be part of a larger SOA).

The situation the project was in had developed from an attempt at implementing SOA by the book (in a somewhat reversed style). As we all know by now, the main tenet of SOA is that it allows you to take specialised components that deal with a single task well and combine them into larger services or applications with business meaning. Of course one might also reason (as my new project had done) that this means that you can take the specification of a new application and decompose it into functionally separate and specialised blocks. Implement these separately and compose them using web services et voilá: instant SOA.

To ensure that the different components would fit together (especially when communicating over the wire, but in general as well) it had been decided that all XML schemata and all implementation classes would be derived from the overall, conceptual domain model. Specifically, the model would be captured in a single set of implementation classes and shared across all the different components. The same model would be reflected in the XML messages passed between components.

When I arrived the project had become embroiled in problems related to tight coupling of its independent components. On the design side the use of a single domain meant that each component had to compromise in how well elements from the domain were suited to its purpose. On the implementation side, using a single domain package in all components meant that every change in any one component meant a rebuild and redeployment of all components.

The second thing

The second thing that happened was a discussion I had with a colleague about an MSN message he had written. He had used the word “enthousiasts”, after which I chided him about speaking “Nenglish” (English mucked up with Dutch influence). A search through a diary proved that he was correct, enthousiasts is perfectly good English — in British spelling.

It took a little time for it to sink in that, even though he had misspelled the word in my eyes, I still knew what he was talking about. Even though it wasn’t my spelling, the concept of what he was saying had rung a bell in my head. One might model the situation like so:

What is illustrated by this diagram is that two people can speak different dialects of the same language yet share the meaning of words and concepts. They each have a language of their own, yet somehow both also “know” a second language that both share, speak perfectly and can use to communicate relatively flawlessly.

So what does this teach us about SOA?

The two situations described above teach us an important lesson about the role of domains and DDD when implementing a SOA: each component within a SOA has to deal with multiple domains, should be aware of this and should be allowed to do so.

A typical component in a SOA has a number of connections to components in the outside world. This is because a typical component in a proper SOA does a single task and does this well and is therefore of interest to other components within the same SOA. And of course, the component itself might use other components to complete its task, for the same reason. So let us say that a given component offers N services to the outside world and references M other components. I then claim that the component has to deal with N + M + 1 different (but obviously related) domains, N + M + 1 separate languages. N languages that it shares with its clients, M languages that it shares with its referenced components and one more: its internal domain that it uses to do its job so well. In practice of course not all these languages will be distinct (or at least not completely); there may be overlap or shared communication languages. But conceptually N + M + 1 is the number and this fact should not be feared but rather respected. After all, it is this fact that allows components within a SOA both to be efficient and proficient at their own tasks, yet interoperate with other components at the same time.

Developing a single component within a SOA is all about performing a single task and doing that right, then passing the results on in a usable form. In that respect SOA is just a reinvention of the Unix command line tools. Tools like sed, grep, ls and so on don’t all do the world — they do one thing, do it well and allow their results to be piped in to the next tool in the chain. At the same time, no single tool cares about how the previous tool reached the results it did — just that it did. SOA components are much the same.

It is at this junction that we reach DDD. Each SOA component deals with a single, solitary, complex problem. A problem no other component in the same SOA deals with, nor should. DDD teaches us that complex problems should be based on a domain suited to solving that problem and that that domain should be the primary focus of the component. The component should care about how to solve its own problem well; it should not care about what anybody else is doing beyond the extent of getting needed data and passing it on.

Moreover, DDD teaches us that the domain is divided into a number of different pieces. One of these pieces is focussed strictly on solving the actual problem (this is called the core domain), the other pieces are ancillary to accomplishing the task at hand. Some ancillary pieces might focus on communication with other components whose focus is on other problems. Eric Evans refers to this as repositories or in the extreme anticorruption layers (which prevent one model from leaking into another). It is therefore not at all unusual to see a structure within SOA components as illustrated on the right.

The figure on the right illustrates a SOA component, which offers a business service. This service is accomplished by leveraging a specialised domain model, tailored to the problem at hand. At the same time the component does not live in isolation — it is published to other components and connected to underlying services. But the publishing and the connecting are not part of the component’s core domain; these task are undertaken by ancillary components. And a prime task of these ancillary components is to translate between the component’s own domain model and that used to communicate with other components. Let there be no mistake, these are anticorruption layers in the literal sense of the term: they allow component to be specialised and service-specific domains to exist in isolation without being corrupted by the needs of the domain of every other component in the same SOA.

Of course that does not mean that each domain of each component within a SOA is completely unrelated to all others. There will by necessity be overlap in the concepts that are captured by two communicating components. However, in order to allow for an optimal solution to the individual problem addressed by a component it is necessary for that component to have full freedom in how it embeds that shared concept within its own domain and how much weight it carries within that internal domain (one man’s priceless is another man’s worthless after all).

At the same time a SOA component is completely worthless if it cannot communicate. It must therefore be able to deal with the communication domains that it shares with other components (the first step in moving from the domain of one component to the domain of the next). The techniques that DDD teaches us for dealing with communicating domains are therefore essential to building SOA components that strike the right balance between interoperability and optimized problem solving.

And so, once again, we see that moving to a new technology and a ”new” architecture is no reason to forget everything  we have learned. In fact, if anything, it shows the importance of recognising “new” ideas for what they are. If you know which wheel is being reinvented, you know which tools you must reinvent to make it run properly as well.

Reference: Domain Driven Design: Tackling Complexity in the Heart of Software

Nowadays, SOA has come along, and suddenly all enterprise architects want XML web services everywhere. For some reason, many think of SOA as a synonym for “everything must be a web service”. What SOA really is, is not the topic of this article. I want to discuss the position these web services get in the overall picture.

The “Business logic” layer could contain business services that are useful to other applications too. In that case, it might be an option to provide these business services to the “outside world” as XML Web Services. So, the user interface is separated from the rest of the application and replaced with a Web Services interface layer. The business logic is now available to all applications that need it. The user interface that had just been removed is now considered another application that uses the business logic layer through a web services layer.

On paper, it might not even look that ugly. There are, however several major downsides to this approach.

First of all, performance is decreased, as XML Web Service calls cost a lot of processing time. Not only marshalling the request and the response take a lot of time, but HTTP communication takes its toll too.

Something developers will notice, especially after the first release, is that this choice of architecture is difficult to maintain. Most changes that have been requested involve the user interface; a little more information here, something else there, etc. However, to get this information to the front-end, changes have to be made in the business logic, domain model and or the Web Service interface.

The third downside is that the “Business Logic” layer and the “User interface” layer are (often) functionally coupled. The main functions exposed in the view have almost a one-to-one mapping to business services. Splitting these two layers into different application would then sound inappropriate.

So why is this apparently homogeneous application split up into different components?

One thing I have heard is that this is the way SOA prescribes it should be done. I’ve read many documents and specifications, but I have never found a single one that says so. It might be obvious that I disagree.

Another excuse is “versioning”. For some reason, people think more of versioning as a problem than as an opportunity. When done right, versioning of a web service should be a big problem. But a more important question is: why should you version a service? Probably because the business rules in the business logic layer have changed. If that is the case, why keep the old version alive? It uses a deprecated business logic layer. Another reason to version is because the request/response model of the web service doesn’t provide all available information. That can be easily solved by adding either a new service, or an optional parameter to the existing request indicating an extended response is wanted. In my article about Web Service versioning in Java, I go more in-depth on ways services can be versioned (limiting to Java).

However, the most common excuse for the separation is reuse. “Maybe, in the future, more application might want to use this functionality too” is a sentence I have heard more than once too often. Will the business logic ever be used by another application? If that is the case, will the request/response model chosen sufficient for that application? Big chance that the answers are respectively “Most probably not” and “Very little chance”.

It is obvious that I am not fond of this solution. Not because I don’t think it really sounds right, but because I have dealt with this structure in my day to day work. Not somehting I would want to wish you.

I prefer to see the analogy between the User Interface (UI) layer and the Web Services (WS) layer. The UI presents an Business Logic interface to human users. HTML is usually the format of choice. A Web Service layer is exactly that, but then presents the same functionality in another format. For example as SOAP/XML messages. Or as JMS messages on a queue. And let’s not forget REST.

When you see the analogy between the UI and the WS interface, an architectural layout as the image on your right is a good option. In this picture, I have drawn a single “WS” box, but there could be more, depending on the types of services you would like to expose. I have, however, never seen more than one WS interface type in an application, and it usually is a SOAP based web service.

The application is still usable by other applications, accessible for other users and a lot easier to develop. There really aren’t any concessions to be made compared to the completely separated variant. Furthermore, the Web Service only has to be added at the point in time another application actualy needs it. This allows the request/response model to be designed in such a way that external application can take full advantage of the business logic.

I am conviced that the last option provides the most possibilities with the least concessions. And isn’t that exactly what we want? Or did I really miss something? In that case, please leave a comment and let me know.