Introduction

The logical architecture of a system presents the significant components that make up the system, as well as how these components interact with each other to deliver the required functionality. The system’s significant components are described in this document, which includes the component’s responsibilities and composition.

Intended Audience for this Document

The intended audience for this document is enumerated in the following list:

· Oracle Retail’s Prospective Customers – through the RGBU Sales and Professional Services organizations, the logical model is used as a tool to allow customers to understand the componentization of our systems, and the some technology underpinnings without being too bogged down into the source code itself.

· All RGBU Groups – the entire organization will now have a level-set architecture from which everyone can understand the significant components of our systems

Logical Model

The logical model diagram shown in Figure 1 depicts the logical components for the RGBU’s integration systems. Each section of the integration systems (RIB, RSL and IGS) are described in the subsequent sections of this document.

Figure 1: RIB/RSL/IGS Logical Architecuture Diagram

The diagram outlines the relationships between the logical components, and shows the packaging of the components.

RIB

The publishing application API is responsible for creating the business object from business content. The RIB publishing adapter accepts the business objects, either java beans or PL/SQL Oracle Objects, and converts it to a RIB message and publishes it to the JMS Server and makes it available to any JMS subscribers.

For PL/SQL Applications, database tables associated with the publishing application typically stage message information. One or more RIB publishing adapters poll the application via a stored procedure call.

For Java EE Applications, the application calls a RIB Enterprise Java Bean (EJB) with the payload information to be published.

The message resides on a Java Message Service (JMS) immediately after publication. The JMS topic provides stable storage for the message in case a system crash occurs before all message subscribers receive and process it.

A fundamental RIB system requirement is that a message must be delivered to and processed successfully exactly once by each subscriber. Furthermore, all work performed by the subscriber and the RIB must be atomically committed or rolled back, even if the JMS server is on a remote host. The standard way to perform this is by using an XA compliant interface and two-phase commit protocol.

After initial publication, a message may undergo a series of transformation, filtering, or routing operations. A RIB component that implements these operations is known as a Transformation and Address Filter/Router (TAFR) component. TAFR is the acronym for Transform, Address, Filter, and Route. A TAFR is completely internal to the RIB and does not reside in either the publishing or subscribing application. The RIB performs these intermediate transformation and routing operations on some messages before making them available to the subscribing application.

A single TAFR may only transform a given message, only filter the message, only route it, or combine any of the three operations.

n Transform - A message may be transformed from one message type into another, for example, 'WH' (warehouse) from RMS to 'Location' for RWMS.

n Filter - A message may be filtered. Filtering can occur based on message type or based on content.

n Route - A TAFR may route a message. For example, whenever a stock order message is published for a warehouse with an instance of RWMS, the TAFR routes it to the particular RWMS instance from where the stock will be fulfilled and not to warehouses that do not stock the order's items.

TAFR operations are specific to the set of subscribers to a specific message family. Multiple TAFRs may process a single message for a specific subscriber and different specific TAFRs may be present for different subscribers. Different sets of TAFRs are necessary for different message families. If all subscribers to a message can process all messages within a message family without any TAFR operations, then no TAFR components are needed.

Message processing continues until a subscribing adapter successfully processes the message or determines that no subscriber needs this message.

When a subscriber gets a message to be processed, the adapter checks to see if the RIB Hospital contains any messages associated with the same entity as the current message. If so, then the adapter places the current message in the hospital as well. This is to ensure messages are always processed in the proper sequence. If proper sequencing is not maintained, then the subscribing application's data can get corrupt.

If an error occurs during message processing, the subscribing adapter notes this internally and rolls back all database work associated with the message. When the message is re-processed (since it has yet to be processed successfully), the adapter now recognizes this message is problematic and checks it into the hospital.

After a message is checked into the RIB Hospital, a retry adapter extracts the message from the hospital and re-publishes it to the JMS topic for reprocessing. The message remains in the hospital during all re-tries until the subscribing adapter successfully processes it.

Component Descriptions

Adapters

A RIB adapter is a component that coordinates business event (message) generation and processing with the respective Oracle Retail application interface. Each adapter in the RIB is created to handle a specific functional interface. RIB adapters are developed using Enterprise Java Beans (EJB) components architecture, subscribing adapters use Message Driven Beans (MDBs) and publishing adapters use Stateless Session Beans (SLSBs).

