soaregistryrepositorydeployment 090316114404-phpapp02

SOA Chief Proprietary Information 2007 SOA Chief All Rights Reserved PAGE 1

SOA Registry Repository Deployment

January 2007


Disclaimer

All advice given and statements and recommendations made in this publication are: provided in good faith on the basis of information provided by third parties and/or otherwise generally available or known by the SOA Chief at the time of writing; and made strictly on the basis that in no circumstances shall this publication constitute or be deemed to constitute a warranty by the SOA Chief as to the accuracy or completeness of the contents of this publication. The SOA Chief shall not be liable for any loss, expense, damage or claim arising out of, or in conjunction with the contents of this publication nor for any omission from it.


Contents

THE SOA REGISTRY REPOSITORY IMPERATIVE .............................................4

COMPLEX SERVICE INFORMATION ...............................................................................................................4

THE CASE FOR GOVERNANCE ......................................................................................................................5

THE CASE FOR AN SOA REGISTRY REPOSITORY .........................................................................................5

BUSINESS PROCESS DRIVEN .........................................................................................................................7

KEY SOA REGISTRY REPOSITORY ASSOCIATED CAPABILITIES .....................9

STANDARDS BASED SOA REGISTRY REPOSITORY ........................................................................................9

INFORMATION MANAGEMENT ......................................................................................................................9

POLICY MANAGEMENT ..............................................................................................................................10

IDENTITY MANAGEMENT ..........................................................................................................................10

DISCOVERY AND REUSE ............................................................................................................................11

ENTERPRISE CATALOG ...............................................................................................................................12

DEPENDENCY MANAGEMENT ....................................................................................................................12

SERVICE VERSIONING ................................................................................................................................13

SERVICE CHANGE NOTIFICATIONS .............................................................................................................13

GETTING STARTED WITH A SOA REGISTRY REPOSITORY ........................................................................14

REGISTRY REPOSITORY SDKS ...................................................................................................................14

PRODUCT SELECTION .................................................................................................................................14

LEADING SOA REGISTRY REPOSITORY PRODUCTS ...................................................................................15

CONCLUSIONS ............................................................................................................................................16

REFERENCES ...............................................................................................17

APPENDIX: STANDARDS COMPARISON ....................................................... 18


The SOA Registry Repository Imperative Service Oriented Architecture (SOA) is being adopted by many Information Technology (IT) organizations as an architectural style because of its promises to make them more agile and efficient. The loosely coupled nature of SOA makes this possible due in large part by providing the ability to enable service components to evolve without requiring costly rework of existing applications. This agility and efficient is also made possible by the increased leverage and reuse of existing service components for developing new service components. SOA deployments have been performed by early adopters and have been comprised of pilot projects with small numbers of simple services. The information regarding these services was also simple and was managed, shared, and tracked informally using Web sites, databases, and e-mails. The complexity and scale of these deployments are growing steadily, as SOA deployments become more common. It is unrealistic to employ informal mechanisms such as Web sites and emails to manage, share, and track service-related information artifacts. An SOA registry repository is becoming an increasingly important component of an average SOA ecosystem. An SOA registry repository assists in managing this rising information complexity and meeting new requirements. This whitepaper explores some of the more common challenges encountered with large-SOA deployments, and offers advice on how an SOA registry repository may be utilized to manage these challenges.

Complex Service Information With the rising complexity of service components, it is no longer realistic to assume that all information describing a service component will be captured in a single artifact, such as a Web Service Description Language (WSDL) file. There are various information artifacts that describe a service component or relate it to other service components and information artifices. Some examples are:

o Multiple WSDL files may describe the various interfaces

and protocol bindings of these interfaces for the service component.


o Extensible Markup Language (XML) schema files may

describe the documents exchanged by messages in the service protocol.

o Business process orchestration for the service component

may be described by artifacts such as Business Process Execution Language (BPEL) descriptions, and Electronic Business Extensible Markup Language (ebXML) business process specification schemas.

o Metadata may describe the assembly structure and

subcomponents of a composite service, mashup. o Extensible Stylesheet Language Transformations (XSLT)

stylesheets may be used as adapters between service components to handle mediation

o Web Services for Remote Portlets (WSRP) descriptions may

