Category Archives: Know your SOA Toolbox

Tips for your initial SOA project

I was asked for advice at a SOA project that starts soon based on Oracle middleware. This is what I came up with as my most critical things to consider at the start of a project. This list is by no means complete and you are welcome to add your top 5.

– It is all too easy to underestimate the efforts of creating a initial working prototype and the reference architecture and then run into large delays because things that seemed so easy just don’t work the way anticipated or the solution proves to be just too slow! So make sure you have the time for try and error until the reference architecture stabilizes and you have solutions for every critical aspect! If this is one of your first projects, don’t get into stress from the beginning due to delivery dates but take some weeks to get a solid reference implementation.

– It is amazing how some things on configuration side are much less intuitive and more complicated than anticipated. Examples for areas where you can spend days understanding the nitty gritty details are
– configuration to optimize performance
– asynch services
– timeouts
Thus it is advisable to have at least one very technical and experienced expert who has deep configuration skills in the team, either from the middleware vendor, from a system integrator or from your own team. Always strange things happen, especially in the beginning and you never know, when you are not very experienced, whether it is a programming mistake or a bug. Fast cycles of understanding, resolving, knowing how to search bugs and solutions in the documentation and fixing it is key.

– for skills in the team: Check you have this type of main skills: Architectural / design, technology and tool expertise.
Make sure you have advanced XML skills: XML Schema, WSDL, especially namespaces, XPath, BPEL. Everybody who is exposed to BPEL and XML is lost without deep understanding because of the untyped, declarative nature of XML things go wrong late after compilation and are hard to track down: “80% of the problems are namespace problems”

– Make performance tests on performance critical aspects early. XML is potentially large and can blow up memory and performance easily. XQuery and Database are means to deal with that. And, even way faster is good old STAX parsing. Again, it takes time to find the bottlenecks and feasible solutions.

– determine main architectural attributes such as the level of loose coupling and make sure everybody buys into them and you map designs to these attributes and guiding principles. This determines efforts and tools.

– don’t be too much in love with tools. Rather have less tools: The complexity rises with each tool and platform drastically and you might end kicking out tools that seemed fantastic but cause problems in the concert of collaborating tools. This is a hard earned lesson 😉

– On change management and project culture many peers have written profoundly, this is important but too broad for this short checklist.


Software AG buys IDS Scheer

While it is great to celebrate events such as Oracle SOA Suite 11, the actual impulse to kick start this blog was a shock: Software AG buys IDS Scheer – the company that creates the business process / Enterprise Architecture (EA) platform “ARIS”. ARIS is as well the basis for Oracle’s cool Business Process Management (BPM) offering “BPA Suite”, with its unique approach to align business process models and executable (BPEL) process in a closed loop.

In June 2006 BPA Suite was still a vision and I had memorable discussions with the responsible managers at Oracle Headquarters on Oracle’s plans for BPM platform. I was at a EDS project at that time that investigated ways to close the business / IT gap through model – code round tripping.

IDS Scheer was under discussion for a takeover for long time, I had IBM, Oracle, SAP on my list, now, surprise surprise, Software AG…

I follow Paul Harmon who said in his book “Business Process Change” that BPM tools will be mature and able to fully deliver to their promises by 2015. It will be very interesting to see what Oracle will do now and until then.

What is needed is a tool that allows to navigate from high level, abstract, not automated process models down to models of executable processes and, from there, allows to drill into deployed processes and statistics on their instances and their behavior. And from EA models that depict the system landscape down to the actual physical systems to get a “life” picture of your overall application landscape.

SCA and Loose Coupling

In Oracle SOA Suite 11 it is easy to put everything into a SCA Composit that makes a SOA solution – BPEL processes, integration logic, business rules, human interaction – you name it.

The question architects should consider is whether conceptually all these belong tightly bundled together.

The answer depends on the desired degree of loose coupling.

If you want to add a SOA-Layer on top of a fixed application it may be feasible to wire integration aspects in the new “Mediators” with business process logic in BPEL. This tightly coupled design may be fine when the integrated application (or a set of applications) will stay for the foreseeable future.

Yet, how would a design look like if you want to achieve loose coupling, where processes orchestrate Business Services whose implementation is easily exchangeable? Then the business aspects in processes and business rules should be isolated from integration logic that is close to end systems.

Then it becomes possible to exchange the underlying applications and the affected integration logic with no changes to the orchestrating process logic in your business related SCA Composites.

Such integration logic could translate the exchanged data into the aplication data dialect and knows their protocols. Following the separation of concern principle such logic is very different to the more business related aspects in highler level BPEL business processes and and should be deployed in distinct chunks. This means business aspects and low level technical aspects do not belong in the same SCA composite.

Following this distinction, for integration aspects you could create own SCA composites, one for each orchestrated Business Service. Or, if you have more demanding integration requirements, consinder creating fassades to end systems that are based on services developed in the “new” Oracle Service bus (OSB – ex BEA Aqualogic Service Bus).

OSB belongs now to Oracle SOA Suite, yet the integration into one holistic IDE and console that consolidates SCA, mediator, BPEL and OSB is one of the major things to look for in future releases of Oracle SOA Suite 😉

Fireworks for SOA Suite 11!

Oracle SOA Suite 11 is a major step for Oracle being a major platform to base a SOA on. I remember first talks on one integrated look and feel and deployment at Oracle HQ some three years ago.

There is an attribute of SOA Suite 11g I really like which is easily overlooked among the overwhelming wealth of new features: Although SCA adds yet another technology to the acronym zoo in modern middleware, it rather not increases complexity, but decreases it. Through SCA as a bundling technology it becomes easier to understand an assembly of the constituents of a composite such as a BPEL process, a human interaction, some rules and routing logic. In earlier versions those have been scattered over JDeveloper and we had to figure out through clicking around how they fit together. Now these puzzle pieces of a composite are graphically grouped in one view, so it becomes way easier to grasp what is actually going on and get started. This reduction of complexity continues during deployment and administration, you always look at one bundle, a SCA composite. This reduction of complexity promises to help adoption of SOA based on Oracle Fusion Middleware.