Mud Slinging and the Enterprise Service Bus

The last few weeks I've been reading up on the Enterprise Service Bus (ESB). I can tell you: it was an amazing journey. I started out with the book by David Chappell and from then on went to IBM DeveloperWorks which is usually a good spot to get technical info. These two sources combined give a nice overview of what an ESB could offer you, and how to put it to use.

That was not enough. I needed more information, especially on what an ESB really is and how to fit it into our architecture. So I looked at a couple of Blogs around the ESB and the Mediation patterns. What surprised me was the number of discussions and especially the tone of them. It seems the whole ESB discussion has degraded to a kind of mudslinging between different fundamental groups. One group states that the ESB is an architectural monstrosity which is not needed whenever the initial design of the service constructs adhere to standards of good design. The other group argues that there will never be such an environment. Oh btw, both groups think they hold the truth, the whole truth and nothing but the truth. Well, what else is new?

I think I understand where this argument is coming from. Just have a look at the ESBs that vendors today deliver. Probably the only thing they have in common is the name and the fact that it can do some routing and transformation. There the resemblance ends. In short, there's no clear definition of what an ESB is or does.

If I look at the architectural concepts that I found during my search, especially mediation, integration and security, there's a lot to be said about using these patterns. If you can find a tool (whether or not it is called an ESB) that fits your needs now and in the near future, why not use it?

So in my opinion, there's definitely a case to be made about an 'ESB'. Just don't know yet exactly what should be in there and what not .....

Oracle ACE Office Hours

Will you be visiting Oracle Open World this year? When you do, make sure to free up some time to visit the ACE's. Every day they will hold office at the OTN Lounge in Moscone West (3rd level). Sort of like a roundtable, advice session or a "live" discussion forum thread-- however you want to view it.

What: Oracle ACE Office Hours
Where: OTN Lounge, Moscone West, 3rd Level

Oracle ACE Office Hours:
Monday, September 22
12:00 – 1:30 and 4:00 – 5:30pm

Tuesday, September 23
12:00 – 1:30 and 4:00 – 5:30pm

Wednesday, September 24
12:00 – 1:30 and 4:00 – 5:30pm

Thursday, September 25
11:00 am – 12:00 pm

I'll be there!

Growing Pains

It’s not hard to build an SOA. That is, technically. Once the domains are clear and the services defined, it’s kinda easy to implement. Sure, there’s lots of work to be done, but no rocket science. But, what happens after you’ve done your Proof of Concept and your first and maybe even your second real-life project?

By then you’re sitting on top of a lot of services, of different granularities and of different types, all mixed together. If you’re lucky, the semantics are still correct (no mismatches yet!). Maybe you even have an ESB running. Slowly but surely the need for additional tooling becomes evident. How are you going to manage this whole environment? How are you going to make sure the next project reuses the generic services that have been so painstakingly defined?

A logical first step would be to get a UDDI, where you can at least register your services. Usually this is not a tool that you would implement in your first project, as you do not yet have the need for location transparency or runtime service discovery. That may change, however. But the main reason for the introduction of a UDDI is the discovery of services: what are the reusable assets my organization has?
If you grow even bigger and you get more and more services, a UDDI will not be enough. You will also need to implement a Service Life Cycle Management environment.

Managing a handful of services (say up to 50) can be done manually, without the need for advanced tooling. As the people involved know about the upcoming changes and are involved in bringing the changes into effect, you can manage a whole lot of services. But .. up to a point. There will be a moment in time when you will have to formalize the procedures and support those with tooling. This is where a Service Repository comes in.

What will a Service Repository bring you? A lot! First of all it will give you a tool for implementing Service Life Cycle Management, as it will support discovery (through visibility), impact and depency analysis, monitor compliance (assets, policies & standards), collect metadata, automate lifecycle staging, etc, etc. What I really like about a repository is that it will become the central focus of development, test and deployment. In the repository you will find all the information you will need, from service contracts, SLA’s, documentation, dependencies, tests, policies, service usage (requires closed loop data gathering). Your repository will be the single point of truth in your SOA!

Unfortunately there’s not many repositories around. According to Forrester (The Forrester Wave: SOA Service Life-Cycle Management, Q1 2008) there are just 3 good repositories available at the moment: Oracle Enterprise Repository (rebranded from BEA AquaLogic Enterprise Repository), Software AG’s CentraSite Governance Edition and LogicLibrary’s Logidex.

Oracle Enterprise Repository, formerly known as BEA ALER, will be rebranded and integrated into the Oracle SOA Suite as well as certified against the Oracle BPA Suite. This is one of the reasons I’m very happy with the BEA acquisition by Oracle. OER is by far the most sophisticated repository around and will be making my life a lot easier!

Oracle vs Open Source

