There were a few threads about whether SOA is about the technology or not.

In my opinion SOA and Architecture in general  are never about the technology - technology is important but it is just one variable in the equation. What we are looking for is a way to satisfy as many of the business needs as we can under all the constraints we face.

For instance, a few days ago I got a question in my email box from someone calling himself coldplay. While I don't think the band has somehow got itself interested in Event Driven Architecture, the question itself looked interesting enough. Here is the situation:

Current Setup
Lets take a e.g of a Inventory Stock Reorder point exception with in heterogeneous apps environment(No-SOA and integrations)...
The exception definition was built into the source apps and when the stock dropped below reorder....event registered and led to a exception. Exception was further handled by a rules based engine and a workflow notification raised ..

Planned Setup
Same e,g as above .. Post SOA implementation.. Inventory management is composite service built by orchestrating collaborative services from SAP and Oracle...which have different data model supporting them...
The exception definition requires to be defined outside the native Oracle apps and might have to get some event related information from SAP web service also .. to arrive to a conclusion as to whether this really is a Exception or not ..


Possible Technical approaches:

• Data Persists somewhere in the processing the Exception
• Data doesnt persist
• In mem database used..


My Question now :

1. What do you advise to be used in EDA?  which would reduce network round trips, decrease apps server loads from the above 3 technical outlooks.
2. What is diff between in-mem db and usual processing of apps logic by a apps server

I feel :

• Data persistence would lead to larger commit times and reduce operational efficiency
• If the data doesnt persist... and all validations are executed on the fly... dont you think the current apps servers would die processing ... or if its processing capacity is increased .. is it going to be economically viable alternative.

To be quite honest I can't really answer the questioned asked because the question lacks the business context -
what are  the implications if events are  missed or lost? What's the acceptable latency that would allow the business to operate properly ? if the Oracle bits and SAP bits need a lot of data from each other - then maybe the whole service partitioning is wrong and the services are not cohesive enough? How many business events are expected anyway? How often? and the list goes on.

Once you answer the business questions you can look at the available technology portfolio and ask whether you would want a in-memory Database or maybe a datagrid would be a better option? and even then the decision is not just technology driven since when you do cost/benefit analysis you need to take into account purchasing costs, operational costs, skillset of the dev team, time to implementation etc.

This is not to say that if you choose a technology that isn't aligned with your architecture you should reconsider the architecture (or technology). Also since each technology product brings into the table its own architecture (with its own constraints and decisions) you probably need to verify the architecture once you make technology choices. but still, at the end of the day it is the business needs that sits in the driver sit, the rest is just tagging along for the ride.