SOA Interoperability and Integration Enhanced by Registry

One of the keys to SOA interoperability and comprehensive service-oriented architecture management -- in or outside of the utility and energy industry -- is the application of a business services registry. This tutorial will examine the features and advantages of the Systinet Registry, particularly as they apply to utilities and energy firms.

Innovative Registry Features Promote SOA Interoperability

The Systinet Registry implements some innovative features to promote SOA interoperability -- among other things.. Earlier this year, Systinet introduced the Governance Interoperability Framework (GIF) to help simplify the deployment and usage of SOA software in a multivendor environment. In effect, the GIF simply provides IT with a standard method of exchanging service information between different SOA products and vendors. The Governance Interoperability Framework supports existing Microsoft, J3E, packaged applications like SAP, and legacy systems: all of which have some level of support for Web services. Exchanging information with the registry becomes very important because this is the place where publishing and discovery of services happens.

Essential Elements of SOA Interoperability

When IT is getting started with a SOA today, typically there are three elements present on the services network:

• A Web-services-enablement or SOA platform
• A Web services or business services registry
• A Web services management component

These are the three technology elements that need to work well together to promote SOA interoperability and thus ensure success in the SOA environment.

Utilities Cry Out for SOA Interoperability

The utility industry (with respect to the need for SOA interoperability) shares similar features with other industries. First, most businesses are in a constant state of change -- which means their business rules and policies are called upon to change as well. And, just as in the utility industry, IT systems in many large companies were built in "silos" to solve functional needs as well as application-specific SOA requirements. As it happened, many of these applications were coded with rules and policies built right into them. Because these business rules and policies have been built into the code, there is not a lot of visibility with respect to these rules and policies. What's more, this built-in policy code tends to be "brittle": it tends to break (behind the scenes) when the rules inevitably change -- especially now as a lot businesses today are starting to try to integrate their formerly "silo-ed" operations horizontally.

How to Enjoy Integration and Access with SOA Interoperability

In order to integrate and access data across ERP systems, regulatory systems, outage systems, there needs to be a way to easily understand how to access these systems. This kind of SOA interoperability would feature three main capabilities:

• Visibility: What services, what data, can be accessed? What are the rules and policies? A foundation is required to obtain this visibility.
• Support for change: as new regulations or new utility operations are brought on, for example, through a merger or acquisition. Change must be handled -- on demand -- without negative impact either on the business or on IT systems. A level of agility is thus required to be able to change as the business changes.
• Support for more cross-functional business processes and data access: The need to provide higher levels business responsiveness: outstripping anything that could formerly have been accomplished by passing paperwork or picking up the phone -- in the interest of integrating data across financial services, ERP systems and so forth.

IT needs to be "on demand", responsive, and able to quickly connect services together -- almost in a dynamic manner: whether it's in response to a merger, new regulation or internal policy changes. Visibility, agility and responsiveness are now realities for both the business and IT. And, as organizations start to shift to SOA, they begin to realize that SOA is an approach that can deliver these benefits.

Managing Shared Services in the Context of SOA Interoperability

SOA (and the underlying goal of SOA interoperability) is really a strategy. It is a structured way to formalize IT systems around policies -- to formalize IT systems around very specific services that can be shared: so that "silo-ed" applications (ERP, regulatory or outage systems, for example) can be leveraged in such a way that services will expose pieces of those applications which can then be shared with either outside utilities or divisions within the organization.

As utilities transition into this new shared-services environment, they will require the means to:

• Ensure that they know what the business services are
• Know where the business services need to operate
• Understand which systems and data they are using

As part of the process, these IT organizations will end up developing a new life cycle -- a business-service lifecycle -- spanning service development from design-time to runtime.

Registry Describes Services, WSDLs, Processes, Policies -- Delivers SOA Interoperability

What is the role of the registry on the services network? In the shared-services environment -- in both design-time and runtime -- there are new descriptions of services (and new standards that support these descriptions). These descriptions encompass: Web services description languages (WSDL), business process execution languages, even policy languages. All of this information is (or ought to be) recorded with respect to each and every service. And each service, together will all of its metadata, is organized and presented as a business service in the registry. This process takes place both in design-time and in runtime.

Registry and Policy Enforcement Key to SOA Interoperability

SOA interoperability involves more than just integrating enterprise systems and storing related service artifacts in a registry. As SOA management systems execute, they will, as part of the policy-enforcement function, seek to discover services that are not conforming with critical business rules and policies. As part of this process, these SOA management systems may need to update and publish new services and policies. These SOA management systems will thus need a common area in which to host this information. And the registry, logically, is this "common area". It becomes the central location for locating (pointing to), discovering and governing services on the network. For both consumer applications and users, it represents the fastest and simplest means for accomplishing these goals.

Bottom-Line Registry Functions Promote SOA Interoperability

In summary, the registry's main functions with respect to SOA (and SOA interoperability) are: service enablement, publishing and discovery. The registry is the foundation for SOA governance, with governance being the act, for example, of describing (and enforcing) policy. [The registry can host the description of a policy, while a SOA management solution will handle the actual policy enforcement.] A policy could take the form of a new regulation. The same service may be running on the network, but now a new regulation might impose restrictions on the use of that service. Perhaps the service can only be used in certain states -- or perhaps there are new privacy regulations that apply to the service, requiring that data used by the service by encrypted. (And so on.) The point is that these variations need to be described somewhere so that changing policies, business rules and regulations can be effectively enforced -- so that nothing falls through the cracks. So that the organization is not exposed to penalties: fines, law suits, business loss, even jail time. The registry is at the core of this governance capability -- encompassing services and policy data across the development life cycle: from design-time to runtime.

For More Information

Learn more about how a registry, coupled with a SOA management solution, can help to achieve SOA interoperability and comprehensive SOA governance: download the free webinar, Optimizing the SOA Lifecycle from Design Time to Runtime with Comprehensive Governance