EMTM 600 Software Development Spring 2011 Lecture Notes 2.

EMTM 600Software Development

Spring 2011

Lecture Notes 2

EMTM 600 2011 Val Tannen 2

Assignments for next time

• Read about the domain model (and if needed again the use cases and user stories) in the handout “EMTM 600 Case Study based on Anchor Machinery”. Read (AGAIN?) “Domain model” in Fowler pp. 116-124.• Write a ½p-1p critique of the domain model design for Anchor

Machinery. Suggest improvements or extensions. Same groups as for Assignment 1.

• CONTINUE DESIGNING YOUR OWN ENTERPRISE APPLICATION:• Give a domain model for your application, as a UML class diagram. For

each class of business objects indicate the user stories for whose implementation they are to be used. Same groups as for Assignment 1.

In preparation for next lecture:

• Read the about Concurrency, chapter 5 in Fowler pp 63-80. Two days before the next lecture email me TWO QUESTIONS about something you didn’t understand. Each student.

• Read (AGAIN?) about the “Remote Façade” pattern in Fowler pp 388-400.


Layers and servers in Java EE architecture

JSP Servlets JDBC

DB

Session EJBs

presentation controller domain data mapping data source

EntityEJBs

browser

Web server Java EE application server

Eg.,Eg.,Eg., Eg.,Eg.,


Strict layering: a good idea!

Clear interface contracts exist between layersThe only references are from layer k to layer k+1

Pros:Limited propagation of changes in other layersEntire layers can be replaced when interfaces are the sameInterfaces can be changed affecting only adjacent layers (mostly…)Distributed deployment possible for layers (requires comm. protocols)Increased security

Cons:Performance suffers from the overhead of propagation through layersExtensibility and changeability suffers if interfaces are not robust enough

(hmm… that is a problem of all architectures!)


Java EE presentation layer technologiesServlet/JSPJava-based standard for generating dynamic content. Content can be in HTML directly or in XML/XSLT or (AJAX) in Java Script + XML or JSON

XML/XSLTSeparates data from its presentation. XSLT stylesheets translate XML to HTML.For example, Java and C# programs may generate XML data, then apply the same

stylesheet!Allows for limited-capability browsers.Much data may be already in XML, if it comes from Web services or B2B interactions.

GUI ApplicationsUser interfaces implemented by applications using Java Swing.Swing provides platform-independent graphical widgets.The client platform must run the JVM (Java Virtual Machine). Easier deployment can be achieved if the application is an applet.This is delivered through a Web browser and uses the JVM built into the browser.


Java EE presentation layer patterns

Model-View-Controller (MVC)The grandaddy of all design patterns!

The View is about user input and how to display output to the user.

The Controller understands the input and decides which data to display.

The Model has the domain objects that capture the “state” of the application, hence what the data consists of at any given time.

Model 2: a small specialization of MVCThe View doesn’t get the data directly from the Model, but through

Controller.

Display is modeled by special objects, possibly created dynamically.

The view has a standard way of displaying such objects.


Servlets

This is the further specialization of Model 2:

the View is based on a browser.

the browser sends HTTP(GET/POST) requests to the Web server.

the Web server passes requests to a servlet.

the servlet’s responses : o “print” HTML (like CGI), oro Java Server Pages (JSP), see the pattern View Helper / Template Based Strategy in textbook


MVC - Model 2 (Servlet/JSP)

Controller object(servlet)

Request (HTTP)

Domain object (EJB)

Display object(JSP)

View instance(browser)

Response(HTTP)


Developing Complex Views

Take a look at a busy news website. The view is large and complicated!JSPs that implement complicated views are hard to write and debug.

Use a pattern called Composite View. It’s really about modular development of JSPs.Goal: minimize the scriptlets inside JSPs.

Some help from Standard Tags , eg., <jsp:include page=“block.jsp”/>

