ACE Briefing @ Oracle HQ

Today we have a briefing of all ACE and ACEDs (Ace Directors). Unfortunately we are not yet allowed to disclose anything that's been said.

Interesting? ABSOLUTELY. It will not surprise anyone that we've seen and heard an awful lot about the soon to be released 11g versions. All I can see for now is to stay tuned!

If you are a serious Oracle professional, the upcoming launch of 11g is something you should be part of. Don't miss out and register here. I think you will be as impressed as all the Ace's and Ace Directors present today.


For those who are attending ODTUG as well, be sure to visit the keynote by Steve Miranda. It's rumoured that we'll see some interesting demo's there around Oracle Fusion Apps.

Accessing Oracle SOA documentation

Ever tried to find that one document about the ESB on OTN? Did you quite remember where you found that BPEL Developers Guide? Well, life's been made easy for you. Marc Kelderman (Oracle Consulting) has made a list of just about all you need to start out with SOA from an Oracle perspective. Go and have a look at Marc Kelderman's shortlist. Way to go, Marc!

SOA: Process driven, message driven or event driven?

For a long time I thought that SOA is process driven, meaning that the functional requirements were discovered by working downwards from a business process perspective to a comprehensive set of services to deliver the business value.

However, the more solutions I see, the less I believe it. Saying so, I realize I need to clarify that a bit more. Whenever you're building an SOA from the Business process downwards, it is smart to discover possible candidate services from your existing legacy environments (building upwards) so you can execute a 'meet in the middle approach'. This usually results in orchestrating business processes (with BPEL) and -simplified - composing composite services (based on atomic services from your legacy).

Is that bad? Not in itself, I think. It depends on the type and the number of processes. Suppose you have - on average - 50.000 running instances of a process. If you have to change that BPEL process you defined, what will you do? The first question to answer is: what do I need to do with my current active processes? Can they continue using the existing process or do the need to switch? Does it depend on the state they are in or not?

This problem gets worse the longer a process runs. It increases the chance that a process change will occur during the time it runs. Besides, not only functional changes impacts the running processes, but an update of the underlying BPEL engine may do so as well. Of course, if the number of instances increases, your problem gets worse too. Ever tried to restart a BPEL engine with 150.000 instances?

If it's a short running process, you could stop all incoming transactions for the specific process and wait for the running processes to finish before you upgrade the process to it's new version. Unfortunately life is usually not that simple.

Let's get back to the initial thought: is an SOA process driven or not? If you follow the scenario I sketched above, you might end up with one that is. What you should keep in mind while designing an SOA application, is that you have to look ahead to see what possible situations you need to able to handle. If you know beforehand that you will have a (very) large number of active processes, that they will be long-running and that they will very likely be subject to change, you might want to consider a different approach. Why? Because migrating running processes in a BPEL environment is a very hard thing to do (and expensive too). You will need to make allowances in your architecture to prevent problems.

In that scenario, a more event-driven or message-driven approach may be the answer. By loosely coupling the stages a process will go through, using either events or messages, you are a lot more flexible when it comes to migrating to new versions of a process(step). This will mean that your 'highest level' process will probably not be visible as a process in your BPEL engine, but the underlying steps may be. Again depending on the duration of the processes.

Oracle Fusion Middleware 11g Launch

Finally the date is known. July 1st will bring us Oracle Fusion Middleware 11g, immediately followed by a huge training program.

What will be delivered:

Oracle WebCenter Suite 11g: the long awaited Portal solution

Oracle WebLogic Suite 11g: BEA Weblogic Server the new middleware foundation

Oracle Identity Management 11g: Next level of security and compliance

Oracle SOA Suite 11g: a new, very tightly integrated environment to build service oriented applications.

What's missing? Oracle BPA Suite 11g, which will probably appear within 1 month.

The delayed delivery (we expected 11g to be released about a year ago) is mainly due to effort that went into the integration of BEA. Too bad that we had to wait, but in the end it is delivering us a whole lot more value. It was worth it! Enjoy 11g!

My Take on Governance: People, Process and Tools

I was reading Dave Berry's blog on how to achieve the ROI on SOA by implementing Oracle SOA Governance tooling. Dave starts with a simple example of how customers - using Oracle BPEL PM - have no clue as on how to achieve reuse. In his blog he states that 'one of the main values of SOA Governance is to deliver savings by enabling this reuse of existing services'. From there on he moves towards governance tooling, enabling visibility, control and monitoring of all SOA artifacts.

My first response was to point out that tooling for reuse is nice, but there's also something about culture. What about the 'not invented here' syndrome? After that, i started thinking (well done, Dave, you got me thinking!) about the elements of SOA Governance. To me governance is about people, process and tools. People, because it's all about the professionals on the job and the need to govern their actions to make sure the right things happen at the right time. To do that, you need a governance process in place that ensures that all artifacts are reviewed and judged to be either confirming to the architecture, or rightly not so. But, that should be done, before anything get's built! Finally it will really enable to process and the people to have good governance tooling available. For to be sure: we do need visibility, control and monitoring to enable reuse. And we do need reuse to reap the major profits of SOA.

For instance, I know of a customer case where the people involved were SOA adepts. However, they decided not to use an existing service, even though it was accepted by the Architecture Board. The main reasons being, that the service was developed by a different department, it's quality and availability could (maybe) not be guaranteed and they could probably do a better job. Unfortunately, this happened not just once, but four times for the same artifact. The company ended up having 4 almost equal services doing almost the same thing. Being able to govern this process would have saved them 3 times building the same component! Tooling in itself would probably have made this problem more visible, but would not have prevented it.

So what are the typical governance processes you see being advocated either internally or by vendors? Let me know!

Oracle Service Bus Explained

There's a lot of confusion towards the positioning of the Oracle Service Bus. In this post I'll try to clear up the issue as best as I can.

First of all, Oracle has already shown a convergence of BEA and Oracle FMW. This will continue even stronger in the upcoming releases, 11g in particular. The strategic platform as it will be introduced with 11g will consist of two main components: Mediator and Oracle Service Bus.

The mediator is an intra-composite mediation component within an application. It is responsible for brokering communications between components that make up a composite (conform Service Component Architecture - SCA). It will enable transformation, routing, event delivery and payload validation. The mediator is almost exclusively based on Oracle ESB (yes, the old Oracle Enterprise Service Bus).

The Oracle Service Bus (OSB) provides service bus capabilities for the entire company, again including standard functionality as transformation, routing, event delivery and payload validation. It's main function is to decouple intra-application communication from inter-application. Endpoint changes will not affect the internals of composite applications. The OSB is based on the Aqualogic Service Bus, augmented with key features from the Oracle ESB, especially JCA adapters, DVM, X-ref and JDev based design-time.

In the long run, I expect the distinction between these implementations to disappear, but I do like the current setup, as it differs between development of application and integration. I wouldn't be surprised to see this pattern appear more.