Deployment Diagram

The UML deployment diagram depicts a static view of the run-time configuration of processing nodes and the components that run on those nodes. The diagram shows the hardware for your system, the software that is installed on that hardware, and the middleware used to connect the disparate machines to one another. The following UML deployment diagram was created in Oracle BPA Suite using the Oracle Business Process Architect:

Use Case Diagram

UML use cases are fundamentally in text form. We see the stick figures and oval shaped entities and assume this to be the core of a use case. What many people don't understand is that a 'fully-dressed' use case includes a form at the backend that contains all the important information. This includes scope, stakeholders, primary actors, conditions, scenario, and other detailed information. Our use case, as illustrated in the following figure, is very simple:

The focus will be on the two-phase commit across Oracle and VSAM. The use case itself is a simple example of an invoice entry screen. In the real world, the invoice is generated by the order. But in our case, we will enter an invoice directly as we don't want to go through the entire order entry process. The use cases are data entries via a Web form. The data being entered is the invoice information to be stored in an Oracle Database and mainframe VSAM data store. The submit invoice use case will then commit one transaction across both databases.

Activity Diagram

The following activity diagram shows, in a top to bottom flow, the state of each database persistence object for the Oracle Database (Invoice), the VSAM database (Legacy Service), and the two-phase commit transaction object in the Oracle Application Server:

All user activity happens in the first part of the process. The remaining activities are related to coordinating the database persistence objects with the transaction manager, and insuring a successful two-phase commit.

Sequence Diagram

The sequence diagram will focus on the sequence of the two-phase commit as this is the core of your example.

This sequence diagram is representative of any two-phase commit scenario. The only difference is in the object lifelines (client, legacy service, invoice, and transaction manager). The client, invoice, and transaction manager are typical of any two-phase commit sequence diagram. The Legacy Service object lifeline is the only difference here. Typically, in the open systems environment, this would be a data access object that would commit a row to an Oracle or other relational database. In our Legacy SOA Integration example, it is a service that commits a record to the VSAM database.

Data Model Diagram

Let's also take a look at the data model for this application. Remember, we have a table on the open systems Oracle Database 10g instance and on the mainframe in VSAM. As this is a logical data model, it appears as though these two entities are tightly coupled and are on the same Oracle database. As we know, they are on separate databases, and even on separate machines, possibly hosted miles apart. The Oracle Invoice table (INVOICES) and mainframe invoice file (MF_INVOICE_DATA) are also loosely-coupled as there is no foreign key relationship for the physical implementation of this data model.

Some interesting things to note when you look at this simple data model:

We discussed these anomalies in the previous chapter, but think it really hits home when you see it in an example.