Advantages of the Service Oriented View
If SOA is so “old” why do we still have all this excitement about service oriented architecture applied to IT? Isn’t SOA an obvious choice anyway? In fact, the history of computer science has always been about movement from the very complex to the obvious. While in the pioneering days of computing it took a John von Neumann to work out programming concepts, these days even an Alfred E. Neuman could easily write a decent program. The reason the “obvious” solution was not used in earlier decades is because “obvious” solutions require more complex technologies (recall my earlier discussion on the preservation of complexity). Think of the electronic spreadsheet which was invented in the early 80’s (Visicalc). In hindsight this invention is something obvious. Why then wasn’t the electronic spreadsheet invented even earlier? If we take a look at the character oriented computer screens prevalent in the decade of the 70’s, it’s clear that a spreadsheet model would not have been adequate for the teletype-like devices of that era. It took cheaper bit-mapped displays for the electronic spreadsheets idea to become viable.
What’s obvious these days is that implementing systems with SOA can lead to better solutions as long as the inherent issues of SOA are tamed and appropriate service interfaces and service management governances are established. In this context, a service-oriented view provides many advantages:
1. Allows a direct mapping to a business perspective. SOA allows the implementation of solutions that can directly mirror the business processes. In the past, system designers had to translate business processes into computer driven structures. System implementations based on awkward mappings of business requirements did work. However, given that the most natural way to describe business processes and organizational flows is through a consumer view and given the fact that older computers couldn’t cope with these views, the resulting IT systems almost always ended up being difficult to use.
In fact, SOA’s facilitation of a direct mapping with the business is key to the emergence of higher-layer business tools such as Business Process Modeling (BPM). BPM represents an even higher level of abstraction of automation which can be still be used to dynamically generate software solutions. The capability to give the definition of business processes to actual business users and then have these definitions used to generate actual applications is only feasible when these processes can call predefined services.
Without SOA there is no BPM.
2. Enables Reuse of well-defined logic blocks. This is a Lego approach. Just as a building contractor assembles the skills needed to build a house, services can, in turn, call services. A general-purpose service can be re-used by several applications.
Admittedly, reuse is not a new concept. It has been the holy-grail of computer science for many years. For example, in the early days code reuse was sought via definition of macros or subroutines—chunks of source code that could be embedded into the application.
While this approach had the advantage of reusing source code providing generic functions (“Convert Data”, “Hash a Table”, etc.) it did have its issues. First of all, programmers would sometimes tweak the library code to better match their requirements; making the code non-reusable. Also, as new programming languages emerged, these libraries became outdated and could no longer be used. This is not to say the use of macros is no longer valid. The use of macros or functions for repetitious snippets of code is still a recommended best practice, but only within the confines of a single application.
In time, other code reuse techniques emerged. The most important of these were the linkable libraries. Unlike macros, the programmer could use the library without having to know the source code; thus giving some degree of protection against improper changes. However, as with macros, these static libraries become embedded in the executable code, using more memory and ultimately forcing the updating of programs whenever the libraries changed.
Enter the Dynamic Libraries. The familiar Windows DLL (Dynamic Link Library) is basically a library that becomes dynamically linked to a program, pretty much on demand. However, dynamic libraries require the use of a specific running environment (i.e. MS/Windows) making them viable only when executed in the same system as the calling application.
Dynamic Libraries represented a good step forward, and indeed they have been extremely popular as commercially available add-ons for development tools such as Visual Basic and more broadly under MS/Windows frameworks. Still, what if you wanted to use a dynamic library from a different platform? What if you could place dynamic libraries into any system and be able to call them from any platform?
Enter the concept of Services!
Just as with DLLs, you can acquire and use external tools and services, but more fundamentally, because of the loose coupling, you can run your service in a system completely different from your own. You can call a Linux service from a Windows application, or call a service located somewhere in a cloud.
SOA is all about transparency . . .
3. SOA is the foundation for transparency. If you call a help desk these days, chances are that the person at the other end of the line is based in a foreign country. Thanks to the lower communication costs and the benefits provided by educational standards and globalization, companies benefit by sourcing the services wherever they are the most cost effective. Likewise, you can run services anywhere and have them accessed by any authorized user. SOA allows you to place a function where it makes the most sense. But, since what makes sense today may not make sense tomorrow, SOA is also about allowing change with a minimum of effort. We can finally decouple the way we logically partition functions from the way we deploy physical computer systems. Service Oriented Architectures should provide as many of the following transparency tenets as possible:
· Access Transparency. Provide the ability to access the system from different devices and mechanisms.
· Failure Transparency. Designing the systems with automatic service failure fallback, without affecting the application.
· Location Transparency. The ability to deploy the system in any location.
· Migration Transparency. Allow minimum or no impact to the existing system when upgrading service implementations.
· Persistence Transparency. If the desired service has not been used, you can load it automatically. If it has been used before you can reuse the code already resident in memory.
· Relocation Transparency. The system should allow you to movie a service from machine A to machine B without impacting clients.
· Replication Transparency. The system should be able to provide the same service from different locations. This supports failure transparency and it can also be used to increase performance via horizontal scalability.
· Technology Transparency. As long as you get the service to do what the service is meant to do, the client shouldn’t care about the technology used to implement the service.
These transparency attributes facilitate legacy integration with new technologies. Since the implementation of the service is hidden from the service consumer, the service-oriented approach enables the integration of older legacy software with emergent software. Once older applications are properly encapsulated under the guise of services, it is also possible to gradually transition a system by re-implementing services one step at a time. This removes the necessity to incur in risky “big-bang” system migrations. Also, these transparency attributes are what makes emerging technologies such as Cloud Computing possible. Without transparency there are no clouds!
4. Simplifies software development by decoupling business processes, decisions, and data. The agility gained from SOA comes from the inherent simplification of the software design. It becomes easier to assign development of different modules to different groups and isolates the way the program accesses the data. More importantly, because SOA can mirror the business processes, you can create organizational structures in IT that truly mirror the business structures.
The diagram above shows this concept pictorially. It’s far easier to decompose and assign each of the various business processes inside the box to the right, using external services, than having to adopt responsibility for the way data is accessed or manipulated.
Now that I have sung the praises of SOA, I want to bring us down to reality just a bit. There are certainly many traps and difficulties in using SOA, and it makes sense to be aware of them so that you can use the well-travelled roads of successful past experiences as much as possible. This means that designing SOA is all about figuring out the concept of patterns and the way services fit into these patterns.
That’s next.
Labels: Advantages, BPM, Cloud Computing, DLL, Macros, SOA, Transparency, Visicalc Microsoft, Visual Basic, Windows
posted by IT Transformation with SOA @ 2:26 PM