Big help from Custom Tags! User-defined, open-source libraries are available: Tag Libs (eg., http://jakarta.apache.org/taglibs)

Good tutorials at THE WEB TIER (http://www.jspolympus.com)

http://jakarta.apache.org/taglibs


AJAX (Asynchronous Java Script and XML)A combination of technologies that relies on more work in the browser.

Improves user experience with Java Script interpreted in the browser.

Java Script execution leads to exchanges with the Web server that are not too noticeable to the user (refreshes only part of the displayed page).

The Web server sends XML or JSON which is then processed in the browser by CSS (cascading stylesheets, uploaded separately) or Java Script. The visual features can be confined to the CSS while the exchange of XML focuses on content.

Special class: XMLHttpRequest has objects that govern the exchanges between Java Script and Web Server. With MS Web servers it’s Active Xobject

Can combine with Tag Libs!

But writing large Java Script code is hard and buggy!


Controller patterns

Assume Servlet/JSP. We have two main choices for the controller/servlet:

Multiple Servlet (a pattern called Page Controller)Not in the textbook; not recommended; widely used!Needs multiple entry points which need to be encoded in HTTP requests.Easier for team development.But may hard-code URIs for the servlets; JSP hard to reorganize.

Single Servlet (a pattern called Front Controller)Single entry point, a “gate-keeping” servlet,

which then creates controller instances.More opportunities to generalize/extend uniformly.Needs a dispatching mechanism to route requests to the right controlling code.This can be cumbersome, luckily there is Struts.


Controller layer: session state

Problem: multiple users, same controller (servlet) with re-entrant code.

Web apps should be stateless! (This does not include persistent info in the domain layer and/or the back-end!)

Two solutions: Cookies and/or URL rewriting

Cookie: unique id returned by Web server to browser on first contact;

browser maintains cookies by URL-domain, attaches them

to further requests. Can be encrypted: we’ll see later the

J2EE automates this:

HttpSession.objects using a special

JSESSIONID cookie

One problem is that some potential customers are very security-conscious and disable cookies in their browser!


More about session state

URL rewriting: session id is attached (encoded) into the URL used for the return page; Web server decodes and provides servlet with session id.

Java EE helps: HttpServletResponse.encodeURL() HttpServletRequest.getRequestedSessionId()))

However, URL rewriting is more complicated to implement: requires JSP (no plain HTML returned and consistency: encode ALL URLs otherwise session is lost

J2EE helps: cookies and URL rewriting can be used together in the same app., and when the client browser does cookies, the application server cookies makes URL rewriting a no-op (thus less performance loss).


Multiple servers and session state

Java EE App Server

Session state must be available to ALL servers!-Save session data in a database-Make copies of session data in several servers; obtain them by messaging(M2M)

Java EE App Server

Web Server

Web Server

Edge NetworkDispatcher


Security

Java EE architecture weak spots:• Browser to Web server communication• (Web container to domain container communication)

Issues:• Authentication: prove that you are who you say you are!• Authorization: I know who you are, but you are not welcome :)• Privacy: both Jim and Jules are authorized clients but they shouldn’t see

each other’s accounts!• Integrity: who is masquerading as Jim?

All four are relevant to browser-web server communication.

(Between web container and domain container, the Java EE framework handles authentication and integrity automatically.)


JAAS

Java Authentication and Authorization Service

A general API for customizable authentication, authorization and access control mechanisms.

It can be used to implement any of the servlet security methods in the J2EE specification:

• HTTP basic authentication (optionally with encrypted password)• Form-based authentication• Certificate based authentication (HTTPS; uses encryption through

SSL)


Web Applications (simpler Enterprise Applications!)

Once we have mastered the presentation and controller layers, we can use the MVC pattern but M --- the model --- is directly represented in a database:

Three layers instead of five! (Simplest approach: Apache PHP + MySQL)

JSP

Servlets

JDBC


Enterprise Applications

What is the big difference between Web apps and Enterprise apps?

Enterprise apps use a Domain Model!

JSP

ServletsJDBC

Why? Domain objects can be shared between distinct functionalities of the same app and even between applications.

Data Acces

Objects

Java Beans/POJO

Session EJBs

Entity EJBs



JavaBeans? (in some Java EE books…)

JavaBeans is also a component framework, just like Enterprise Java Beans. This is where similarities stop!

JavaBeans is about intra-process components.It solves problems such as assembling widgets,in particular visual (GUI) widgets (recall VisualBasic?).Swing uses JavaBeans.

