The vision for a new specification is to create a unified environment allowing to:
... publish, search for and retrieve a wide variety of technical documents which describe a customer's SOA environment. This includes such things as schemas, service descriptions, business process design models, policy documents and so on. ... [they] facilitate various activities across the life cycle of a SOA artifact, such as design, assembly, quality assurance, deployment, runtime operation and monitoring of SOA based applications and business processes.
The authors of the specification see the Repository as a foundation for managing services’ lifecycle and foresee its usage for design time:
- A designer uses an Integrated Development Environment (IDE) product to design and publish a service description (WSDL) and schemas for a service offering.
- The repository notifies a service developer when a WSDL used by her offering changes.
- A designer developing a business process offering searches for available services to use in defining his business process environment.
- A designer performs impact analysis based on changes in dependent components.
It can also be used for run time service invocation:
- A developer tests a design using a repository which contains the correct set of components.
- A design tester is notified when a component of interest is changed in the repository.
- An Enterprise Service Bus (ESB) performs a dynamic query of the repository to determine routing based upon meta-data associated with its SOA environment service components.
- A network manager edits and stores updated policies in the repository.
- Automated tooling performs policy enforcement based on policies of record stored in the repository.
And finally for service monitoring:
- An operations manager updates service meta-data in the repository with current information on performance and availability.
- A business manager makes decisions on what services to use based on quality of service information in the repository.
The specification defines a common data model for SOA repositories which facilitates the use of common tooling and data sharing. It provides a rich representation of the data model that supports semantic query. It is comprised of 10 documents including: The Foundation Document, The Atom Binding Document, Atom Binding Model Schema, Core Model Schema, Policy Model, Service Implementation Model Schema. SOA Model Schema, SOAP WSDL Model Schema, WSDL Model Schema and XSD Model Schema.
The specification is based on the following design principles:
- Use of existing standards where possible (e.g., XML, XML Schema, OWL, XPath2, APP (Atom Publishing Protocol), ASF (Atom Syndication Format), etc.).
- Vendor neutrality.
- Does not include governance models, but may be used by them.
- Driven by use cases.
- Data model extensibility for new data types, and support for system and user defined metadata.
- Inclusion of an XML Schema based serialization for its data model.
- Use of XPath 2 to describe its query grammar.
- Use of OWL Lite to describe its classification system grammar.
- Separation of the data model from the bindings which describe the interaction APIs clients use to interact with the repository.
The specification defines the following artifacts that can be stored in repository:
- Document Artifact - any physical documents stored in the repository. The predefined document types (treated specially) include, for example, XML Schema or WSDL documents..
- Service Implementation Model Artifact - artifacts representing service implementation layer, for example, Service Operation or Service Endpoint.
- Derived Artifact - artifacts dynamically created as a result of publishing documents supported by derivation model, for example, WSDL PortType or Policy Expression.
- SOA Model Artifact - artifacts based on The Open Group’s SOA Ontology providing a conceptual representation of a SOA environment
- User Defined Artifact Model - extensibility element supporting creation of interoperable user defined artifacts
Each artifact can contain three major types of metadata:
- Relationships - associations between artifacts.
- Properties - named attributes of an artifact instance (built-in or user-defined).
- Classifications - artifacts taxonomy
The new repository specification is a huge leap forward from UDDI. While it introduces a lot of new techniques and approaches for repository usage, it seems to repeat some of the same shortcomings that UDDI had:
- Despite the fact that service registry and repository are two different systems with different audiences and different architectural requirements, they are bundled together in a single specification
- The specification is geared towards a technical audience leaving aside business analysts who typically have the lion’s share of SOA solutions design activities.