COMP9321 Web Application Engineering Semester 1, 2017

Slides:



Advertisements
Similar presentations
3 Copyright © 2005, Oracle. All rights reserved. Designing J2EE Applications.
Advertisements

Welcome to Middleware Joseph Amrithraj
Quality of a Class Abstraction: Coupling & Cohesion Michael L. Collard, Ph.D. Department of Computer Science Kent State University.
Web Service Ahmed Gamal Ahmed Nile University Bioinformatics Group
1 Software Design Introduction  The chapter will address the following questions:  How do you factor a program into manageable program modules that can.
J2EE Design patterns Sharath Sahadevan August 8, 2002 St Louis Java SIG.
Spring, Hibernate and Web Services 13 th September 2014.
What is Software Design?  Introduction  Software design consists of two components, modular design and packaging.  Modular design is the decomposition.
Copyright Irwin/McGraw-Hill Software Design Prepared by Kevin C. Dittman for Systems Analysis & Design Methods 4ed by J. L. Whitten & L. D. Bentley.
George Blank University Lecturer. CS 602 Java and the Web Object Oriented Software Development Using Java Chapter 10.
Module: Definition ● A logical collection of related program entities ● Not necessarily a physical concept, e.g., file, function, class, package ● Often.
Object-Oriented Enterprise Application Development J2EE Blueprints.
Satzinger, Jackson, and Burd Object-Orieneted Analysis & Design
.NET Mobile Application Development Remote Procedure Call.
12-1 © Prentice Hall, 2004 Chapter 12: Design Elements Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
UNIT-V The MVC architecture and Struts Framework.
Chapter 10 EJB Concepts of EJB Three Components in Creating an EJB Starting/Stopping J2EE Server and Deployment Tool Installation and Configuration of.
Java Frameworks Indy Java Users Group January 29, 2003.
JDBC Session 5 Tonight: Data Access Patterns 1.J2EE Architecture & Design Patterns 2.The Data Access Tier 3.Data Access Patterns –DataAccessObject (DAO)
The Design Discipline.
Chapter 9: Coupling & Cohesion Omar Meqdadi SE 273 Lecture 9 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Introduction to distributed systems Dr. S. Indran 23 January 2004.
Coupling and Cohesion Pfleeger, S., Software Engineering Theory and Practice. Prentice Hall, 2001.
Coupling and Cohesion Source:
第十四章 J2EE 入门 Introduction What is J2EE ?
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 09. Review Introduction to architectural styles Distributed architectures – Client Server Architecture – Multi-tier.
Cohesion and Coupling CS 4311
GRASP: Designing Objects with Responsibilities
Core Indigo Patterns Ted Neward
Enterprise Integration Patterns CS3300 Fall 2015.
آرمان حسين‌زاده آذر  Access to data varies depending on the source of the data.  Access to persistent storage, such as to a database, varies greatly.
COMP9321 Web Application Engineering Semester 2, 2015 Dr. Amin Beheshti Service Oriented Computing Group, CSE, UNSW Australia Week 8 1COMP9321, 15s2, Week.
Java EE Patterns Dan Bugariu.  What is Java EE ?  What is a Pattern ?
COMP9321 Web Application Engineering Semester 2, 2015 Dr. Amin Beheshti Service Oriented Computing Group, CSE, UNSW Australia Week 7 1COMP9321, 15s2, Week.
CSCE 315 – Programming Studio Spring Goal: Reuse and Sharing Many times we would like to reuse the same process or data for different purpose Want.
© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/3 JSP Application Models.
Chapter 9: Coupling & Cohesion Omar Meqdadi SE 273 Lecture 9 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
SOFTWARE DESIGN & SOFTWARE ENGINEERING Software design is a process in which data, program structure, interface and their details are represented by well.
Coupling and Cohesion Schach, S, R. Object-Oriented and Classical Software Engineering. McGraw-Hill, 2002.
Coupling and Cohesion Pfleeger, S., Software Engineering Theory and Practice. Prentice Hall, 2001.
A service Oriented Architecture & Web Service Technology.
COMP9321 Web Application Engineering Semester 2, 2016 Dr. Amin Beheshti Service Oriented Computing Group, CSE, UNSW Australia Week 8 1COMP9321, 16s2, Week.
J2EE Platform Overview (Application Architecture)
COMP9321 Web Application Engineering Semester 2, 2016
7. Modular and structured design
WEB SERVICES From Chapter 19 of Distributed Systems Concepts and Design,4th Edition, By G. Coulouris, J. Dollimore and T. Kindberg Published by Addison.
WEB SERVICES.
Coupling and Cohesion 1.
Unit – 5 JAVA Web Services
Introduction to J2EE Architecture
Software Testing and Maintenance Designing for Change
Design and Maintenance of Web Applications in J2EE
Cohesion and Coupling Chapter 5, Pfleeger 01/01/10.
Inventory of Distributed Computing Concepts and Web services
Service-centric Software Engineering
Improving the Design “Can the design be better?”
CS223: Software Engineering
Lecture 1: Multi-tier Architecture Overview
Inventory of Distributed Computing Concepts
Software Design CMSC 345, Version 1/11.
Software Design Lecture : 9.
Software Design Lecture : 8
Software Design Lecture : 10
SAMANVITHA RAMAYANAM 18TH FEBRUARY 2010 CPE 691
Distributed Systems through Web Services
Middleware, Services, etc.
WEB SERVICES From Chapter 19, Distributed Systems
Cohesion and Coupling.
DESIGN CONCEPTS AND PRINCIPLES
Software Testing and Maintenance Designing for Change
Presentation transcript:

