Managing services with XML schemas

In an SOA environment there are many important artifacts that use XML schemas to define the service implementation. Some of these are described here.

Business objects

Businesses often adopt standardized representations of information that is key to their business. Some of these are standardized in individual companies to support particular market sectors.

Business messages

Message driven architectures rely primarily on XML schema definitions to define the formats that are used to exchange information.

Business Events

As with messages, event structures are often defined in XML schemas to assist in reporting and systems management.

Service operation signatures

Even when services are described using WSDL, the parameters of the service operations are often expressed using XML schemas expressed in XSD documents. This allows different services to share a common information model.

WSRR provides the capability to register XSD documents and to identify the important XML Schema constructs in those documents that will affect the interoperability or common dependencies between services being managed.

For each XSD document WSRR identifies:

Global complex types

These identify the actual types used in interface and message definitions. WSRR identifies only the name and namespace of the complex type from the XSD, it does not maintain finer grain structure.

Global simple types

These identify the actual types used in interface and message definitions. WSRR identifies only the name and namespace of the type from the XSD.

Global elements

These identify elements that have global visibility and can thus be used in interface and message definitions. WSRR identifies only the name and namespace of the element from the XSD.

Global attributes

These identify attributes that have global visibility and can thus be used in interface and message definitions. WSRR identifies only the name and namespace of the attribute from the XSD.

Each of these constructs results in an object that is stored in the registry and related to the schema document that declared it. These "derived" or "logical" objects cannot be created or deleted by the user, they are managed entirely by the registering or de-registering of the XSD document that defines them.

There is a special extension of global complex types that is used to support templates. WSRR interprets certain local attributes and these can be used when creating concepts from templates as follows.

The only information available for these local attributes is the name.

The objective for all these "derived" objects is to allow the named construct to be annotated with metadata to indicate how it must be used throughout the SOA enterprise. This allows a particular construct declared in a document to be managed differently from other constructs declared in the same document. This has the implication that if any document is deleted or even updated (in terms of content), any derived objects will be deleted and the attached metadata will be lost.

In addition to this shredding of XSD documents, WSRR automatically detects and maintains dependencies between documents. At the time of loading or creation, of the dependent document, the documents that it depends on must be:

• Already available in WSRR. Special handling of this is required because xsd:include, xsd:import, xsd:redefine statements do not include enough information to resolve between different versions of the same schema (same name, location and namespace).
• Provided with the dependent document as part of the load. In this case the document that is depended on will also be loaded and shredded.
• Available from the uri given in the import or include location hint. In this case the document that is depended on will also be loaded and shredded. The location field of the referenced document is populated with its URL.

For each of these dependencies encountered and resolved, WSRR will ensure that a built-in relationship is established between the dependent document and the depended on document.