Contents
Primary Presentation
Informal Notation |
|---|
UML |
|---|
OPCRuntimeRefinementView_PP3.png
Element Catalog
PoEndPointBean
This stateless session bean implements the SOAP web services interface called OpcPurchaseOrderService. When a purchase order request arrives, it simply validates the order and, if OK, sends the order to the WorkFlowMgrQueue using JMS.
OtEndPointBean
This stateless session bean implements the SOAP web services interface called OpcOrderTrackingService. Requests for information about an order are handled by interacting with ProcessManagerBean. Order information is retrieved using the PurchaseOrderBean entity bean.
WorkFlowManagerBean
This message-driven bean is activated when there is a message in the WorkFlowMgrQueue. It processes two kinds of messages:
- purchase order message. When processing such messages, this component interacts with ProcessManagerBean to insert the order in the database in the Pending state. Then it interacts synchronously with the Bank external service provider to validate and charge the customer's credit card. If the credit card is OK, it sends a message to the OrderFillerQueue JMS queue to be processed by OrderFillerBean. Finally, it sends another message to CRMQueue, which will be processed by CrmBean (send email to the customer informing the order is being processed).
- invoice message. This is a message that came from one of the external suppliers in response for a booking order. When an invoice message is received, this component basically interacts with ProcessManagerBean to update the status of the corresponding order. If the message confirms the last invoice that is part of a travel package order, WorkFlowManagerBean sends a JMS message to CrmBean to notify the customer via email.
WorkFlowManagerBean also sets a timer with the EJB container so that it is activated periodically to check the status of all pending orders.
WofkFlowManagerBean is one of the two components in the Adventure Builder system that act as service user of external services (the other is BrokerRequestorBean).
The life cycle of a purchase order can be summarized by the following UML state machine diagram.
PurchaseOrderBean
This entity bean persists the details of a purchase order (user who placed the order, date of the order, total price, head count, departure and arrival dates, departure city, etc.). The status of the order as it's processed is not stored within this entity bean; it's ManagerBean that keeps the order status.
ActivityBean
This entity bean persists the details of an activity reservation (activity id, location, price, date/time, head count).
TransportationBean
This entity bean persists the details of a flight reservation (e.g., origin, destination, carrier, flight id, departure time, arrival time, travel class, fare)
LodgingBean
This entity bean persists the details of a hotel reservation (hotel id, start date, number of nights, rate per night, number of rooms).
CreditCardBean
This entity bean persists the credit card information (credit card number, type, expiration date, etc.) of a user.
ProcessManagerBean
This session bean provides operations to retrieve and update the overall status of a purchase order and the status of the individual supplier orders.
ManagerBean
This entity bean is used by WorkFlowManagerBean to persist the status of the purchase order containing order id, order overall status, and the status of each separate supplier order.
OrderFillerBean
This component is used to process the purchaseorder. It reads the purchaseorder and splits it into smaller purchaseorders, one each for activities, transportation and lodging. It then sends each of these smaller purchaseorders to the webservicebroker that in turn sends them to external suppliers.
- It provides an interface called sendPO that is used by the workflowmanager to send purchaseorders.
- It requires an interface sendRequest that it uses to send purchaseorders to each individual supplier.
BrokerRequestorBean
This message driven bean makes requests to external suppliers. It requires the following interfaces:
- AirlinePOService - This is used to send purchaseorders to external airline suppliers.
- ActivityPOService - This is used to send purchaseorders to external activity suppliers.
- LodgingPOService - This is used to send purchaseorders to external lodging suppliers.
BrokerServiceBean
This component is the OPC's window to external suppliers for activities, lodging and transportation. It provides the following interfaces:
- WebServiceBroker - This is a web service that is used by the external suppliers to submit invoices back to the OPC.
- getInvoice - This interface can provide the invoices that are sent by external suppliers.
- sendRequest - This interface can be used to contact external suppliers and place orders with them.
CRMBean
This component is used for customer relationship management. For this application it is only used to communicate with the user. It reads messages from a queue, creates the corresponding email messages according to templates and I18N requirements, and sent them to users.
WorkFlowMgrQueue
TODO
OrderFillerQueue
TODO
WebServiceBrokerQueue
TODO
CRMQueue
TODO
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.
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
See OPC Module Uses View - 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 SOA View). 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.
EJB configuration
For each EJb, a pool of bean instances is provided by the application server. There are three parameters that can be configured separately for each EJB via deployment descriptor:
- minimum (and initial) number of bean instances in the pool
- maximum number of bean instances in the pool
- timeout for an idle instance to be passivated or deleted
Rationale
TODO: Describe here the rationale for any significant design decisions whose scope is limited to this view. Also describe any significant rejected alternatives. This section may also indicate assumptions, constraints, results of analysis and experiments, and architecturally significant requirements that affect the view.
Related Views
Parent view: Top Level SOA View
- Interface documentation: