Posts Tagged ‘advices’

Protecting your services with a simple fuse..

Michael Nygard, in his book Release It! Design and Deploy Production-Ready Software describes a pattern he called Circuit Breaker. It is based on the idea of fuses, that is, anything that may be dangerous should be put around a safe structure, that may disable the operation requests if it has any chance to do any harm to the application itself or others. It is best described through the image (click to enlarge):

The Circuit breaker pattern, as described by Michael Nygard

The flow is like that: the dangerous operation has the fuse as a shell. The first state, “closed fuse”, has a counter of failed invocations and a threshold. When the client produces an invocation, it allows the invocation to pass through. If the call succeeds, then resets the counter. If it fails, increment the counter. If the counter reaches the threshold, it disables the fuse, going to the “open fuse” state. This state has a variable that represents an ammount of time and another one representing the moment in time when it has become the active state. Any call to the dangerous operation in this state will cause it to fail without even invoking the operation. When it is in this state for the amount of time specified in the variable, it decides that the call deserves another chance. So the invocation goes to the “half open fuse”. This state tries to invoke the operation again. If it fails, go to the open state again, resetting the timer. If it succeeds, go to the closed state again, resetting the counter of failed invocations.

OK, nice pattern, but what does it have to do with SOA?

The magic in this pattern (and the whole book) is that it brings light to subjects that most developers don´t give enough attention. One of these subjects is that you cannot rely on the network. Final. I have never seen any thrustable network (and I believe you haven´t, too!), so, as long as SOA is a kind of distributed architecture that relies on the network and we cannot rely on the network, so we can´t rely on services either! So, as long as services are unthrustable, we can apply this pattern, to:

  • Ensure that we won´t get stuck waiting for services that might never return;
  • Ensure that, if the server that is holding the web service is drowning from lots of invocations, at least we are not the ones that are gonna disable it for good;
  • And many many other good reasons to do so. Read the book 😉

As Michael himself doesn´t give any hints on the implementation of such a pattern, I decided to implement it, and you can download it from the downloads section. It is very simple, as it doesn´t allow only web services to be invoked via the pattern, but any other kind of dangerous operation too. You can modify the code the way you want to achieve your desire. My hint is that, allied to stuff like AOP and interceptors in general, you may do it the ultimate solution to never, ever have this kind of problem again.


Patterns of System Integration #1: Services mediator

Disclaimer: this pattern does not refer to Oracle´s SOA Suite 11g Mediator, nor any Thomas Erl´s Patterns (although it looks like the implementation of pieces of some of his patterns).

So, give me a brief description on what it is about.

People who are used to work with SOA are, usually, used to work with ESB´s – I say “ESB´s”, plural, to mean different kinds from different vendors of ESB – and BPEL. ESB´s are often used to justify decoupling of clients from service providers. I think it is great, but people usually forget that ESB´s, as long as they are too decoupled from the system, do not provide so much advantages as it should. So, usually, ESB´s are a layer of extra complexity to systems (the exception are some odd situations that don´t fit the usual description). Sometimes, you need some piece of software that is more intimate to the system, that can interact in an easier way to the system (like some easy way to audit calls, log them, place warns on whether systems are responding or not – therefore avoiding issues on being overloaded due to slow responsiveness of external services -, etc.). So, thinking about it, I developed this pattern.

Explain it better, what is it about?

People need to be in control of their applications. People should be in control of their applications. Usually, that´s not what happens to a SOA-based app, because we rely too much on external tools and forget that good things may be done at home, too. So, you don´t need to use a service composition to audit external services I/O, for example. If you would do so by today´s standards, you would build a service to do the auditing, then group the external service and the audit service into one piece of service composition, then offer the composition´s contract to the client… too much work. You should not build separate services unless you need them as services (after all, SOA is about getting the IT to work along with the business, right? So, it should not try to add extra pieces of complexity, like one more service, to the business, right?); so, you should approach the problem with another solution, like intercepting the messages according to your programming language way of doing so.

