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.