I work a lot with Java developers and software architects. Often there's a discussion in the projects about which software to use for what purpose. Increasingly i find people to be very rigid about this choice: it's all OSS or nothing. In a way it reminds me of the old anti-Microsoft atmosphere.

Therefore I'd like to start a poll, to find out if this issue is alive or that it's just me :p.

Do me a favour and fill in the poll on the side?

So, is WSDL the standard for service contracts?

A Service Oriented Architecture is based upon the use of services (hence service orientation). It's implementation is based upon standards. One of which is the way services interact, namely by messages (XML messages usually).

Standardization is the most important thing for SOA to become a working concept. XML has become the de facto standard for the definition of messages between services. That's fine, but in my opinion we are missing one critical item. THERE IS NO STANDARD FOR SERVICE CONTRACTS.

EH??? Some people will argue that WSDL is THE standard for the service contract, but that's not quite true. A WSDL is an implementation of a service contract, specifically for web services. However, a service does NOT have to be a webservice!

Let's approach it theoretically. What do I need to know to access and use a service? I need several different things at different times. When I need a service to fulfill a specific task, I need to know what services are available, what their service consist of, what data it uses (in) and delivers (out), depencies (if any), security constraints and QoS.
At runtime I need to know where it is located, how it is accessible, what credentials to use, how it is secured, etc.
To manage it I need to know: where it is located, its resource requirements, what technical depencies it has (services it uses, but also db access), what security profile is active, SLA requirements (availability), etc.

All we have now is a WSDL, being the Web Service Definition Language, which is used for webservices at runtime. It does NOT have all the information that is listed above.

So, to answer my own question: Sorry to say, but NO, WSDL is not the standard we need!

Oracle & BEA: A Match Made in Heaven?

Today Charles Phillips and Thomas Kurian disclosed Oracle's strategy concerning the integration of BEA and Oracle. Lots of changes, though most are not surprising. Oracle's vision towards SOA has been clear for the last few years, and I look upon this merger as one of the highlights. I am surprised that there's relatively little overlap between BEA and Oracle's offering. In fact, it is an example of realworld synergy, leading to a best-of-breed SOA technology stack. In that sense I fully agree with the closing words of Thomas Kurian:this is the best middleware suite in the industry. So, the answer is yes: it's a Match Made in Heaven!

Some highlights
Not surprisingly, Oracle has integrated WebLogic into both JDeveloper and the Application Server, replacing OC4J. This will be good for performance and stability. But, it gets better. Oracle has announced Oracle Service Bus, in fact replacing ESB with AquaLogic Servicebus (ALSB). Customers will have several years to decide to stay on current installation of ESB or ALSB, and migrating later. JRockit, the world's leading VM will be the standard VM for Oracle, Coherence will be the central component for dehydration. So we get zero latency in the VM and unparallelled performance for the dehydration store. I feel like I'm in a candy store!

Oracle Service Bus
Thomas presented a roadmap towards Oracle Service Bus. This does not mean that the ESB and the Aqualogic Service Bus are discontinued, but they will converge towards the OSB. No forced migration here, but the OSB will consist of the strong points of both ESB and AL-SB.

The Oracle SOA offering will look like:
Oracle BPA Suite
Another interesting development is the integration of BPM Studio into the BPA Suite. It's fair to state that the Oracle BPA Suite, in conjunction with the Oracle SOA Suite (BPEL PM in particular) is the world's best-of-breed for procesmanagement, -design and execution. The added functionality from BPM Studio will create a comprehensive set of tools to support both process architecture, design and execution in a fully supported roundtrip engineering environment. This will also mean that from the new version onward, XPDL will be supported.
Integrating all the tools will take some time, but in the end we will have the BPA Suite for architectures and high level proces modeling, the BPM Suite for building processes in XPDL/BPMN and BPEL to execute them. The roundtrip engineering will be between BPM Suite and BPEL. Oracle aims to deliver a web-based Proces Designer, although the details about this are not yet fully clear.

The Road to 11g
So, when will 11g be available? Well, JDeveloper 11g will probably go GA towards the end of the year (might even be launched during OOW 2008). Fusion Middleware will take some longer, due to the ongoing integration. I think it's worth waiting for. The newly added components JRockit, Coherence and BPM Studio will make the whole Suite a lot better. Besides, it also gives Oracle time to finish WebCenter and WebCenter Spaces, products that will revolutionize the way we build web apps.

IDE
And the winner is ....... JDeveloper. Yes, JDeveloper will continue to be the central IDE for Oracle. All the components in the stack will have a plugin in JDeveloper to increase production and quality. Of course, Eclipse will still be supported, but not for BPA and BPEL.


If you want to read more about Oracle's strategy, go to http:www.oracle.com/goto/july1. The webcast will be made available soon too.