Most Read This Week
SOA & Web Services
A Unifying Mechanism for Effective SOA: The Business Service Registry
The top seven dangers of using a non-registry based SOA revealed
By: Luc Clement
Jun. 22, 2005 12:00 PM
Service-oriented architecture (SOA) is gaining widespread acceptance as a way to map business processes and tie together enterprise applications using Web services. Without a standards-based Business Service Registry to act as the unifying mechanism, however, SOA cannot fulfill its promise. The following is a guide to avoiding the seven dangers of implementing SOA without a Business Service Registry - while at the same time, gaining a major boost in IT agility and application interoperability.
In recent years, there has been a steady migration away from non-standard legacy interfaces and toward Web services. By offering a standards-based interoperability platform, Web services allow enterprises to more efficiently integrate applications and improve the accessibility of business processes for customers, partners, and internal users. Essential for both business-to-business commerce and internal business applications, Web services are increasingly used by organizations that want to improve their responsiveness and efficiency.
Yet the exciting new capabilities offered by Web services arrive with a degree of risk. An unplanned, broad adoption of Web services opens companies to uncertainty and even potential anarchy. How can enterprise architects make sure that the people who need the services will find them? Is there a way to ensure that developers are not wasting their time developing services that already exist? How can management ensure that services comply with technology, business policies, and application standards? Finally, how can IT and business leaders control how the services interoperate both inside and outside the firewall?
Companies need the architectural benefits of service-oriented architecture (SOA). An SOA can coherently map business processes with enterprise applications, inspire integration and reuse of applications, and foster effective governance of SOA services - often at dramatically lower costs and with less resources.
Still, enterprise architects who implement an SOA often realize that a key ingredient is missing: business service visibility and, therefore, control. If users, partners, and business analysts cannot easily find these business services and identify their attributes, the promise of SOA is largely lost. If developers cannot readily find and reuse services, they essentially don't exist.
The solution to this loss of control is a platform-neutral, standards-based method for publishing and discovering services. Using a standards-based Business Service Registry, Web services can be published as SOA business services that are ready for mapping and interoperability. By publishing services information, including capabilities and policy support, the Registry becomes the overall system of record for the entire SOA. The Business Service Registry allows the standardization of activities and procedures for enabling, publishing, discovering, and managing business services across the enterprise and between trusted business partners and clients.
Discussions with numerous SOA users illuminated several problems with using a non-registry based SOA. The following are seven of the most common reported dangers of not supporting an SOA with a Business Service Registry:
Danger #1: Wasted, Ineffective Applications Caused by Misalignment with Processes
Danger #2: Lack of Application Consistency and Integrity
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads