Thought Leadership for the Global C-Suite

The VITO Report

Subscribe to The VITO Report : eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get The VITO Report : homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


VITO Report Authors: Elizabeth White, Liz McMillan, Roger Strukhoff, Timothy Fisher, Ernest de Leon

Related Topics: SOA & WOA Magazine, VITO Report

Article

Demystifying SOA - Myths About SOA Web Services Architecture

SOA enables an enterprise to increase the loose coupling and the reuse of frequently used software assets

For example, the telecom customers would have their own legacy systems/applications in place, which would dictate the details about the services and the service contracts. It would be required in these cases to align the new definitions of the services and the service contracts with the already existing ones, and the flexibility to reuse something already existing reduces this drastically. In other words, only green-field customers can reuse the SOA components to a large extent.

In a legacy environment, it is required to "wrap" the legacy applications that provide the services, in appropriate SOA wrappers that can expose a service view of the existing legacy applications. It is also required to define appropriate service contracts to provide an indication of the details for service invocation.

Myth #11: Services in the context of SOA are not explicit
Services are autonomous, and they are explicit with specific boundaries defined for each. These services are built to perform specific tasks or to provide specific functionality. Services are discovered using service contracts, and are invoked using the information in the service contract. Each service has a specific life cycle, as shown in Figure 7.

Initially, the services are identified along with the customer. Once the services are identified, they need to be defined, built, and deployed. The federation of services is basically the collaboration between the various services that results in a composite service that provides an aggregated functionality. The services are used extensively once they are deployed. Subsequently, when the reuse level of the services drops or a newer service replaces an already existing service, then the service enters the withdraw phase. At this time, it is possible to reshape the service, which might result in the identification of a new service.

Myth #12: SOA is applicable only to specific industrial domains such as Internet Data center
SOA is an architectural concept, and does not have any dependency on any specific industrial segment. Though it has evolved in the context of an e-service-based industry or an e-commerce-based organization, it is equally applicable to any other industry. The concepts of an SOA can be applied to a telecom domain, financial services domain, and so on. For more details on HP's SOA approach, see http://h20219.www2.hp.com/services/ cache/242475-0-0-225-121.html.

Myth #13: SOA can be sold to customers as is
While SOA is bound to help in the sales of several software products and best practices, it is preferable to tie it up with practical examples and case studies, enriched using the business processes. Because it is not possible to sell a theory in isolation, SOA needs to be coupled with a set of practical examples and products before it can be successfully demonstrated to customers.

Summary
In today's context, it is good to understand clearly what SOA can do and what it is. There are perceptions about SOA that are not always accurate. This article is an attempt to clarify those perceptions and put things in proper perspective. Once the concept of SOA is clear, it helps both the field teams to sell it appropriately and the delivery teams to set the expectations as to what exists and what can be reused.

More Stories By Raghu Anantharangachar

Raghu Anantharangachar is a solution architect with the Hewlett Packard Global Delivery India Centre, Bangalore. He has over 15 years of experience and has worked on porting, network management, and system integration projects in the past. He has a Bachelor's degree in Computer Science and Engineering from Bangalore University and a Master's degree in Industrial Management from the Indian Institute of Science, Bangalore.

Comments (1)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.