COMP9321 Web Application Engineering Semester 1, 2017 Dr. Amin Beheshti Service Oriented Computing Group, CSE, UNSW Australia Week 8 http://webapps.cse.unsw.edu.au/webcms2/course/index.php?cid= 2457 COMP9321, 17s1, Week 8

Assignment 1 Marks on GradeBook Assignment 2 is due end of Week 9: Sunday, 7 May 2017, 23:59:59 COMP9321, 17s1, Week 8

J2EE Design Patterns 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. COMP9321, 17s1, Week 8

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, 17s1, Week 8

First.. What is Cohesion & Coupling? COMP9321, 17s1, Week 8

Cohesion Seven levels of Cohesion: 7. Functional 6. Informational 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 Best Worst COMP9321, 17s1, Week 8

Cohesion Seven levels of Cohesion: 7. Functional 6. Informational 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 Best Worst Coincidental: module performs multiple, completely unrelated actions (degrades maintainability & modules are not reusable) COMP9321, 17s1, Week 8

Cohesion Seven levels of Cohesion: 7. Functional 6. Informational 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 Best Worst Logical: module performs series of related actions, one of which is selected by calling module. (interface difficult to understand & module difficult to reuse) COMP9321, 17s1, Week 8

Cohesion Seven levels of Cohesion: 7. Functional 6. Informational 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 Best Worst Temporal : module performs series of actions related in time. (code spread out -> not maintainable or reusable) COMP9321, 17s1, Week 8

Cohesion Seven levels of Cohesion: 7. Functional 6. Informational 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 Best Worst Procedural : module performs series of actions related by procedure to be followed by product. (not reusable) COMP9321, 17s1, Week 8

Cohesion Seven levels of Cohesion: 7. Functional 6. Informational 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 Best Worst Communicational : A communicationally cohesive module is one which performs several functions on the same input or output data. For example, obtain author, title, or price of book from bibliographic record, based on a passed flag (not reusable) COMP9321, 17s1, Week 8

Cohesion Seven levels of Cohesion: 7. Functional 6. Informational 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 Best Worst 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!) COMP9321, 17s1, Week 8

Cohesion Seven levels of Cohesion: 7. Functional 6. Informational 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 Best Worst Functional : module performs exactly one action (more reusable, corrective maintenance easier, easier to extend product‎) Microservices COMP9321, 17s1, Week 8

Coupling Seven levels of Coupling: 5. Data 4. Stamp 3. Control Coupling is defined as the ‘degree of interaction between two modules’. Seven levels of Coupling: 5. Data 4. Stamp 3. Control 2. Common 1. Content Best Worst COMP9321, 17s1, Week 8

Coupling Seven levels of Coupling: 5. Data 4. Stamp 3. Control Coupling is defined as the ‘degree of interaction between two modules’. Seven levels of Coupling: 5. Data 4. Stamp 3. Control 2. Common 1. Content Best Worst Content : one module directly references contents of the other module. e.g., accessing local data of another module. (almost any change to M1 requires changes to M2‎) COMP9321, 17s1, Week 8

Coupling Seven levels of Coupling: 5. Data 4. Stamp 3. Control Coupling is defined as the ‘degree of interaction between two modules’. Seven levels of Coupling: 5. Data 4. Stamp 3. Control 2. Common 1. Content Best Worst Common : two modules have write access to the same global data. (difficult to reuse + module exposed to more data than necessary ‎) COMP9321, 17s1, Week 8