describe how service components are utilized within portals o Business tenets and rules, organizational policies, and

procedures may define how service components and service artifacts may be defined and reused.

The Case for Governance Governance is defined as the art and science of managing outcomes, goals, consistent with measurable preconditions and expectations through processes, policies, and structured relationships which are applied to organization and utilization of distributed enterprise capabilities that may be under the control of different ownership domains

Organizational policies that insist on how service components and service artifacts may be defined and reused are simply insufficient. There must be a centralized point of control, logically speaking of course, that provides full lifecycle governance for service components and artifacts which enforces the organizational policies that govern them. This will ensure that the organizational policies are applied in a consistent and predictable manner throughout the SOA deployment, as well as across all SOA deployments, and results in improved quality and integrity of managed outcomes.

The Case for an SOA Registry Repository An SOA registry repository fulfills the role as the central point of control, System-of-Record (SOR), for managing service artifacts throughout the SOA lifecycle and enforcing organizational policies with


the SOA ecosystem.

The following is an example that describes a registry repository using a simple analogy:

o A registry repository is similar to a pubic library

o It has a repository that contains all types of electronic

assets, similar to how the library bookshelves contain all types of published content (books, magazines, videos, and so forth)

o It has a registry that contains metadata, data about data,

which describes the electronic artifacts, similar to how the library’s card catalog contains information describing the published content on the book shelves

o In some cases the registry and repository are administered

jointly, an integrated registry repository, similarly the card catalog and book shelves are administered jointly

o Multiple registry repositories should be able to work

together to offer a unified service, federated registry repositories, much like how multiple libraries participate in a collaborative network in order to offer a unified service. This is a wish more than it is a reality. Current registry repository products have a limited, if one at all, sense of federation.

The early SOA deployments recognized the imperative for more

formal mechanisms, other than simple Web sites, for managing, sharing, and tracking the ever increasing complexity and diversity of service artifacts. This led to the use of a registry such as a Universal Description, Discovery, and Integration (UDDI) registry to manage, share, and track service artifacts. Even though utilizing a UDDI registry is an improvement over less formal approaches, it has a critical limitation: a registry can simply store links or pointers to service artifacts. The actual artifacts must reside externally to the registry, utilizing informal and inconsistent mechanisms such as Web sites. This causes the actual artifacts to be ungovernable by the registry. The missing piece is a repository that stores the artifacts. If we revisit the library, what is a library only contained a card catalog and the books were contained in some external location.

While a repository can contain the actual artifacts, a best

practice is to only have the repository contain certain artifacts such as


the WSDL, or other interface, files, and policies and the link to other service artifacts such as example code, and supporting documentation.

An SOA registry repository should provide full lifecycle governance capabilities that allow organizations to define and enforce organizational policies to govern the publication, invocation, execution, and mediation of service information. Organizational policies are as unique as organizations themselves thus the SOA registry repository should provide a framework that allows organizations to develop custom policies, policy assertions, and policy templates for governing any service artifact, including metadata. The SOA registry repository should also provide a framework that allows organizations to define custom lifecycles and lifecycle events which trigger lifecycle state changes. The SOA registry repository should enforce design-time conformance, such as Web Service- Interoperability (WS-I) compliance when a service is published, and change-time conformance such as requiring approvals for all service artifact modifications. In addition to design-time and change-time conformance, an SOA registry repository could also provide a mechanism to develop run-time policies, such as service-level-agreements (SLAs), and distribute them to policy-enforcement-points (PEPs) for runtime enforcement.

Business process Driven Organizational and domain-specific business rules must be enforced to ensure that valid service artifacts are being published to the SOA registry repository. Simple syntax validation is not enough, but rather semantic validation must be performed on each artifact. An example would enforce a business rule that states “All WSDL artifacts MUST contain only Simple Object Access Protocol (SOAP) bindings and use Document style communication”. A registry repository should be business rules engine driven such that business rules can be enforced at any stage of a defined lifecycle. It should also allow business rules to be defined by organizations and specific to the various types of artifacts. If a governance policy fails during any stage of the lifecycle part of the business rule should be to notify the appropriate parties. The real value and power of an SOA is the ability to compose, orchestrate, and choreograph atomic, fine grained, services into higher order, more coarse grained, services and capabilities. The ability to mash together data resources and functionality from multiple services, applications, and legacy systems leads to a higher level organizational


