Tag Archives: SOA

JMeter 2.5 Release

I am quite happy that my first contribution to a pretty well known open source program has made it into the latest release of JMeter, the famous load-testing tool from the Apache folks. At the beginning of this year I needed to do some load-testing on JMS topics with durable subscriptions. At the time those weren’t available in JMeter so I dug into the code and added the functionality, which was less difficult than anticipated.

The Non-SOA View on SOA: Part 1

There is a bunch of folks out there that don’t like SOA (Service-Oriented Architecture) for various reasons. So I try to look at things without all the buzz and distill out a few aspects that in my view provide value. The goal is to provide an alternative perspective that is hopefully hype-free.

I want to split this in two parts: First (in this post) comes the conceptual side of things, which looks at what SOA in my view is about at its core. Second are the more practical benefits we get from the way SOA is approached in real life. This will be a separate post.


As a “preface” let me point out that I look at things mostly from a technical perspective. So everything along the lines of “SOA is about business and not technology” gets pretty much ignored. There are two reasons for that: Firstly I am a technical person and more interested in the technical aspects. Secondly, the business argument is probably the one most resented by skeptics. So let’s get started …

The core thing about SOA is that all functionality is made available as a service (surprise, surprise). This is really trivial and hardly worth mentioning. However, it has far-reaching consequences once you dig a bit deeper. And it’s those secondary aspects that provide the advancements.

  • The right level of slicing up things: Of course there were many other approaches and technologies before (e.g. OO and  CORBA). However, none of those has kept its promise. Admittedly it remains to be seen to what extent SOA can fulfill expectations. On the other hand, those expectations are still in flux as we all continue to improve our understanding. So there is a chance that expectations and reality will actually meet some time (where?). Also, the criticism I am aware of is not about this aspect. In fact it seems pretty much undisputed, at least I have never heard anything from customers or prospects.
  • The service is the application: A direct consequence of the previous point is that the service gets elevated to the place that was formerly held by an entire application; at least from a user’s perspective. Whether the implementation reflects this or not is irrelevant to the consumer.
    For new development it is usually desirable that the internals match the services exposed to the outside. For “legacy” stuff that just gets a service interface, the wrapper logic takes this place. In either case, however, the exposed logic is much smaller than an entire application.
  • State management: There has been a lot of talk about loose coupling. This principle can be applied at many levels, transport protocol and data format being the obvious ones. A slightly more subtle place is the handling of state, which pretty much depends on the aforementioned transport protocol and data format.
    The interface, at least of the initial operation, must be exposed in a way that it can just be called.  In other words it is kind of stateless. Of course from that point on everything could be state-full. There is no difference between SOA and traditional applications here. In reality, however, people pay much more attention to keeping things stateless when working in a SOA context.
  • Life cycle management: This one is strongly related to the point “the service is the application”. The notion of a life cycle has formerly mostly been on the level of entire applications. The obvious disadvantage is that this huge scope almost demands big bang-approaches for new versions. With the effort and costs associated for bringing a new version into production, there are only very few such releases and much stuff gets crammed into it. The risks increase, business agility is close to zero and nobody is really happy. With a service as the “unit to be delivered”, the scope is drastically reduced and so are things like risk, complexity etc. Thus I think the concept will be brought to much more practical relevance than before.
  • Standards: Although a real SOA can be built using an entirely proprietary technology, in reality a set of standards has established itself. Yes, there are probably to many WS-* things around that only work together in particular versions. So I would not recommend to jump onto too many things. But with the basic things you are certainly on the right track.

There is probably a whole lot more to say, but let’s keep it here for now. I am looking forward to any comments on the subject!

Lifecycle Management with SOA and BPM: Part 2

One response I got for my post on Lifecycle Management was the following:

Are you saying that one idea is that an organisation can run its whole development lifecycle by modelling it inside of a BPM tool, using it like a workflow manager?

