We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Where SOA Meets Cloud

David Linthicum

When Considering Services...

Vote 0 Votes

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

This blog is your first step toward understanding the issues you will face as cloud computing and SOA converge. The movement to cloud computing is a disruptive change that IT departments will soon face as SOA and cloud computing begin to have an effect on the modern enterprise. IT managers must learn how to give as well as take information in this new, shareable environment, while still protecting their company's interests. Innovative companies will take advantage of these new resources and reinvent themselves as unstoppable forces in their markets. Those who don't take advantage of this revolution will become quickly outdated, perhaps out of business.

David Linthicum

David Linthicum is the CTO of Blue Mountain Labs, and an internationally known distributed computing and application integration expert. View more


 Subscribe in a reader

Recently Commented On

Monthly Archives