Info (Data) -Centric SOA and how it differs from task-oriented (process) SOA
5th Oct 2016
How it differs from task-oriented (process) SOA
More and more businesses across world markets are starting to get hip to the benefits offered by SOA (service oriented architecture). Unbeknownst to many however, there are actually two types of SOA, each having its own unique attributes. It could be stated that process, or task-oriented SOA is the most common type encountered; this is because its structure either closely mimics the operational configuration of the business in question or suits their system. However, it should be noted that informational or data-centric SOA, offers many distinct advantages over the task-oriented model, and in certain scenarios, vice-versa.
Task-Oriented SOA
In a task-oriented SOA model, there are essentially three layers to contend with. First, there's the process layer, which basically oversees the activities of the entire architecture. Next you have the service layer; this area is like a network of conduits that send and map everything out. Any additional adapters required to connect applications to the process layer would also be considered an integral part of the service layer as well. Finally there is the application layer; here, you have the actual applications and storage elements required to perform tasks. Most of the activity occurs in and around the application layer of a task-oriented SOA
Task-oriented SOA is not without its advantages; it is highly modularized, enabling it to keep its application processes segregated from those of its applications. What does this mean? This allows a task-oriented SOA to very quickly and quietly change or swap components with no ill effects. Ultimately, this may enable some specific types of organizations to become more nimble and perhaps also lower their IT budgets as well.
But everything has its downside, and task-oriented SOA is no exception. This particular type of architecture relies on a centralized processing engine to perform tasks and make decisions; this can give way to synchronicity errors between the running applications (modular components) and the engine itself. Despite its proposed flexibility, a task-oriented SOA may in fact not be flexible enough for some situations. As with most other types of computer infrastructure, long term planning and design often play a very important role in determining how useful a system can ultimately be. So despite the flexibility offered by task-oriented SOA, it still might not be elastic enough to deal with some scenarios. The functionality (of a task-oriented SOA) is also based on the notion that individual system processes will correspond directly with business processes (a 1 to 1 ratio). This idea that an application provides one independent service prevents an organization from being able to reexamine their IT assets and implement them in newer, more creative ways. In other words, there is a tendency for business practitioners to evaluate the capabilities of their system and its processes and try to mold their business around them. This is the exact opposite of what they should be doing; business owners and managers should be utilizing their IT assets in a creative fashion to enhance their core business concepts and values instead.
Then there's the other type of SOA; the kind that's based more on the data being processed, rather than the processes themselves. What constitutes info-centric SOA? First off there's the event layer to contend with; this layer houses the rules and event processing data necessary to keep things organized and running smoothly. In a info-centric SOA, potential activities are often organized into channels which allow the system to determine the best corresponding action(s). Second, we have the service layer, which is responsible for keeping track of events as well as sending out requests for assistance from specific applications and processes. Lastly, there is the application layer. This layer is responsible for responding to calls for action that are requested by the other layers, and much like application layer in a task-oriented SOA, it also features all the components and/or storage elements as well.
Nothing's perfect of course, and information-centric SOA is certainly no exception to the rule. In order for info-SOA to be effective the proper conditions have to be recorded and laid out in both pre and post tables. This essentially dictates that a designer must take nearly every possible scenario into account; entirely possible, but extremely tiresome. Arguably, the most foreboding aspect of information-centric SOA is its overwhelming complexity. Whereas in task-oriented SOA you have a centralized system that everything is sent through, which basically keeps everything in order; info-centric SOA relies on a much more complex set of rules (pre and post) which govern its activities. This obviously makes managing or controlling it more tedious and difficult, and of course further complicates the addition or design of new components as well.