Sun Certified Enterprise Architect EE5 Assignment (Part II)

2.1.1. Stereotypes

2.1.2. Colors

The following diagram shows the main components in the SuD, and their interactions.

• Component diagram

• Presentation Layer class diagram
• Business Logic Layer class diagram
• Data Access Layer class diagram
• Services Layer class diagram

2.4.1. Use case diagrams

• Post Request for Parts. The Post Request use case allows an authorized Dreamcar representative to place a request for a required quantity of parts.
• Review Open Bids. The Review Open Bids use case allows an authorized Dreamcar representative to review open bids placed in response to an open bid request.
• Submit Bid for Open Parts Requests. The Submit Bid for Open Parts Request use case allows an authorized supplier to bid on open bid requests of interest that exist in the system.
• Issue PO to Winning Bidder. The Issue PO to Winning Bidder use case allows a Dreamcar representative to select a winning bid for a specific bid request and issue a PO to the supplier associated with that bid.
• Schedule Work in Factory. The Schedule Work in Factory use case allows an authorized Dreamcar representative to schedule work in the car assembly plant, which relies on the successful bid requests placed with suppliers in the auction system.

2.4.2. Other main sequence diagrams

2.4.3. Common diagrams

The major risk identified for this application is security vulnerabilities. If the system is compromised, several companies can be affected (dreamcar and suppliers). These are some security related risks:

1. Man in the middle attacks
2. Modification of the PO by a third party
3. Compromised node
4. Phising
5. DNS spoofing
6. Brute force attacks

Mitigation strategies:

• Using mutual SSL for external communication. Encrypts and authenticates both parties. Dreamcar certificate must be granted by a certification authority but for suppliers is no needed: supplier certificates can be created by dreamcar in case of not having one and can be obtained remotely on a simple SSL connection (only dreamcar uses a certificate). That avoids 1,4, and 5
• PO is digitally signed by dreamcar once it is created, before it is stored and sent
• Physical security: Production servers must be located in a restricted access area. This way physical access is limited. Avoids threat number 3
• Production servers administration must be rescticted. No new software can be installed without a formal request. Avoids threat number 3
• Network security: Firewalls, DMZ. Sensitive server are protected by more firewalls in order to avoid or cascade node compromising. Avoids threat number 3
• Threat 6 is mitigated by using strong certificates (at least 128 bit encryption)

The ability to ensure the integrity and consistency of the application and all its transactions. Reliability flaws in the system can be very hard to detect and correct, sometimes resulting in the need of a complete application redesign. These are some reliability related risks:

1. Concurrent modifications of the same data
2. Concurrent request creation for the same parts
3. Ensuring PO delivery
4. Ensuring reliability supposing the Inventory Service non XA transactional

Mitigation strategies:

• Concurrency is handled by the implicit use of CMT transactions (created by the EJB container on BLL EJBs first method invocation in the stack). Since heterogeneous resources participate in the business, all of them must be global transaction (XA) capable. Database isolation level must be set as repeatable read since non-repeatable reads are not permitted (to ensure certain use cases reliability), but phantom reads are not a problem.
  On the other hand, for non-idempotent operations (for example any BLL method that changes request status), model state verification is performed inside the transaction in a double-checked locking or optimistic locking fashion, in order to ensure thread safety.
• Points 2 and 4 are explained in the 4.1. Inventory System section.
• PO delivery is guaranteed by the use of JMS. Since requirements do no state anything about this, messaging has been introduced as optional, to promote supplier interoperability (if the supplier infraestructure is not JMS ready, the PO is sent encrypted by email).

The system must be able to accommodate to an arbitrary (growing) load, fulfilling performance and availability QoS specifications. This ability is mandatory, since:

1. Provided specifications do not estimate expected loads
2. The system is known to have a growing load in the future (additional markets will be supported)

Mitigation strategies:

• Initial production topology has all nodes clustered. Adding new nodes in the future to accommodate to a higher load is straightforward.
• Application is designed to be distributable. HTTP session is serializable and lightweight.
• Ensuring reliability is not dependent on the load of the system
• Pre-production performance test
• Monitoring: All nodes must be monitored in order to identify bottlenecks and overloaded resources

Locking is needed to mantain reliability (not several requests for the same parts). Inventory system web service is supossed to offer this functionality and is called in request creation and closing to lock and unlock the parts. If the existing service would not provide this functionality it can be performed remotely (in the wrapper implementation InventorySystem) as long as the webservice API would let identify the parts somehow. The inventory system is not supposed to be XA transactional, despite of being desired. Sequence diagrams using this system have been designed to use the service after all transactional calls have been made. This way in case of an error using this service, a global rollback could be made.

