View Source

Primary Presentation

Informal Notation

Software Architecture Documentation (SAD) > Top Level SOA View > TopLevelC&CView_PP.png

Visio file

UML

Software Architecture Documentation (SAD) > Top Level SOA View > TopLevelC&CView_PP2.png

soapatterns.org notation

Software Architecture Documentation (SAD) > Top Level SOA View > TopLevelC&CView_PP3.png

Element Catalog

Web browser

This component represents the user interface of the application running on a web browser. Consumer Website is a Web 2.0 application implemented using GWT. Therefore, in addition to HTML, the web browser runs JavaScript code that uses Ajax to communicate with the server. Using the web browser, a customer of Adventure Builder opens the web site, browses through the existing catalog of adventure packages, places orders, and tracks the status of existing orders.

Consumer Website

The ConsumerWebsite is a multi-tier application implemented using Java EE technology. It's the client facing part of the Adventure Builder system. It is implemented using GWT code, a number of JSP and html pages, and standard components of the WAF framework. Its primary responsibility is to process the http requests coming from customers browsing the catalog or placing/tracking orders. Requests to place or track orders are relayed to the OPC application via SOAP web services.

See the Consumer Website Multi-tier View for a description of the internal components of Consumer Website.

OPC

OPC is the order processing center application. It's a Java EE application that communicates with external components using SOAP web services.Internally, it consists of loosely coupled EJBs that communicate with each other using primarily asynchronous messaging. The internal architecture follows the message channel design pattern [Hohpe 2003]. See the OPC C&C View for a description of the internal components of OPC. The core functionality of the Adventure Builder is implemented in this module. Its major functions are:

Accept purchase order requests from the ConsumerWebsite for processing.
Fill a purchase order by communicating with external suppliers.
Provide a mechanism for the Consumer Website to query the current status of a purchase order.
Upon completion of processing a purchase order, send an email to the customer reporting its success or failure.

OPC provides the following interfaces, which are exposed as SOAP web services:

OpcPurchaseOrderService - used to create a purchase order.
OpcOrderTrackingService - used to track the status of a purchase order.
WebServiceBroker - used by external suppliers to submit invoices back to OPC.

OPC requires the following interfaces, which are provided by external partners as SOAP web services:

CreditCardService - used to validate the credit card transaction with a bank.
AirlinePOService - used to send purchase orders to external airline suppliers.
LodgingPOService - used to send purchase orders to external lodging suppliers.
ActivityPOService - used to send purchase orders to external activity suppliers.

The UML activity diagram below shows the processing of a purchase order. It uses a split-and-join pattern when filling an order. For simplicity, the diagram does not show interaction with a database. Following is the equivalent diagram using the BPMN notation.

Software Architecture Documentation (SAD) > Top Level SOA View > TopLevelC&CView_POActivityDiagram.png

Adventure Catalog DB

This is a relational database that stores the adventure builder catalog containing various adventure packages. It also stores information about users for user authentication and authorization. The database server is MySQL Cluster 7.0 configured to use the InnoDB engine.

Adventure OPC DB

This relational database stores purchase orders, invoices coming from the external suppliers and related information. The database server is MySQL configured to use the InnoDB engine.

service registry

Data repository that works as a basic registry of the external services used by OPC. More specifically, it has name, location and metadata about all the SOAP web services offered by the banks, airline, lodging, and activity external partners. TBD: use a relational database or XML based files.

Bank

This component represents an external application hosted by a bank or credit card administrator. The application provides a SOAP web service to verify customers' credit card information.

Airline Provider

This component represents an external application hosted by an airline partner company. The application provides a SOAP web service to book air travel.

Lodging Provider

This component represents an external application hosted by a lodging partner company. The application provides a SOAP web service to book hotel rooms.

Activity Provider

This component represents an external application hosted by an activity provider partner company. The application provides a SOAP web service to book adventure activities, such as hot air ballooning, surf classes, and mountain climbing expeditions.

User's email client

This is the email inbox of the end user (vacationer) who placed an adventure travel purchase request. OPC sends email notifications to the user via SMTP to inform of the status of the orders.

Context Diagram

N/A

Variability Guide

Configurability of data access

To configure data storage such that it supports different database vendors, we don't want to use any SQL statements in our queries that use vendor specific syntax and can potentially hinder migrating databases. We also use the DAO pattern to abstract away clients from accessing data directly.

Email communication

All email communication parameters (hostname, ports and protocol) should be configurable outside the code via a configuration file. The parameters are read at load time.

Rationale

We have chosen a Service Oriented Architecture for the Adventure Builder because we desire a high degree of interoperability between internal and external entities in the system. This gives us a great deal of flexibility in terms of implementation platforms.
- For example, the Airline Provider component may be implemented using Java, PHP, .NET, IBM CICS or any other technology that supports SOAP web services.
- Internally, it's possible, for example, to reimplement and deploy Consumer Website using .NET. OPC doesn't have to change because the SOAP Web services communication allows such level of interoperability.

We have also a clear separation between the user interface and the business logic. The Consumer Website (user interface) and OPC (business logic) are two separate applications that together implement the functionality described in the System Overview.

We chose to implement the service registry using a simple data repository because of ease of implementation. Creating a UDDI registry was an alternative that was rejected because it would bring increased complexity with no apparent benefit, given that the repository is only queried internally (using a standard format is more relevant when the registry will be accessed by external players).

Related Views

Refinement of Consumer Website: Consumer Website Multi-tier View
Refinement of OPC: OPC C&C View
Interface documentation:
- OpcPurchaseOrderService Interface Documentation
- OpcOrderTrackingService Interface Documentation

Contents