Informal Notation |
|---|
UML |
|---|
OPCRuntimeRefinementView_PP3.png
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.
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.
This message-driven bean is activated when there is a message in the WorkFlowMgrQueue. It processes two kinds of messages:
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.
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.
This entity bean persists the details of an activity reservation (activity id, location, price, date/time, head count).
This entity bean persists the details of a flight reservation (e.g., origin, destination, carrier, flight id, departure time, arrival time, travel class, fare)
This entity bean persists the details of a hotel reservation (hotel id, start date, number of nights, rate per night, number of rooms).
This entity bean persists the credit card information (credit card number, type, expiration date, etc.) of a user.
This session bean provides operations to retrieve and update the overall status of a purchase order and the status of the individual supplier orders.
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.
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.
This message driven bean makes requests to external suppliers. It requires the following interfaces:
This component is the OPC's window to external suppliers for activities, lodging and transportation. It provides the following interfaces:
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.
TODO
TODO
TODO
TODO
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.
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.
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.
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.
This component represents an external application hosted by an airline partner company. The application provides a SOAP web service to book air travel.
This component represents an external application hosted by a lodging partner company. The application provides a SOAP web service to book hotel rooms.
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.
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.
See OPC Module Uses View - Context Diagram
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.
The system allows adding an partner provider by keeping a registry of the external services (element 'service registry' in the Top Level SOA View).
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.
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:
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.
Parent view: Top Level SOA View