COMP9321 Web Application Engineering Design Patterns II Dr. Basem Suleiman Service Oriented Computing Group, CSE, UNSW Australia Semester 1, 2016, Week 7 http://webapps.cse.unsw.edu.au/webcms2/course/index.php?cid=2442 COMP9321, 16s1, Week 7 1 Acknowledgement/Contributions Service Oriented Computing Group, CSE, UNSW Australia • Dr. Helen Paik • Prof. Boualem Bentallah • Dr. Srikumar Venugopal • Dr. Moshe Chai Barukh • Dr. Amin Beheshti • Dr. Basem Suleiman • Many others from service oriented computing group COMP9321, 16s1, Week 3 2 J2EE Design Patterns Week 6, Design Pattern Part I: Design guidelines: • Servlets, JSP, JavaBeans Model View Controller: • MVC is the J2EE BluePrints recommended architectural design pattern for interactive applications • Two MVC architectures, centralized and multiple controllers Front Controller (Command): • For providing a central dispatch point to handle all incoming requests. COMP9321, 16s1, Week 7 3 J2EE Design Patterns 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 COMP9321, 16s1, Week 7 4 Service Locator Pattern COMP9321, 16s1, Week 7 5 Service Locator Pattern 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. Context • Service lookup and creation involves complex interfaces and network operations. Problem • 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. COMP9321, 16s1, Week 7 6 Service Locator Pattern 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 COMP9321, 16s1, Week 7 7 Service Locator Pattern – Relationships To build a service locator pattern, we need: Service Locator InitialContext ServiceFactory BusinessService COMP9321, 16s1, Week 7 8 Service Locator Pattern 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 COMP9321, 16s1, Week 7 9 Service Locator Pattern 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: COMP9321, 16s1, Week 7 10 Service Locator Pattern 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: COMP9321, 16s1, Week 7 11 Service Locator Pattern 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. COMP9321, 16s1, Week 7 12 Service Locator Pattern – Participants and Responsibilities COMP9321, 16s1, Week 7 13 Identifying Service Locator Pattern in the phonebook lab COMP9321, 16s1, Week 7 14 Identifying Service Locator Pattern in the phonebook lab COMP9321, 16s1, Week 7 15 Identifying Service Locator Pattern in the phonebook lab COMP9321, 16s1, Week 7 16 Dependency Injection COMP9321, 16s1, Week 7 17 Dependency COMP9321, 16s1, Week 7 18 SAX Books Parser Example COMP9321, 16s1, Week 7 19 What is "dependency injection" ? • 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. COMP9321, 16s1, Week 7 20 Benefits of "dependency injection" … COMP9321, 16s1, Week 7 21 Data Access Object COMP9321, 16s1, Week 7 22 Data Access Object 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 COMP9321, 16s1, Week 7 23 Data Access Object (DAO) Pattern Solution • Use a Data Access Object (DAO) pattern to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data. • The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, an external service like a B2B exchange, or any others • The business component that relies on the DAO uses the simpler interface exposed by the DAO for its clients. The DAO completely hides the data source implementation details from its clients. • This pattern allows the DAO to adapt to different storage schemes without affecting its clients or business components, the DAO acts as an adapter between the component and the data source. http://www.oracle.com/technetwork/java/dataaccessobject-138824.html COMP9321, 16s1, Week 7 24 Data Access Object Pattern – Relationships http://www.oracle.com/technetwork/java/dataaccessobject-138824.html COMP9321, 16s1, Week 7 25 Data Access Object: Participants and Responsibilities http://www.oracle.com/technetwork/java/dataaccessobject-138824.html COMP9321, 16s1, Week 7 26 Business Delegate COMP9321, 16s1, Week 7 27 Business Delegate 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 COMP9321, 16s1, Week 7 28 Business Delegate 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. • Using a Business Delegate reduces the coupling between presentation-tier clients and the system's business services. • Another benefit is that the delegate may cache results