Contents
Primary Presentation
Element Catalog
OpcApp
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.
opc
This package contains all the order processing logic, including the workflow, internal queues used for communication between elements, and interaction with external web services.
crm.ejb
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.
invoice
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).
mailer
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.
financial
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 asynchronous 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.
utils
This package contains utility classes that are used by the OPC application, such as glue code for JMSAPI. In the future, this module will be moved to the utils package outside opc.
orderfiller
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.
powebservice
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:
otwebservice
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:
orderreceiver
The orderreceiver helps in persisting the purchase order in a relational database.
workflowmanager
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
purchaseorder
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.
webservicebroker
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.
requestor
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.
provider
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.
processmanager
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.
ejb
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).
manager.ejb
Contains an entity bean to persist a purchase order. The entity bean uses container-managed persistence (CMP).
Context Diagram
Variability Guide
Add or remove bank
The system allows adding or removing partner banks by keeping a registry of the external services (element 'service registry' in the Top Level SOAView). A new bank has to implement the CreditCardService interface. At run time new banks are identified by OPC by querying the registry for external services that implement that interface.
Add or remove airline, lodging or activity provider
The system allows adding an partner provider by keeping a registry of the external services (element 'service registry' in the Top Level SOA View).
- A new airline has to implement the AirlinePOService interface. At run time new airlines are identified by OPC by querying the registry for external services that implement that interface.
- A new lodging provider has to implement the LodgingPOService interface. At run time new lodging providers are identified by OPC by querying the registry for external services that implement that interface.
- A new activity provider has to implement the ActivityPOService interface. At run time new activity providers are identified by OPC by querying the registry for external services that implement that interface.
The webservicebroker module provides an abstraction layer within the OPC that contacts all external partner providers. Other modules of OPC are oblivious to changes in the set of available suppliers. Other modules only know the identity of the new supplier.
Rationale
Related Views
- Parent view: Top Level Module Uses View
- Refinement of workflowmanager: Workflowmanager Module Uses View
- OPC Module Decomposition View
- Interface documentation: