SOA and EDA

[system]

webMethods has put out a series of articles on SOA (SOA Made Simple). The latest installment comes up with a new term “EDA” or Event Driven Architecture. And like SOA, it is not really a new thought pattern.

I have to say after reading the article that I don’t really agree with their attempt to draw a distinction between SOA and the new EDA. The sticking point to me is the thought that SOA is request/reply and EDA is more pure asynchronous messaging being driven by events/triggers etc. There is nothing about SOA and it’s concepts that require a request/reply or synchronous architecture. SOA can also be event driven and frequently is. SOA is a concept on how services are constructed and wired not how they are invoked or triggered.

Honestly this looks like an attempt to make SOA or now the new EDA fit a product suite. A lot of other vendors are attempting to do this as well. Enough of my opinion here, tell me what you think. Here is a link to the article on Advantage.

[url=“http://advantage.webmethods.com/cgi-bin/advantage/main.jsp?targChanId=soa_made_simple6”]http://advantage.webmethods.com/cgi-bin/advantage/main.jsp?targChanId=soa_made_simple6[/url]

markg
http://darth.homelinux.net

[wMusers.Com1 (wMusers.Com)]

I agree that Event-Driven Architecture (EDA) is not a contrasting or superior architecture to SOA, at least not when SOA is defined broadly and understood correctly.

However, many early implementors and the tool vendors that supply them view SOA as a runtime-searchable library of point-to-point, synchronous web services with no consistent approach to security, orchestration, transformation or failover.

Sure, EDA is a marketing-driven term, but it is also helpful in understanding what it takes to be successful with SOA on an enterprise scale.

Now, if WM could just get a few more of the EDA features such as WS-Security and Soap over JMS baked into the core of the product instead of into Glue and ServiceNet they’d really be onto something.

Mark C

[reamon]

The concepts are not the creation of wM. As usual, the folks behind this are the analysts at Gartner. An article from 2003: [url=“http://www.computerworld.com/softwaretopics/software/appdev/story/0%2C10801%2C81133%2C00.html”]IT news, careers, business technology, reviews | Computerworld

TIBCO has posted something similar to what wM has: [url=“http://www.tibco.com/software/standards_support/soa_eda.jsp”]http://www.tibco.com/software/standards_support/soa_eda.jsp[/url]

Both wM and TIBCO are parroting what Gartner (Roy Schulte and David Smith) defines as SOA and EDA.

IMO, Schulte has introduced the “EDA” stuff to replace the old “pub/sub” stuff which sounds dated when compared to the new, way-wicked cool sounding “SOA.” It’s a way to remind those that jumped on the SOA bandwagon that “hey, there’s still this messaging stuff out there–don’t forget about it.” But that’s just pure speculation on my part.

This blog takes issue with Gartner’s view:
[url=“http://blogs.ascential.com/soa/archives/2004/11/eventdriven_arc.html”]http://blogs.ascential.com/soa/archives/2004/11/eventdriven_arc.html[/url]

From that blog:
“I think the concept of EDA is similar to ESB, and that it probably arises from the integration vendors, looking for a home for their technologies in the new architecture.”

EDA a new architcture? I disagree. Event-driven is a concept that has been around for years and many, many vendors have provided tools that fit that concept.

[wMusers.Com1 (wMusers.Com)]

One of my fellow members on the SOA Blueprints TC recently quoted from this IBM-authored article on the Service Integration Maturity Model.

I haven’t quite had time to digest what the authors mean by “eco-system integration”, but I did find the seven levels of service integration maturity to be a useful start toward assessing the maturity of an organizations SOA efforts.

---

[b]quote:[/b]

The seven stages of maturity

At IBM, we have been working on a maturity model and process for achieving desirable stages of maturity, a model called the Service Integration Maturity Model (SIMM). The level of de-coupling and amount of flexibility achievable at each stage of maturity are what make up the following seven levels of maturity:

1. Silo (data integration) []Integrated (application integration) []Componentized (functional integration) []Simple services (process integration) []Composite services (supply-chain integration) []Virtualized services ( virtual infrastructure) []Dynamically reconfigurable services (eco-system integration)

Each level has a detailed set of characteristics and criteria for assessment, and what follows is a brief description of the highlights of each level:

• Level One: The organization starts from proprietary and quite ad-hoc integration, rendering the architecture brittle in the face of change. []Level Two: The organization moves toward some form of EAI (Enterprise Application Integration), albeit with proprietary connections and integration points. The approaches it uses are tailored to use legacy systems and attempt to dissect and re-factor through data integration. []Level Three: At this level, the organization componentizes and modularizes major or critical parts of its application portfolio. It uses legacy transformation and renovation methods to re-factor legacy J2EE or .NET-based systems with clear component boundaries and scope, exposing functionality in a more modular fashion. The integration between components is through their interfaces and the contracts between them. []Level Four: The organization embarks on the early phases of SOA by defining and exposing services for consumption internally or externally for business partners – not quite on a large scale – but it acts as a service provider, nonetheless. []Level Five: Now the organization extends its influence into the value chain and into the service eco-system. Services form a contract among suppliers, consumers, and brokers who can build their own eco-system for on-demand interaction. []Level Six: The organization now creates a virtualized infrastructure to run applications. It achieves this level after decoupling the application, its servcies, components, and flows. Now the infrastructure is more finely tuned, and the notions of the grid and the grid service render it more agile. It externalizes its monitoring, management, and events (common event infrastructure). []Level Seven: The organization now has a dynamically re-configurable software architecture. It can compose services at run-time using externalized policy descriptions, management, and monitoring.

<!-/quote-!>

---

Mark

[Yemi_Bedu]

Hello,

For seven, they could be talking about building a service to handle a new document, based on unit components it contains. As an example, I would look at it the way we use WM IS to do segment processing. Well for a new document, if it has elements compatible with existing services on a system but not assembled in a static handler, an auto build of a new processor can happen to work on the data. That would allow for a tight processor that doesn’t have to worry about trying to loop through unused elements and you only have to make the initial segment handlers for updating processing tasks.

That then would be a Document-Event Driven Architecture. I am not sure how easily we can take advantage of this from a Field-Event Driven Architecture. Maybe something along the lines of parsing a simple string to make the processor, like “check inventory of item x and reorder” having three units. But that maybe be better built and faster processing from a statically existing service. Just some thoughts. Good day.

Yemi Bedu

[wMusers.Com1 (wMusers.Com)]

Not sure about that Yemi. I think it refers more to using Spring-like external configuration to modify the behavior of the service-oriented architecture at runtime without deployment of programming changes. I also see some of the JBoss interceptors or AOP facets concepts at work here. You don’t have to modify existing web services to change how a enterprise-wide performance monitoring “facet” would work or to tweak the logging level of a particular service invocation.

Mark

[Yemi_Bedu]

Hello,

Glad you had enough time to digest the article. I think you are right about Spring. The Interceptors are more inline to what I was saying, that is cool though. In fact, the Spring in a way could describe the interceptor use policies.

We can duplicate this interceptor in a noisy fashion with triggers and a state array. That array can be created through configuration files and loaded on execution. All types of triggers will subscribe to the same document, but only execute if it is in the required state (simple field filter). Playing from the ONJava article, something like:
[Container name=“ShipSchedule”]
[interceptor ref=“ValidateSO” /]
[interceptor ref=“CreateSO” /]
[interceptor ref=“CreateInvoice” /]
[/Container]

[Container name=“ShipProduct”]
[interceptor ref=“UpdateInventory” /]
[interceptor ref=“SendInvoice” /]
[/Container]

That would be nice. Would need some presumptions about docs/interval, threading, and need for replies. I sure love that autowire stuff for simplifying configurations in explicit scopes.

AOP scares me. More from a debugging perspective. I keep looking at these things and how they relate to WM IS services and using them with flows. although an AOP approach would be a seemingly only option for doing that logging level change you mentioned without making the service a bloated mess. Is there anything out there today that can do AOP style changes on flow services? The two sides of the coin are changes before execution (so we would reference the end result in later flows) and runtime changes (so we would not even need to worry about modifying some of our existing solutions). Good day.

Yemi Bedu

[system]

Good dialog as always. I did here Roy Schulte speak today about the EDA and SOA. The summary version is that the traditional EAI vendors are appropriate for large corporations with lots of integration points. Kind of what we already knew. The EDA term has been around for a while but I got the impression he is using it to bring the traditional vendors back into the fold.

markg
http://darth.homelinux.net

[jeffadkins]

I think you need to think about EDA and SOA not as competing architectures, but complementary.

Events signal a change to the state of the system. A user asks for something, a piece of hardware fails, a timer expires. Services perform an action. In essence, a service says "Give me X, I’ll do Y and give you back Z” It should be a truly a modular piece of code, but the modularity is at the business functional level.

So, an event simply causes a service or sequence of services to execute.

I think a more appropriate term would be Event-Driven, Service Oriented Architecture. The separation is because neither is required for the other to work.

Our lives are filled with events that drive us to use a service. The phone rings, we talk on it. This is an event and a service.

So, I don’t believe that EDA and SOA are irrelevant or just marketing terms, but rather trying to create a model of reality.