ppt97 presentation - University of Connecticut

Transcript ppt97 presentation - University of Connecticut

CSE298
CSE300
Distributed Object Computing and Java
Wei Lin, Xu Ma
Walter McClure, Chengzhong Wang
Computer Science & Engineering Department
The University of Connecticut
191 Auditorium Road, Box U-155
Storrs, CT 06269-3155
{weilin,xma,czwang}@engr.uconn.edu
[email protected]
CSE.RU-1.1
CSE298
CSE300
Motivation



Distributed Object Computing
 Interaction Among Various Components
 Large-scale Software Systems Over
Heterogeneous Platforms and Networks
Java is an Excellent Candidate to Implement
Distributed Systems
Java Features Support DOC
 Middleware and Distributed Architectures
 Enterprise JavaBeans
 Database Support
 Java and XML
 and more...
CSE.RU-1.2
CSE298
CSE300
Objectives

Investigate the Current State of the Art of Java in
Support of DOC

Focus on Java Support of Enterprise Computing
 Interoperability of Servers, databases, COTs,
and Legacy Applications
 Commercial Products

Explore and Predict the future with Respect to
emerging and potential tools and technologies
CSE.RU-1.3
CSE298
CSE300
Overview of Presentation


Distributed Computing
Middleware and Distributed Architectures
 Survey of Distributed Architectures
 CORBA
– IIOP
 RMI
 JavaSpaces



XML and Java
Java Database Support
 JDBC
 SQLJ embedded SQL
 Object-relational Mapping (ODMG Java
Binding)
Enterprise JavaBeans
CSE.RU-1.4
CSE298
CSE300
Why Distributed Applications

Evolution of Current Systems
 First there were Mainframes
 Hierarchical Databases and Dumb Terminals
 All software was monolithic
– User Interface, Business Logic, and Data access were all
combined together into single application.

Client/Server Architecture(Two-tier)
 GUI would reside on client, Database on server,
and business logic on client, server, or both.

Client/Server(Multi-tier)
 Further separates application layers into
components.
 Shields client from changes to other parts of system
CSE.RU-1.5
CSE298
CSE300
Next Step: Distributed Systems

Brings Concept of Multi-Tier Client/Server
Systems to Natural Conclusion:
 Business Logic and Data Access are no longer
differentiated.
 Functionality of application is exposed as objects.
 Can interact with other objects in that system as well
as other systems.

Furnishes Utmost Flexibility
 Communication is constrained by component
interface definitions.
 Specify functionality and implementations of that
functionality.
 Implementations can be altered significantly without
affecting other components throughout the system.
CSE.RU-1.6
CSE298
CSE300
Why Distributed Computing

Continues evolution of computer systems from
multi-tier client/server architectures.
 Improves concurrency through connectivity
and internetworking.
 Replication of systems will produce more
reliable and available applications.
 Scalability and portability will be amplified by
modularity.
 Dynamic configuration and reconfiguration of
the applications will help extend them
throughout the enterprise.
 System itself becomes more effective by
availability of open systems and shared
resources.
CSE.RU-1.7
CSE298
CSE300
Why Distributed Computing

Continues evolution of computer systems from
multi-tier client/server architectures.
 Distribute related processing among multiple
resources.
 Decentralizes nature of the enterprise.
 Processing power is no longer central, but spread
over the network.

Heterogeneous environments pose challenge to
software components of system to exploit their
power.
 Distributed computing offers software to use full
potential of the enterprise.
CSE.RU-1.8
CSE298
CSE300
Java and Distributed Object Computing


Java’s extensibility and affinity for the Internet and
networking technologies makes it ideal to develop
distributed applications.
Programming models offered by Java technology
offer platforms to develop simpler and more
powerful applications.
 Java can be used to develop applications in
heterogeneous and homogeneous
environments.
 Extensions can be built on top of current Java
architectures to leverage the technology with
current systems in place.
 New systems built on top of Java technologies
offer robust, dynamic, and scalable solutions.
CSE.RU-1.9
CSE298
CSE300
Distributed Object Computing and Java
Middleware and Architectures for
Distributed Systems
CSE.RU-1.10
CSE298
CSE300
CORBA


Common Object Request Broker Architecture
Facilitates communication of application
components and objects across a distributed,
heterogeneous environment.
 Language and platform independent.
 Interfaces are defined for objects across the
network.
 Provide interoperability for other objects