agility. The composition, orchestration, and choreography of services and business processes ,which commonly cross domains of ownership, is a factor in the adoption of SOA within the organization due to the reuse nature of services. In order for organizations to succeed, they must enter into a paradigm shift that diverts the control of the organization’s future from the IT population over to the business population. In the SOA paradigm IT becomes more of an enabler to the business rather than a driving force.

A registry repository should provide the ability to compose higher grain services, which could also be incorporated as tasks in the orchestration of a business process services or extended to the supply chain in service choreography.

In a similar manner to business rules associated with service publication, there must be enforcement of business rules and organizational policies around the composition, orchestration, and choreography of services.


Key SOA Registry Repository Associated Capabilities

Standards based SOA registry repository Some SOA registry-only product vendors have released versions of their products with product-specific (proprietary) extensions in order to add repository capabilities. These were normally added through loose integration mechanisms where the registry and repository are two separate modules but have touch points between them. These products meet, either partially or fully, the governance requirements expected of an integrated registry-repository. This maybe an acceptable solution for some architects, however this type of solution is only practical when the SOA deployment is controlled by a single organization which can ensure either the utilization of a single registry repository, or if multiple instances are required that they are the same vendor product and interoperate.

In reality, SOA deployments tend to span organizational and governance boundaries. Organizations, regardless of size, prefer to have local autonomy over their SOA deployments, but also need to seamlessly integrate their services with the SOA deployments of other organizations. SOA deployments must be federated using open standards, in order to have local autonomy but also provide seamless global integration and interoperability.

The trend of vendor-specific, integrated registry repositories has

been overshadowed by the growing trend towards integrated registry repository products that are based on standards facilitating federation and general interoperability.

Information Management An integrated registry-repository, open standards-based, allows organizations to share and link information with other organizations in a secure fashion. A federated information management allows distributed registry repositories to appear as a single, virtual registry repository, but also allows organization to retail localized control own their registry-repositories. For instance, an enterprise may deploy a federated registry-repository consisting of a series of registry-repositories in different ownership, organizational, domains. This federated environment would allow individuals to discover information


seamlessly across the enterprise within any organizational domain. For example, they could search for available services for purchase ordering. The United Nations Centre for the Facilitation of the Administration, Commerce, and Transport (CEFACT) organization considered a federated information management requirement as a key requirement in selecting an open standards-based, integrated registry-repository.

Policy Management The enforcement of organizational policies that are described in a machine-processable syntax is a requirement of governance. This format is typical Extensible Markup Language (XML). These policy files must be published, managed, discovered, and governed the same as other service artifacts, in an SOA deployment. Policies need to be linked and composed across enterprise boundaries in a federated SOA deployment. Current policy management is performed within proprietary policy stores using product centric mechanisms. While there has been maturity in the standards associated with policy expression and governance over the past several years, they still remain immature. In any case, policies are managed and governed in the same manner as other service artifacts in an SOA registry repository. The Organization for the Advancement of Structured Information Standards (OASIS) Extensible Access Control Markup Language (XACML) standard is used by the ebXML Registry standard to express federated policy management of access control policies.

Identity Management Simply deploying an open standards-based, integrated registry repository is not sufficient for SOA deployments across an enterprise. A mechanism is required for securely managing the identities of consumers, and authenticating then when accessing service components and artifacts. The threat is exposing an enterprise’s services and artifacts to external consumers from other organizations within the enterprise or outside the enterprise in an insecure or unauthorized manner. This threat is addressed with federated identity management by instituting a circle of trust across all services with the federated


environment. This allows for single sign-on (SSO) such that a consumer is authenticated once and then uses the authenticated session to access services throughout the environment without having to be reauthenticated. Authorization credentials can also be mapped across systems in the federated environment.

Federated identity management mechanism should be supported by an SOA registry including single sign-on. The SOA registry repository should also integrate with identity management and access services using open standards such as Security Assertions Markup Language (SAML).

