OPC Module Decomposition View

From SAD

Jump to: navigation, search


Primary Presentation


Visio file

Element Catalog


OpcApp stands for Order Processing Center Application. The business logic of the Adventure Builder is implemented in this module. It provides the following functionality:

  • Accepting purchase order requests from the ConsumerWebsite for processing by hosting the Purchase Order Web Service.
  • Provide a mechanism for the Consumer Website to query the current status of a purchase order by hosting the Order Tracking Web Service.
  • Communicate with external suppliers to process and maintain the status of a purchase order.
  • Upon completion of processing a purchase order, send an email to the customer of its success or failure.

This package contains all the order processing logic, including the workflow, internal queues used for communication between elements, and interaction with external web services.


This is the Customer Relationship Manager (CRM) module. The job of this module is to send out an email once an order has been completely and successfully processed. It is implemented as a message-driven bean. In the future this module can hold additional information about customers that could assist in providing the customers with a better experience. This could include things like a history of a particular customer's purchases, or sending out periodic emails to customers regarding new and fresh deals.


This package contains a data structure that holds information that the OPC uses to communicate with external suppliers. The data structure also holds the status of an order in the invoice (for more information on the lifecycle of an order see the state diagram in the OPC C&C view).


The mailer is a helper module and its primary responsibility is to send out emails using the Java Mail API. It is provided with a message and email addresses to send out emails. In the future this module will be moved to the utils package outside opc.


The financial module is responsible for verifying and charging the customer's credit card. For this purpose it calls the external web services provided by the bank. The verification of the credit card happens in a synchronous manner and the OPC application waits for the external web service to reply before moving on. If the response from the banking service is not positive, the OPC application does not further process the order.


This package contains utility classes that are used by the OPC application, such as glue code for JMS API. In the future, this module will be moved to the utils package outside opc.


This module reads an internal queue of order requests. When an order arrives, it decomposes the order into requests to the different providers involved. These requests are sent in XML format to internal queues.


This module provides a web service that is used by ConsumerWebsite to communicate the details of a purchase order to the OPC for processing. The web service interface is OpcPurchaseOrderService:


This module provides a web service that is used by ConsumerWebsite to query the status of an order by providing the order id. The web service interface is OpcOrderTrackingService:


The orderreceiver helps in persisting the purchase order in a relational database.


The workflowmanager coordinates the processing of a purchase order and tracks the status of the purchase order throughout its lifecycle. The workflow manager mediates the interaction among the other internal modules of the OPC in such a manner that they (other internal modules) are oblivious to each others existence.
For more details see the workflowmanager Module Uses View


This package contains the classes that correspond in memory to the data entities required to create a purchase order. For each data entity, there is a POJO and an entity bean. The POJOs are used throughout the application as data transfer objects. The data entities in this package are:

  • Activity
  • CreditCard
  • Lodging
  • PurchaseOrder
  • Transportation
  • ContactInfo
  • Address

See the data model for a description of what each entity represents.


The webservicebroker is responsible for the interaction via web services with the airline, lodging and activity providers. This module is divided into two sub-modules described below.


Contains classes that can invoke the external web services provided by airline, lodging and activity supplier partners. It also contains a message-driven bean that can receive messages sent through an internal queue. These messages contain exactly the requests to be sent to the external web services.


This module provides a web service that is visible to airline, lodging and activity supplier partners. This web service is implemented in a session bean and is used by the external partners to submit the result of processing requests made to them. Calls to this web service are forwarded to an internal queue.


The processmanager is used by the otwebservice module to retrieve from the database adventure package purchase orders and their updated status. It is also used by the workflowmanager to retrieve the orders placed with the external providers and persist their status. This module contains the submodules (ejb and manager.ejb) described below.


Contains a session bean that offers operations to retrieve orders and update the status of a given order (both the adventure purchase order and the orders placed with the partner suppliers).


Contains an entity bean to persist a purchase order. The entity bean uses container-managed persistence (CMP).

Context Diagram


Variability Guide



The choice of EJBs in the implementation, including session beans, message-driven beans and entity beans is based on:

  • Developers are familiar with EJB development and component-based development.
  • These highly modular EJB components promote reuse.

Related Views

Personal tools