Today I read the remarkable article in the Computable that according to Gardner EDA (Event Driven Architecture) will be the successor of SOA (Service Oriented Architecture). That would suggest that EDA and its technology is newer than SOA or that EDA tools will replace the current SOA-tools. Well, I'm not that into the History of ICT. But about three years ago Oracle introduced their Enterprise Service Bus as part of the SoaSuite. You could consider the ESB as the succesor of Oracle's InterConnect in J2EE technology. Remarkable also is that you can find Oracle Workflow's Business Event System parts in the ESB technology. The Business Event System (the name sais it all) is part of Oracle Workflow since version 2.6, that was introduced in 2001 if I'm right.
Oracle Service Bus (fka. BEA's AquaLogic Service Bus) was introduced in 2005. And there are serveral other service busses maybe with an even longer history.

So Busineess Events could be (and should be) part of our applications since a long time. In fact Enterprise Application Integration (another Three Letter Acronym or TLA), is about firing and receiving business events from applications.

I believe that EDA does not succeed SOA. In fact SOA is about Services and Services on their own are not usefull. Services are triggered with an information object. And this infact is an event. Connecting Services in to a business flow (what we call "orchestration") is about passing Business Events between Services folowing a Business Process. Nowadays we tend to do that using BPEL or BPMN.

Therefore I would state that SOA = EDA + BPM. I must confess that I did not make that up on my own. Since I'm a former Oracle Employee, this is what I've learned from the positioning of Oracle's toolstack onto SOA.

Having a Service Bus is not a replacement of your SOA toolstack but a very valuable addition to it. It's a very good idea to have a Service Bus abstract your services from your Business Process. That makes it easier to do things like aggregating services, replacing services, transformations from Enterprise Business Objects to Application Business Objects, etc. But this article is not about the value of an Service Bus. For that I could write a complete separate article.

Read also this previous article.

The very main reason for me to write this blog-entry is to introduce a new word: Popotopi. I would love to see this home-made word pop-up in upcoming discussions over the world. To be honest, I used another word for it: PoJo: Plain Old Java Object. The word PoPoToPi means Plain Old Point To Point Interface. I like the word, because of its cadens, how it rolls over your lips.

Ok, another reason then: to explain one of the questions I'm currently involved in. My current customer has just celebrated the first aniversary of their EAI department. That means they have been busy with integration for quite some years. Mainly on Tibco. But now they have some projects going around introducing two other ESB/Soa platforms, one of them being Oracle SoaSuite. This drives them to think about integrating the integration platforms. How to exchange services, what is the scope of one integration environment, how to define bridges etc.

Looking into this I also discovered that they have several environments of their current Tibco Platform, because of having several domains. One of the colleagues I have in this department is catagolizing the services of one of the domains. His impression is that about 80 percent is just point to point. Although most of them are neatly defined using a so-called Canonical Data Model.

Having a Canonical Data Model is nice. It's just like the Hub-and-Spoke architecture of Oracle's Industrial Archeology Artefact: InterConnect. InterConnect was technical not a very sophisticated product. But the whole idea behind InterConnect I do like still. The Common View in InterConnect, that is the Canonical Data Model, is the abstraction on message level between end-points. It is based on Logical Entities on which you map the physical entities of your Enterrpise Information Systems (EIS).

But if you conclude that 80% of your integrations is point to point then you should think about how successfull you were in implementing EAI (Enterprise Application Integration).
A coupling is point-to-point if the two end-points are not re-used anywhere. Although the coupling uses a Canonical Data Model, the business event that is based on the CDM is not re-used. The reuse and thus the advantage of this approach only pays-off when you subscribe another end-point to the business event in the hub, if you have another application publish the business event or when you decide to replace one of the end-points without modifying the CDM.

Although the couplings are based on a CDM it is very interesting to compare the different CDM's (the message definitions) of the different integrations. As said: a CDM should be based on logical entities. This Logical Entities should also be reused over the different integrations. For example: an order in the "CreateOrder" integration should be the same in the "UpdateOrder" integration.

Drilling down in to the Logical Entities, it should also be interesting to reuse parts of the Logical Entities. For example: the address of a person, a customer, a supplier or an organization, be it a home, billing or shipping address, should be allways the same in structure. Actually a person being a customer or a supplier or a TradingPartner's contactperson is allways the same in structure.

It would be very interesting to see to what extent the standardization on CDM's is put through. Honestly, it would surprise me if there are not more then one definition of whatever Logical Entity in the different interfaces.
Every coupling, integration is defined and implemented in different projects. Only if a project-member does know of the existance of a reusable artefact and/or if there is budget to make artefacts generic enough, a project might leverage the advantage of EAI or feed the potential of it.

If every Logical Entity is neatly defined only once ever, especially when it is describe in a central library of artefacts, that would be great. Then you could say that you were quite succesfull in implementing a sufficient EAI.

If not, you can't speak of a succesfull, efficient EAI. Then, to me, you have implemented Popotopi's on a modern platform, where so-called services are not much more then simple building blocks (not services). But ask yourself and decide for yourself if it was worth the investment.

It is too bad, because a good EAI with uniquely, accurately, correctly and completely described buildingblocks, triggers, CDMs and message-object-mappings could be a very good base for the implementation of a SOA. Where a buildingblock could really be a service, a trigger could really be a Business Event in your Event Driven Architecture and the CDM's and mappings a base for your Enterprise Business Objects with their transformations.

I used to do Quick Scans on the performance of Custom Development Applications. It would be nice to do such a scan on EAI implementation to see what the impact on the implementation of SOA is in such a case. Or at least to think about it along with a customer.

I just realize that maybe I have to explain my earlier post on my vision on SOA. I stated that it is all about: "Don't postpone to tomorrow what you can do today".

A few years ago I had a discussion with a colleague that resulted in an article in our consulting-magazine. He asked me if I would use InterConnect for an interface that processes 1000000 records in batch every night, were the receiving application is not interested in the records real-time.
But then your only argument to use an EAI-tool like InterConnect, Tibco or ESB that the receiving application needs the application realtime.

But it results in a costly batch that has to be maintained. The batch has to fit in the batch-window. There is no reuse of the code (transformations and data-enrichments in the batch). And also the providing application is pressurized because of requirements of the remote application. When you're able to get the change-events in the source application in real-time then you have all the information at hand at the moment the event occurs. Then you can do the transformations and enrichments at that very moment. You could do that asynchronously when these actions would cause the End-user-session to be less responsive.
Doing so you can subscribe multiple applications/services to the events. Also after processing the event the publishing application got rid of the responsibility.

If your receiving application is not able to get the mutations real-time, you can collect the mutations in a staging table. And then you only need a very light batch that just processes each mutation from the staging table in the receiving application. Since all the transformations and enrichments are done at real-time the mutations are in a processable state for the batch.

When you are to soa-enable an enterprise that uses packaged apps like Oracle E-business suite or conventional (Designer/Developer) custom-apps than you may have to break up the conventional way of working with batches. Possibly you can copy and paste transformation and data-enrichment code from the batches. But big chance that you have to rebuild it with technologies as XSLT.

When you have to build or maintain a custom-app or you work as a developer at a packaged-app-provider then also keep this in mind. Try to work event-driven. See that on every mutation event you're able to put a message on a queue (for example AQ) or publish an event to an ESB-product (Oracle SoaSuite).

Oracle Workflow had the Business Event System, which is a really nice system for publishing and subscribing to events. It is AQ based and available with every main product of Oracle (database, AS). It mainly executes in the database so for custom Forms applications, especially when they're based on Designer/Headstart/CDM Ruleframe, the ideal way to expose change-events asynchronously.
Very unfortunately Oracle decided to de-support Workflow (and thus BES). It is supported as long as the product that it's shipped with is supported. So as long as Oracle DB 10g or Oracle AS 10g is supported you can use Workflow/BES.

Actually it is quite remarkable that they de-support it. Because BES used to be written in Pl/Sql but in the very latest release (2.6.3 or 2.6.4 that shipped with 10gR2) they re-build it into a J2EE container! I wonder why they did that, because soon after that the Statement of Directoy noticed the de-support. I have two possible explanations:

1. E-Business Suite still ships with embedded workflow. Release 12 is OC4J based (R11 is still based on the formally for customers desupported old Oracle 9i Application Server version 1.0.2.2). In R12 the Oracle embedded Workflow will still be available and so the BES can be J2EE based. Also it makes it simpler to have Java-calls on events. In 2.6.2 it used some kind of D-tour-solution from Pl/Sql to java.
2. Did you ever took a glance at the datamodel of Oracle SoaSuite ESB 10.1.3? You will see some tables of ... indeed: Oracle Workflow/BES!