Discovery and Reuse The ability to construct complex service components from atomic, task-specific service components is one of the lures of the SOA paradigm. This is similar to constructing houses from legos. Service components may be reused virtually endless times in other services. A credit rating service is an example of an atomic service component that can be utilized by any number of more complex services such as mortgages, car loans, financial aid applications, or credit cards. All of the service-related artifacts available within an SOA deployment are managed from the registry repository. Developers should have access to this information during design-time, in order to discover and leverage existing service components in new the development of new service components. Discovery of service artifacts should be possible to be performed utilizing any organizational search criteria. A discover capability should be one of the foundational capabilities provided by a registry repository. This capability should be extensible and be able to accommodate a wide variety of discovery queries, from the most simple to complex domain-specific queries. A set of predefined discovery queries should be provided by the registry repository; however it should also allow organizations to construct custom ad-hoc queries by providing a query syntax that supports complex expressions using Boolean logic. Some examples of discovery queries would include the following:

o Find all WSDL documents that use a specified namespace

pattern o Find all Service Bindings or Services that have a certain


text pattern in their documentation o Find all Service Bindings that are SOAP bindings AND use

DOC Literal style AND do not use HTTP as transport o Find all WSDLs with Service implementations that use

specified implementation platform (for example, Java™ 2 Platform, Enterprise Edition or J2EE™, .Net, and so on)

o Find all WSDLs with Service implementations that use

specified platform resources (such as database, Java Message Service or JMS, Java API for XML Registries or JAXR, and so on)

If not managed and governed, the flexibility and expressive

power of ad hoc query syntax could lead to usability and performance issues. An example of this might be the query syntax may be to complex to be utilized by a typical user. It could also result in inefficient queries which could place excessive work loads on the registry repository. This could be rectified if the ability to store queries similar to stored procedures in a relational database.

A registry repository should provide organizations the ability to define parameterized, ad hoc queries as stored queries which in turn could be invoked by consumer applications with the parameters being supplied as invocation parameters. This capability allows organizations to define approved, domain-specific discovery queries within the registry repository, and these discovery queries then could be utilized by their user communities. The queries could be exposed to users as simple web applications hiding the complexity of the registry repository.

Enterprise Catalog By establishing an enterprise catalog of service artifacts improves their discoverability and artifact specific queries, like those in the discovery discussion. The indexing of database tables is similar to cataloging service artifacts. Information is automatically converted to metadata during publication, and the metadata is then used to facilitate efficient discovery of the published information. For example, an organization could define cataloging policies for WSDL artifacts such that when WSDLs are published, they are cataloged in a WSDL-specific manner to generate metadata that includes information on:


o The documents referenced by the WSDL (other WSDLs and

XML schemas) o The name spaces referenced by the WSDL and related

documents o The name and description of the bindings, interfaces, and

types used by the WSDL These types of metadata can be utilized in WSDL-specific types of discovery queries, as those mentioned in the discovery discussion.

Dependency Management Keeping track of the numerous dependencies among service components is a significant challenge in an SOA environment, especially when service reuse is in full force. An SOA registry repository which provides dependency management can assist with this issue by managing the complex relationships of service artifacts. Examples of these relationships are Contains, Depends On, Extends, Implements, Uses, and Supersedes. SOA deployments are not cookie-cutter and as such a fixed set of relationships may not be suitable for all deployments. A standard set of relationships should be provided by an SOA registry repository, but should also allow organizations to develop custom relationships based upon its specific requirements.

Service Versioning New requirements, among other reasons, influence the evolution of services over time. A service’s evolution involves modifications to its implementation and/or public interface. The ability to have many consumers of a single service, some could be unknown, increases the management issues of the service interface and its modification impacts. In many cases, these types of changes usually require deploying a new version of the service, while maintaining the older version until its consumers have had time to migrate to the new version. New versions of supporting service information artifacts typically accompany the publication of the versions of a service or service component. A versioning capability that automates version on control of any type of service artifact should be provided by a registry repository. This capability should allow providers and organizational policies to


determine when to treat modifications to an existing service artifact as updates to the artifact or a new version artifact.

Service Change Notifications As a service matures and evolves it is important that the consumers of that service be notified of the changes. For instance, it is important to notify consumers of a service when a new version of that service is available, so they can begin planning any migrations to the new version.

