7 Understanding Versioning

This chapter describes how Oracle Application Integration Architecture (AIA) handles versions for Enterprise Business Objects (EBOs), services, and participating applications. Major and minor versions, backward compatibility, and naming conventions are discussed.

This chapter includes the following sections:

• Section 7.1, "Schema Versioning"

• Section 7.2, "Service Versioning"

• Section 7.3, "Participating Applications Versioning"

7.1 Schema Versioning

Oracle AIA allows for the natural evolution of EBOs. Each of the EBOs continues to evolve over multiple generations as you add content, remove existing content, or change the semantics or characteristics of existing content. The primary reasons for changes in EBOs are:

• Product enhancements

• Bug fixes

• Adoption of new technologies and language enhancements

7.1.1 Major and Minor Versions

Each of the EBOs in the library has its own release life cycle, so each object has a version number that is used to differentiate versions. EBO version numbers are not aligned with participating applications release numbers, and new releases of participating applications do not necessarily result in introduction of new versions of the objects.

The version number is composed of two parts-major and minor version number.

A new major version number is introduced when the object undergoes the following types of changes, which could break the backward compatibility of the object:

• Changing the meaning or semantics of existing components

• Adding required components

• Removing required components

• Restricting the content model of a component, such as changing a choice to a sequence

• Changing the type of an element or attribute

A new minor version number is introduced when the object undergoes the following types of changes:

• Adding optional components, such as elements, attributes, or both

• Adding optional content, such as extending an enumeration

• Adding, changing, or removing default initializations, changing the order of elements in a choice, and so forth

Backward compatibility means that newer clients must be able to interpret data from older services. Forward compatibility means that older clients must be able to interpret data from newer services.

The major and minor terminology used in this section refers to characteristics of the change, not to any quantitative measure. One small change could be sufficient to qualify for a major version change if that change breaks backward compatibility. Similarly, enormous changes may result in a minor version change if backward compatibility is not broken.

The Enterprise Object Library is always cumulative. Within a single major version, the schema module for that EBO might have undergone several iterations of changes that warranted incrementing of minor version number. For every iteration of backward-compatible changes, the minor version number is incremented. Hence, the schema file that is present in the folder related to the major version always contains the latest version. The Enterprise Object Library contains the latest version of the schema module for every one of the major versions introduced for each of the EBOs.

A release that updates the major version number of an EBO contains changes that might sometimes make it incompatible with the prior major release. This means that consumer applications that depend on an earlier major release might need to be modified to work with the new release. On the other hand, a release that updates the minor version number of an EBO is a backward-compatible change. This means that an application written against version 1.0 works when targeted against versions 1.1 and 1.2, but may fail if moved to version 2.0 of the EBO.

Because Oracle AIA leverages a service-oriented architecture that involves the common adoption of the request/response interaction style by the web services, backward and forward compatibility surface at the same time. When a provider application is upgraded, the provider application needs to be backward compatible to understand requests from older requesters. At the same time, requesters need to be forward compatible to recognize the responses of the provider application. Compatibility in both directions, at least among minor versions, ensures the utmost degree of independence of providers and requesters.

Because the architecture does not mandate (in most situations) that the requester and provider of the message be upgraded at the same time, additional transformations must be provided to transform XML messages written against previous major versions into a format to work against the newer versions and vice versa. In some cases, these transformations may not be technically feasible or may not make functional sense. In these situations, the applications receiving the messages cause an irrecoverable error.

The version of the schema is identified with the help of the schema declaration version attribute that is available in the XML schema and with the help of a required custom attribute on the XML instance document. An XML instance specifies exactly which namespace and minimal version it is structured to validate against. The XML instance does not use the schemaLocation attribute. The XML instance documents provide the schemaVersion attribute on the top-level Enterprise Business Message (EBM) element to indicate the version of the schema used to generate the document. For example:

<GetAccount ... schemaVersion="1.1"> ... </GetAccount>

7.1.2 Namespaces

Each of the EBOs has its own namespace. This is advantageous because it minimizes the duplication of names and it provides the flexibility for letting each of the business objects have its own release cycle. The namespace uses the following format:

http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/[object name]/v[version number]

The namespace name is the same across multiple minor and major versions and is changed only when the schemas undergo major architectural changes. Introducing backward-incompatible changes alone do not warrant namespace changes.

Here is a sample namespace:

http://xmlns.oracle.com/EnterpriseObjects/Core/EBOParty/v1

The innermost layer of the objects library is a set of namespaces that contain those constructs that are commonly used throughout the Enterprise Objects Library. Some of these namespaces include core component types, business datatypes, and core datatypes. In earlier releases, only one namespace holds all of the common components and reference components.

These namespaces are imported by the next layer of namespaces, which denote functional areas. Each second-layer namespace has a set of declarations that are specific to a business process or functional area. For example, the documents used for placing a purchase order all reside in the PurchaseOrder namespace.

In addition, customer-specific namespaces exist that are designed to house customer-specific extensions.

When the innermost layer namespaces are versioned, the next layer namespaces are also versioned if they have to leverage the new common constructs. The functional layer-specific namespaces can be versioned independently because the functional-layer namespaces have no necessary dependency on them. The innermost layer does not import the functional layer-specific namespaces. This scheme implies that the entire snapshot as a whole has no actual version-it is merely a group of interdependent schema modules that are versioned independently.

7.2 Service Versioning

Oracle AIA allows for the natural evolution of Enterprise Business Services (EBSs). A change, either in the interface definition or the implementation that could affect the contract that the consumer relies upon leads to the creation of a new version of the service.

With this concept, Oracle AIA facilitates the co-location of multiple implementations of a single EBS with each version being totally identifiable. Multiple versions of the same service allows for consumers to use a particular version of the service that caters to their needs. Introduction of a new version of the service does not force the consumers of a specific version of the service to switch to the latest version immediately. Figure 7-1 is an illustration of versioning.

Figure 7-1 Illustration of Versioning

7.2.1 Naming Conventions

This section discusses the naming conventions only with respect to versioning.

Similar to EBOs, each of the EBSs in the library has its own release life cycle and each of the services has a version number. The first version of the service does not have a number affixed to it. The default value is 1.0. Subsequent versions of the service have numbers affixed to the name of the service to differentiate different versions of the object. This construct allows for multiple versions of the service to be co-located in the same ecosystem and enables you to recognize the multiple versions of the same service. The EBS version numbers are not in alignment with those of participating applications release numbers. New major releases of participating applications do not necessarily result in the introduction of new versions of the services.

The namespace name is the same across multiple minor and major versions and is changed only when the service undergoes major architectural changes. Introducing backward-incompatible changes alone does not warrant namespace changes.

7.3 Participating Applications Versioning

The applications that participate in the integration also continue to evolve regardless of whether they are playing a requester or provider role. The new versions of the applications can introduce enhancements to their native functionality, to the underlying connecting technologies, or to the web services standards. The Application Business Connector Services that are specific to participating applications will not have any impact if the new version of the participating application does not introduce any changes pertaining to the connectivity/transport protocol, web service definitions, or payloads.