SOA without BPM without SOA

Some people argue that SOA and BPM are two different things. That is probably right because it is possible to create a service landscape without having a business process representation. But if you look at the main reason for establishing a service oriented architecture the perspective changes.
The main reason for SOA is business agility. Every technology that helps to achieve that goal is welcome to be integrated in the SOA technology stack.
BPM makes perfect sense as it fosters better aligment on business and IT and helps to shorten development cycles.
Ok understood. But if that is true wouldn’t be be enough to use a BPM only without services? The answer is no because in order to create a flexible BPM solution it must be based on a sound service landscape. If that is not the case changing a business process would require new services to be created or existing to be altered. Sooner or later this would lead to service proliferation which would render the BPM approach useless over time. The result would be anything but hardly an agile system.

My conclusion: Using BPM as part of a SOA makes perfect sense if it is based on reliable and well designed services.

Evolution of Languages

After working a while with Groovy in a project I have the impression that it is the better Java.
Mainly because it introduces nice productivity features such as closures, runtime compilation, loose typing, operator overloading just to name a few.
These features are available in C# for instance as lambda expression, extensions methods or type inference. And runtime compilation and operator overloading are even part of the .NET-Platform since version 1.
But while the C# language evolves from version to version in a logical way, in the Java world a new language is created. It is called a scripting language. Why that? Every language that can be compiled at runtime can be used as a scripting language.
I think it would be better to add those productivity features to the next version of Java without further cluttering the Java platform. This would help developers and decision makers to choose the right technology.

Next Generation ESB – The Internet Service Bus

Microsoft made available the first version of it’s Bitzalk Services as Community Technical Preview (CTP).
Biztalk Services serve as the basis for the next generation ESB the so called Internet Service Bus (ISB).
Unlike the name suggests it is not dependent on Biztalk Server.

The ISB offers functionality in the following areas:
– Identity management
– Connectivity
– Workflow

It supports point-to-point and relayed connections to improve performance.

Why ISB?

Quote:”The name Enterprise Service Bus reflects the historical focus of ESBs within the enterprise. But as business requirements expand to include interconnectivity between enterprises, and as enterprises factor out portions of their information systems to hosted “solutions, traditional ESB approaches become inadequate.

Microsoft offers the ISB infrastructure as a hosted service that helps to get started with the technology within no time.

Although it seems to be a good idea to have an internet wide service bus, it raises questions that have to be answered before this technology will be accepted.

– How reliable is this infrastructure? As reliable as the internet itself?
– Will it be a free service? What are the costs?
– Does my organization accept the Microsoft dependency? Especially for B2B connectivity?
– How can my organization integrate it’s own security profiles?

Nevertheless the idea of having an internet wide bus infrastructure is interesting and worth to keep an eye on.

Microsofts ESB Offering

If you asked IT professionals about Microsofts offerings in the area of Enterprise Service Bus (ESB) you did not get an answer.
It is not that they had nothing to offer it just seemed that Microsoft did not think that from a marketing perspective it was the right strategy to sell an ESB as a product.
But in fact with Biztalk Server they had the infrastructure whose functionality would be best described as ESB functionality (adapters, message subscription, content based routing, transformation, etc…).
The strategy changed now as Microsoft offers ESB Guidance.
It comprises guidance, components and services that allow to use Biztalk Server as a pure ESB.

Features are:
– Intelligent Routing
– Message Transformation
– Itinerary Processing
– Legacy and LOB Application Adaptation
– Service Orchestration
– Metadata Lookup
– Exception Management
– Distributed Deployment
– Centralized Management
– Business Rule Engine
– Business Activity Monitoring

After skimming through the documentation it seems that the EBS Guidance does not introduce any ground-breaking changes. It is more a description of Biztalk Server from the ESB perspective. It is an example of the modularity and extensibility of Biztalk Server.

Quote: “Many of these components and services rely on features implemented by BizTalk Server 2006, such as the Orchestration, Transformation, and Business Rules engines and the Message Box database.”

If someone asks today about Microsofts ESB offerings, the ESB Guidance is the place to look at.

Legacy Integration with JBI

In the article Integrating CICS with the Jbi4CICS Component Amedeo Cannone and Stefano Rosini describe how to integrate a CICS system using a JBI component.

To me it shows two things.

1. How standardization (JBI) helps to create reusable components.
2. The power of the modularization with clearly defined responsibilities.

The result is that you can integrate your legacy assets with minimal effort.