Java程序辅导

COMP9321 Web Application Engineering
Semester 2, 2016
Dr. Amin Beheshti
Service Oriented Computing Group, CSE, UNSW Australia
Week 8
1COMP9321, 16s2, Week 8
http://webapps.cse.unsw.edu.au/webcms2/course/index.php?cid=2445
Assignment 2
2COMP9321, 16s2, Week 8
Deadline Extended:
The due date for this assignment 2 is (end of Mid Semester Break):
Sunday, 2 October 2016, 23:59:59.
Demo will be held during the lab times in week 10.
UNSW, CSE, Calendar:
https://student.unsw.edu.au/calendar
J2EE Design Patterns
3COMP9321, 16s2, Week 8
Last Week, Design Pattern Part I:
Model View Controller: 
• MVC is the J2EE BluePrints recommended architectural design pattern for 
interactive applications.
Front Controller (Command): 
• For providing a central dispatch point to handle all incoming requests.
J2EE Design Patterns
4COMP9321, 16s2, Week 8
This Week, Design Pattern Part II:
Service Locator: 
• Typically used in business layer for locating resources (such as database 
connection)
Data Access Object: 
• A typical pattern for data access layer (linking the data storage layer with 
the application)
Business Delegate: 
• A pattern to reduce coupling between presentation-tier clients and 
business services. 
First..
What is Cohesion & Coupling?
5COMP9321, 16s2, Week 8
Cohesion
6COMP9321, 16s2, Week 8
Cohesion is defined as the ‘degree of interaction within a module’.
Seven levels of cohesion
7. Functional  
6. Informational
5. Communicational
4. Procedural
3. Temporal
2. Logical
1. Coincidental Worst
Best
Cohesion
7COMP9321, 16s2, Week 8
Cohesion is defined as the ‘degree of interaction within a module’.
Seven levels of cohesion
7. Functional  
6. Informational
5. Communicational
4. Procedural
3. Temporal
2. Logical
1. Coincidental Worst
Best
Coincidental: module performs multiple, completely unrelated actions
(degrades maintainability & modules are not reusable)
Cohesion
8COMP9321, 16s2, Week 8
Cohesion is defined as the ‘degree of interaction within a module’.
Seven levels of cohesion
7. Functional  
6. Informational
5. Communicational
4. Procedural
3. Temporal
2. Logical
1. Coincidental Worst
Best
Logical: module performs series of related actions, one of which is selected by calling module.
(interface difficult to understand & module difficult to reuse)
Cohesion
9COMP9321, 16s2, Week 8
Cohesion is defined as the ‘degree of interaction within a module’.
Seven levels of cohesion
7. Functional  
6. Informational
5. Communicational
4. Procedural
3. Temporal
2. Logical
1. Coincidental Worst
Best
Temporal : module performs series of actions related in time.
(code spread out -> not maintainable or reusable)
Cohesion
10COMP9321, 16s2, Week 8
Cohesion is defined as the ‘degree of interaction within a module’.
Seven levels of cohesion
7. Functional  
6. Informational
5. Communicational
4. Procedural
3. Temporal
2. Logical
1. Coincidental Worst
Best
Procedural : module performs series of actions related by procedure to be followed by product.
(not reusable)
Cohesion
11COMP9321, 16s2, Week 8
Cohesion is defined as the ‘degree of interaction within a module’.
Seven levels of cohesion
7. Functional  
6. Informational
5. Communicational
4. Procedural
3. Temporal
2. Logical
1. Coincidental Worst
Best
Informational : module performs a number of actions, each with its own entry point, with 
independent code for each action, all performed on the same data structure
(This is an ADT!)
Cohesion
12COMP9321, 16s2, Week 8
Cohesion is defined as the ‘degree of interaction within a module’.
Seven levels of cohesion
7. Functional
6. Informational
5. Communicational
4. Procedural
3. Temporal
2. Logical
1. Coincidental Worst
Best
Functional : module performs exactly one action
(more reusable, corrective maintenance easier, easier to extend product )
Coupling
13COMP9321, 16s2, Week 8
Couplingis defined as the ‘degree of interaction between two modules’.
Seven levels of cohesion
5. Data
4. Stamp
3. Control
2. Common
1. Content Worst
Best
Coupling
14COMP9321, 16s2, Week 8
Cohesion is defined as the ‘degree of interaction between two modules’.
Seven levels of cohesion
5. Data
4. Stamp
3. Control
2. Common
1. Content Worst
Best
Content : one module directly references contents of the other module.
(almost any change to M1 requires changes to M2 )
Coupling
15COMP9321, 16s2, Week 8
Cohesion is defined as the ‘degree of interaction between two modules’.
Seven levels of cohesion
5. Data
4. Stamp
3. Control
2. Common
1. Content Worst
Best
Common : two modules have write access to the same global data.
(difficult to reuse + module exposed to more data than necessary  )
Coupling
16COMP9321, 16s2, Week 8
Cohesion is defined as the ‘degree of interaction between two modules’.
Seven levels of cohesion
5. Data
4. Stamp
3. Control
2. Common
1. Content Worst
Best
Control : one module passes an element of control to the other.
(modules are not independent)
Coupling
17COMP9321, 16s2, Week 8
Cohesion is defined as the ‘degree of interaction between two modules’.
Seven levels of cohesion
5. Data
4. Stamp
3. Control
2. Common
1. Content Worst
Best
Stamp : data structure is passed as parameter, but called module operates on only some of 
individual components.
(affects understanding + unlikely to be reusable + passes more data than necessary)
Coupling
18COMP9321, 16s2, Week 8
Cohesion is defined as the ‘degree of interaction between two modules’.
Seven levels of cohesion
5. Data
4. Stamp
3. Control
2. Common
1. Content Worst
Best
Data : every argument is either a simple argument or a data structure in which all elements are 
used by the called module. Example:
•display time of arrival (flight number) 
•get job with highest priority (job queue)
(maintenance is easier)