So, my pattern is about intercepting outgoing messages / incoming responses by building transparent, language-friendly units, in a manner that, if you need extra capabilities but do not want (or do not need) to build extra services, you should consider applying this pattern.

How to do it?

First, you should take the original WSDL and override it, replacing the original address – a technique shown here. I´m gonna call this service “shell service”, from now on. The shell service´s purpose is to provide the capability of adding this extra logic, which means it should be built in the main programming language you use in your application. To build it, you should use the same logic as the mentioned post, but should modify the provider to something like the following:

package com.alesaudate.webservices;

import javax.xml.soap.SOAPMessage;
import java.util.Iterator;
import javax.xml.namespace.QName;

public class SOAPProvider {

	public Dispatch<SOAPMessage> getDispatcher (String wsdl, String namespace, String servicename, String portName){

		try {
			//create a representation of the service
			Service service = Service.create(new URL(wsdl), new QName(
					namespace, servicename));

			final Iterator<QName> ports = service.getPorts();

			QName methodToBeCalled = null;

			//Select the port to be called
			if (portName == null)
				methodToBeCalled =;

			else {
				while (methodToBeCalled == null || !methodToBeCalled.getLocalPart().equals(portName)) {
					methodToBeCalled =;

			//Create the dispatcher, given the data.
			Dispatch<SOAPMessage> dispatch = service.createDispatch(
					methodToBeCalled, SOAPMessage.class, Service.Mode.MESSAGE);

			return dispatch;
		} catch (Exception e) {
			throw new RuntimeException("Error calling web-service", e);
package com.alesaudate.webservices;

import javax.xml.soap.SOAPMessage;

public class MySOAPProvider implements Provider<SOAPMessage>{

	public static final String ORIGINAL_WSDL = "http://localhost/SampleService?wsdl";
	public static final String ORIGINAL_SERVICE = "sampleService";
	public static final String ORIGINAL_PORT = "samplePort";
	public static final String ORIGINAL_NAMESPACE = "sampleNamespace";

	private SOAPProvider provider;
	public MySOAPProvider() {
		this.provider = new SOAPProvider();

	//You may add any extra logic here.
	public SOAPMessage invoke(SOAPMessage request) {
		Dispatch<SOAPMessage> dispatcher = provider.getDispatcher(ORIGINAL_WSDL, ORIGINAL_NAMESPACE , ORIGINAL_SERVICE,ORIGINAL_PORT);
		SOAPMessage response = dispatcher.invoke(request);
		return response;


Just to remind the reader, I would like to mention that this technique has been shown here.


I have shown here a design pattern that I call Services Mediator. Basically, it is the same that an Enterprise Service Bus does, but with the difference that it must be implemented in the same language that the application uses, providing, then, more control to the application programmer. So, at any time the services need some business logic, but does not necessarily need to use services to do so, the programmer may add this logic inside the services shell.

A Simple Explanation on what an ESB is…

Today, I would like to say just a few words on ESB´s. As you may know, I´m a Java developer, but I work specifically with SOA (Service-Oriented Architectures) and Service-Oriented Computing in general. So, my day-by-day tools include not only those of Java, but some known as belonging to SOA stack, like BPM, BPEL and ESB.


ESB is an acronym for Enterprise Service Bus. It is a tool designed to provide flexibility to SOA, and refers often to the Message Broker pattern. It´s use often provides flexibility to SOA, but, indeed, adds more complexity to the overall architecture.

Generally, an ESB must provide or enhance the following features:

  • Services virtualization
  • Services security
  • Services management
  • Services availability
  • (other) SOA Messaging Patterns
  • WS-* specs support

Services virtualization

To be succeeded on its intent, the Enterprise Service Bus must have the ability to “hide” the underlying services. Such capability is achived by deploying services on the very own ESB, with abstract service contracts, or by “hiding” them, providing a new service contract and then routing messages to the underlying implementation. This capability is very important because by doing so, the ESB can:

  • Re-route messages (for example, if a service is not available, it may call another one instead)
  • Add security and SLA (Service Level Agreements) layers
  • Group (or split) service capabilities from (or to) several different service contracts
  • Hide informations on implementations (for example, suppose that that we don´t want the client to know that the underlying implementation is a JMS service – yes, it can be one!)
  • And the main purpose: provide service decoupling

The last quoted capability is so important that it deserves its own explanation: the structure of a concrete service contract includes a section where the service address is specified. But, suppose that I can not guarantee that this address will always be the same. If this service address changes, all clients will be impacted, and, for sure, that is not what we expect when implementing SOA. Also, suppose that a service model changes (which, of course, is highly undesirable if someone wants to succeed when adopting SOA, but it may happen in the real world). The ESB may completely override service contracts, routing messages to the real implementation and even transforming messages so the can be compliant to the real implementation (just a note here: transformations, in SOA, are very undesirable as they decrease the system performance, but, still, they may be neccessary).

Services security

Suppose that you want a given service to be secure. This service needs muthual authentication through certificates, but still, it needs to be very, very, very (very!) fast, as you cannot tolerate it to delay too much. Now, consider that this same service is going to be consumed both from the inside of your application (still being used as a service) and from outside. The outside requests must be handled in a secure way in opposite to the inside ones. Then, you can place the whole security stuff in the ESB, as it does the rest. This approach has a bonus, which is that you are sppliting processing need through layers and machines, as the ESB machine processes the security layer and the service layer machine processes the logic itself (along with some XML parsing, for both of them).

Services management

Well, services management is pretty wide term, but as far as I concern, the main pieces that an ESB provides in this sense are:

  • Services “split” capability
  • Services “regroup” capability (in oppose to the previous topic)
  • message filtering
  • add SLA capabilities

So, the “split” and “regroup” has been mentioned in the topic of services virtualization, as the ability to “rewrite” service contracts. Message filtering is in the sense that, generally, the ESB transcends the web services capabilities and that it can filter messages. A practical example of this filtering is that, suppose that you set in place a query service and that a malicious user place a query that intends to cause overflow on the server, making it to crash. The ESB can cut off the request and/or the response, limiting, for example, the size of the message, allowing to pass only messages below 8 megabytes.

Services availability

An ESB can enable high availability / load balancing capabilities for web services, increasing the failure recovery hability of the SOA application. Just in case you ask: this is an example of why one of the services design principles is to make statelss services. So, if any of you ask me how to make a stateful service, it is more likely that I answer you something like “you don´t need this” rather than “do x, y, and z”.

SOA Messaging Patterns

There are lots of SOA (and Enterprise Integration in general) patterns that an ESB implements. I would be here for at least a couple of hours writing about them, but I would be repeating what is already catalogued, and you can check these patterns at website.

WS-* specs support

A good ESB must comply with a few standards, as this is one of the major goals of SOA. The WS-* specs are a couple of specs to address some common issues related to web services, like distributed transactions (WS-Transaction), dynamic addressing (WS-Addressing) and security (WS-Security), just to mention a few. You can check a more complete list of specifications here.

So, what am I waiting for? I want to use an ESB!!

Hold on. There are lots and lots of discussions on whether it is good or not to place an ESB over a SOA architecture, and how far the benefits go and how far the headaches go. I would only be awakening the flame war of “to ESB or not to ESB” by exposing my opinion here, so I would like to keep it for myself. If you want to check it for yourself, have a look at this google query.

What is BPEL and its purpose?

BPEL is an acronym for Business Process Execution Language. It was created as a way of translating BPMN into the SOA world, or bring a notation for business interaction between web services. However, BPEL is a specification fault, and here I present my reasons:

1) Make the common case fast – or – Keep It Simple, Sir

The BPEL specification aims to achieve between web services orchestration. However, the interaction between services often requires, translation of complex objects to other complex objects. If there are variations between input parameters or output, some parts of the process should be partially or completely redone, making it difficult to maintain this.

2) Offer Bonus

The BPEL specification provides standard elements which facilitate the addressing of complex issues, such as waiting for a certain time interval before proceeding with certain tasks. However, most common cases in BPMN, as the interaction with humans, there is no standard specification. This turns out to be the burden of specific tools such as Oracle BPEL – which makes the process strongly coupled to a vendor .

3) Learn what to use, and when

BPEL is a tool that should be used on systems that have had the development cycle ended. The tool is primarily for service orchestration – which does not mean it should be taken as the only means to do so. What I mean is that if a system is developed in a single programming language, is a high probability that integration done within the scope of this language is better and faster than using BPEL tools. Thus, BPEL is ideal for orchestration between separate services for creating new – but should not be used to create basic services.

Explained my reasons, I say I have been using BPEL for any SOA project. It is inevitable to say before starting a project that has claim to be SOA, ask yourself if it is SOA or just SOA-Ready . Most systems do not need SOA-Ready BPEL, SOA in contrast to systems where the most need.

It’s as simple as can be. Development approaches top-down, meet-in-the-middle or green field should be avoided to the maximum use of BPEL. Only bottom-up approaches to the use of the tool can be considered (not yet approved). Even for bottom-up, one must answer some questions:

  • How many different languages are used in the project? If the answer to this question is “more than one”, there is good chance that BPEL fits well in context. Otherwise, consider adapting what already exists before considering the adoption of this tool.
  • There must be the existence of a single transaction during the invocation of these services? If the answer is yes, I issue a warning: it is possible, with specific tools, controllers use distributed transactions to ensure that this requirement is fulfilled. However, it is always easier to accomplish this control within the scope of the applications themselves ( use the right tool in what she does best )
  • Are there business analysts involved in the project? If so, maybe BPEL is well put: because the process can help the understanding between the BPMN and BPEL implementation. Otherwise, BPEL may not be justified.

In conclusion … BPEL, like so many other well-established tools, is a fantastic tool. However, it should be able to use. The correct use of certain tools in a project may make its use essential. But the use of wrong tools can make your design to be developed slowly, much more expensive and difficult to maintain. As with any tool misused.

Categories: BPEL Tags: , ,

Is SOA dead or not?

03/11/2010 1 comment

Well, boys and girls … inaugurate this blog as a way to express some ideas about IT and, if possible, share some knowledge. Much of the knowledge that accumulates in IT does not come with critical analysis, ie, managers, architects, developers and almost everyone involved in any way with IT not do an analysis of how important a tool / technology is important for their business / system.

And example is the technology that is mentioned in the title of post:

SOA serves for what? And to whom?

SOA is essentially an integration technology (EDI, EAI and other acronyms go hand in hand with SOA). This means that any procedure in SOA should be carefully thought out. Prepare a system to embark on SOA is a task that requires concern with several aspects:

  • What other applications might need on my system
  • data that will be exposed will be sufficient / excessive?
  • who use my system will be inside or outside the organization? How to ensure that only the right people see the data exposed by my services?
  • How to ensure that the system will always flexible

These are the concerns that surface when using an SOA implementation. And, somehow, are responsible for the failure of technology to return the ROI and agility that is promised by the vendors of SOA.

But these concerns are in development, right? How to ensure that developers will have these concerns? The answer is simple: the developers not going to worry about it. And nor should they. The key to effective implementation of the SOA Governance SOA.

Apparently, it’s simple. And it is. The problem is that some companies refuse to systematically implement a governance strategy for thinking that it is not necessary, or because you think the developers alone can meet the data requirements. Turns out, no, developers are not paid to think about the flexibility of future systems, these systems only. And so they do. Then, the deployment of SOA failure every time a project has no SOA governance.

This is a very simple logic. 100% of SOA projects that I know that they had failed SOA governance. And then, some people may say “is, but almost all cases of SOA governance have also fail.” And those people I say nothing, show evidence. IBM has a page of success stories for anyone who thinks that SOA is dead.

I say the following: SOA is not dead, nor die. Just let people know just apply the knowledge properly.


Marco Mendes Blog >> “SOA Dead!? … Another of the series … The festival of foolishness that plagues the Internet.” (pt-BR)

SOA is Dead, Long Live Services

Categories: SOA Tags: , ,