Updated: 5-Dec-2017
Foundations of ISA – Base paradigm – Scale ISA global
Iteration 1: The SOA case
Before all, what is the SOA (Service Oriented Architecture)?
Is this a mean to make communicates two systems? An architecture that promote layering? An integration style? Does it require a software bus? What is the protocol? What is its technological stack? The ultimate goal of the SOA is it to target the professionals of the trade? The SOA Manifesto own definition?
Not so clear…
At first glance, I would say that SOA is an architectural style for communication, deriving from the more general paradigm Client/Server.
Initially, I had put the SOA in the useless concepts chapter, since it does not fit well with object Orientation. However, the SOA, at least the term, is so often used in Information Technology that it seems to me impossible to avoid consider this architectural style in itself. So like the others paradigms for ISA, a table of analysis is elaborated.
| Meaning | |||
| A service-oriented architecture (SOA) is a style of computer software where services are provided to the other components by application components, through a communication protocol over a network (Wikipedia – 2016). | |||
| Pros | Powerful paradigm to integrate complex systems thru the service and contract notions. Deployed together with a software Bus, the SOA outperformed Mediator design pattern to promote it at the organization scale (low coupling).
Promotes a business approach of the functionalities rather than technical one. Largely disseminated paradigm with a wide experience and an extended community. Can be adapted to the targeted organizations. Standardization of the exchanges. Provides interoperability in heterogeneous contexts. The SOA is appropriate to separate concerns in layers. The UI and the business treatments can be clearly separated. SOA makes explicit the remote call. Not doing that was one of the most criticized aspects of the traditional distributed Objects. |
||
| Cons | Many difficulties in SOA adoption and even more in maturity progression.
SOA has many declinations, very diverse ecosystems and maturity levels. This doesn't make easy the generalization for ISA of a complete suite of principles and practices. SOA works well in adapting to very diverse contexts and organizations. In other words it is fine for solving heterogeneity issues. ISA, as it is a homogeneous approach, is not in this situation, at least at its heart. Standardization and interoperability is not so well done (SOAP versus REST versus …; WS stack incompatibility – among versions, among vendors; organization specific standard; lack of applicative context). Transactions are not gracefully managed and require compensation mechanism. The service granularity is not simple to determine (coarse-grained versus micro-service, service versus service operation). state-full services are often discouraged mainly because of scalability issues. This enforces the consumer to keep the whole context. This prohibition makes impossible isolation between clients at a business process scale. Like in oo, the abstraction levels are not easy to deal with in SOA. For instance, at a first abstraction level you might have identified 3 services. But when refining the design, you find that you need to group 2 of this 3 services and split another in 2 services. When signature final definition and realization come into play, you realize that new services may be required and some others completely refactored. SOA often drives to functional decomposition of a system and to an Anemic Domain Model, those are both bad practices as pointed out respectively by B. Meyer (Object-Oriented Software Construction § 5.2 functional decomposition) and by Martin Fowler (See References). SOA do not provides integration solutions neither at the UI level (layer) nor at the data level (layer). Examples: Reuse of a very common editing interface, data bulk load. Correlatively but distinctly, the SOA is inefficient on large and complex data (a data grid in a client/server solutions like Microsoft VB or Oracle Forms is for instance much more simple and efficient). Contrary to oo, the object notion is lost by the SOA when traversing architectural layers. For instance, the SOA cannot support object linking and their dynamicity (like in OLE and DDE). The SOA makes more complex the software construction (multiple interfaces, mapping of DTO, layers and systems responsibility limits dilemma, etc.). The Uniform Access Principle (UAP) is an important property the oo paradigm can support to make implementation easy and runtime independant of the implementation details of features. It is not relevant at all at SOA. In a broad sense, UAP is also applicable to object access in it self, not just to its features. This is crucial because Objects are always available if you have access rights on them. This property avoid having the silos commonly encountered in SOA applications. This property avoid the need for any “data centric” approach the SOA may implies |
||
The best
At the heart of SOA is the Service Contract, the contract between the provider and the consumer. That is this concept that makes the SOA so efficient; the ability to make working together the separated components thru a well defined interface. This allows building complex systems by assembling complex components made by separated teams.
The agreement by an interface contract is not limited to the computing domain, but is also the approach used by very varying industries, like electricity, mechanics, electronic, transporting, commercial trading, etc.
Another key to the SOA is that the service notion is quite easy to understand. You ask something to a provider, you give it some data, and this result in a change in the system and/or data in response. This is very similar with a dialogue between two people. This triviality is not shared by the object Oriented paradigm for instance.
The worst
The difficulty to SOA adoption also comes from the concept of contract. This is because a contract is a commitment between 2 stakeholders. It is an agreement. You have to decide. To tell precisely what you need, what you want. This is in my opinion the key difficulty to SOA adoption: People are afraid to commit themselves, to decide… Because even if they can freely change the contract after, changing it is a form of discredit of themselves.
There are ways to address that difficulty. For instance, having a Mediator Team that is specialized in making Service agreement between teams.
Another way is dictatorial. One guy makes a complete definition of the service. This is the way most REST APIs are “designed”. They often are the result of the process of building a running applicative system, driven by the user interface needs. Then the API is what it is, but it run.
This is why, in my humble opinion, this approach is so “successful”.
The table above mainly showed that almost for each advantage, a corresponding disadvantage is also identified.
Where the SOA excels is in solving heterogeneity problems. Since ISA is a homogeneous approach it is not in this situation. So the SOA core cannot be pertinent in the ISA context.
All that said, it remains two important SOA qualities not trivially supported by an oo approach: (1) the ability to integrate complex systems and (2) the promotion of a business approach instead of a purely technical one.
These two properties appear important in the ISA scope. So they have to be supported.
(1) Integration
The chosen (distributed) OO approach is perfectly adequate in order to manage integration within ISA heart. In particular, the notion of Interface already exists. There are just some extra features to add to it in order to incorporate the Contract notion (Specification, Service Level Agreement).
Furthermore, the SOA integration capacity could be interesting at ISA borders. For instance, the SOA seems appropriate for interaction between systems from different business domains. Another usage could be the encapsulation of non ISA compliant (existing) systems. In both cases, the OO approach could be used to solve the impedance mismatch between SOA and ISA, in particular thru the Facade design pattern.
The pertinence of introducing an “Object Bus” (Mediator design pattern) has to be considered.
(2) Business orientation
Object Orientation has proven not to be very appropriate for the communication and the dialog with business people. It is certainly the most important reason for which UML has incorporated the Use Cases concept. On top of that, a Business process level is also often required. They are typically expressed using BPMN.
On the other hand, while SOA is declared to be suitable to follow a business approach, that is not as true as this. Yes it's true if you have well defined and followed the SOA governance across your organization. But in real world, this is not often the case. The SOA struggled to grow in maturity levels and it is certainly not the technical (geek) oriented REST API trend that will change that tropism. (Also refer to “Service Orient or Be Doomed!: How Service Orientation Will Change Your Business” for benefits of SOA for business).
So what?
ISA should find its own way taking into account these experiences.
For the moment, we can already notice:
(a) BPM, use case and Object model (data) of a business domain are valuable to support a business approach (among multiple references “use case Driven Object Modeling with UML”).
Other SOA properties
Finally, ISA must also provide some other more trivial SOA qualities: Separation of concerns between layers and explicit remote call.