Yes, exactly. Many people are currently thinking about how they can streamline the approval chains they have around their software development processes. The challenge here is in many cases that the tools (project management, spreadsheets, …) are disconnected from the layer where the actual work happens. And we all know what happens in such a case sooner rather than later…

So the idea is to connect the various layers that have a role here. The top-level of such a process is usually about the “stage” of a software asset (e.g. new application, enhancement, bug fix etc.). What you can then do is manage the transition from one stage to another (e.g. from development to testing) by means of a BPM system. This is the first level of visibility.

To take things a step further would then mean to also connect the stuff that gets you a deeper insight. Those would typically be the technical systems like issue tracking (these have a broader scope than just bug tracking), built systems, results from automated testing etc.

So at the end it all comes back to the idea of end-to-end visibility. And here, once more, the advantage of a universal BPM system (as opposed to something that comes together with a specific application like CRM or ERP) kicks in: You can connect pretty much everything quickly and then model the process you want.

And for management the whole thing comes with reporting and business activity monitoring (BAM) out-of-the-box. So you not only know what’s going on an individual level but also get the complete picture in real-time whenever you want. I would think that this is what many managers are longing for.

David A. Fisher “An Emergent Perspective on Interoperation in Systems of Systems”

When David A. Fisher wrote this paper in 2006, the hype around Web Services and SOA had just begun. The point that struck me most when reading the executive summary, was that Fisher does not limit his thoughts to technical systems. Instead he accepts the fact that the involved people are also an important part of the equation. This aspect seems to be ignored by most authors and is -in my view- a major reason why many theories seem to be so far from reality.

The paper is more than 60 pages long, so nothing for a quick lunch break reading. However, I recommend reading at least the executive summary. It made me curious enough to schedule special time for the rest of the document.

Asynchronous Communication

In the context of SOA (Service-Oriented Architecture) there has been a revival of the asynchronous communication pattern. And that is really what it is: a pattern. First and foremost we are not talking about a specific product, protocol or API but simply a way how to design systems and applications. After this has (hopefully) been clarified between us, let’s look at some of the in my opinion important aspects. I start off with a (certainly non-academic) definition:

Asynchronous communication simply means that when making a call into an “external system”, my program/component/service etc. does not expect an immediate response with the actual result (this would be synchronous communication). I am only interested in getting a positive acknowledgement that my request has been received (but not processed) correctly. I don’t care about any further logic that is going to be executed in some other program. Instead things continue on my side and at some other place the result of my request may be received and processed further. (There are quite a few use-cases when I don’t expect a result at all.)

At a first glance this may seem way more complicated than simply making a call, wait for the result and then continue. And to a degree this perception is correct, although I must say that in my view people exaggerate greatly here. In all the cases I have seen so far the really bad problems were not caused by the pattern itself. Rather it was a cumbersome integration on the tool-level. If you have to bother with e.g. complicated mappings before you can send data over to your message broker from the “regular” code, this will certainly inhibit the use of the pattern (and rightly so). But you should blame your tool set and not the pattern in this case!

What is indeed a bit challenging when you first start using this pattern, is that it requires a fundamental shift of your mindset for designing your system or application. What you need is a loose coupling of your components. Technically speaking this means that there must be another component that is ready to receive a response matching your original request and then continues working on it.

(If you followed the discussion around SOA lately, you may have come across that term “loose coupling” more than once already. So you can think of asynchronous communication as a means for reaching this design goal. Bear in mind though, that we only look at the communication layer here! Loose coupling should also be concerned about the semantics, so in technical terms the data model needs to support this as well. However, I wanted to discuss asynchronous communication here, so let’s leave it with loose coupling for now.)

