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.

SOA Components

What do you really need in an SOA technology stack? To answer that question, let's first have a look as to what SOA really is. SOA is an architectural style, based on service orientation. Ok, so what's architecture? If you Google that term, you'll find 1 gazillion different definitions. I like to look upon architecture as the structure a company gives to its vision. It addresses all the choices (trade-offs) an organization has to make regarding its structure, the way it is organized, how it addresses customers, suppliers, partners and personnel, how and where resources are used (one of them being IT) ... and a lot more. So it's not even about IT, even though a lot of people think so.

If you start working with architecture and especially SOA, sooner or later you will apply it to IT as well. From that point of view, let's see what components you need. Service orientation, as it name says, is based on the use of (business) services.

Let's start at the bottom: services usually make use of data, which will be stored in a database (usually). Next, services exchange data thru messages, so you need something to transport your messages. As different services use different messages (alas!), you will also need a component to transform messages from one format to another. Finally you will need a platform to support a user interface to which the service can be exposed, even though this really is outside the SOA stack. So, basically what you need for an SOA platform is:
- database
- routing & transformation (ie a 'bus')
- UI platform

However, there's more to it. Life isn't that simple anymore. One of the strengths of an SOA is the ability to combine services into a new service: orchestration. So we want to add an orchestration engine to the stack. What else do we need/want? Well, building an SOA is one thing, managing one is another. As you can imagine, the number of services might get large very soon. So you will need at least two additional components: a sort of repository where you can register your services and a management tool that shows you how your services are doing.

Are we done yet? Nope! Managing services is more then just taking care of availability, we also have to take care of security. Who is allowed to use what service? To maintain the reusability of a service, we want a non-intrusive form of security, as a separate layer.

Ok, let's step back and see what we have now:
- database
- routing & transformation (ie a 'bus')
- UI platform
- orchestration engine
- service repository and registry
- management tools
- non-intrusive security

To top it all off, I would like to add a rules engine, to be able to reuse business logic in services, orchestrations, UI, routing and transformations.

Luckily you don't need the whole stack when you start out with SOA, especially when you start small and only within your company. But as SOA is especially very good at organizing processes within your company but also between companies, it will grow fast.

Unfortunately there are not many vendors around who can offer you the full stack. For each and every component I've mentioned there are commercial best-of-breeds and Open Source alternatives. However, integrating tools from just a single vendor can be a challenge, and integrating a lot of best-of-breed tools from different vendors and OSS can be a nightmare (and usually is :p). This is one of the reasons I am very enthusiastic about the Oracle SOA Suite, as it delivers a well integrated suite of components. Most of these are even best-of-breeds, especially the Oracle BPEL Process Manager. I think the integration with BEA will make the Oracle stack even more complete and robust.

Also good to see is that there are a number of OSS projects like GlassFish, who are delivering good SOA components. Unfortunately there are not enough standards yet to overcome the integration challenges. Enough work to do!

How hard is it?

As you can see, I'm quite an evangelizer for SOA. The main reason being that it delivers (in my humble opinion) the alignment between IT and Business. Delivering business services (recognizable and usable services for the business community) is what IT is all about. However, whenever I get into discussions with IT personnel, I usually meet a lot of (initial) resistance. Of course, change is stressfull and can even be threatening, I understand that. But what I really don't understand, from a technical point of view, is: isn't it great to have all those new technological challenges out there? Isn't it marvellous to see you can build services so easily and building return on investment?

Service discovery, part 3: Meet in the Middle

Finally I found some time to finish this series. My apologies to those who've been waiting for part 3, but ..... here it is.

I have outlined two different approaches so far: bottom-up and top-down. As is usually the case, both have merits and drawbacks. In fact, the real solution is to do both, and not just one. That's what I call 'Meet in the Middle'. The top-down approach is very important to achieve the business goals, where the bottom-up approach is just as important to utilize the investments made in the current systems for the last few years. By combining these two approaches you get the best of both worlds: integration with the current application infrastructure (in a service-oriented way) and preparedness for more process driven functionality which supports the business needs.

But (of course there's a but) there's a little more to it. Matching the two approaches is not as easy as it sounds. There will be quite a gap between the business services as described in the top-down approach and the application services discovered in the application infrastructure. The trick is now, to take a business service and analyse which of the application services youi need to compose a service that will bridge the gap. This composite service can be multi-layered, and usually is.

One of the paradigms we use in grouping and discovering services is domain driven design (see Eric Evans marvellous work). Stated shortly: we define business domains (top-down here) consisting of delimited data and corresponding services (multi-level services: from data manipulation to business level services). This domain (and therefore its data) can only be accessed through the services. These are the building blocks for the future business functionality.

The attentive reader will have seen the problems looming on the horizon. The main issue is, that the domains we have recognized will be spread over the existing application infrastructure. So, how are you going to delimit the domains? That's the hardest part. In a greenfield it's easy, because you can define and build the domains. In real life situations you will usually build a part of the domain and integrate it with the existing applications. So you will need composite domain services which will present a unified view towards its consumers, and will integrate the different data sources on the back-end.

How hard this is, usually depends on the openness of the systems involved. Even though a lot of systems are walled of, there are usually several strategies you can employ. This goes from the use of service adapters, wrappers, up to direct database calls and file interfaces. You'd be surprised how far you can get.

Service Discovery, part 2: Top-down

Time for part II. In Part I I explained that the Bottom-up approach is valid in itself, but it is does have its limitations.

A logical alternative is the Top-down approach. In short: this approach looks at the processes in the business, decomposes them into subproces/tasks/functions until 'logical units of work' are defined, which we call services.

Is that all there is to it? In principle: yes. However, there's more to it than meets the eye. A pure BPM (Business Process Management) approach, for example as advocated by IDS Scheer, will deliver a 4-layered process structure for the entire organization. Since the introduction of the Oracle BPA Suite you are then able to convert the lowest level of process to an executable process (BPEL) in which individual tasks become service-operations.

The decomposition of the process in itself is not enough to discover services, because you will have to convert the 'candidate-service' into a real-world executable and discoverable service. This means you will have to compare the functionality of the service with the available infrastructure (which consists of more services, hopefully). Quite often, the service functionality is delimited by specific functionality not being available. For example, suppose you run a very specific proprietary financial system where you cannot interact with either the business logic or the data store. If this is the ultimate source that you will have to use, the chance of being able to fulfill the service functionality needs are quite slim.

Does this invalidate this approach? Of course not. I find this approach working very well in those areas where SOA is used to add new functionality to an existing infrastructure or in a complete greenfield situation (which are quite rare). What this approach does for you is that it's easy to involve the business into designing the new services. The defined services are very recognizable for the business, but not always easy to implement.

Using tools to convert services that are discovered during the process analysis, means that the process analysis has to be done very thoroughly. And, even more important, the process analyst should have knowledge of the limitations of the execution platform. Otherwise you'll end up with services and orchestrations that work rightly on paper, but will never execute in reality. How to address that will be explained in part III.