Services are the building blocks of SOA, and cloud computing for that matter, 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 or cloud 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.
Leave a comment