Essential for both business-to-business commerce and internal business applications, web services are increasingly used by organizations that want to improve responsiveness and efficiency. By offering a standards-based interoperability platform as an alternative to non-standard, legacy interfaces, web services allow enterprises to more efficiently integrate applications and improve the accessibility of business processes for customers, partners, and internal users.

	express delivery
	• print  • comment
	Without a registry to track services and their inter-relationships, an SOA environment not only lacks coherence and control, it invites chaos. Luc Clement is a senior program manager at Systinet, and serves as co-chair of the OASIS UDDI Specification Technical Committee. Systinet is the maker of Systinet Registry, a business services registry that fully supports the latest UDDI V3 specification.
	Glossary terms: registry, UDDI, metadata, business process, lookup tool Sponsored links: your text link here

Yet the exciting new capabilities offered by web services arrive with some risk. An unplanned, broad adoption strategy 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 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?

Companies need to deploy web services within the framework of a service-oriented architecture. An SOA can coherently map business processes with enterprise applications, inspire integration and reuse of applications, and foster effective governance of services within the SOA — often at dramatically lower costs and with fewer resources.

Yet enterprise architects implementing an SOA often realize a key ingredient is still missing: business service visibility and, therefore, control. If users cannot easily find these business services, the promise of SOA is largely lost. If developers cannot readily find and reuse services, they essentially don’t exist.

The solution is a platform-neutral, standards-based registry that publishes web services as SOA business services, ready for mapping and interoperability. By publishing services information, including capabilities and policy support, the business services registry becomes the overall system of record for the entire SOA. Conversations with numerous early adopters of SOA have shown that problems arise when this registry functionality is omitted. Following are seven of the most commonly reported dangers of not having a business service registry:

Danger #1: Ineffective Applications Caused by Misalignment with Processes — A business service registry provides easy-to-use tools with which business analysts can survey an enterprise's business services portfolio and determine which are available to automate processes and address pressing business needs. Whether it’s tracking down sales leads or conforming to e-government compliance, a registry allows analysts to measure the impact of changes in business requirements on processes and services.

Danger #2: Lack of Application Consistency and Integrity — Ultimately, the registry’s enabling role for governance of services may be its most important advantage. A registry offers the nuts-and-bolts compliance and approval tracking process that can ensure the integrity of service governance and policies. Companies are enforcing compliance to a growing list of standards and codes, such as Basel II, Sarbanes-Oxley (SOX) and HIPAA. SOA governance is essential to conforming to any business, industry, or security standard, and a registry is essential for SOA governance.

Danger #3: Difficult to Relate and Reuse Application Functionality — One of the most important roles of an SOA business service registry is to expose information and applications that are redundant, conflicting, or inefficiently distributed across the organization. The goal is visibility of the business services portfolio — getting users to the right applications at the right time. Visibility enables speedier development, greater application reuse, improved governance, and better business planning and management. Without visibility, IT architects and developers can’t fully grasp which applications are under construction, which could be adapted for reuse, and which components are available.

Danger #4: Proprietary, difficult to maintain interoperability software — A business service registry that is fully compliant with standard web services and the web services standard UDDI interface offers the greatest flexibility in implementing SOA. Any business service endpoint can be published and located in a registry, whether or not it is a web service. Standards compliance is vital to ensuring that you have the best, most up-to-date interface that delivers on-demand, location-independent interoperability.

Danger #5: No Motivation to Reuse Services — One of the most immediate ways an SOA business service registry can create ROI is by helping businesses cut development costs. The key lies in increasing the reuse of enterprise applications. Even in smaller businesses, applications can easily get lost in different business-unit and development-platform silos. Web services and SOA can help make applications more readily available, but without a registry to guide the way, it remains difficult to locate them or evaluate their usefulness.

Danger #6: Time Wasted Locating Service Information — By providing a fully annotated, service-oriented view of applications, a business service registry speeds the development cycle. A registry provides an automated process for developing, unifying, and replacing more ad hoc procedures. It does so by identifying important versioning, technical information, and participant information related to particular development tasks, so that projects get up and running more quickly.

Danger #7: No Control and Lack of Dependable Business Services — One of the key elements of visibility and reusability offered by a business service registry lies in its enablement of process definition and the development of extensive service descriptions. By offering a high level of detail, the registry does more than simply enable the ability to locate a service; it reveals the content behind a service and makes it easy for users, developers, and analysts to get a deeper understanding of business services to determine whether they’ve found the right service.

These same service descriptions enable managers to better monitor and control services. Enterprises can develop metadata for services, detailing everything from security and performance criteria to versioning and release notes.

A business service registry creates the practical framework for letting companies manage all the information about their services. Without a registry to track services and their inter-relationships, an SOA environment not only lacks coherence and control, it invites chaos.

More on this topic