A notification capability should be supported by the registry repository such that interested parties can create subscriptions to events that may be of interest to them. Subscription should be flexible enough that interested parties can express precisely the types of events that are of interest to them. Change notification should invoke services that automate the governance workflow process.


Getting Started With A SOA Registry Repository

Registry Repository SDKs A registry repository is not simply a design-time service for publishing, managing, discovering, and governing service artifacts. While this is an important aspect, it also should support the utilization by deployed services as a source for operational and configuration data at runtime. A registry repository should provide a software development kit (SDK) to develop custom registry client applications and services. Many of the registry repository product vendors offer a SDK for the Java platform and support the Java for XML Registries (JAXR) standard, which is the standard Java application programming interface (API) for registries and repositories.

Product Selection When organizations begin evaluating which registry repository to deploy within their SOA ecosystem, the registry repository choices seem to be categorized as follows:

1. Proprietary registry-repository 2. UDDI registry without a repository 3. UDDI registry with a proprietary repository 4. ebXML registry-repository 5. Combination of UDDI registry and ebXML registry-repository

Since federated SOA deployments require a standards-based

registry repository, it suggests eliminating options 1 and 3 in the above list. The remaining choices, all standards-based, involve two standards, UDDI and ebXML Registry.

A UDDI registry offers a subset of capabilities offered by an ebXML Registry. See Table 2: Registry Standards Comparison Matrix in the Appendix for details. Specifically, it provides only a registry and no repository. Pointers to service artifacts, such as WSDL, get published in a UDDI registry. Both pointers and the actual service artifact get published to the ebXML Registry. Thus, an ebXML registry-repository can be used for governance of any type of service artifacts throughout their life cycles. An ebXML registry-repository is highly extensible. This extensibility has been a double-edged sword for the ebXML Registry


standard. On the positive side, it enables organizations to enforce custom governance policies for managing their service artifacts. On the negative side, it also makes the standard harder to understand and deploy because of its generic and extensible nature. This problem is being addressed by the emergence of vertical or use case-specific profiles of ebXML Registry that define precisely how to make use of its generic and extensible features in a standard, interoperable manner within a particular domain. For example, in the Web services area of greatest interest to those doing SOA deployments, a Web Services Profile is being defined by the OASIS ebXML Registry Technical Committee (TC).

A UDDI registry may be adequate for simpler SOA deployments. However, experience has shown that as SOA deployments increase in complexity and scale — which they inevitably do — an ebXML registry is a much better fit. It is sometimes the case that a SOA deployment starting with a UDDI-based implementation will later migrate to an ebXML Registry-based one, as needs grow.

It is not necessary to choose between the two standards. Newer

products are appearing that support both standards in a single engine. An example of this new class of registry-repository products is Sun’s Service Registry. When deploying such a registry, be aware that the functionality offered by each interface is quite different. As discussed, the ebXML Registry interface provides the fuller set of capabilities. This means that a dual-interface registry like the ebXML Registry interface is employed more pervasively, while the UDDI interface is used more specifically to interoperate with clients restricted to the UDDI protocol.

Leading SOA Registry Repository Products In this past year, 2006, there was a tremendous amount of consolidation in the SOA registry repository marketplace. BEA Systems acquired the Flashline registry product, webMethods acquired Infravio and its X-Registry Platform, and Systinet was acquired by Mercury Interactive, which was later acquired by Hewlett Packard (HP). After all the consolidation and product announcements by IBM and Sun Microsystems, there are four mainstream SOA registry repository products that support the two registry repository standards. The registry repository matrix, in Table 1, provides a list of the leading registry repository vendors, products, and the technology supported.


Table 1 Registry Repository Matrix

Conclusions In the past, enterprise integration was achieved via data

integration using a common enterprise database as the integration point. SOA represents the latest approach to enterprise integration via loosely coupled service integration based on a component and document-centric architecture. The next logical step is a federated SOA deployment that achieves enterprise integration within and across enterprise boundaries via service integration enhanced with secure, federated information management.

Today’s SOA deployments are becoming increasingly complex and require strong governance capabilities. A standards based registry-repository is emerging as an important SOA infrastructure component. First-generation Web services registries based solely on UDDI lack many important capabilities, including repository functions, which are necessary for governing and managing complex SOA deployments. An ebXML registry-repository provides a much richer set of capabilities to meet the advanced governance and federated information management requirements of complex SOA deployments. A new class of registry-repository will support both UDDI and ebXML Registry standards in a single solution.