communicating with them.


Objects across the network are passed by
reference.
Underlying functionality of architecture
provided through the Object Request Broker.
CSE.RU-1.11
CSE298
CSE300
Object Request Broker(ORB)

Facilitates the client/server relationship between
components and their objects.
 All communication among distributed
components handled by ORB.
 Comprises all mechanisms needed to:
– Find and identify objects across the system.
– Manage connections of various components across the
network.
– Monitor the delivery of data.
 Provides transparency to the users of objects in the
application.

Translate all parameters into format for
transportation.
 -Process of marshaling and unmarshaling.
CSE.RU-1.12
CSE298
CSE300
Object Requests to other Objects
Client
Server
Object Reference to Server
Network
ORB
ORB
Orb finds server
ORB finds object being referenced. The client has no knowledge of where the object resides.
Reference to that object is passed back to the client where the method is invoked.
Client
Server
Method Invocation
Method Invocation
Network
ORB
Unmarshall Parameters
Marshall Parameters
ORB
Client invokes method on that reference which in turn invokes it on the server. The ORB
marshals and unmarshals the parameters as shown.
Client
Server
Object Reference to Server
Network
ORB
Unmarshall Return Value
Marshall Return Value
ORB returns value in marshaled form which is then unmarshaled for by the client’s ORB
ORB
CSE.RU-1.13
CSE298
CSE300
Interface Definition Language(IDL)


When a client makes a request on an object
methods supported by that object must be known.
 IDL defines interfaces; thus interactions
between application components.
 Provides basic framework for outlining the
objects handled by the ORB.
 Interface determines types of requests that can
be made on the object.
Compiled IDL code generates client stubs and
server skeletons.
 Stubs and skeletons map IDL interface
specifications to language specific
implementations of those interfaces.
CSE.RU-1.14
CSE298
CSE300
Object Adapters


Object adapters interface a component’s
implementation with its ORB.
 Common set of operations for accessing ORB.
 Connect CORBA objects and ORB itself.
 Maps interface of a called object to the
expected interface of the client.
 Register CORBA objects and create object
references to those objects.
Object Adapters sanction the diversity of objects
and implementations that can be developed
throughout the CORBA architecture.
 Ensures to keep ORB as simple as possible.
 Without OAs, variety of objects that could
interface with ORB would be very limited.
CSE.RU-1.15
CSE298
CSE300
Internet Inter-Orb Protocol(IIOP)




The different ORBs in use need a standard
protocol to communicate over.
The General Inter-Orb Protocol(GIOP) is a
collection of message requests ORBs can make
over a network.
Adherence to this standard ensures ORBs from
different vendors will be able to interoperate.
The GIOP was mapped to TCP/IP to create the
Internet Inter-Orb Protocol.
 Maps GIOP connections to TCP/IP sockets.
 Allows ORBs to use Internet as backbone.
 Transport protocol which allows other
architectures to interface with CORBA
applications, i.e. Java RMI
CSE.RU-1.16
CSE298
CSE300
Extending CORBA’s Functionality



Additional functionality is needed to build upon
the ORB and object adapters to create enterpriseclass-distributed applications.
The OMG provides interfaces through which the
additional functionality is offered.
 Implementations of these services is up to the
vendors.
CORBAservices and CORBAfacilities provide
additional horizontal and vertical functionality to
the CORBA architecture.
 CORBAservices are useful to all applications.
 CORBAfacilities provides general facilities
and specialized facilities.
CSE.RU-1.17
CSE298
CSE300
CORBA and Java


Creating CORBA applications with Java will
require a Java enabled ORB as well as an IDL
compiler.
 Java IDL is an ORB available by SUN for
CORBA applications
 idl2java compiler will map an IDL interface to
generate client stubs and server skeletons in
Java.
Java fits well with CORBA due to architectural
similarities.
 CORBA’s module construct is analogous to
Java’s package construct.
 CORBA use of interfaces directly corresponds
with that of Java
CSE.RU-1.18
CSE298
CSE300
CORBA and Java


Creating CORBA applications with Java will
require a Java enabled ORB as well as an IDL
compiler.
 Java IDL is an ORB available by SUN for
CORBA applications
 idl2java compiler will map an IDL interface to
generate client stubs and server skeletons in
Java.
Java fits well with CORBA due to architectural
similarities.
 CORBA’s module construct is analogous to