The RIB provides four types of adapters that Oracle Retail applications can exploit to integrate with one another. These adapter types are: publisher, subscriber, TAFR, and hospital retry. They have been built using different technologies based on their particular needs.

Subscriber and TAFR adapters use Message Driven Bean (MDB) technology to register with JMS topics and receive messages for further processing.

Publisher and hospital retry adapters make use of the Java SE (Standard Edition) timer facility to schedule repetitive events that trigger calls to Stateless Session Beans (SLSBs) to query application tables for messages to publish to the JMS server.

The RIB Hospital

The RIB Hospital is a collective term for a set of Java Classes and database tables whose purpose is to provide a mechanism to handle system and business related errors while meeting the fundamental RIB requirements:

n Guaranteed once-and-only-once successful delivery.

n Preservation of publication sequence (even in case of failures).

When a message is processed, the adapter checks to see if the RIB Hospital contains any messages associated with the same businessObjectId as the current message. If so, then the adapter places the current message in the hospital as well. This is to ensure messages are always processed in the proper sequence. If proper sequencing is not maintained, then the subscribing application's data can get corrupted.

If an error occurs during message processing, the subscribing adapter notes this internally and rolls back all work associated with the message. When the message is re-processed (since it has yet to be processed successfully), the adapter now recognizes this message is problematic and checks it into the hospital.

RSL

RSL handles the interface between a client application and a server application. The client application typically runs on a different host than the service. However, RSL allows for the service to be called internally in the same program or Java Virtual Machine as the client without the need for code modification.

All services are defined using the same basic paradigm -- the input and output to the service, if any, is a single set of values. Errors are communicated via Java Exceptions that are thrown by the services. The normal behavior when a service throws an exception is for all database work performed in the service call being rolled back.

RSL works within the Java EE framework. All services are contained within an interface offered by a Stateless Session Bean. To a client application, each service appears to be merely a method call.

Some Oracle Retail applications, such as RMS, are implemented in the PL/SQL language, which runs inside of the Oracle Database. RSL uses a generalized conversion process that converts the input java object to a native Oracle Object and any output Oracle Objects to the returned java object from the service. There is a one-to-one correspondence of all fields contained in the Java parameters as in the Oracle Objects used.

Simple Service Call

In the client application, some event triggers a service call. The first step is for the client to find the location of the service. This is done by using the “ServiceAccessor” which connects to the application server’s Java Naming and Directory Interface (JNDI) instance.

Once the “Remote Home” of the service is located, the client then creates a “Remote” instance or handle to the service which is returned to the client to perform calls to the service.

At this point, the Java EE application server infrastructure takes control and performs a remote method invocation on the CommandExecutionService Stateless Session Bean. This EJB is responsible for looking up the implementation of the service interface, invoking the client requested service method call and returning the result.

The execution and control of database commits and rollbacks is dependent on three factors: the configuration of the Stateless Session Bean, the success or failure of the service call, and whether the transaction is started by the client or the application server.

If an error is encountered during the service execution, normal behavior is to roll back all database work. This is performed when an exception is thrown by the service for container managed transactions.

Component Descriptions

The Client Application Layer

This layer is developed by client application developers. The code for this is dependent on the business processes of the Client.

The Service Access Layer

This layer is generated by the Oracle Retail Integration Team. Its purpose is to provide a typed set of interfaces and implementations for accessing services. The Service Access Layer is the only set of interfaces that the Client Application Layer developer needs to be aware of. Although different implementations of the Service Access Layer might be used by the Client application, depending on the local or remote location of the required services, the Client Application Layer developer doesn’t need to be aware of this.

The Service Provider Layer

This layer is implemented by the developers belonging to the service provider or knowledgeable in the service application domain. Each service must implement its corresponding interface as declared in the Service Access Layer.

For RMS, RWMS or other Oracle Forms applications, each service will be offered via a PL/SQL Stored Procedure and use Oracle Object technology for input and output parameters.

For Java EE offered services, input and output parameters will be generated via Value Objects; Java beans that implement a defined interface and consist of “getter”, “setter” and “adder” methods.