The common sense SOA: Necessary components

A service-oriented architecture is only as good as the components and design standards that make it. If you want a practical and usable SOA -- not just a bucket of services -- then you should pay attention to five aspects of SOA development, say integration experts. The following bits of advice were gleaned from Ron Schmelzer, an analyst at ZapThink; Steve Craggs, president of Saint Consulting; and Jamey Harvey, deputy CTO for the District of Columbia.

Open standards. SOAs don't have to be based on open standards, but they won't be as useful in a cross-platform environment if they aren't. Adhering to standards such Web Services Description Language (WSDL), XML and WS-Security ensures that the SOA will be adaptable to all enterprise systems.

Granularity. How you splice application functions into Web services is a key consideration. If too many single-function services are needed to execute a process, the performance slows. Likewise, a bloated service that contains the entire process becomes too specific to use in other applications. The most practical approach is to create a balanced collection of smaller, reusable services for common functions and larger ones for one-off processes.

Service contracts. WSDL is the standard specification for creating a Web services contract, or a description of things such as the format and endpoint for a service. A well-defined service contract will result in more reusable services.

Enterprise Service Bus. An ESB provides a backbone for publishing services and enabling applications to access them. It also typically has useful features such as adapters for legacy systems, services-orchestration capabilities, security authorization and authentication, data transformation, support for business rules and the ability to monitor for service-level agreements.

Other integration tools. Not all integration should be done with Web services. EAI (for integrating application transactions), EII (a sort of middleware data query engine) and ETL (for moving data into a data warehouse or database) all have their place. They can also all be linked to an ESB via Web services.

So there's no benefit to trying to turn everything into a Web service. "An SOA itself is only a tool in the belt of the enterprise architect," says Schmelzer. "It's good for dealing with change, for handling heterogeneity. But it's not good for building tightly coupled systems."

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email Computerworld
• Follow Computerworld on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark