Page tree


Contents

Primary Presentation

Element Catalog

Context Diagram

Variability Guide

Rationale

Related Views

Primary Presentation


Informal Notation

Visio file

UML

Element Catalog

end user machines

This node is used to represent a user who can access the Adventure Builder application using a PC. It is most likely that he is using a web browser to place or track a purchaseorder.

bank server machine

This node is external to the system. It represents the server hosted by a bank that provides services to verify a user's account.

airline provider server machine

This node is external to the system. It represents the server hosted by an airlines supplier that provides services to place a transportation purchase order.

lodging provider server machine

This node is external to the system. It represents the server hosted by a lodging supplier that provides services to place a lodging purchase order.

activity provider server machine

This node is external to the system. It represents the server hosted by an activities supplier that provides services to place an activities purchase order.

firewall

TODO

Adventure Builder local network

TODO

svr-web1

TODO

svr-web2

TODO

web1a, web1b, web2a, web2b

TODO

svr-opc

TODO

OpcGF

TODO

svr-db1

TODO.

svr-db1, svr-db2

TODO.

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.

svr-dbopc

TODO.

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.

admin user machine

TODO

srv-mailer

TODO

TODO: REMOVE...

website.ear

This is an enterprise archive artifact that is deployed on an application server. It contains the consumer website application.

opc.ear

This is an enterprise archive artifact that is deployed on an application server. It contains the opc application.

Context Diagram

TODO: Add here a context diagram that graphically shows the scope of the part of the system represented by this view. A context diagram typically shows the part of the system as a single, distinguished box in the middle surrounded by other boxes that are the external entities. Lines show the relations between the part of the system and the external entities.

Variability Guide

TODO: Describe here any variability mechanisms used in the portion of the system shown in this view, along with how and when (build time, deploy time, run time) those mechanisms may be exercised. Examples of variability include: optional components (e.g., plug-ins, add-ons); configurable replication of components and connectors; selection among different implementations of an element or different vendors; parameterized values set in build flags, .properties files, .ini files, or other config files.

Rationale

Scalability

All the components that are SOAP web service providers in the Adventure Builder System are implemented using stateless session beans. This type of EJB component can be replicated across machines in a cluster and each machine can also make available a pool of such EJBs. This feature allows scaling of the number of requests it can handle. Horizontal scalability is achievable by adding more machines to the cluster. Vertical scalability is also an option by increasing the capacity of any machine (and then increasing the number of EJB instances in each EJB pool). See EJB configuration discussion in OPC C&C View#Variability Guide.

Nevertheless, the transactions performed by these stateless session beans ultimately require access to the database. The database cannot be easily replicated and may become a performance bottleneck if the number of calls increases beyond expectation.

Related Views

N/A

  • No labels