Service Locator Pattern
19COMP9321, 16s2, Week 8
Service Locator Pattern
20COMP9321, 16s2, Week 8
Context
Service lookup and creation involves complex interfaces and network operations.
Problem
• The service locator pattern is a design pattern used in software development to
encapsulate the processes involved in obtaining a service with a strong
abstraction layer.
• When J2EE clients interact with the server side components (EJB: Enterprise
Java Beans) or DataSources, clients must locate the service component, which
referred to as a lookup operation in JNDI: Java Naming and Directory Interface.
• Locating a JNDI-managed service object is common to all clients that need to
access that service object.
• It is easy to see that many types of clients repeatedly use the JNDI service, and
the JNDI code appears multiple times across these clients. This results in an
unnecessary duplication of code in the clients that need to look up services.
Service Locator Pattern
21COMP9321, 16s2, Week 8
Solution
• Using a central registry known as the "service locator", which on request returns
the information necessary to perform a certain task.
• Service Locator object will abstract all JNDI usage to hide the complexities of
initial context creation and lookup operations
• Multiple clients can reuse the Service Locator object to reduce code complexity,
provide a single point of control
msdn.microsoft.com
Service Locator Pattern
22COMP9321, 16s2, Week 8
To build a service locator pattern, we need:
Service Locator
InitialContext
ServiceFactory
BusinessService
Service Locator Pattern
23COMP9321, 16s2, Week 8
To build a service locator pattern, we need:
Service Locator:
The Service Locator abstracts the API lookup services, vendor dependencies, lookup
complexities, and business object creation, and provides a simple interface to clients.
InitialContext
ServiceFactory
BusinessService
Service Locator Pattern
24COMP9321, 16s2, Week 8
To build a service locator pattern, we need:
Service Locator:
The Service Locator abstracts the API lookup services, vendor dependencies, lookup
complexities, and business object creation, and provides a simple interface to clients.
InitialContext:
The InitialContext object is the start point in the lookup and creation process.
ServiceFactory:
BusinessService:
Service Locator Pattern
25COMP9321, 16s2, Week 8
To build a service locator pattern, we need:
Service Locator:
The Service Locator abstracts the API lookup services, vendor dependencies, lookup
complexities, and business object creation, and provides a simple interface to clients.
InitialContext:
The InitialContext object is the start point in the lookup and creation process.
ServiceFactory:
The ServiceFactory object represents an object that provides life cycle management for
the BusinessService objects. eg., The ServiceFactory object for enterprise beans is an
EJBHome object.
BusinessService:
Service Locator Pattern
26COMP9321, 16s2, Week 8
To build a service locator pattern, we need:
Service Locator:
The Service Locator abstracts the API lookup services, vendor dependencies, lookup
complexities, and business object creation, and provides a simple interface to clients.
InitialContext:
The InitialContext object is the start point in the lookup and creation process.
ServiceFactory: The ServiceFactory object represents an object that provides life cycle
management for the BusinessService objects. eg., The ServiceFactory object for
enterprise beans is an EJBHome object.
BusinessService: is a role that is fulled by the service that the client is seeking to
access. The BusinessService object :
• is created or looked up or removed by the ServiceFactory.
• in the context of an EJB application is an enterprise bean.
• the context of JDBC is a DataSource.
Service Locator Pattern
27COMP9321, 16s2, Week 8
Identifying Service Locator Pattern in the phonebook lab
28COMP9321, 16s2, Week 8
Identifying Service Locator Pattern in the phonebook lab
29COMP9321, 16s2, Week 8
Identifying Service Locator Pattern in the phonebook lab
30COMP9321, 16s2, Week 8
Dependency Injection
31COMP9321, 16s2, Week 8
Dependency
32COMP9321, 16s2, Week 8
SAX Books Parser Example
33COMP9321, 16s2, Week 8
What is "dependency injection" ?
34COMP9321, 16s2, Week 8
• In software engineering, dependency injection is a software design
pattern that implements inversion of control for
resolving dependencies.
• Dependency injection means giving an object its instance variables.
• Dependency injection provides the ability to pass by reference (or
"inject"), service objects into a client (a class or a delegate) at
deployment time.
• This is a top-down approach, in contrast to a bottom-up one wherein
the clients discover or create service objects on their own.
Benefits of "dependency injection" …
35COMP9321, 16s2, Week 8
Data Access Object
36COMP9321, 16s2, Week 8
Data Access Object
37COMP9321, 16s2, Week 8
Context
• Access to data varies depending on the source of the data. Access to persistent
storage, such as to a database, varies greatly depending on the type of storage
(relational databases, object-oriented databases, flat files, and so forth) and the
vendor implementation.
Problem
• For many applications, persistent storage is implemented with different
mechanisms, and there are marked differences in the APIs used to access these
different persistent storage mechanisms. Other applications may need to access data
that resides on separate systems.
• An example is where data is provided by services through external systems such as
business-to-business (B2B) integration systems, credit card bureau service, and so
forth.
http://www.oracle.com/technetwork/java/dataaccessobject-138824.html
Data Access Object
38COMP9321, 16s2, Week 8
Solution
• Use a Data Access Object (DAO) to abstract and encapsulate all access to the data 
source. The DAO manages the connection with the data source to obtain and store data.
http://www.oracle.com/technetwork/java/dataaccessobject-138824.html
Data Access Object: Sequence Diagram
39COMP9321, 16s2, Week 8
http://www.oracle.com/technetwork/java/dataaccessobject-138824.html
Business Delegate
40COMP9321, 16s2, Week 8
Business Delegate
41COMP9321, 16s2, Week 8
Context
• A multi-tiered, distributed system requires remote method invocations to send and
receive data across tiers. Clients are exposed to the complexity of dealing with
distributed components.
Problem
• Presentation-tier components interact directly with business services. This direct
interaction exposes the underlying implementation details of the business service
application program interface (API) to the presentation tier.
• As a result, the presentation-tier components are vulnerable to changes in the
implementation of the business services: When the implementation of the business
services change, the exposed implementation code in the presentation tier must
change too.
http://www.oracle.com/technetwork/java/businessdelegate-137562.html
Business Delegate
42COMP9321, 16s2, Week 8
Solution
• Use a Business Delegate to reduce coupling between presentation-tier clients and
business services.
• The Business Delegate hides the underlying implementation details of the business
service, such as lookup and access details of the EJB architecture.
• Another benefit is that the delegate may cache results and references to remote
business services. Caching can significantly improve performance, because it limits
unnecessary and potentially costly round trips over the network.
http://www.oracle.com/technetwork/java/businessdelegate-137562.html
Business Delegate
43COMP9321, 16s2, Week 8
http://www.oracle.com/technetwork/java/businessdelegate-137562.html
• Client: requests the BusinessDelegate to provide access to the
underlying business service.
• BusinessDelegate: uses a LookupService to locate the required
BusinessService component.
Business Delegate Sequence Diagrams
44COMP9321, 16s2, Week 8
http://www.oracle.com/technetwork/java/businessdelegate-137562.html
Business Delegate, API, and API Engineering
45COMP9321, 16s2, Week 8
What is API?
• Application programming interface (API) is a set of routines, protocols, and tools 
for building software applications.
• An API expresses a software component in terms of its operations, inputs, 
outputs, and underlying types.
• An API defines functionalities that are independent of their respective 
implementations.
• A good API makes it easier to develop a program by providing all the building 
blocks. A programmer then puts the blocks together.
What is API Engineering?
• API engineering is an application of engineering to the design, development, and 
maintenance of APIs.
Business Delegate, API, and API Engineering
46COMP9321, 16s2, Week 8
Web APIs?
• Web APIs are the defined interfaces through which interactions happen 
between an enterprise and applications that use its assets.
• When used in the context of web development, an API is typically defined as a 
set of HTTP request messages, along with a definition of the structure of 
response messages, which is usually in an XML or JSON (JavaScript Object 
Notation) format. 
Microservice
e.g. Microservices in IBM Bluemix
https://developer.ibm.com/bluemix/2015/01/19/microservices-bluemix/
Business Delegate, API, and API Engineering
47COMP9321, 16s2, Week 8
Web APIs?
• While "web API" historically has been virtually synonymous for web service, 
the recent trend (so-called Web 2.0) has been moving away from Simple Object 
Access Protocol (SOAP) based web services and service-oriented architecture 
(SOA) towards more direct representational state transfer (REST) style web 
resources and resource-oriented architecture (ROA).
• Part of this trend is related to the Semantic Web movement toward Resource 
Description Framework (RDF).
• Web APIs allow the combination of multiple APIs into new applications known 
as mashups.
http://www.programmableweb.com/
More Patterns
48COMP9321, 16s2, Week 8
Core J2EE Patterns Catalog:
http://www.oracle.com/technetwork/java/index-138725.html
On this site, you will find the entire Java 2 Platform, Enterprise Edition (J2EE) Pattern 
catalog from the book Core J2EE Patterns: Best Practices and Design Strategies
authored by architects from the Sun Java Center.
A few more things to consider
49COMP9321, 16s2, Week 8
Guarding a View
50COMP9321, 16s2, Week 8
Guarding a View
51COMP9321, 16s2, Week 8
Guarding a View
52COMP9321, 16s2, Week 8
Guarding a View
53COMP9321, 16s2, Week 8
Guarding a View
54COMP9321, 16s2, Week 8
Duplicate Form Submissions
55COMP9321, 16s2, Week 8
Duplicate Form Submissions
56COMP9321, 16s2, Week 8
Duplicate Form Submissions
57COMP9321, 16s2, Week 8
Synchronizer Token
58COMP9321, 16s2, Week 8
Synchronizer Token
59COMP9321, 16s2, Week 8
Background Tasks
60COMP9321, 16s2, Week 8
Background Tasks
61COMP9321, 16s2, Week 8
Background Tasks
62COMP9321, 16s2, Week 8
References
63COMP9321, 16s2, Week 8
• Core J2EE patterns, Deepak Alur, John Crupi and Dan Marlks, Prentice Hall
• http://www.oracle.com/technetwork/java/index-138725.html
• Patterns of Enterprise Application Architecture, Martin Fowler, Addison-Wesley
• http://java.sun.com/blueprints/patterns/
• http://www.oracle.com/technetwork/articles/javase/index-142890.html
• From Modules to Objects, Professor James Landay, Software Engineering Lecture
64COMP9321, 16s2, Week 8