Java’s package construct.
 CORBA use of interfaces directly corresponds
with that of Java
CSE.RU-1.19
CSE298
CSE300
Java RMI




Simple and direct model for distributed computing.
Java-to-Java distributed solution.
Three layer architecture.
 Stubs/Skeletons: Client side stubs and server
side skeletons
 Remote reference layer: Reference/invocation
behavior.
 Transport: Connection set up and
management and remote object tracking.
Boundary at each layer is defined by a specific
interface and protocol.
 Each layer can be replaced by an alternate
implementation without affecting other layers
in the system.
CSE.RU-1.20
CSE298
CSE300
Java RMI



RMI can pass full objects as arguments and return
values.
RMI can move class implementations from client
to server and server to client.
Ability to pass behavior.
Building distributed applications is
a four step process.
•Define interfaces to remote objects.
•Implement remote objects.
•Run rmic on remote implementation
classes.
•Make code network accessible.
CSE.RU-1.21
CSE298
CSE300
Passing Behavior


Ability to move behavior(class implementations)
across the network provides maximum flexibility.
 Changing server policies would only require
one new Java class to be installed on on server.
Example: Server Defined Policy
 Suppose a current application enforces specific
policies.
 Client could upload behavior from the server with a
simple method call.
 Client receives implementation and offloads
processing to client.

Ability to pass objects by value optimizes
distributed architecture. Much of the processing
for applications can occur locally.
CSE.RU-1.22
CSE298
CSE300
Transport Protocols


Original protocol which RMI operated over was
the Java Remote Method Protocol(JRMP).
Addition of IIOP to RMI transport protocols
enabled architecture to interface with CORBA
objects.
CSE.RU-1.23
CSE298
CSE300
Extensions on top of Java RMI


New interfaces that sit on top of Java RMI
Leasing
 Allows Java objects to negotiate and establish
contracts with each other for the use of its
resources.
 Enhances reliability and fault tolerance by
providing a means for Java objects to react to
failures in the system.

Transactions
 Support consistency over a set of operations
between participating objects.
 Operations can be grouped to guarantee completion
of all or none.
CSE.RU-1.24
CSE298
CSE300
Extensions on top of Java RMI

Distributed Events
 Provide a system for objects to register to be
notified when state changes of objects occur.
 Enables reliable event-based programming in
distributed applications.
CSE.RU-1.25
CSE298
CSE300
JavaSpaces


Unified mechanism for dynamic communication,
coordination, and sharing of objects between Javabased network resources such as clients and
servers.
 No need to track client, server, or intermediate
associations of objects by requester or provider.
 Full objects can be stored as entries into the
space.
 Simplifies creating distributed applications.
 Can be used with existing software infrastructures.
Decouples the providers and requestors of
network services by delivering a unified space for
sharing, communication, and coordination.
CSE.RU-1.26
CSE298
CSE300
JavaSpaces


JavaSpaces acts like dynamic networked
marketplace for distributed objects.
A JavaSpaces server holds entries.
 An entry is a typed group of objects.
CSE.RU-1.27
CSE298
CSE300
Goals of JavaSpaces Technology








Simple programming interface.
Easier development using less code.
One simple interface can be used for sharing,
cooperation, and communication of objects.
Legacy interoperability.
Objects can be stored as data and behavior.
Network resources can communicate
asynchronously.
Multiple implementations are possible, including
database connectivity.
Service implementations will be transparent. All
entries will operate in the same manner.
CSE.RU-1.28
CSE298
CSE300
JavaSpaces: Stock Trading Example



Stock trading system would exchange entries
containing stocks, owners, bids, quantities,
portfolio, and live feed and graphic applets.
 Seller places entry in the space and requests to
be notified when there is an interested buyer.
 Anonymous buyers read for stocks that are
attractive to them.
 Buyer determines to buy a stock and places a
bid entry.
 Seller is notified that bid entry has been placed.
Seller could send code to buyer to complete the
purchase.
This example could be extended greatly using
leases, transactions, and distributed events.
CSE.RU-1.29
Distributed Persistence and Distributed
Algorithms
CSE298
CSE300



JavaSpaces is to help address these two issues.
Distributed Persistence
 Provides ability to store related objects and
retrieve them based on value-matching lookup
for specific fields.
Distributed Algorithms
 Can be modeled as a flow of objects between
participants.
 Different from traditional distributed architectures
