Transcript ppt
EMTM 600
Software Development
Spring 2011
Lecture Notes 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.
EMTM 600 2011 Val Tannen
2
Layers and servers in Java EE architecture
Java EE application server
Web server
presentation
controller
Eg.,
Eg.,
JSP
Servlets
browser
EMTM 600 2011 Val Tannen
domain
Eg.,
Session
EJBs
data mapping
data source
Eg.,
Entity
EJBs
Eg.,
JDBC
DB
3
Strict layering: a good idea!
Clear interface contracts exist between layers
The only references are from layer k to layer k+1
Pros:
Limited propagation of changes in other layers
Entire layers can be replaced when interfaces are the same
Interfaces 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 layers
Extensibility and changeability suffers if interfaces are not robust enough
(hmm… that is a problem of all architectures!)
EMTM 600 2011 Val Tannen
4
Java EE presentation layer technologies
Servlet/JSP
Java-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/XSLT
Separates 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 Applications
User 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.
EMTM 600 2011 Val Tannen
5
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 MVC
The 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.
EMTM 600 2011 Val Tannen
6
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
o
“print” HTML (like CGI), or
Java Server Pages (JSP), see the pattern
View Helper / Template Based Strategy in textbook
EMTM 600 2011 Val Tannen
7
MVC - Model 2 (Servlet/JSP)
Request
(HTTP)
Controller object
(servlet)
View instance
(browser)
Response
(HTTP)
Display object
(JSP)
Domain object
(EJB)
EMTM 600 2011 Val Tannen
8
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)
EMTM 600 2011 Val Tannen
9
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!
EMTM 600 2011 Val Tannen
10
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.
EMTM 600 2011 Val Tannen
11
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!
EMTM 600 2011 Val Tannen
12
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).
EMTM 600 2011 Val Tannen
13
Multiple servers and session state
Java EE App Server
Web Server
Edge Network
Dispatcher
Web Server
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)
EMTM 600 2011 Val Tannen
14
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.)
EMTM 600 2011 Val Tannen
15
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)
EMTM 600 2011 Val Tannen
16
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:
Servlets
JSP
JDBC
Three layers instead of five! (Simplest approach: Apache PHP +
MySQL)
EMTM 600 2011 Val Tannen
17
Enterprise Applications
What is the big difference between Web apps and Enterprise apps?
Enterprise apps use a Domain Model!
presentation
data mapping
controller
domain
Servlets
Java
Beans/
POJO
Data
Acces
Objects
Session
EJBs
Entity
EJBs
JSP
data source
JDBC
Why? Domain objects can be shared between distinct functionalities of
the same app and even between applications.
EMTM 600 2011 Val Tannen
18
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!
EMTM 600 2011 Val Tannen
19
Sharing Domain Objects
Web server 1
JSP
Servlets
Java EE application server
Session
EJBs
browser
persistent
beans
JDBC
Web server 2
JSP
Servlets
DB
EMTM 600 2011 Val Tannen
20
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
EMTM 600 2011 Val Tannen
21
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.
EMTM 600 2011 Val Tannen
22
Domain Model for Anchor Machinery Case Study:
EMTM 600 2011 Val Tannen
23
Enterprise Applications - Take 1
In Anchor Machinery, we used a Domain Model:
presentation
controller
domain
Data
Access
Objects
Servlets
JSP
data mapping
data source
JDBC
POJO
Goal: domain objects can be shared between distinct functionalities of
the same application and even between applications.
EMTM 600 2011 Val Tannen
24
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!
EMTM 600 2011 Val Tannen
25
Enterprise Applications - Take 2
Goal : distributed domain objects
New problems: interference/consistency(transactions!), security
EJB Container
presentation
controller
HTML
Servlets
JSP
Struts
EMTM 600 2011 Val Tannen
domain
Session
EJBs
data mapping
CMP
Entity
EJBs
data source
Specific to
App.Server
Vendor
BMP
Entity
EJBs
CMP: Container-Managed Persistence
BMP: Bean-Managed Persistence
(next lecture)
JDBC
26
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)
EMTM 600 2011 Val Tannen
27
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.
“Client”
object
Host 1
Eg., servlet
or session EJB
EMTM 600 2011 Val Tannen
method invocation
What happens
here?
“Server”
object
Host 2
Eg., session EJB
or entity EJB
28
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.
EMTM 600 2011 Val Tannen
29
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-languageindependent) 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.
EMTM 600 2011 Val Tannen
30
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)
EMTM 600 2011 Val Tannen
31
CORBA elements (static version)
“Client”
object1
“Server”
object2
Skeleton &
Adapter
Stub
ORB 1
Host 1
EMTM 600 2011 Val Tannen
IIOP
ORB 2
Host 2
32
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.
EMTM 600 2011 Val Tannen
33
Java’s RMI
(Remote Method Invocation)
Sun’s definition
Remote 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.
EMTM 600 2011 Val Tannen
34
Java’s RMI
(Remote Method Invocation)
What Sun’s definition means
RMI = Java-to-Java no need for IDL.
no need for a CORBA ORB, use Java libraries
Transport: Java RMP (Remote Method Protocol) which
uses Java serialization of objects.
EMTM 600 2011 Val Tannen
35
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)
EMTM 600 2011 Val Tannen
36
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)
EMTM 600 2011 Val Tannen
37
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-byvalue, 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-byreference. 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.
EMTM 600 2011 Val Tannen
38
Java’s
Object Serialization
Sun’s definition
Object 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.
EMTM 600 2011 Val Tannen
39
Java’s
Object 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.
EMTM 600 2011 Val Tannen
40
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
EMTM 600 2011 Val Tannen
41
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
EMTM 600 2011 Val Tannen
42
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.
EMTM 600 2011 Val Tannen
43
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)
EMTM 600 2011 Val Tannen
44
EJB 2.1 inter-operation
request factory
EJB
home
EJB
home
EJB
“Client”
object
factory method
EJB
proxy
Host 1
remote interface
method
EMTM 600 2011 Val Tannen
EJB
proxy
Container
Host 2
45
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!)
EMTM 600 2011 Val Tannen
46
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.
EMTM 600 2011 Val Tannen
47
Message Driven Beans
The third kind of EJB, after session and entity EJBs.
Logically, they are in the controller layer.
Physically, they are deployed in the EJB container.
presentation
controller
domain
data mapping
HTML
Specific to
App.Server
Vendor
Servlets
JSP
JMS
Message
Driven
Beans
data source
Session
EJBs
Entity
EJBs
JDBC
EJB Container
EMTM 600 2011 Val Tannen
48
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.
EMTM 600 2011 Val Tannen
49
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 2011 Val Tannen
50