Coupling Seven levels of Coupling: 5. Data 4. Stamp 3. Control Coupling is defined as the ‘degree of interaction between two modules’. Seven levels of Coupling: 5. Data 4. Stamp 3. Control 2. Common 1. Content Best Worst Control : one module passes an element of control to the other. (modules are not independent) COMP9321, 17s1, Week 8

Coupling Seven levels of Coupling: 5. Data 4. Stamp 3. Control Coupling is defined as the ‘degree of interaction between two modules’. Seven levels of Coupling: 5. Data 4. Stamp 3. Control 2. Common 1. Content Best Worst 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) COMP9321, 17s1, Week 8

Coupling Seven levels of Coupling: 5. Data 4. Stamp 3. Control Coupling is defined as the ‘degree of interaction between two modules’. Seven levels of Coupling: 5. Data 4. Stamp 3. Control 2. Common 1. Content Best Worst Data : every argument is either a simple argument or a data structure in which all elements are used by the called module.  Each datum is an elementary piece, and these are the only data shared; e.g., passing an integer to a function that computes a square root. (maintenance is easier) <good design has high cohesion & weak coupling> COMP9321, 17s1, Week 8

Service Locator Pattern COMP9321, 17s1, Week 8

Service Locator Pattern 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. COMP9321, 17s1, Week 8

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, 17s1, Week 8

Service Locator Pattern The Service Locator abstracts the API lookup services, vendor dependencies, lookup complexities, and business object creation, and provides a simple interface to clients. COMP9321, 17s1, Week 8

Service Locator Pattern InitialContext: The InitialContext object is the start point in the lookup and creation process. COMP9321, 17s1, Week 8

Service Locator Pattern 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. COMP9321, 17s1, Week 8

Service Locator Pattern 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, 17s1, Week 8

Service Locator Pattern COMP9321, 17s1, Week 8

Service Locator Pattern To build a service locator pattern, we need: https://www.tutorialspoint.com/design_pattern/service_locator_pattern.htm COMP9321, 17s1, Week 8

Dependency Injection COMP9321, 17s1, Week 8

Dependency COMP9321, 17s1, Week 8

SAX Books Parser Example COMP9321, 17s1, Week 8

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, 17s1, Week 8

Benefits of "dependency injection" … COMP9321, 17s1, Week 8

 Data Access Object COMP9321, 17s1, Week 8

Data Access Object Context Problem 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, 17s1, Week 8

Data Access Object 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 COMP9321, 17s1, Week 8

Data Access Object: Sequence Diagram http://www.oracle.com/technetwork/java/dataaccessobject-138824.html COMP9321, 17s1, Week 8

Business Delegate COMP9321, 17s1, Week 8

Business Delegate Context Problem 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, 17s1, Week 8

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. 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 COMP9321, 17s1, Week 8

Business Delegate Client: requests the BusinessDelegate to provide access to the underlying business service. BusinessDelegate: uses a LookupService to locate the required BusinessService component. http://www.oracle.com/technetwork/java/businessdelegate-137562.html COMP9321, 17s1, Week 8

Business Delegate Sequence Diagrams http://www.oracle.com/technetwork/java/businessdelegate-137562.html COMP9321, 17s1, Week 8

API and API Engineering COMP9321, 17s1, Week 8

API and API Engineering 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. COMP9321, 17s1, Week 8

API and API Engineering 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/ COMP9321, 17s1, Week 8

API and API Engineering 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/ COMP9321, 17s1, Week 8

authored by architects from the Sun Java Center. More Patterns 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. COMP9321, 17s1, Week 8

A few more things to consider COMP9321, 17s1, Week 8

Guarding a View COMP9321, 17s1, Week 8

Guarding a View COMP9321, 17s1, Week 8

Guarding a View COMP9321, 17s1, Week 8

Guarding a View COMP9321, 17s1, Week 8

Guarding a View COMP9321, 17s1, Week 8

Duplicate Form Submissions COMP9321, 17s1, Week 8

Duplicate Form Submissions COMP9321, 17s1, Week 8

Duplicate Form Submissions COMP9321, 17s1, Week 8

Synchronizer Token COMP9321, 17s1, Week 8

Synchronizer Token COMP9321, 17s1, Week 8

Background Tasks COMP9321, 17s1, Week 8

Background Tasks COMP9321, 17s1, Week 8

References 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 COMP9321, 17s1, Week 8

COMP9321, 17s1, Week 8