which is to create method-call-like protocols .

JavaSpaces implements “flow of objects”
 Protocols are based on the movement of objects in
and out of JavaSpaces implementation
CSE.RU-1.30
CSE298
CSE300
JavaSpaces



JavaSpaces is a way of building distributed
systems.
The requestor and provider of network services
can be decoupled by using objects exchanged in
one or more spaces.
Technology provides reliable distributed storage
for the objects in the system.
CSE.RU-1.31
CSE298
CSE300
What is XML?


XML stands for Extensible Markup Language,
which is a subset of SGML
Different between XML and HTML
 HTML is a markup language; XML is a meta
language, which can be used to define markup
language.
 HTML defines presentation structure; XML
defines data structure
CSE.RU-1.32
CSE298
CSE300
XML 1.0





W3C Recommendation 2/10/98
XML Documents
 Logical structure: properly nested elements
 Physical structure: properly nested entities
Well-formed XML Documents
Valid XML Documents
BNF
document ::= prolog element Misc*
prolog ::= XMLDecl? Misc* (doctypedecl Misc*)?
doctypedecl ::= ‘<!DOCTYPE’ S Name (S ExternalID)? S? (‘[‘
(markupdecl | PEReference | S)* ‘]’ S?)? ‘>’
markupdecl ::= elementdecl | AttlistDecl | EntityDecl | NOtationDecl | PI | Comment
element ::=EmptyElemTag | Stag content Etag
CSE.RU-1.33
CSE298
CSE300
DTD - Document Type Definition

document type definition contains markup
declarations that provide a grammar for a class of
documents. This grammar is known as a document
type definition, or DTD.
 Element type declaration
 Attribute-list declaration
 Entity declaration
 Notation declaration
CSE.RU-1.34
CSE298
CSE300
XML Document Example - DTD