EJB is an inter-process framework, server-side:it manages distributed business objects in a >3-tier architecture.

Lame definition: “Bean: a Java object with a partially standardized interface”

Much confusion!Best to avoid the JavaBean terminology!Cute terminology: POJO --- Plain Old Java Objects!


Sharing Domain Objects

JSP Servlets

JDBC

DB

Session EJBs

persistentbeans

browser

Web server 1

Java EE application server

JSP Servlets

Web server 2


Business Objects and the Domain Model

business logic/objects = domain logic/objects

A simple pattern for business logic: Transaction Script (Fowler pp. 110-115)

It organizes the logic by request (transaction). Works in simple cases.

Basically that’s what we use in Web apps.

The Domain Model (Fowler pp. 116-124) pattern: structure follows business objects which have the data but also implement the business logic.

Since business objects are shared, we need transactional properties to work with them, especially when we interact with shared storage.

ACID: atomicity, consistency, isolation, durability


Domain Modeling Techniques

This is essentially the traditional Object-Oriented Design.

Overarching goals: 1) Robustness (enabling easy change/evolution)

2) Efficiency

Techniques (from Software Engineering course):

Functional decomposition (not so robust)

Object modeling (data+operations)

- CRC class - responsibility - collaborator (XP fame)

- UML -> RUP (rational unified process)

Data-centered design (good for simple create-read-update-delete apps)

XP (extreme programming): constant interaction with software client, iterative development, based on user stories.


Domain Model for Anchor Machinery Case Study:


Enterprise Applications - Take 1

In Anchor Machinery, we used a Domain Model:

JSP

ServletsJDBC

Goal: domain objects can be shared between distinct functionalities of the same application and even between applications.

DataAccessObjects

POJO



Not enough!

To achieve the essential goals of• Performance• Scalability• Availability• Reliability

Most enterprise applications need• Logical layering to become physical layering• Load balancing

Hence, we need distributed objects!


Enterprise Applications - Take 2

Goal : distributed domain objects

New problems: interference/consistency(transactions!), security

HTML

JSP

Servlets

Struts

JDBC

Session EJBs

CMPEntityEJBs


Specific toApp.Server

Vendor

CMP: Container-Managed PersistenceBMP: Bean-Managed Persistence(next lecture)

BMP EntityEJBs

EJB Container


Enterprise Java Beans (EJBs)

Components that implement domain logic in a distributed enterprise application.

Components are conceptual --- their implementation may consist of multiple Java classes and interfaces.

(POJO need just one class; EJBs need several in EJB 2.1, later simplified in EJB 3.0)

EJBs reside in an EJB container. The container plays essential roles in • Deployment (1-1 correspondence with EJB-JAR files)• Concurrency (multithreading)• Transaction support• Security (credentials for access to EJBs)• Memory management (pool of instances, swap to disk)• Persistence (for CMP entity EJBs)


Object remote inter-operation Objects can be deployed on different hosts. A host is usually a

separate machine but sometimes just a different process on the same machine. For Java, this means another JVM running in parallel.

Host 1 Host 2

“Client” object

“Server”object

method invocation

Eg., servletor session EJB

Eg., session EJBor entity EJB

What happens here?


CORBA: Common Object Request Broker Architecture

From Object Management Group.

Objective: to facilitate interoperability of components in distributed (client-server) systems

Based on object-oriented concepts. Language bindings: C, C++, Smalltalk, Java, Ada, COBOL, Lisp and Python. Language interoperability was the main goal of CORBA (and its Achilles’s heel!).

Basic architecture and specifications plus CORBA services: life-cycle, naming, transactions, persistence, query, trading, licensing, security, etc.

Domain-specific (finance, manufacturing, life sciences, etc.) task forces that develop standards for domain-specific components.


CORBA elements: an architecture and some specifications

ORB (Object Request Broker): application provided by CORBA vendor, one per host. Clients find a CORBA service because it is registered through an object broker.

IDL : (Interface Definition Language) : general (prog-language-independent) object-oriented type system; used to describe the type structure of the communicating objects.

Client IDL Stub : a proxy for the server object; the client call goes to the stub. The stub is in charge of marshalling communication for the client, using the ORB. Automatically obtained by compilation from IDL.


