At the end of the last year, we could watch a massive campaign promoting a paper "Practical SOA for the Solution Architect" ran by Ganesh Prasad , a consultant architect of WSO2. Although we both worked in IT and with SOA similar time and both our names are 'holy' names, I have found myself in disagreement with Ganesh in several points. I'd like to capture the attentions of Solutions Architects in discussion on these points of practical SOA (assuming there is an impractical SOA as well).
First of all, in contrast with Ganesh, I believe that a Solutions Architect does not only understand Business Requirements (BR) provided by Business Analysts and produces a High Level Design document targeting integration but, independently from Business Analysts, needs to analyse and validate all BR. This is the only way to find what Business really needs rather what is said in the BR. I am still not convinced (for the last 10 years) that service orientation is about component integration instead of interaction and that just integration of the component can satisfy new business needs. Well, it is also possible that Ganesh has defined the Target Audience for the whitepaper in such way that I simply do not fit in.
A novel approach to architectural solutions, proposed in this "practical SOA", revolves around the Data Layer and Technology Layer. Being a bit surprised, I suspect that Ganesh does not really distinguish between Solutions and Technical architect works: the whole purpose of service-oriented solution is in the integral composition of business/operational and technical/automated means. Talking exclusively about data and technology is barely a half way journey. I do agree with Ganesh that these two layers are fundamental for the "loosely-coupled interoperability" but it seems that this concern is secondary comparatively to the work to be done - creation of a business functional solution. To my taste, I'd prefer that the Data Layer were designed once as a framework element rather than asking a Solutions Architect to design it for every project. Also, I am not sure that I "buy in" the idea of "SOA Product", which a Solutions Architect apparently has to choose in the Technology Layer according to the whitepaper, - I am not aware of such thing as "SOA Product" (no one can buy SOA while SOA does not require any new technology or products).
Following along the "Practical SOA..." whitepaper, we can find that the Technical Layer is supposed to consist of the three "Core Components": Service Container, Broker, and Process Coordinator. Let's take a look at these components.
Service Container is set as a host for "Custom Logic" known in service-oriented solutions as service implementation or Service Body. It is unclear why we need a container for a Service Body and what it might be for a variety of services that operate under different ownership and authority (OASIS SOA RAF). Each original "Custom Logic" may require its specific implementation and even its platform/technology. What characteristics of the Service Container should be in addition to the service implementation are not articulated unfortunately.
Talking about Broker, the whitepaper identifies three base elements: Adapter, Transformer, and Mediator. All of them are represented as the means to involve legacy systems and their logic/data into the architectural solution. This is a quite reasonable assumption that interfaces and data of old legacy systems may be incompatible with contemporary legacy systems but this constraint does not justify a necessity of a Broker. Even if we setup an Adapter- Transformer, this still does not explain why we need a brokering capability (I am not sure I understand why anybody would like to "hide, proxy or throttle access to a legacy data or app" using a Broker if we have an Adapter already). On the other hand, if we do not look further for more flexible and robust solution, the Broker has to combine Adapter, Transformer, and Mediator capabilities together. The major concern in this case is an obvious system bottleneck constituted by such Broker.
In reality, the Best Practice of service-oriented solutions, which involve old legacy systems, advices to start by creating an individual service for each system and then design interactions with this service replacing interactions with the system. Described service can accumulate the Adapter and Transformer capabilities. It makes sense to affiliate these capabilities directly with the legacy system rather than overload a Broker with such special tasks.
Now, Broker can focus on mediation, in particular, on network mediation. This is a self-sufficient task that many be addressed by an infrastructure specialist regardless information transformation and the use of specific systems' interfaces. Aforementioned mediation should link sender and receiver endpoints at the transport level knowing where each participant of the interaction situates in the network at the moment.
It is necessary to note in this context that content-based mediation is an anti-pattern. In service-oriented ecosystems sender (requester) always know who it deals with, who the provider is; otherwise, there is no way to establish business trust, which is a precondition for each service interaction (OASIS SOA standards). Disparately, a content-based mediation assumes that the mediator does not only aware of the business logic of all interactions but also can make a decision (instead of the sender) which receiver the message may be directed to. While this is a great technical capability useful when all interaction participants are under the same control, it does not fit with the Principle of Service Composability and the concept of Service Contract (OASIS SOA standards).
The only alternative solution that permits an intelligent intermediary (like a Broker) requires that this intermediary to become a fully-fledged actor-delegate of the service with all its business responsibilities. No Brokers take such responsibilities on themselves (which is OK) but this sets a content-based mediation aside from the business transactions between consumers and services. Instead, the consumer has to identify the receiver in the request but has not necessary specify the receiver's endpoint, which may be discovered/resolved by the mediating intermediary.
Before discussing Brokers, I started talking about services that buffer individual legacy systems. The reasons for this design are: an old legacy system is
a) an old legacy system is unlikely capable of performing as a service
b) an old legacy system is exposing its internal constraints on the consumers (usability aspects)
c) an old legacy system does not support the majority of Principles of Service Orientation and, thus, cannot be used as a service
At the same time, an old legacy system can be effectively used as a resource for the service, which allows reusing the legacy functionality when needed. Thus, a Broker may be good for the services but error-prone for brokering legacy systems.
The whitepaper also represents so-called Process Coordinator whose job is "to pull components together dynamically based on run-time status and that can invoke Brokers in the role of Adapters based on per-defined business logic. I have two comments in this regard: 1) invocation of brokers instead of adapters is odd, especially in the distributed model; 2) if we talk about services rather than components; dynamic invocation of services requires the willingness and trust that we described before. We cannot omit these activities unless we had performed them up-front and created a pool of available (based on Service Contracts) trusted services. I do not see what might be so special about this Process Coordinator, which is known, IMO, as a conductor of service orchestration for years.
The rest of the whitepaper explains some common design mistakes and provides examples of correct use of discussed service infrastructural elements, which I find useful. This also includes an explanation why data models specific to particular services are more valuable than an "impractical ... search of a Canonical Data Model", i.e. one for all. In the example, a Canonical Data Model confronts to data models for Institutional Banking, Retail Banking and Wealth Management and loses. I have to note that listed banking data models belong to quite independent baking domains that, therefore, do not need to share the same data model. It seems that the example is not representative enough to state that a Canonical Data Model is not needed. I can propose a different approach - a Canonical Data Model may be created as a united collection of domain-specific information artefacts (business data objects) inside each of mentioned banking domains independently from the data models used in the services/application existing in the domains. In this case, every consumer of data creates and maintains its own data model, which in essence is a view on the Canonical Data Model. This allows to utilise Master Data Management technique: each service may request data according its own data model but the actual values are nothing else than a sub-set of data of the Canonical Data Model When a need for data in the application/service changes, its view on shared Canonical Data Model changes appropriately and no other consumers of the data are affected.
As it is expected, the whitepaper, accredited by WSO2, represents a "theoretical" support for the WSO2 solution for SOA. However, it is still a secret to me why it required new terminology and presentation of relatively known solutions and practices as if it has been discovered for the WSO2 solutions specifically.
Leave a comment