With one component sending out a request and another one handling the response, we have a solid foundation for a highly distributed system . Yes, you can also design a distributed system with synchronous communication but this is probably more difficult. What comes to mind when talking about distributed systems is scalability. More specifically, we are talking about horizontal scalability (scale out), which is spreading the load over more machines instead of putting more resources into a single machine. Having many relatively small systems work on things typically has two main advantages compared to going for bigger machines: Firstly the approach scales further and secondly it is cheaper because you can use standard hardware.

Another big plus of asynchronous communication is robustness, provided you are using a message broker that offers guaranteed delivery. Once your message broker has confirmed the receipt of the request you can be sure that it will be delivered to the receiver. (You can use the publish-subscribe pattern to allow the sender not having to know about receivers. More on that in a separate post later.) And it is certainly easier to only have to make the message broker highly available than to do the same for each and every piece of code. So by having the message broker as a central piece of infrastructure you can reach a high level of high availability relatively easily.

That’s it for now, there will be more posts on related topics.

Business Activity Monitoring (BAM) and Related Areas

When you work in the software industry you are probably used to seeing things change rapidly. One of the disadvantages that come with this is a “heterogeneous” use of terms. It is often due to the fact that we do not want to bother ourselves with precise definitions. A very sloppy use of language is the natural consequence.

As some people have noticed in the past I tend to speak rather neatly. I can attribute this to my parents who were very much concerned with a correct usage of language (my father used to work as a German teacher after all). So I may be a bit more aware of the implications of an imprecise use of language. Therefore, today I want to look at some terms that are often used either without much differentiation or without a precise notion of the relationships between them. They are

  • Monitoring,
  • Business Activity Monitoring (BAM) and
  • Reporting

Monitoring is mostly used to describe an operational activity that looks after currently ongoing things at an individual level. It typically deals with questions like “What activities in my organization are currently causing problems?”. In a Business Process Management (BPM) context this means checking that all process instances are running fine. An operator will query the BPM system and ask for process instances that failed entirely, exceeded timeout limits for single process steps etc. Also automated activities fall into this category. So if you have set up an alert that alarms a human being or another system if some threshold has been exceeded, I would also consider this as monitoring.

However, we are gradually moving into a grey area here. Depending on the type of the rule that is associated with this alert, the focus moves more towards the Business Activity Monitoring (BAM) area. So imagine a threshold that is not concerned about a single incident any more. Rather it can be of a “composite” nature and look at an average for a certain time frame (e.g. average order amount per day of the week). Such figures are usually called Key Performance Indicators (KPIs). Managers tend to be much more interested in KPIs than in the characteristics of a single, although very important, activity in the organization. So instead of asking “How are we doing with order 5297523?” they would like to know “How is our on-time order fulfillment rate today?” You can think of this as monitoring for operations management. If you want to know how you are doing NOW from an overall perspective, BAM is what you probably need.

Take away the “now” attribute from this and you pretty much end up with Reporting. This answers question like “How was our on-time order fulfillment rate this month?”. In many cases this will be closely linked to Business Intelligence (BI) and Data Warehousing (DWH) topics. Some of the BI/DWH providers have also realized that their customers do not only want to know how they did in the last month but how things are going at the moment. The simple reason is that looking into the past is good to identify structural issues that can then be tackled. However, it does not help to identify a current or upcoming problem and avoid its worst consequences by taking instant counter measures.

Being able to react in almost real-time to what’s going on, is the real value of BAM. The later you realize that something is going wrong the fewer options you have and the more likely it becomes that you can only try to repair damage already done. Although implicitly mentioned in the above paragraph, I want to highlight that BAM is not only concerned with existing but also with upcoming problems. You should expect a BAM solution to be able to identify trends and alert you based on that.

So there are distinct, yet related use-cases for all these functions and you definitely want to combine them to get most from them. I can well imagine that over time these things will, at least to a degree, merge into broader solutions. One last word here: The statements given here can not reflect all possible variations and in your particular case things may seem to be different. Don’t be disturbed by that feeling. Rather analyze the situation and you will probably discover that the general lines are still the same, although the details may vary.