1. Statement of the Technical Field
This invention relates to a service registry and repository system and method. In particular this invention relates to a service registry and repository system and method for accessing objects in an object repository.
2. Description of the Related Art
A service registry and repository registers and stores service descriptions as part of a service-oriented architecture (SOA) promising business agility and resilience through reuse, loose coupling, flexibility, interoperability, integration and governance. These promises are addressed by separating service descriptions from their implementations, and using the service descriptions across the life cycle of the service. Standards-based service metadata artefacts, such as Web Service Definition Language (WSDL), XML schema, policy or Service Component Architecture (SCA) documents, capture the technical details of what a service can do, how it can be invoked, or what it expects other services to do. Semantic annotations and other metadata can be associated with these artefacts to offer insight to potential users of the service on how and when it can be used, and what purposes it serves.
Service descriptions are used by analysts, architects, and developers during a Development Phase of the SOA life cycle to locate services to reuse and to evaluate the impact of changes to service configurations. Service descriptions are used by deployers in a Change and Release Phase and by administrators in a Runtime Integration Phase. It is used in the Operation Phase of the life cycle to support policy enforcement required by Service Level Agreements (SLAs) and to present a more comprehensive view of the managed service environment. Service descriptions are used by various technologies for different purposes and needs to be persisted in a reliable and accessible format. Service descriptions are variously described as metadata, objects, documents, entities and artefacts.
A service registry and repository is an application that persists service descriptions as a data objects in a relational database system. Typically a user uses a graphical tool to design classes that represent the service descriptions that need to be persisted. Java objects, that represent the classes, are compiled into binary files. Database schema are generated that can represent the objects and are installed into a relational database (IBM® DB2®, Oracle etc). The objects are registered with service register and stored within the repository. The objects are persisted and retrieved directly from the object database. IBM and DB2 are registered trademarks or trademarks of International Business Machines Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation.
One type of service registry and repository stores the descriptions as objects within the repository and queries the repository using an object query language. An example of this type of service registry is IBM WebSphere® Registry and Repository (WSRR) uses an IBM object query language called XMeta Query Language (XMQL) for internal communication with the repository. WebSphere is a registered trademark or trademark of International Business Machines Corporation in the United States and/or other countries.
XMeta Query Language (XMQL) is a declarative object query language designed for the efficient retrieval of objects stored in a repository such as WSRR. XMQL allows the use of the dot operator for accessing predefined properties on a given modelled object type. XMQL also allows a dereferencing operator for traversing relationships between any two given object types. The XMQL query expression is defined in the context of a given package registered with WSRR. XMQL has a “SELECT-FROM-WHERE” type of structure and returns a set of objects.
The SELECT-FROM-WHERE clause is the basic structure of an XMQL query. It allows the user to specify which class(es) should be searched to retrieve information, and which parts of the information to be included in the results set. It also allows the user to specify conditions to filter out of the results set the instances that do not meet the conditions.
The SELECT clause defines the structure of the query result, which can be either a collection of objects, or a collection of rows with the selected attribute values. The entries in the select part of a query constitute the so-called projection list of the query, in that they define what is projected out of the repository and into the result set entries (result objects or result rows of atomic values, depending on the number and type of the entries in the projection list). When retrieved, the type of the query result is a List of instances of objects, or a List of arrays (result rows) of instances of objects (result row columns).
The FROM clause introduces the primary class extent against which the query runs. A class extent is the set of all instances of a given class (including instances of its sub-classes). A variable needs to be declared to iterate over the instances of the class being queried, the so-called primary iteration variable. That variable can be used in the other parts of the query and denotes an instance of the class extent being iterated upon. The FROM clause also allows the introduction of other variables to iterate over instances that can be reached through navigation via multiplicity-many references from previously introduced iteration variables. These extra variables are called secondary iteration variables. As explained above, unqualified class names in a query expression are resolved relative to that package, the so called query context package.
The WHERE clause introduces a predicate that filters the instances of the class being queried. This is an optional sub-clause.
The basic SELECT-FROM-WHERE structure can be extended with other optional clauses.
USPTO Backgrounds
USPTO Backgrounds