Soaregistryrepositorydeployment 090316114404-phpapp02

SOA Registry Repository
Deployment

January 2007

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

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.


Vendor Product(s) UDDI ebXML
BEA Aqua Logic 3.0
Enterprise

webMethods X-Registry Platform 2.0,3.0 X

IBM WebSphere Registry

Sun 3.0 X

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.


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/pro
ducts/aqualogic/service_registry/

[IBM WSRR] WebSphere Registry and Repository
http://www-
128.ibm.com/developerworks/websphere/library/techarticles/0609_mc
kee/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

UDDI 3.0 ebXML Registry 3.0
Category/Feature
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 SAML 2.0
Management

Architecture
Object-Oriented API No Yes
API offers API offers a few task-
type-oriented oriented calls that may be
calls that used by any type of
keep growing metadata object
as new types Consistent and uniform
are actions
added in each supported via few API calls
release of across
UDDI entire information model

Object-Oriented No Yes


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

Extensible No Yes
Information Model 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 Yes
by tool Integrated
vendors) 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 Yes
Fixed Ad hoc syntax
syntax supports

Stored parameterized queries No Yes


Publish
Can publish metadata describing any Yes Yes
type of information artifact Rich set of ~25
Inadequate standard metadata

Can publish any type of information No Yes
artifact Actual Information

Relationships
Predefined relationship types Yes - Very Yes - Extensive
User-defined relationship types No Yes
Ability to relate any two objects in No Yes
registry using any relationship type

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

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (18)

Similaire à Soaregistryrepositorydeployment 090316114404-phpapp02

Similaire à Soaregistryrepositorydeployment 090316114404-phpapp02 (20)

Dernier

Dernier (20)

Soaregistryrepositorydeployment 090316114404-phpapp02