<!ELEMENT PLAY (TITLE, FM, PERSONAE, SCNDESCR, PLAYSUBT, INDUCT?,
PROLOGUE?, ACT+, EPILOGUE?)>
<!ELEMENT TITLE (#PCDATA)>
<!ELEMENT FM
(P+)>
<!ELEMENT P
(#PCDATA)>
<!ELEMENT PERSONAE (TITLE, (PERSONA | PGROUP)+)>
<!ELEMENT PGROUP (PERSONA+, GRPDESCR)>
<!ELEMENT PERSONA (#PCDATA)>
<!ELEMENT GRPDESCR (#PCDATA)>
<!ELEMENT SCNDESCR (#PCDATA)>
<!ELEMENT PLAYSUBT (#PCDATA)>
<!ELEMENT INDUCT (TITLE, SUBTITLE*, (SCENE+|(SPEECH|STAGEDIR|SUBHEAD)+))>
<!ELEMENT ACT
(TITLE, SUBTITLE*, PROLOGUE?, SCENE+, EPILOGUE?)>
<!ELEMENT SCENE (TITLE, SUBTITLE*, (SPEECH | STAGEDIR | SUBHEAD)+)>
<!ELEMENT PROLOGUE (TITLE, SUBTITLE*, (STAGEDIR | SPEECH)+)>
<!ELEMENT EPILOGUE (TITLE, SUBTITLE*, (STAGEDIR | SPEECH)+)>
<!ELEMENT SPEECH (SPEAKER+, (LINE | STAGEDIR | SUBHEAD)+)>
<!ELEMENT SPEAKER (#PCDATA)>
<!ELEMENT LINE (#PCDATA | STAGEDIR)*>
<!ELEMENT STAGEDIR (#PCDATA)>
<!ELEMENT SUBTITLE (#PCDATA)>
<!ELEMENT SUBHEAD (#PCDATA)>
CSE.RU-1.35
CSE298
CSE300
XML Document Example - Data
<?xml version="1.0"?>
<!DOCTYPE PLAY SYSTEM "play.dtd">
<PLAY>
<TITLE>The Tragedy of Richard the Third</TITLE>
<FM>
Text placed in the public domain by Moby Lexical Tools, 1992.
SGML markup by Jon Bosak, 1992-1994.
XML version by Jon Bosak, 1996-1998.
This work may be freely copied and distributed worldwide.
</FM>
<PERSONAE>
...
</PERSONAE>
<SCNDESCR>SCENE England.</SCNDESCR>
<PLAYSUBT>KING RICHARD III</PLAYSUBT>
<ACT><TITLE>ACT I</TITLE>
...
</ACT>
......
</PLAY>
CSE.RU-1.36
CSE298
CSE300
DOM - Document Object Model





An application programming interface for HTML
and XML documents
Language-independent specification: defined in
OMG IDL
Language bindings for Java and ECMAScript
HTML or XML document <-> object tree
DOM (Core) Level1 and DOM (HTML) Leve1
CSE.RU-1.37
CSE298
CSE300
The DOM Structure Model


Interface Node and NodeList
Derived interfaces
 Document
 DocumentFragment
 DocumentType -- no children
 EntityReference
 Element
 Attr
 ProcessingInstruction --no children
 Comment -- no children
 CDATASection -- no children
 Entity
 Notation
CSE.RU-1.38
CSE298
CSE300
Portable Data/Portable Code



Sun Microsystem’s vision of XML technology
Project X
 Java Platform Standard Extension for XML
 Provide basic XML functionality to read,
manipulate, and generate text.
 Conform to the XML1.0 specification and
(DOM) Level 1 Core Recommendation
Conversion between Java Class/Bean and XML
document
 IBM’s BeanML
 Bluestone’s XwingML
CSE.RU-1.39
CSE298
CSE300
Conclusions - XML and Java, the Natural
Companions






XML’s markup and charater data are encode in
Unicode and Java intrinsically supports the
Unicode standard
XML structures map easily to Java object
structures
Both Java and XML are portable across platforms
Many XML components are already available for
Java, from parsers to XSL and Xlink engines
Many of the core standards for processing XML are
developed with Java in mind, I.e. DOM, SAX, etc.
Risks: security
CSE.RU-1.40
Java Database Support
A call-level interface:JDBC
CSE298
CSE300




Low Level, Invoke SQL Commands Directly
A Base Upon Which to Build Higher-level
Interfaces and Tools, such as
 SQLJ
 Java Blend
What does JDBC do?
 Establish a Connection with a Database
 Send SQL Statements
 Process the Results
Latest Update: JDBC 2.0 API
 Core API
 Standard Extensions
CSE.RU-1.41
Java Database Support
JDBC 2.0 API
CSE298
CSE300

New Features of JDBC Core API
 Scrollable Result Sets
 Result Sets that can be Updated
 Batch Updates
 SQL3 Data Type Support (SQL types ARRAY,
BLOB, CLOB, STRUCT, DISTINCT and REF)
 Custom Mapping of SQL3 User-Defined Types
to Java Classes
 Storing Java Objects in an Object-Relational
Database
CSE.RU-1.42
Java Database Support
JDBC 2.0 API
CSE298
CSE300

JDBC 2.0 API Standard Extension
 Rowset
 Establishing Database Connections Using
DataSource Objects and the Java Naming and
Directory InterfaceTM (JNDI)
 Connection Pooling
 Distributed Transactions
CSE.RU-1.43
CSE298
CSE300
Java Database Support
JDBC Product
A Distributed Object JDBC Architecture
OPENjdbc, the JDBC Driver for DataBroker
CORBA-based JDBC solution provides a complete
technology bridge from current to future IT solutions
CSE.RU-1.44
Java Database Support
Embedded SQL Statements:SQLJ
CSE298
CSE300



A Language that Embeds Static SQL in Java
Program
Specified by Oracle, IBM and Compaq's Tandem
Jointly, Accepted as ANSI Standard in December
1998
How Does SQLJ work?
CSE.RU-1.45
Java Database Support
SQLJ Features
CSE298
CSE300

Preceded by: #sql






#sql { UPDATE TAB SET COL1=:x WHERE COL2>:y AND
COL3<:z };
Provides Application Developers with a Higherlevel Programming Interface for Static SQL
SQLJ translator performs type-checking and
schema-checking of SQL statements at program
development time
SQLJ Runtime, a Thin Layer of Pure Java Code
above a JDBC Driver
Comprehensive Facilities
Database Independence
CSE.RU-1.46
Java Database Support
SQLJ and Oracle8i
CSE298
CSE300


Oracle Database Server -- Oracle8i
 Java virtual machine internal to the database
Oracle Extends Support for Standards Based SQLJ
 Implemented SQLJ into Oracle8i
 Supports Access to BLOB and CLOB Data
 Supports SQL Object Types in SQLJ Programs
through JPulisher tool
 Java Stored Procedures and Triggers
 Provides Access to Oracle Proprietary
Language PL/SQL
 Using SQLJ in Oracle8i EJB Server
 Oracel Java IDE -- JDeveloper
CSE.RU-1.47
CSE298
CSE300
Java Database Support
SQLJ Example
import java.sql.*;
import sqlj.runtime.ref.DefaultContext;
import oracle.sqlj.runtime.Oracle;
public class JDBCInterop {
#sql public static iterator Employees ( String ename, double sal ) ;
public static void main(String[] args) throws SQLException {
if (args.length != 1) {
System.out.println("usage: JDBCInterop ");
System.exit(1);
}
Oracle.connect(JDBCInterop.class, "connect.properties");
Connection conn =
DefaultContext.getDefaultContext().getConnection();
CSE.RU-1.48
Java Database Support
SQLJ Example
CSE298
CSE300
// create a JDBCStatement object to execute a dynamic query
Statement stmt = conn.createStatement();
String query = "SELECT ename, sal FROM emp WHERE ";
query += args[0];
// use the result set returned by executing the query to create
// a new strongly-typed SQLJ iterator
ResultSet rs = stmt.executeQuery(query);
Employees emps;
#sql emps = { CAST :rs };
while (emps.next()) {
System.out.println(emps.ename() + " earns " + emps.sal());
}
emps.close();
stmt.close();
}
}
CSE.RU-1.49
Java Database Support
ODMG Java Binding
CSE298
CSE300




Impedance Mismatch
Object Data Management Group (ODMG)
 Java Binding was Added to ODMG 2.0
 Applies to both ODBMS and RDBMS
Persistence by Reachability
Database Transparency
 Automatically Mapping between Database and
a Cache in the Application Memory
 Java Objects are Mapped into the Cache When
Application Navigates through them
 Database Tracks Java Objects in the Cache and
Write them back to Database at Transaction
Commit Time
CSE.RU-1.50
Java Database Support
ODMG Java Binding
CSE298
CSE300
Three-Tier Model
GUI
Application
Logic
Application
Logic
Object
Management
.
.
.
Client
Application
Logic
Database
Server
Object
Management
Application Servers
CSE.RU-1.51
Java Database Support
ODMG Java Binding Components
CSE298
CSE300



Java Object Definition Language (ODL)
 Define the Specifications of Object Types that
Conform to the ODMG Object Model
Java Object Manipulation Language (OML)
 Support the ODMG Object Model with
Collections, Transactions and Databases
Java Object Query Language (OQL)
 Provides Fast and Efficient Object-Querying
Capabilities in Java
 OQL Queries and Java Methods can call each
other interchangeably
CSE.RU-1.52
Java Database Support
ODMG Java Binding Product 1
CSE298
CSE300

Visual BSF from Objectmatter
 Object-relational Java Framework that Allows
Java Objects to be Easily Saved and Retrieved
from Relational Databases








Non-intrusive and Dynamic
Open Architecture
Complete Object Modeling
Legacy Database Integration
Security
Powerful Query Capabilities
Standards Based
Fast Performance
CSE.RU-1.53
Java Database Support
ODMG Java Binding Product 2
CSE298
CSE300

POET Object Server 5.0 from POET
 POET's Java SDK and SQL Object Factory
Adds Distributed and Enterprise Critical
Feature
 ODMG 2.0 Compliant Java API Binding
 Java Objects are Mapped to the POET Object
Database or a Relational Database at Runtime
 Transparent Java Object Persistence
 Multi-threading and Transaction Capabilities
 Tier Independent

Other Products
 Java Blend, Jasmine…
CSE.RU-1.54
CSE298
CSE300
Introduction to Enterprise JavaBeans

What is EJB?
 Server side component implementing business
logic
 wrapping DB
 wrapping existing application
 providing new business functions

Similar to Java Bean
 wrapped in ejb-jar
 visual deployment and management



Easy programming
Write once, run anywhere (client and server)
Reusable
CSE.RU-1.55
CSE298
CSE300
Multi-tier EJB Applications


Heavy-duty servers in the organizations
 Deployed over intranet
 Improved performance
 Improved manageability
 Easier maintenance
 In-control system upgrade
Thin clients
 GUI presentation
 Easy to download
 Possible built-in upgrading features
CSE.RU-1.56
CSE298
CSE300
High-level View of a Simple Scenario



Transparent invocation
Container-managed persistency
Transaction
CSE.RU-1.57
CSE298
CSE300
EJB Roles and Deployment
CSE.RU-1.58
CSE298
CSE300
Client’s View Contract



Contract between client and container
Fulfilled by both EJB provider and container
provider
Includes
 Identity
 Method invocation
 Home interface
 JNDI

Naming convention
Session Bean example:
 TraderBean
 Trader
 TraderHome
CSE.RU-1.59
CSE298
CSE300
SessionBean Example
public class TraderBean implements SessionBean {
public void ejbRemove() throws ... { ... }
public void ejbActivate() … { … }
public void ejbPassivate() ...
public void setSessionContext(SessionContext ctx) ...
public void ejbCreate () ...
public TradeResult buy( ... ) ...
public TradeResult sell( ... ) ...
public double getStockPrice(String stockSymbol) ...
}
public interface TraderHome extends EJBHome {
Trader create() …
}
public interface Trader extends EJBObject {
public TradeResult buy ( ... ) ...
public TradeResult sell ( ... ) ...
public double getStockPrice(String stockSymbol) ...
}
CSE.RU-1.60
CSE298
CSE300
Component Contract


Contract between Bean and container
Includes
 Bean class instance’s view of its lifecycle
 For session Beans, state management callback
methods invoked by container to notify of
important life cycle events



Context for communication between Bean and
container
Environment properties
Container provided services
 Transaction demarcation
 Security enforcement
CSE.RU-1.61
CSE298
CSE300
Ejb-jar File




Java classes for enterprise JavaBeans
 TraderBean.class, Trader.class,
TraderHome.class
Deployment descriptor
 TraderBeanDD.ser
Environment properties
Manifest file containing EJB entries
 example:
Name: …/TraderBeanDD.ser
Enterprise-Bean: True
CSE.RU-1.62
CSE298
CSE300
Container Intermediates
Method Invocation
CSE.RU-1.63
CSE298
CSE300
EJB Types


Session Bean
 Executes on behalf of a single client
 Can be transaction-aware
 Access shared data source
 Short-lived
Entity Bean
 Shared by multiple clients
 Representing data source
 Transaction-aware
 Long-lived
 Survives server crashes
CSE.RU-1.64
CSE298
CSE300
Stateful Session Bean Lifecycle
Transaction related restrictions:
 One TX at a time
 No invocation from outside the current TX
 No remove when in a TX
CSE.RU-1.65
CSE298
CSE300
Stateless Session Bean Lifecycle



Scalable
Minimized resources
Client gets more complex
CSE.RU-1.66
CSE298
CSE300
Entity Bean Lifecycle
CSE.RU-1.67
CSE298
CSE300
Concurrency, Transaction and Reentrant
CSE.RU-1.68
CSE298
CSE300
EJB Transactions Support





JTS -- Java mapping of OMG OTS
 Flat transaction
 Two-phase commit protocol
Declarative transaction attribute
 Class level
 Method level
Client-managed demarcation
 with begin and commit calls
 TX context is propagated to all servers
Bean-managed demarcation
Container-managed demarcation
CSE.RU-1.69
CSE298
CSE300
EJB Security Support







Compliant with JDK security package
User-based security
 EJBContext.getCallerIdentity() call
Role-based security
 EJBContext.isCallerInRole(Identity) call
AccessControlEntry in deployment descriptor
 Method level
 Class level
RunAsMode and RunAsIdentity
Deployer and system administrator can modify
security role using container tools
Restrictions apply
CSE.RU-1.70
CSE298
CSE300
Deployment Tools 1


Manage deployment descriptor attributes
Customize business logic
CSE.RU-1.71
CSE298
CSE300
Deployment Tools 2

Manage security attributes
CSE.RU-1.72
CSE298
CSE300
Deployment Tools 3

Manage transaction attributes
CSE.RU-1.73
CSE298
CSE300
Deployment Tools 4

Manage container-managed persistency
CSE.RU-1.74
CSE298
CSE300
Conclusions and Future Research


Conclusions
 Java’s extensibility and adherence to open
standards will continue to evolve as a robust
technology with which to build distributed
systems.
 Extensions to current specification will allow
newer technologies to be built upon existing
standards for even more powerful distributed
environments.
Future Research
 Keeping up with introductions of newer
specifications.
 Converging technologies.
CSE.RU-1.75