SOA is mainly a mindset, an enterprise strategy whose natural implementation is represented by web services. In the early years, when the WS-approach began to emerge, it suffered from difficulties due to many factors such as complex adoption process and poor standardization. Now, the time has matured for using this technology with little effort while getting great advantages, both immediate and as an investment for our future works. In this chapter, we will go through the advantages of loose coupling, which is a key concept for an effective modular and extensible system. Then, we will show how SOA makes re-using easier with respect to traditional approaches. Designing pluggable services also favors the integration of processes, and guarantees a high degree of flexibility over time and technology changes. Finally, we will see how all these advantages contribute to raise the ROI.
The concept of "coupling" in software development comes into play at many levels. A common example is represented by the interface-implementation pattern, where the interface (also referred to as "contract") aims to decouple itself from the specific implementation(s). It can be generally defined as a measure of the dependencies among components. The more tightly one component is dependent on another, the more it is difficult to modify it without having to consider the impact of the modification on the rest of the system.
Keeping the overall measure of coupling low is therefore a good practice, maybe one of the more important indicators of a well-designed architecture. A loose-coupled system is easier to maintain, prone to evolving, and integrates better with other applications. In a word, it's the key-point of a successful architecture.
As we had mentioned earlier, loose coupling in general, can be applied in several ways in the programming field. One of the first examples of this pattern is the very basic concept of "interface" that every object-oriented language provides. Defining and using the interface in place of a concrete class (the implementation) is the first step towards loose coupling. This way, we obtain an independence from the concrete implementations of the interface. Hence, changing an implementation means no impact over the existing code wherever the interface is used.
Another example of loose coupling is the "Dependency Injection" mechanism provided by an Inversion of Control (IoC) container, such as Spring framework or PicoContainer. In this case, the container configuration, usually expressed by an XML file, allows us to "wrap" the various components together in a loose manner. Not only are we free to switch from one component implementation to another, but can also add or remove some orthogonal mechanisms (aspects) such as security or interceptors, just to make some examples. All this can be done by changing the configuration, without any modification of our code.
In the context of web services, though, the levels of loose coupling we can obtain extend this reach far beyond. Among these decoupling goals we can find:
Platform independence: Thanks to the XML-based communication, we get a language-neutral approach. Therefore, the server and client platforms are completely independent (for example Java and .NET).
WSDL language-neutral aspect and automatic code generation: Starting the design of a web service from its WSDL (contract-first approach) is a good practice since it allows us to have a language-neutral service definition. Furthermore, the code is automatically generated into the specific language. An example of automatic code generation from WSDL is shown in the following figure:
Document style: The independence from the platform can also be obtained with CORBA or other RPC forms. Every RPC approach, however, means a heavy impact over the existing code, when it comes to changing the signature of a business method in the back-end. This is not a good practice, as back-end methods should not be exposed. Document style instead means easier maintenance and flexibility, since it involves thinking in terms of messages, rather than distributed-objects. Hiding business methods through document style is illustrated in the following figure:
Flexibility and Fault-tolerance: A change in the structure of an exchanged object's class is generally a critical operation when it comes to distributed applications. The overall impact is quite significant since the "actors" involved in the communication must be updated with the latest class version. This is not the case with web services. Thanks to the fact that objects are serialized and deserialized to and from an XML stream, most structural changes can be introduced with zero-impact. Let's take for instance the sample code (Listing 30 — SOAP Document wrapped web service) shown in Chapter 2 in the "Document/literal wrapped" section and add a new attribute, with correspondent getter/setter methods, in the class
Outcomeat server side:public class Outcome { private String retCode; private String retMessage; private String other; ... }The server module can now assign a value to the new attribute and the clients that update to the new
Outcomeclass can receive that value. But what about the clients who do not update? Well, they will continue to work in the same way. They will obviously not be receiving the new value, but the deserialization process will not break. On the other side, we can remove an attribute (for example,retMessage) in the server module, and have a non-updated client receive a null value in this field,though still working.Asynchronous communication: Another important web service feature consists of being able to call a service in an asynchronous mode. This adds another level of loose coupling, since the caller module gains independence from the immediate availability of the called component, which for instance, may not be under our control.
It should be noted that there may be cases where tight coupling is better. In fact, low coupling has a price in terms of performance loss due to the introduction of interfaces. Furthermore, tight coupling allows strong type-safe checking at design time, which translates into robustness while loose coupling can only be checked at run time. Generally, the advantages of loose coupling in terms of modularity, flexibility, and scalability are considered to largely overcome its disadvantages.
Programming by components and libraries is functional to layering software development and thus to re-using parts with a modular approach. The developer takes already developed libraries (from within the company's repository or third-party) and builds upon them.
In the same way, the web services approach is functional to layering business process composition, since it allows the WS-developer to re-use already running developed services. By re-using components, the developer uses libraries and the compiled code should run as desired. Now, by re-using services, what is exploited is running code. The re-used service, in fact, is presumably already serving other clients or other "consumer" modules. Remember that one service may call another service, acting as a client in that specific communication process.
The level of re-use of web services is one of the most significant indicators of a successful SOA initiative. In other words, re-use provides high business value. In fact, the higher the number of processes that re-use a service, lower the cost of that service, and the easier it is to maintain and to test the code. High reusability is a clear indicator of how good the service originally designed was. It is a sign of the farsightedness of the analyst and designer teams. The service should be as independent as possible from a specific application requirement, possibly throughout, making extensive use of parameterization, or by decomposing it into more fine-grained services. The goal is to make the service "survive" the scope of one or few applications, and become generic enough to serve a wide range of applications or business processes with a modular approach. Indeed, this result is generally obtained as an effect of consistent investments into the quality of development process and standardization aspects, where great effort can be spent in the phase of designing new services.
A high number of services should not be regarded as a good indicator of SOA success, but quite the opposite. It is the ratio between the number of business processes built upon the services, and the number of used services that gives an index of Reusability:
Total number of Business Processes using Services
Reusability index = ____________________________________________________
Total number of Services
In the mid-to-long run, designing business processes or solutions can therefore become a matter of assembling services rather than creating new ones.
SOA is above all an integration-oriented design philosophy. It is a kind of approach that has been around since the beginning of the programming era. Indeed a number of legacy business functions, originally developed in COBOL or RPG, have been written following this paradigm. Many such pieces of code have survived most technology evolutions and are still running and often considered the most reliable and stable part in some systems. Being developed as shareable independent units, they can be seamlessly wrapped into web services today, and integrated in a SOA environment, and then survive again.
This teaches us an important lesson that when designing an application that is not intended to expose services, creating business functions with software as a service (SaaS) methodology is a winning practice. Thinking modular and shareable is the best insurance for our code, our work, and our design.
Integration may then happen at various levels. It can become a company's internal need, where new applications can be built exploiting already developed services. However, another interesting option is making a service available to others, thus exposing it externally. This paves the way for a new IT frontier.
The Internet is adding a new value to its nature as a repository of contents, explored by users through the browser. It is also becoming a container of business services that can be used by applications or accessed, joined and assembled to create new business processes. Manufacturers, suppliers, and customers (just to make an example) are becoming aware of the huge potential to be realized from adopting a service-oriented approach. This goes far beyond the Electronic Data Interchange (EDI) standardization introduced years ago to allow the business-to-business (B2B) data exchange. Now, the goals are the pluggability of services, and the overcoming of the B2B boundaries down to the consumer side that is business-to-consumer (B2C).
From what we have discussed so far, it should be clear enough how SOA can lead to a better ROI. Indeed, these chapters are very interlaced one to the other.
Loose coupling, in fact, means easier maintainability, and hence a saving in the maintenance phase. But it also helps re-use, which translates into less work to be done while developing new business processes. Seamless integration, on the other hand, means reduced effort when it comes to putting together heterogeneous subsystems that need to interact.
Loose coupling: Minimize maintainability effort
Reuse: Exploit already developed services
Seamless Integration: Reduce integration work
As you can see all these aspects are inherent to saving, and this could by itself be enough motivation to favor SOA adoption.
Saving, however, is not the only goal that SOA can lead to. It paves the way for new business opportunities since companies can react quickly and effectively to their customer's needs. Furthermore, the new development model, based on composition and the assembling of already available services, will disclose huge potentials for the business process designers.
Here is an analogy to help illustrate these potentials. Consider an exposed service analogous to an Application Programming Interface (API) of an operating system or a language. A set of API, possibly created by different third-parties, can be exploited by a developer to build a complex application or a specialized library. Similarly, a set of services from various sources can be used by a SOA designer to create a business process application or specifically, more complex libraries of services. This structured assembling process will not only boost the development by a significant factor, but will also allow rapid adaptation against the changes and evolution of the requirements.
In this chapter, we explored in detail the advantages that the SOA approach can lead to. Thanks to loose coupling, we can design at a higher level of abstraction, focusing on business concepts and actions, reducing the dependencies from the specific service implementation. Re-using can leverage the already developed services and therefore limit the development process to the creation of new services and assembling the existing ones. These factors are, on the other hand, key elements for a seamless integration within a flexible and adaptive information system. In the end, we learned that designing by services can help to build a solid infrastructure upon which we can plug our future projects. Nevertheless, we can also benefit from immediate advantages, since breaking the business processes down to their modular services allows for a better management, and opens the way to cooperation not only within the company, but also on behalf of third-party subjects.