TMCnet News
The Five "But's" of Service Oriented Architecture (SOA)By TMCnet Special Guest David Cameron, http://www.aptsoft.com Today service oriented architecture (SOA) remains largely hype. The promise of modular, reusable services connected seamlessly into larger applications, while great in theory, has, by some estimates, reached only about 20 percent of its potential. It is time to ask why and what to do about it.
Imagine a technology architect faced with solving real business challenges who attends an introductory briefing on the concepts of a service-oriented architecture. Our architect, who must then apply these concepts to applications that solve real business problems, identifies five shortcomings and asks for a response. 1. But What About Data Management?
A service oriented architecture does nothing to solve one of the major issues in application development: the provisioning and maintenance of data. In fact, an SOA can make this process highly complicated. Unless accounted for programmatically or via some intelligent middleware design, data is simply passed in and out of services via XML.
While this works well at a micro level, when services are strung along into the processes that comprise an application, dependencies emerge which can significantly reduce the value of loosely coupled services.
For example, in an application that processes invoices with four sequential services, it is likely that each service creates data for the next service (approvals, inventory checks, etc.). Step 4 is in the process is highly dependent on the way data is processed in each of the previous steps. So, if a change to one of those results in different data—such as a change in the format of the shipping address—step 4 also needs to be changed.
Likewise if a step 2a is inserted, steps 3 and 4 will likely need to be modified. This results in cascading maintenance effort.
2. But The Processes My Services Support Aren't That Simple
Imagine a process that is not strictly sequential. For example, to process an order we need four approvals (via four different services) which can occur in any order but they must all occur before the fifth service creates the shipping manifest.
Because services typically work synchronously (you call a service and wait for a response), and because they only have information from prior steps, it is difficult to model and execute a non-sequential process.
3. But My Services Don't Let Me Respond to Activity I Can’t Predict or Model
How do I model and arrange services into processes I can’t predict in advance? For example, airport operations where, as any frequent traveler will tell you, the sequence of events is not planned in advance but rather made up on-the-fly based upon events on the ground (current arrival and departure status, equipment status, weather, etc.).
4. But Not Everything is a Service (Yet)
While purity of architecture is a laudable goal, very few organizations will actually adhere completely to the precepts of an SOA. More likely, IT environments will continue to include traditional applications that require integration via databases, middleware, or custom APIs.
5. But The Logic in My Services Needs to Change Frequently
Ultimately, services make decisions by applying the logic programmed into them to the data they are given. But what if that logic changes frequently so that it becomes difficult to maintain inside the service?
For example, a service evaluates a particular pattern of data access to see if it indicates an internal security breach and if so, then it opens an investigation. Since the triggering pattern must constantly evolve as data thieves get smarter, the need to constantly rewrite the code would inhibit the ability to stay ahead of the thieves.
Solving These Problems with Complex Event Processing
So how do we address these shortcomings? The common thread in all of the examples above is that they are event-driven.
Event-driven applications involve processes that are typically unpredictably non-linear (their timing and sequence cannot be defined in advance), dynamic (their characteristics change quite frequently), and continuously influenced by outside events (they can quickly mutate in response to real-time external activity). They require a new technology platform that fits inside an SOA: Complex Event Processing (CEP).
CEP is an emerging technology uniquely suited to solving a new class of business problems found in multiple industries. CEP enables the automated detection and understanding of often subtle and shifting patterns of human and system activity flowing through an IT infrastructure as well as the orchestration of timely responses.
CEP was first developed at Stanford University by David Luckham in the late 1990s under a DARPA grant. Initially, the work was focused on developing a system that could detect patterns of activity on IT networks that indicated attempts at intrusion and, upon detection, trigger automated countermeasures.
When implemented inside an SOA, CEP extends and enhances it to cover event-driven applications and hybrid applications involving events and services. But stay tuned for more on that next time.
Coming Next: CEP and Its Role in an SOA.
David Cameron, Vice President of Product Integration at AptSoft Corporation, writes and speaks regularly about the intelligent application of technology to address business challenges. He can be reached at [email protected].
|