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:
EBOs evolve over multiple generations as you add, remove, or change the semantics or characteristics of content. The primary reasons for changes in EBOs are:
Adoption of new technologies and language enhancements
Each EBO in the library has its own release life cycle, so each object has its own version number. EBO version numbers are independent of participating application release numbers. New releases of participating applications do not necessarily result in new EBO versions.
The version number consists of the major and minor version numbers.
The following changes, which may break EBO backward compatibility, require a new major version number:
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
The following changes require a new minor version number:
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
The type of change, not the size, determines whether a new version is major or minor. A small change warrants a major version change if it breaks backward compatibility. Similarly, enormous changes may result in a minor version change if backward compatibility is not broken.
The Enterprise Object Library contains all major versions of every EBO, but only the latest minor versions within the major versions. Hence, the schema file in the folder for the major version always contains the latest minor version.
Consumer applications that depend on an earlier major release might need to be modified to work with the new release. For example, 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 unless modified.
Because Oracle AIA uses a service-oriented architecture for request/response interaction, backward and forward compatibility surface at the same time. An upgraded provider application must be backward compatible to understand requests from older requesters. Similarly, requesters must be forward compatible to recognize the responses of the provider application. Compatibility in both directions, at least among minor versions, ensures independence of providers and requesters.
The architecture does not mandate (in most situations) concurrent upgrade of the requester and provider, so additional XML message transformations between older and newer major versions are required. 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 schema declaration version attribute in the XML schema and a required custom attribute in the XML instance document identify the schema version. An XML instance specifies its namespace and minor version. 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. For example:
<GetAccount ... schemaVersion="1.1"> ... </GetAccount>
Each EBO has its own namespace. This minimizes duplication of names and allows each business object to 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 a schemas undergoes major architectural changes. Introducing backward-incompatible changes alone does not warrant namespace changes.
Here is a sample namespace:
The innermost layer of the Enterprise Objects Library is a set of namespaces that contain constructs commonly used throughout the library. Some namespaces include core component types, business datatypes, and core datatypes. In earlier releases, only one namespace held all common components and reference components.
Second-layer namespaces import the innermost layer namespaces. Each second-layer namespace has declarations that are specific to a business process or functional area. For example, the PurchaseOrder namespace contains all documents used for placing a purchase order.
In addition, customer-specific namespaces house customer-specific extensions.
When the innermost layer namespaces are versioned, the next layer namespaces are also versioned if they use the new common constructs. However, the reverse is not true: versioning the second-layer namespaces does not require versioning the innermost layer namespaces. The innermost layer does not import the functional layer-specific namespaces.
Enterprise Business Services (EBSs) evolve over multiple generations as you change the interface definition or the implementation. When a change affects the contract the consumer relies upon, it leads to the creation of a new service version.
Oracle AIA facilitates the co-location of multiple EBS implementations with identifiable versions. This allows consumers to use the service version they need. A new version does not force consumers to switch to the latest version immediately. Figure 7-1 is an illustrates versioning.
This section discusses naming conventions only with respect to versioning.
Similar to EBOs, each EBS in the library has its own release life cycle and each service its own version number. The first service version does not have a number. The default value is 1.0. Subsequent versions have numbers affixed to the name of the service. EBS version numbers are independent of participating application release numbers. New releases of participating applications do not necessarily result in new EBS versions.
Participating applications in both requester and provider roles also evolve. New application versions can introduce enhancements to underlying connecting technologies or web services standards. Changing the connectivity/transport protocol, web service definitions, or payloads of Application Business Connector Services (ABCSs) specific to participating applications does not affect integrations.