The provided BDM (business domain model) has several uncertainness. The solution adopted has been to keep that BDM (see DAL class diagram) as generic and extensible as possible, never adding restrictions to the original, despite of the current SuD not fully exploiting its features.
These are the problematic relationships:

• PurchaseOrder-Bid: Provided BDM sets this relationship as 1:1, but this contradicts use case definition, where a PO is created for the winning bid after the auctioning has finished. That is why the multiplicity is set as 0..1-1, in other words, all PO belongs to a single (winning) bid, but not all the bids has a PO associated
• PurchaseOrder-Request: Provided BDM sets this relationship as *:1. Use cases do not reflect how a request can have multiple POs associated (since at most it has a single winning bid and therefore a single PO). The possible interpretation for that is future functionality, for example allowing multiple winning bids (a supplier could bid for a partial quantity of the requested parts, or maybe requests can be made for different parts at once), or creating several POs to the same winning bidder.
  In any case that is out of the scope of the current SuD. The original multiplicity has been kept (to promote extensibility) despite of not being currently used.
• Request-Part: Provided BDM is no clear about this relationship. Can a request be made for different parts at the same time? (Use cases suggest no). Again the BDM is modelled to support this feature (composite requests) (see PartInfo association class)

Review Open Bids use case definition states:

Since request-bids multiplicity is 1:* the previous statements must contain several typographical errors. The use case definition has been interpreted as follows:

Issue PO to winning bidder use case definition states:

Is not clear what is the procedure that choose the most valid bid, and what happens if the representative do not accept that chosen bid.

The solution adopted is giving the user an ordered view of the bids based on the ascending price, (the chosen then will be implicitly the first in the list), and allowing the dreamcar representative to select any of the bids, and mark it as the winner.

SuD must use JEE standard security architecture (see JSR 244, J2EE.3.3) with the following properties:
Defined roles:

• dreamcar
• supplier

Authentication procedure: HTTPS Client Authentication
Authorization rules:

• Request protocol must be HTTPS
• Any resource (web or ejb) non stereotyped as one of the previous role names, is protected and can only be accessed if logged principal has any of these roles.
• Resources (or methods) stereotyped as one of the previous role names, can only be accessed by principals with that role

Deployment mapping: Defined roles are mapped at deploy time to LDAP groups of the same name, that must be maintained externally to the SuD.

Error handling: Service to worker pattern is mandatory in order to have all model charged before the view rendering begins. If an error occurs the user must be redirected to the last view successfully rendered and show an non technical error message.
Logging: The following logging is mandatory, and will be implemented by LoggingFilter in PL and LoggingInterceptor in BLL:

• Inter-tier invocations: remote user ip, user principal, date, resource accessed
• All throwables

All resources dependent of the environment (usually configuration files) must be deployed externally to the ear.
The first time the application is deployed in an environment, the deployer must create the shared library Environment dependent properties (see deployed artifacts diagram). This library contains a single properties file for the environment dependent properties. The deployer must edit the file (according to the bean provider instructions), in order to give the properties the right value for that environment.
Future deployments of the application will not require any special action, just install the new ear, and associate the shared library.
The purpose of this procedure is to keep the ear unchanged between environment promotions, making the application more maintainable.

All jsp text readable by the client must be externalized to properties files according to PropertyResourceBundle specification. That makes the application more extensible to support new languages and easier to maintain.

Environments:

• Development: Local developer machine. Single application server instance integrated with IDE. No webserver, no load balancing, no caching. External systems LDAP, and RDMBS are targeted to a distributed single development instance, administrable by the developer. Messaging is tested with the JMS provider integrated in the application server.
• Integration: Same topology as development. Target of continuous integration. External systems LDAP, and RDMBS are targeted to a distributed single integration instance non administrable by the developer (data must be consistent). Automatized builds (sinchronization with SCM repositories), deployments, and unitary testing. Record and notification of results. Also functional testing.
• Preproduction: Mirror of production environment. Same topology, same data. Performance testing and tunning. Verification of non-functional requirements. Final acceptance
• Production: End user environment. Same configuration that preproduction.

When a new supplier is going to be enrolled the following actions must be manually performed:

• LDAP user creation
• Add the new supplier user to the "Suppliers" LDAP group
• Creation of the digital certificate for the supplier in case of not having one. Storing the certificate in LDAP
• Adding supplier data to LDAP entry, (email,...)
• In case of supporting messaging, creating the queue for the supplier and registering needed access information in LDAP
• Adding a new exception to the DMZ firewall, to enable B2B communication from the supplier specified IP addresses (IP filtering enabled)
• Sending the certificate and endpoint information to the supplier over a secure channel (physically, by phone, by postal mail,..., in addition to a simple SSL connection to Dreamcar servers (this functionality is out of the SuD))