Services are the building blocks of SOA, and like building blocks of a house or a building, the quality will define the value of the finished product. In this case, the SOA itself. Thus, spending time on what services do, how to define them, how to design them, and how to build them is a good investment in time, and something that’s missing within many architectures.
Clarify these services issues at the outset of a SOA project to build better blocks:
First, services don’t need to be Web services.
However, this is a confusing statement for those of you who have been absorbing the hype. The fact is, you can build a SOA without Web services, opting for more traditional approaches such as transactions, distributed objects, or custom software systems. Indeed, when considering “special needs architectures,” such as those requiring high performance, the use of Web services are clearly contraindicated.
Second, services produce behavior and data, not just data. Most who design, create, and/or expose services think of them as data providers, and indeed they are in most instances. You invoke the service, data is produced in the context of a structure, and consumed into another system. However, while many services are very data-oriented, services are able to provide behavior as well, or, the ability to do something around the containment of the data, or perhaps provide behavior without data at all.
Third, services are not applications, and should not be designed like applications. As you’ll see below, services have their own specific design orientation. The way you define and design a service is very different than what many consider traditional application design. You’re building a much smaller system that exists within many systems, and thus special attention needs to be paid to interoperability, granularity, core purpose, and testing approaches.
Finally, each service has a specific purpose, and they are not complex or naturally dependent upon other services. Thus, they are easily abstracted into composite applications, in essence, leveraging these services as if they are functions local to the composite. This is where exposed services have a tendency to fall down. Since they were not designed, but abstracted, they typically have far too many dependencies to be as useful as services that were designed correctly from scratch. That’s the tradeoff. Services should exist with a high degree of autonomy. They should execute without dependencies, if at all possible. This allows you to leverage the service by itself, and design the service with this in mind no matter how course- or fine-grained the service is.
How does one design a service? Also, what tools are available? There are certain steps architects and developers can follow. Here are some suggestions, assuming new service design.
- You need to define the purpose of the service. What will the service do, and who are the intended user; human, application, and / or other services?
- You need to determine the information to be bound to the service, including both metadata and schemas. This means you need to understand how information is leveraged by the service, and what functions require what data.
- You need to determine the functions (methods) encapsulated inside the service; in other words, the behaviors you would like to expose. It’s also at this step where we define each function, including how the function breaks down using a traditional functional decomposition chart.
- You need to define any interfaces into the service, both machine and human. This means we need to determine how the service will interact with the calling applications, and through what mechanisms.
- You need to define how the service is to be tested, using the suggestions above. This is a very important but often neglected step where you define how those who leverage the service will test the service within the context of their usage pattern. You need to define test information, service invocation, and validity of results.
What’s core to the success of SOA is a clear approach to service design, development, and testing. At the end of the day, it’s good old-fashioned discipline that comes into play here, more so than new technology, tools, and programming tricks. That’s not what people want to hear in the context of the deafening hype, but that’s the reality.
The truth of the matter is that services are a new challenge for developers, and they bring their own sets of requirements. In many ways it’s as much of a shift in thinking as was the movement from structured analysis, design, and development to object-oriented analysis, design, and development. We all know how long that took, and in many respects it’s still going on today.
What we’ll see in the short term is what you expect to see with any new approach…poorly designed, developed, and tested services that bring high cost and lost productivity. Thus, the failures will lead to rethinking, relearning, and retooling to get service design right. Count on large expenditures on training, tools, and testing infrastructure over the next 3 to 6 years. Also, count on some pushback on the whole SOA concept as people understand that they are very dependent on the underlying services, and thus the architecture will suffer as well as developers move along this learning curve.
Attention needs to be paid around the process of exposing existing legacy systems as collections of services. While it appears that you’ll have to take the interfaces as they are deployed, now exposed as services, there is actually a lot the developers can do to design abstracted services that better serve the architecture. While many believe that tools and technologies that turn APIs or transactions directly into services are the way to go, most will find that services built using those principles provide very little value in the long run.