Vendor Product(s) UDDI ebXML

BEA Aqua Logic Enterprise

3.0

webMethods X-Registry Platform 2.0,3.0 X

IBM WebSphere Registry

Sun 3.0 X


References [SOA] Service-Oriented Architecture http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf [UDDI] UDDI www.oasis-open.org/committees/tc_home.php?wg_abbrev=uddi-spec [EbRR] ebXML Registry Meta Links http://ebxmlrr.sourceforge.net/tmp/ebXMLRegistryLinks.html [BEA ALER] Sun’s Service Registry http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/aqualogic/service_registry/ [IBM WSRR] WebSphere Registry and Repository http://www-128.ibm.com/developerworks/websphere/library/techarticles/0609_mckee/0609_mckee.html [X-Reg] webMethods Infravio X-Registry Platform http://www.webmethods.com/Products/Fabric/SOA/Registry [SUNR] Sun’s Service Registry www.sun.com/products/soa/registry/ [S2] Systinet 2

http://www.systinet.com/products/systinet_2


Appendix: Standards Comparison The following table is a comparison of the most common standards, UDDI and ebXML Registry 3.0, utilized in registry-repositories. Table 2 Standards Comparison

Category/Feature

UDDI 3.0 ebXML Registry 3.0

Standards

Service Description WSDL 1.1 WSDL 1.1

Messaging SOAP 1.1 SOAP 1.1 with Attachments

Message Security OASIS Web Service Security

Access Control XACML 1.0

Identity Management

SAML 2.0

Architecture

Object-Oriented API No API offers type-oriented calls that keep growing as new types are added in each release of UDDI

Yes API offers a few task-oriented calls that may be used by any type of metadata object Consistent and uniform actions supported via few API calls across entire information model

Object-Oriented No Yes


Extensible API No Yes New API calls may be defined using standards-based API extensibility

Extensible Information Model

No Yes New information model types may be defined using standards-based


Category/Feature UDDI 3.0 ebXML Registry

Core Features

Registry Yes Yes

Repository No (added by tool vendors)

Yes Integrated registry-repository Any type of

Discovery

Predefined queries Yes Yes

User-defined queries No Yes

Ad hoc queries No Yes

SQL query syntax No Yes Ad hoc syntax supports

XML query syntax

Yes Fixed syntax

Yes Ad hoc syntax supports

Stored parameterized queries No Yes



Publish

Can publish metadata describing any type of information artifact

Yes Inadequate

Yes Rich set of ~25 standard metadata

Can publish any type of information artifact

No Actual

Yes Information

Relationships

Predefined relationship types Yes - Very Yes - Extensive

User-defined relationship types No Yes

Ability to relate any two objects in registry using any relationship type

No Yes

Packaging/Grouping Support

User-defined packages No Yes

Group any number of objects in same No Yes

Group an object in multiple packages No Yes

Security Features

Digital signature based authentication Yes - Yes - Required

Basic access control based on Yes – Yes

User-defined, fined-grained access No Yes

Federated identity management and No Yes

Audit trail Yes Yes


Protocol Bindings


HTTP binding (REST) No Yes Allows any metadata or

SOAP API binding

Yes Yes

Taxonomy Support

Predefined taxonomies Yes Yes

User-defined taxonomies No Yes

Taxonomy browsing and validation No Yes

Classification of artifacts Yes Yes

Classification of any metadata object No Yes

Life Cycle Management

Approval No Yes

Update Yes Yes

Automatic Version Control No Yes

Deprecation No Yes

Undeprecation No Yes

Deletion Yes Yes


Federation

Federated Queries No Yes

Object references between any object No Yes


Object replication from any registry Yes Yes

Information Management

Metadata Validation No Yes

Artifact Validation No Yes Unrestricted, may be used to

Event Subscription and Notification

Ability to select events using custom No Yes

Content-based event notification No Yes


Client SDK Support

JAXR API Yes Yes

Other Features

Web Services Support Yes Yes

Domain-Specific Profile Support No Yes Extensibility features allow standard

soaregistryrepositorydeployment 090316114404-phpapp02

Education