CORBA elements: an architecture and some specifications (cont’d)

Server IDL Skeleton : provides static interfaces to the methods of the server object. Also automatically compiled from IDL.

Server Object Adapter : accepts method invocations on behalf of the server object, instantiates the server object if needed, and passes the calls using to the server object using the skeleton interfaces. Supported by the ORB, vendor-specific.

Dynamic proxies and skeletons: DII (dynamic interface invocation) and DSI (dynamic skeleton interface) plus an Interface Repository. These facilitate communication without compile-time knowledge of types, using the ORB to find out about the interface that the desired object implements.

Transport uses a specific protocol IIOP (Internet Inter-ORB Protocol)


CORBA elements (static version)

Stub

“Client” object1

ORB 1

Skeleton &Adapter

“Server” object2

ORB 2IIOP

Host 1 Host 2


CORBA strengths and weaknesses

+ Set of standard interfaces.

+ Language- and platform-independent.

+ Specifies services needed by most distributed apps.

- Must use IDL + your development languages (eg., Java).

- Very few vendors implement the much-needed security and transaction services.

- “Damn complicated”!

CORBA did not fulfill the expectations of its creators.


Java’s RMI(RRemote MMethod IInvocation)

Sun’s definitionRemote Method Invocation (RMI) enables the programmer to create distributed Java-to-Java applications, in which the methods of remote Java objects can be invoked from other Java virtual machines, possibly on different hosts. A Java program can make a call on a remote object once it obtains a reference to the remote object, either by looking up the remote object in the bootstrap naming service provided by RMI or by receiving the reference as an argument or a return value. A client can call a remote object in a server, and that server can also be a client of other remote objects. RMI uses Object Serialization to marshal and unmarshal parameters and does not truncate types, supporting true object-oriented polymorphism.


Java’s RMI(RRemote MMethod IInvocation)

What Sun’s definition meansRMI = Java-to-Java no need for IDL.no need for a CORBA ORB, use Java librariesTransport: Java RMP (Remote Method Protocol)

which uses Java serialization of objects.


RMI’s how-to

Steps to follow: write a Java remote interface

must be public and extends java.rmi.Remote every remote object is described by one or more remote

interfaces write a Java remote object (well, a server class really)

implements the remote interface in the main method of the server class

• write code that creates instances (remote objects)• write code that registers remote objects in the RMI

Registry (bootstrapping)


RMI’s how-to (cont’d)

Steps to follow (cont’d) write a Java client (eg. applet) compile

the server code • first with javac • then with a special compiler rmic which creates stubs and

skeletons the client code (as usual)

launch start RMI Registry (server-side bootstrap name server) start server (creates and registers remote objects) run client (load the stubs also; this can be automated)


RMI’s special features

Distributed garbage collection. CORBA does not have it. Objects that are passed as arguments or returned as results must

implement java.io.Serializable If the client passes a client-local object as argument, that object is passed-by-

value, a copy of the object is serialized and sent to the server’s environment; similarly if the server returns a server-local object. CORBA does not do this.

However, if a remote object is passed as argument or returned, it is passed-by-reference. This is like CORBA.

RMI has a primitive, non-persistent, naming service for locating remote objects. RMI provides configurable security (SecurityManager object) to limit what

the stub proxies can do in the client’s environment. Essential for applets.


Java’sObject Serialization

Sun’s definitionObject Serialization extends the core Java Input/Output classes with support for objects. Object Serialization supports the encoding of objects and the objects reachable from them into a stream of bytes and it supports the complementary reconstruction of the object graph from the stream. Serialization is used for lightweight persistence and for communication via sockets or Remote Method Invocation (RMI). The default encoding of objects protects private and transient data, and supports the evolution of the classes. A class may implement its own external encoding and is then solely responsible for the external format.


Java’sObject Serialization (cont’d)

Example // Serialize today's date to a file.

FileOutputStream f = new FileOutputStream("tmp");ObjectOutputStream s = newObjectOutputStream(f);s.writeObject("Today");s.writeObject(new Date());s.flush();

// Deserialize a string and date from a file.FileInputStream in = new FileInputStream("tmp");ObjectInputStream s = new ObjectInputStream(in);String today = (String)s.readObject();Date date = (Date)s.readObject();

To allow itself to be serialized, a class should implement the java.io.Serializable or the java.io.Externalizable interface.


Java RMI strengths and weaknesses

+ Simple but very powerful!

+ Nice extra features (see previous slide)

+ Provides configurable applet security.

- Doesn’t work with other languages than Java.

- Naming service is too primitive (but we have JNDI)

- Lacks transaction support (but we have JTA)

- RMP lacks security features: no authentication, has trouble with firewalls


The choice made by the EJB specification

To get the best of both the CORBA and the Java world, and being a Java technology,

EJB adopts: RMI over IIOP

Advantages:

• Develop only in Java (no IDL…)

• Pass serialized objects around

• Use IIOP and CORBA security services

• Use IIOP to interoperate with CORBA-compatible legacy applications


EJB 2.1 elements

EJBs are created using the Factory design pattern (cannot just instantiate a class…)

The EJB factories are called EJB homes (EJB 2.1)and they implement an interface written by the programmer called a home interface. The homes are generated automatically and made part of the container. (Simplified in EJB 3.0)

“Client” objects find EJB homes through a standard naming service that implements the JNDI (Java Naming and Directory Interface) API.

Java EE applications servers provide this service.

The (unique) JNDI names are given at deployment time.


EJB 2.1 elements (cont’d)

Like RMI, the EJB specification uses remote interfaces to describe what a remote EJB can do.

The EJB contains classes that implement the remote interface.

When a “client” object uses an EJB home to get an EJB, what it really receives is a proxy object that implements the remote interface.

These proxy objects is automatically generated and they access the container methods needed to get to the actual implementations of the remote EJB and run them.

(This was simplified and made more transparent in EJB 3.0)


EJB 2.1 inter-operation

Host 1

Container

“Client” object

EJB

request factory

Host 2

EJBhome

EJBhome

factory method

EJBproxy

remote interface method

EJBproxy


Local EJB interfaces

Remote EJB access requires serialization, which is expensive.

When we “know” that an EJB will be accessed from the same host, EJB 2.1 (since 2.0) offers an alternative:

• Local home interface (plays the role of the home interface for access from the same JVM)

• Local interface (plays the role of the remote interface for access from the same JVM)

(Implementing EJB with three classes is cumbersome for developers. In EJB 3.0, only one class is used. Hence EJBs in 3.0 are often called POJOs!)


Types of EJBs

• Session EJBs Non-persistent components that provide access to

domain objects on the server. They implement domain logic when that

logic needs to be accessed from multiple controller objects

concurrently.

• Entity EJBs Represent domain objects, correspond to persistent

information. More about persistence, and the objecter-lational mapping,

in the next lecture.

• Message-Driven Beans See next.


Message Driven BeansThe third kind of EJB, after session and entity EJBs.

Logically, they are in the controller layer.

Physically, they are deployed in the EJB container.

HTML

JSP

Servlets

JDBCSession

EJBsEntityEJBs


Specific toApp.Server

Vendor

Message DrivenBeans

JMS

EJB Container


Message Driven Beans (cont’d)

Based on JMS, Java Messaging Service. This is asynchronous communication so it reaches the application eventually even if it is down temporarily.

JMS has two messaging models: Point-to-point (JMS Queue) Publish-and-subscribe (JMS Topic)

An MDB is a special kind of EJB that acts as a message consumer in the JMS messaging system. MDBs receive messages and perform business logic (perhaps by delegation to a session EJB) based on the message contents.

Where do the messages come from? From a MOM (Message Oriented Middleware) system (eg. IBM WebSphere MQ,

Sun ONE). MDB connects your Java EE application to MOM enterprise application integration projects.


Message Driven Beans (cont’d)

MDBs are housed in the EJB container.

The container provides standard EJB services to MDB, such as security services and automatic transaction management, which are handled as for all EJBs.

The container always calls an MDB’s onMessage() method by using the transaction handling specified in the bean's deployment descriptor.

EMTM 600 Software Development Spring 2011 Lecture Notes 2.

Documents

Transcript of EMTM 600 Software Development Spring 2011 Lecture Notes 2.