SEI/CBS Initiative Software Engineering Institute Carnegie Mellon University Pittsburgh, PA...

SEI/CBS Initiative

Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213-3890

Sponsored by the U.S. Department of Defense© 1999 by Carnegie Mellon University

Enterprise Java Beans - page 1

Enterprise JavaBeans™A COTS Architecture for Modern Enterprise Systems Kurt Wallnau•Robert Seacord•John Robert•Santiago Comella

© 1999 by Carnegie Mellon University SEI/CBS Initiative Enterprise Java Beans- page 2

Outline of Today’s Tutorial

Why Enterprise JavaBeans™ (EJB)?

An Overview of EJB

Security and Transactions

Portability and Legacy Systems

Summary and the Future of EJB

SEI/CBS Initiative




Why Enterprise JavaBeans™ ?


Why Enterprise JavaBeans™?

The Nature and Challenges of Enterprise Systems

Best of Breed vs. Off-the-Shelf Infrastructures

Closed vs. Open Infrastructures

Enterprise JavaBeans™ (EJB) Benefits

Technical/Market/Business Triangulation


What are Enterprise Systems?

Enterprise systems (ES) automate business processes, i.e., how work gets done

Enterprise systems are1 • large• heterogeneous• distributed• evolving• dynamic• long lived• mission critical• systems of systems

1. John Salasin, “DAMES: Dynamic Assembly of Military Enterprise Systems,” briefing materials


Challenges of Enterprise Systems

Large Requirements setting, costestimation, project management

Heterogeneous Platform interoperability, app.Portability, project tooling

Distributed Complex non-functionalbehavior, systems management

Evolving Predictable and cost-effectiveadaptation

Dynamic Safe, non-disruptive rollout ofnew system capabilities

Long-lived Technology upgrade, staffturnover

Mission critical Hard attributes: transactions,security, performance, etc.

System of systems Application interoperability,organizational ownership

ES Property ES Challenge


ES’s Are Big Business

Estimates of ES1 market in federal systems alone is currently $3.7 billion, up from 1998 estimate of $2.8 billion• BAAN, SAP, PeopleSoft and other enterprise

resource planning (ERP) systems are meeting this demand

• Software component technologies are another market response- Estimates of this market range from $7

billion by 20022 to $12 billion by 20013

1. http://www.planetit.com/techcenters/docs/enterprise_apps/news/PIT19990707S00032. Gartner Group3. IDC http://www.selectst.com/downloads/IDC/IDC.asp


Structure of an Enterprise System

Infrastructure

Platform (HW/OS)

Business Objects(Shared Data)

Business Logic

Clients

There are various ways of viewing enterprise systems• 2-tiered, 3-tiered, N-tiered• by infrastructure technology

This N-tiered view will serve our purposes for today


Structure of an Enterprise System

Infrastructure

Platform (HW/OS)

Business Objects (Shared Data)

Business Logic

Clients

• business rules• application services

• relational data• object-to-relation mapping

• distribution, events, naming,• transactions, security, etc.

Ou

r fo

cus

is h

ere

...


ES Infrastructures are Complex

NetworkingConnection mgmt

SecurityTransactionsThread Pool

SynchronizationPersistence

Infrastructure (e.g., Middleware)

Business Objects (Shared Data)

Business Logic

NamingSystem mgmt

The technical infrastructure needed for mission-critical applications is non-trivial

Load BalancingFailover


“Best of Breed” Infrastructure is Problematic: The GEE Experience

NetworkingConnection mgmt

SecurityTransactionsThread Pool

SynchronizationPersistence

NamingSystem mgmt

Netscape Browser & ES

Microsoft Explorer & IIS

Java Web Server

Visibroker/Java

OrbixWeb

JDK/RMI

Netscape DS

Microsoft IISJava Key

JSAFE

CRYPTIXSSLEAY

JCE

Visibroker/C++ ITS

Microsoft Access

Oracle 7.x and 8.x

ODBC/JDBC

Orbix NamesVisi Names

Netscape DSMicrosoft IIS

Load BalancingFailover


The GEE: Some Lessons

We built an enterprise infrastructure from COTS “parts” choice-points for product specific options• product selections limited by “ensemble effect”• latest versions of products often are often un-

integratable with previous ensemble• significant ongoing cost for product tracking and

evaluation of new releases• complex rules for build and deploy• product/technology insulation is very very hard • tremendous vertical and spanning product and

technology competency needed• product and technology competency is a wasting

asset


Infrastructure

Platform (HW/OS)

Clients

1.11.2

1.3

COTS ERP: Proprietary, Vertically-Integrated ES

Pro

pri

etar

y S

crip

tin

g a

nd

M

od

elin

g T

oo

ls

Pre-Integrated Infrastructure using vendor selected products and policies

Pre-specified business processes, process templates and data items


EJB: Specification for “Open” but Proprietary ES Frameworks

Infrastructure

Platform (HW/OS)

Clients

EntityBeans for Persistent Data

SessionBeans for Service Connections

Specification of security, persistence, life cycle, naming, transactions via server and container contracts

COTS Bean Families


COTS ERP vs. EJB: pros and cons+ Infrastructure bundled

with "best practice"processes

Infrastructure open for 3rd

party product lines inenterprise processes

+ Single vendor supportinga large customer base

Multiple vendorscompeting for samecustomers

+ Mature and stabletechnology base

New technologyincorporates new features

- Single vendor "lock-in" toproprietary interfaces

Specification not sharpenough to avoid "lock-in"

- Large, unwieldy packagewith arbitrary complexity

Significant customdevelopment still needed

- Potential for capriciousproduct evolution

Potential for capriciousspecification evolution

COTS ERP Package Enterprise JavaBeans™


Rationale for EJB?

Large Requirements setting,cost estimation,project management

N/A

Heterogeneous Platforminteroperability, app.Portability, projecttooling

JVM and now Java EnterpriseEdition define de facto platform

Distributed Complex non-functional behavior,systems management

Component model definesresource management rules

Evolving Predictable and cost-effective adaptation

Component model separatesbusiness from infrastructure

Dynamic Safe, non-disruptiverollout of new systemcapabilities

N/A

Long-lived Technology upgrade,staff turnover

Standard component model andserver/container contracts

Mission critical Hard attributes:transactions, security,performance, etc.

Transaction, security, resourcemanagement are built in to spec

System ofsystems

Applicationinteroperability,organizationalownership

N/A

ES Property ES Challenge EJB Benefit


To Bean or Not To Bean? (1)

Ultimately this will require consideration of technical, market and business pros and cons

Technical• + The J in EJB addresses heterogeneity• + Specification ties together a variety of ES

infrastructure services in a “standard” way• - The J in EJB may suffers from performance

problems and JVM bugs• - Not all services are sufficiently well defined to

enable cross-container bean portability


To Bean or Not to Bean? (2)

Market factors refer to the performance and viability of EJB in the technology marketplace:• + EJB may unify a fragmented “app server”

market, and jumpstart a market in servers and containers

• + EJB leverages tremendous interest in Java, and many EJB servers are now available

• - EJB is not “open”--Sun controls the spec, and its future evolution is unpredictable

• - Technology battle with Microsoft and fast Java evolution guarantee continued EJB instability


To Bean or Not To Bean? (3)

Business factors will be particular to each organization. These are representative pros/cons• + Organization is engaged in a general

switchover to Java technology, so why wait?• + Market in server/container providers provide

competitive alternatives and fallbacks• - Technology instability and immaturity will

cause delays, rework, risking added cost and delayed time to market

• - EJB vendors will continue to provide proprietary and non-standard features


The Remainder of the Tutorial

John Robert describes EJB in detail

Robert Seacord takes a more in-depth look at several aspects of EJB and discusses strengths and weaknesses found

Santiago Comella-Dorda discusses issues of Enterprise JavaBean portability and integration with legacy systems

Robert Seacord closes with a brief summary and some thoughts on the future of EJB

SEI/CBS Initiative




Enterprise JavaBeans™

Overview


EJB Overview

What is EJB?

EJB Roles

EJB Architecture

EJB Services

Building an EJB Application

EJB & CORBA

Summary


EJB in the n-Tier System

LegacyLegacySystemsSystems

ClientClientApplicationApplication

EJB Server

Clients Application Data

You Are Here

DatabaseDatabaseClientClientAppletApplet

Browser


What is EJB?

Specification for component based distributed computing framework using Java technology.

Enterprise JavaBeans Specification describes• roles and responsibilities for component-based

software development of server-side applications.

• an architecture including EJB Servers, Containers, and Beans.

• a set of services including naming, transactions and security.

• interoperability with database servers and CORBA applications.


EJB Specification

Evolving Technology• Release 1.0 - March 98, Final• Release 1.1 - May 99, Public Draft

Goals• Component-based software development.• Separate business logic from system code.• Address application life cycle.• Compatible with CORBA (non Java apps).

Specification owned by Sun and supported by 40+ companies.


EJB Roles

Bean Provider

ApplicationAssembler

Deployer

SystemAdmin.

Platform Provider

Ap

plicatio

n D

evelop

men

t and

Dep

loym

ent

- Producer of enterprise beans.

- Combines enterprise beans into larger deployable parts.

- Deploys enterprise beans into a specific operational environment.

- Container provider and server provider.

- Configuration and administration of infrastructure.


EJB Architecture

Picture provided by Sun Microsystems, Inc.

The container is the platform.The component is your application.


EJB Platform

Container

Manage EJ Bean life cycleMake EJ Bean Interfaces Available with JNDIProvide basic security servicesPersistence Management (DBMS and other)Manage transaction context

Provide naming service using JNDIProvide OMG/OTS compliant transaction service

EJB Server


EJB Platform Vendors

Select EJB complaint platform for purchase (1.0 or 1.1).

EJB Platform vendors supplement standard EJB with proprietary features.

Current Vendors include• BEA Systems - WebLogic• Bluestone - Sapphire/Web• IBM - WebSphere• Inprise - Application Server• Oracle - Oracle8i• Persistence - PowerTier • Sun/Netscape alliance - reference implementation


EJB Application

Enterprise Enterprise JavaBeans™ JavaBeans™ ComponentComponent

Application consists of multiple beansBeans are “portable” across containersBeans can be purchased or constructed


Types of Enterprise JavaBeans

Session Bean• Used for client interface• Not shared between clients• Two kinds of Session Bean:

- stateless - common object identity- stateful - unique object identity

Entity Bean• Maps to data in database or application• Shared between clients• Persistent state

- container managed - access defined at deployment- bean managed - access defined as part of bean

• Support optional in 1.0 and mandatory in 1.1


Entity Bean

Session Bean

Mixing Beans

EJB applications use a combination of entity beans and session beans to implement business logic.

Application Server

DatabaseDatabaseClientClient

Application Server

PrefixBean

SuffixBean

EchoServiceBean


EJB Client Interfaces

EJBHomeEJB

Home

EJBObjectEJB

Object

Factory InterfaceFinder Interface

Remote InterfaceContains bean services seen by clients


EJB Architecture


The purchased EJB server is the platform.The application consists of session and entity beans.Application interfaces are made available to clients at time of deployment.


Deployment

Deployment provides a mechanism for adapting a component for a specific runtime environment.

Deployment is an intermediate step between coding a bean and executing a bean. By using a deployment descriptor, some attributes of the bean implementation are specified by the deployer, and implemented by the platform provider.

Two kinds of information in a deployment descriptor• Enterprise beans’ structural information - can’t change• Application assembly information - can change

Deployment descriptor+ DeployBean

Platform SpecificImplementation

of Bean


EJB Overview

What is EJB?

EJB Roles

EJB Architecture

EJB Services


EJB & CORBA

Summary


EJB Services

Standard EJB services allow application developers to• focus on business logic rather than infrastructure• defer responsibility for common services to the EJB

platform• create “portable” applications that can be reused• support a component marketplace

Standard EJB services include• Persistence• Naming• Transactions• Security


Persistence

EJB Definition“The data access protocol for transferring the state of the entity between the enterprise bean instance and the underlying database is referred to as object persistence.”

Two types of persistence• bean-managed - persistence logic implemented directly

inside the enterprise bean class.• container-managed - persistence logic delegated to

container.

The underlying data source may be an existing application rather than a database.


Bean-Managed Persistence

Enterprise bean provider writes database access calls (using JDBC or SQLJ) directly in the entity bean.

Entity bean is tied to the data source in which the entity is stored.

More portable across EJB platforms than container-managed entity bean.

Bean• SQL code• persistence logic

Deployment Descriptor

persistence-type

DeployEntityBean

SQL codepersistence logic

+


Container-Managed Persistence

Data access components (like JSBC and SQLJ calls) are generated at deployment time by container tool.

Entity bean is independent from the data source in which the entity is stored.

Less development effort for bean provider.

Bean• generated SQL code• generated

persistence logic

Deployment Descriptor

persistence-typecmp-fields

DeployEntityBean

+


Name Service - Deployment

Benefits• EJB server has built-in name server.• Service name of bean is assigned at

deployment time, not compile time.• Some EJB servers support enterprise bean

replication.

E ch o S e rv iceH o m e

E ch o S e rv ice

d o m e s tic in te rn a tio n a l

O S C

DeployDeployment Descriptor

bean home name


Name Service - Lookup

Benefits• JNDI allows clients to use one interface for

locating CORBA, LDAP, NDS, and file objects. • Allows management of enterprise wide services

using naming hierarchy.

E ch o S e rv iceH o m e

E ch o S e rv ice

d o m e s tic in te rn a tio n a l

O S C

Runtime

MyClient

Context ct= getInitialContext(…)ct.lookup(“EchoService”)


Transactions


Benefits• EJB applications can defer transaction logic to

EJB server and container.• Distributed transactions.


Security

Benefits• Permissions specified for each bean service at

deployment time.• Builds on security of JDK.

Detailed discussion by Robert Seacord.

DeployDeployment Descriptor

security roles ...

Generated Bean Code• security logic




Application Server

How do we build an EJB application?


Step 1: Create Interfaces


EJB Server

Home I/F

Remote I/F

EJB specification

This is generated

You write this

Specifies the interface provided to bean clientspublic interface Accountextends EJBObject{ public getName(…) public setName(…)

Specifies the life cycle interfaces public interface AccountHomeextends EJBHome{ public create(…) public findByPrimaryKey(..)


Step 2: Create Implementation


EJB Server

Home I/F

Remote I/F

AccountEntityBeanimplements

EJB specification

This is generated

You write this

Implements bean interfacespublic class AccountBean implements EntityBean { public void ejbActivate(...) {………} public void ejbPassivate(…) {……….} public getName(…) {……..} public setName(…) {…….. }


Step 3: Deployment Descriptor


EJB Server

Home I/F

Remote I/F

AccountEntityBean

Deployment descriptor

implements

EJB specification

This is generated

You write this

“Tells” the container how to deploy the bean (how to do DBMS access, transactions, security, naming, etc.)


Step 4: Deploy


EJB Server

Home obj

Remote obj

Home I/F

Remote I/F

AccountEntityBean

Deployment descriptor

implements

implements

implements

delegates

EJB specification

This is generated

You write this


Entity Bean Inheritance - 1Java.rmi.Remote Java.io.Serializable JDK

EJBSpec

BeanProvider

(Wombat)

Producedby Acme

tools

ContainerProvider(Acme)

EJBMetaData EJBObject

EJBHome

EnterpriseBean

EntityBean

Extends or implements interface

Extends implementation, code generation or delegation



EJBSpec

BeanProvider

(Wombat)

Producedby Acme

tools


EJBMetaData

AccountHome

EJBObject

AccountBean

EJBHome

EnterpriseBean

Account

EntityBean





EJBSpec

BeanProvider

(Wombat)

Producedby Acme

tools


EJBMetaData

AccountHome

AcmeHome

AcmeAccountHome

EJBObject

AccountBean

AcmeRemote

AcmeRemoteAccount

EJBHome

EnterpriseBean

Account

AcmeMetaDataAcmeBean

AcmeAccountMetaData AcmeAccountBean

EntityBean




EJB & CORBA

EJB and CORBA are complimentary standards.

EJB uses CORBA for• Enabling non-Java clients to access EJB

applications.• Interoperability for EJB environments that

include systems from multiple vendors.

EJB-to-CORBA mapping (separate specification)• Mapping of EJB interfaces to RMI-IIOP.• Propagating transaction context.• Propagating security context.• Interoperable naming service.


Summary

The EJB architecture simplifies distributed application development by• providing pre-integrated solution

framework• separating the business logic from

distributed system services• providing standard services, including

naming, transactions, and security • managing life cycle functions


References

[1] Enterprise JavaBeansTM Specification Version 1.1

http://java.sun.com/products/ejb/docs.html

[2] Enterprise JavaBeansTM Specification Version 1.0

http://java.sun.com/products/ejb/docs10.html

[3] Enterprise JavaBeansTM Tools http://java.sun.com/javaone/javaone98/sessions/T402/index.htm


For More Information...

Telephone 412 / 268-5800Fax 412 / 268-5758Email [email protected]

[email protected]@[email protected]

World Wide Web http://www.sei.cmu.eduU.S. mail Customer Relations

Software Engineering InstituteCarnegie Mellon Pittsburgh, PA 15213-3890

SEI/CBS Initiative




EJB Security Management


Security Management OverviewThe enterprise bean class provider should not hard-code security policies and mechanisms into the business methods• allows appropriate deployment for the

operational environment of the enterprise

The application assembler may define • security roles for an application

- semantic grouping of permissions• method permissions for each security role

- permission to invoke a specified group of methods


Security Management Overview - 2

SecurityRoles

MethodPermissions

EJB

Bean Provider

ApplicationAssemblerDeployer

Users

Groups

SystemAdmins


Bean Provider’s Responsibilities

The bean provider should not implement security mechanisms or security policies in the enterprise beans’ business methods • rely instead on the security mechanisms

provided by the EJB Container

It is possible, however, to programmatically access a Caller’s Security Context...


Programmatically Accessing a Caller’s Security ContextTwo methods allow the bean provider to access security information about the enterprisebean’s caller•getCallerPrincipal •isCallerInRole

In general, security management should be enforced by the container • the security API should is used infrequently


Declaring Security RolesSecurity roles are declared in the deployment descriptor...<enterprise-beans><entity><ejb-name>WombatPayroll</ejb-name><ejb-class>com.wombat.PayrollBean</ejb-class><security-role-ref><description>This security role should be assigned to the employees allowed to update employees’ salaries.</description><role-name>payroll</role-name></security-role-ref></entity></enterprise-beans>…


Application Assembler’s ResponsibilitiesDefine security roles in the deployment descriptor <security-role>

<role-name> employee <description> allow employees to access their own data

Specify the methods of the remote and home interface that each security role is allowed to invoke<method-permission>

<role-name> employee

<ejb-name> WombatPayroll

<method-name> getEmployeeInfo

Link declared security role references to security roles <role-link> payroll-department (add to bean description)


Deployer’s Responsibilities

Ensures that an application is secure after it has been deployed in the operational environment

Assigns principals and/or groups of principals used for managing security in the operational environment to defined security roles• not specified in the EJB architecture!• specific to that operational environment

Can use the security view defined in the deployment descriptor merely as “hints”


EJB Container Provider’s ResponsibilitiesThe EJB container provider provides the implementation of the security infrastructure

A security domain can be implemented, managed, and administered by the EJB Server• e.g., the EJB Server may store X509 certificates

The EJB specification does not define the scope of the security domain• the scope may be defined by the boundaries of

the application, EJB Server, operating system, network, or enterprise


System Administrator’s ResponsibilitiesTypically responsible for • creating a new user account• adding a user to a user group• removing a user from a user group• removing or freezing a user account

Security domain administration is beyond the scope of the EJB specification...


Proceed with Caution…

InsecureSecure

EJB SpecificationEIS

EJB ServerVendor

Threats


Summary

The EJB architecture does not specify how an enterprise should implement its security architecture• assignment of security roles to the operational

environment’s security concepts is specific to the operational environment

• identification and authentication left to EJB Server vendor’s

Security will be vendor specific for some time• no plans to address problem in EJB 2.0


References

[1] Java Authentication and Authorization Service (JAAS)http://java.sun.com/security/jaas/.

[2] Java Cryptography Extension (JCE)http://java.sun.com/security/JCE1.2/spec/apidoc/index.html

SEI/CBS Initiative




EJB Transactions


Distributed Transactions

EJB allows application developers to write applications that atomically update data in multiple databases • may be distributed across multiple sites• sites may use EJB Servers from different

vendors

The enterprise Bean Provider and the client application programmer are not exposed to the complexity of distributed transactions.


ACID Properties

Atomicity. In a transaction involving two or more discrete pieces of information, either all of the pieces are committed or none are.

Consistency. A transaction either creates a new and valid state of data, or, if any failure occurs, returns all data to its state before the transaction was started.

Isolation. A transaction in process and not yet committed must remain isolated from any other transaction.

Durability. Committed data is saved by the system such that, even in the event of a failure and system restart, the data is available in its correct state.


Programmatic vs. Declarative Transaction Demarcation

Bean-managed transaction demarcation• enterprise bean code demarcates transactions

using javax.transaction.UserTransaction• accesses between UserTransaction.begin

and UserTransaction.commit calls are part of a transaction

Container-managed transaction demarcation• container demarcates transactions per

instructions provided by the Application Assembler in the deployment descriptor


Container-Managed Transaction DemarcationNotSupported - container invokes enterprise Bean method with an unspecified transaction context

Required - container invokes enterprise Bean method with a valid transaction context

Supports• If the client calls with a transaction context,

same as Required• If the client calls without a transaction context,

same as NotSupported


Container-Managed Transaction Demarcation - 2

RequiresNew - container invokes enterprise Bean method with a new transaction context

Mandatory - container invokes enterprise Bean method with the client’s transaction context

Never - container invokes an enterprise Bean method without a transaction context • client is required to call without a transaction

context


Isolation Levels

Describes the degree to which access to a resource manager by a transaction is isolated from other concurrently executing transactions

Part of the EJB 1.0 specification -- has been eliminated in EJB 1.1!• API for managing an isolation level is resource-

manager specific• bean provider may specify the same or different

isolation levels for each resource manager


Updates to Multiple Databases

DB A DB B DB C

Client X Y

Server

•Multiple databases •Single transaction


Updates to Multiple Databases in Same Transaction

DB A DB B

X

EJB Server

Y

EJB Serverclient


Updates to Multiples Databases on Multiple Servers

DB

TP

begin

commit

X

Y

EJB Server

EJB Server

client


Two-Phase Commit (2PC)

JDBC 1.2 does not support XA two phase commit• impossible for an EJB server using JDBC 1.2 to

directly support for distributed transactions

Distributed transactions requires the existence of database drivers that support XA 2PC• in most cases, developers are relying on the

vendor to provide database drivers


Relationship to JTA and JTS

Java Transaction API (JTA)

Java Transaction Service (JTS)



JTA specifies the interfaces between a transaction manager and the other parties involved in a distributed transaction processing system• application programs• resource managers• application server


Java Transaction Service (JTS)

Java binding of the CORBA Object Transaction Service (OTS) 1.1 specification Provides transaction interoperability using the standard IIOP protocol for transaction propagation between servers

Intended for vendors who implement transaction processing infrastructure for enterprise middleware• may be used by an EJB Server vendor as the

underlying transaction manager


EJB Relationship to JTA and JTS

Does not require the EJB Container to support the JTS interfaces

Requires that the EJB Container support the javax.transaction.UserTransactioninterface defined in JTA

Does not require support for• JTA resource manager (XAResource)• application server interfaces


Summary

Transaction-based systems can be implemented simply using EJB

Transactions are not simple -- transaction behavior is affected by choice of• session bean or entity bean• stateful or stateless session bean• bean-managed vs. container-managed

transaction demarcation• transaction attributes• lots more stuff!


References

[ 1 ] Java Transaction API (JTA). http://java.sun.com/products/jta.

[ 2 ] Java Transaction Service (JTS). http://java.sun.com/products/jts.

[ 3 ] OMG Object Transaction Service. http://www.omg.org/corba/sectrans.htm#trans.



Telephone 412 / 268-5800Fax 412 / 268-5758Email [email protected] Wide Web http://www.sei.cmu.eduU.S. mail Customer Relations


SEI/CBS Initiative




Integration of Legacy Software in EJB


Agenda

Types of legacy systems

Integrating legacy business logic

Integrating legacy data


Types of “Legacy” InfrastructuresData

• Mainframes

• Non-relational databases

• File systems...

Systems: Data + Logic (Niklaus Wirth)

• TP monitors, COBOL systems

• ERP systems

• CORBA and COM servers


Integrating Legacy Business LogicKeep and leverage investment

Access old system through a new interface

(Internet…).

Substitute the old code in an incremental way

- eliminating big-bang approach


Traditional Approaches

Legacy System

Function 1

Function 2

Internetserver

Screen

HTML

Screen ScrappingTerminal emulation…

CGIextension

Nativecomm.CGI

Script

New, pretty and Internet

aware System

Big- BangConversion

IT managercommitssuicide.


Traditional Approaches : Advantages & ProblemsScreen scrapping and terminal emulation• fast and “cheap” • plenty of support tools • the new system is as inflexible and hard to

maintain as the old one• it is just a “make up”

Big bang conversion • definitive solution• plenty of liberated IT resources are needed• the EIS must not be vital, a period of adaptation

to the new system must be admissible


Application Server Approaches

Legacy System

Function 1

Function 2

EJB Server

Internetserver

Service Broker

Screen

HTML

Nativecomm.

AdapterNativecomm.

Function 2bean

CGI orServlets

Applet

Wrapped functionality

Function 1bean

MessageService.


Adapter Strategy: Details

COBOL system

no state betweenfunctions

Function 1

Function 2

Green screen

terminal

Text only

EJB server

AdapterStatelessSession

Communication: error control,connection pooling,timing...

NOT_SUPPORTED

Func. 1StatelessSession

Func. 2StatelessSession

Workflow 1StatefulSession

Wrapper of Function 1If The COBOL system

enables rolling a function then NEW_REQUIRED

Text onlyWorkflow model.

If it involves more than one

function then NOT_SUPPORTED


Application Server Approaches : Advantages & ProblemsSometimes it is very difficult to divide the old monolithic system into discrete functions.

Legacy interfaces can be very hard to use. Text based communication, for example, is error prone.

Step by step approach.

Very good “effort / added-value” relation.

Straightforward approach with well defined steps.


Integrating Legacy Data: Why?

Cannot migrate the data • legacy systems may still use it.

Don’t want to replicate data for coherence and maintenance.

Data needs to be accessed from EJB applications• preferably in a transparent way, I.e. through Entity

beans.


XA

Legacy Data II: Present Approach

Mainframes,Relational DB,File systems,

OO databases.

JDBC Driver

ODBC Driver

Custom ResourceManager

Native Access

JDBC-ODBCBridge

Native

Access

Native Access

EJBServer

XA

JDBC

CUSTOM

“Regular”Container

“Specialized”Container

Transaction Manager

EntityBean

EntityBean

Native Access


Connector

Connector

Legacy Data III: Future Approach

Database

Connector

EJBServer

ContainerEntityBean

TransactionProcessor

ERP

Transactions

Security

Resource management

Native Access

Native Access

Native Access

Standardinterfaces


Connectors

Java SM Community Process Initiated• expert group being formed

Schedule for specification release not yet defined• not expected until at least 2000• implementations will follow

For more information contact: Rahul Sharma, Member of Technical Staff Sun Microsystems, [email protected]


Connectors: Advantages

Standard connection EIS resources and application servers.

No more proprietary and non-portable solutions like specialized containers.

Only covers the system level interfaces. Application level interfaces are still vendor specific.


Conclusions

Application servers in general, and EJB in particular, are powerful and smart ways to integrate legacy systems in modern EIS.

Every legacy integration effort includes risks. It is a difficult task that requires a great deal of expertise.

Other options like big-bang migration or screen scraping are more expensive or do not fully solve the problem.

SEI/CBS Initiative




Portability in EJB


Implementation vs. Standard (MTS vs. EJB)Implementation • Over-specification: every function, interface and

behavior is defined• Single vendor

Standard• Under-specification: different grades of

imprecision - compatibility test suites and reference

implementations can help portability• Multi-vendor environment brings competence

and innovation


Portability Is Not EJB’s Only Target

PortabilityCompatibility With

existing servers

Product differentiation


EJB Development Process

Component Market

Enterprise Bean Provider

E.Beans

GenericE. Beans

SpecializedE. Beans

Application templateMarket

ApplicationAssembler

1

23

EJB Deployer

Deployed application

Set of assembledE. Beans

Deployed E. Beans

EJB PlatformProvider

Ser

ver

&co

ntai

ner


When Portability is Important

Component vendors that want a broad-based

market for their components.

Application assemblers that want a large market

of pre-built components for reuse.

Application server providers that want to expand

the number of third-party components available

for their platforms.


When Portability is Not ImportantEnterprises that make a strategic decision to use a particular EJB server to take advantage of proprietary features.

Organizations that custom develop beans to meet non-negotiable requirements or to differentiate their application.

Application server providers that want to offer non-standard extensions as a business strategy.


Basic Structure of an Enterprise Bean

EJB Server

EJB Container

Enterprise Bean•Home•Remote interface•Bean•DDEB-Container

Contract

EB-Client

Contract

Server-ContainerContract

ClientJNDI...

PortabilityRelated


The Enterprise Bean Contracts

Source Code• API definition• Programming practices, rules and prohibitions

Deployment descriptor• XML based syntax• Defined set of attributes

Life cycle, transactional behavior….


Source Code Incompatibility

Different flavors of JPE APIs • JDK 1.1 vs. 1.2• RMI-CORBA mapping

Additional and proprietary APIs• XML• Security

Semantic differences• Objects passed by value• JNDI


Deployment Descriptor IncompatibilitySyntactic differences have disappeared with EJB 1.1’s XML-based descriptor.

There is a “standard core” set of deployment descriptor attributes.

Different servers add additional attributes to control specific capabilities• difficult to use only standard attributes• Compatibility problems in deployment

descriptors can affect the source code


Conclusions

Are EJB applications portable? • we could say that it is possible to make portable

EJB applications, but it requires some workarounds and developer guidelines.

Portability will increase with future releases of the standard • the holes in the standard will be gradually filled• EJB servers will more closely meet the standard • test suites and reference implementation will be

soon released.


Conclusions -2

Portability in EJB is an inversion. • Making portable EJB applications is harder than

using proprietary capabilities. • Is it worth the effort in your case?

SEI/CBS Initiative




Additional Slides (I will only use them for specific questions)


Resource Managers

They must provide:• The XA interface to make them transactional aware• A “custom” interface to access data

- JDBC is one of these “custom” interfaces- Can be used by bean-managed persistence or

container-managed if interface understood by container

• Pooling, concurrence and similar features implemented at this level


Resource Managers- 2

JDBC is a resource manager to access a special kind of legacy data: relational databases• There are JDBC native drivers for plenty of

databases: mainframes... • If not native version available ==> an ODBC driver

and a JDBC-ODBC bridge can be used.• Developing JDBC drivers is complex but all EJB

infrastructure can make transparent use of them.

There are other resource managers to access other kinds of data e.g., OO, file system, SAP.


Specialized Containers

If we want to use CM persistence, the container must

“know” the resource manager• Normal containers know JDBC sources,

sometimes plain file systems.• There could be other containers that know other

resources: ODMG sources, SAP R/3….- Versant Container to access the Versant ODBMS in

WebLogic- WebSphere to CICS


Different approaches:

• Traditional solutions: - Screen scraping, CGI extensions, “magic converters”….

- They meet only some objectives.

• Application server solutions- Adapters

- Service brokers

Legacy Programs

Middleware

SEI/CBS Initiative




EJB Roadmap


Java 2 Enterprise Edition

•Platform specification•Reference implementation (RI)•Application programming model (APM)•Compatibility test suite (CTS)


J2EE Status and Schedule

J2EE Platform Specification• Public Draft June 15• Public Release July 1999• Final Release December 1999

J2EE RI & CTS• Beta September 1999• FCS December 1999

J2EE APM document• Public Draft August 1999• Sample App Beta August 1999


Enterprise JavaBeans 2.0 SpecificationIntegration of Enterprise JavaBeans with the Java Message Service™ (JMS)

Improved support for entity beans persistence support for relationships among EJBs

Support for inheritance and subclassing of Enterprise JavaBeans

Query syntax for entity bean finder methodssupport for additional methods in the Home Interface

Mechanisms for container extensions EJB Server network interoperability protocol


Integration of EJB with JMS

JMS is an API for accessing enterprise messaging systems from Java programs.

JMS integration is needed to allow • Enterprise JavaBeans to be invoked

asynchronously from clients• EJBs to interoperate with legacy systems that

use JMS for integration• use of disconnected clients with Enterprise

JavaBeans• use of Enterprise JavaBeans within

publish/subscribe configurations.


Improved Support for Persistence for Entity Beans

Define a standard interface between the container and the persistent storage mechanism• insure that a bean developed on one EJB server

can be portably deployed in a different server environment with a different- persistent storage facility- set of tools- database

• enable tools to operate across the containers of multiple vendors


Support for Relationships among Enterprise JavaBeansThe bean provider in EJB 1.1 is responsible for• management of 1-1, 1-n, and m-n associations

among enterprise beans • management of relationships between

enterprise beans and their dependent objects

Capture information about relationships so that it can be made available at • deployment time • run time


Support for Inheritance and Subclassing of Enterprise JavaBeans

EJB currently supports class inheritance but not component inheritance

Subclassing of components being considered for EJB 2.0• unclear how object persistence will be

implemented• practical advantages unclear


Query Syntax for Entity Bean Finder Methods Define a format for specifying the query criteria or the selection predicates that are to be used by finder method implementations• support the definition of portable finder

methods


Mechanisms for Container Extensions

Interceptors are methods the container invokes during the bean invocation protocol • provides a portable means for specializing the

behavior of the container for specific operational environments

• reduces the need for specialized containers


Support for Additional Methods in the Home InterfaceCurrently no means for adding methods independent of individual bean instances (other than create and finder methods)• home methods are similar to static members in

traditional OO• can be used, for example, to support bulk

update operations


EJB Server Network Interoperability Protocol Movement towards requiring RMI/IIOP

Complete the mapping of EJB via RMI/IIOP by specifying support for interoperable security and naming • supports network interoperability among

CORBA-based EJB server implementations


Not Planned for EJB 2.0

Portable, security solution• vendors must implement their own custom

solutions


EJB Release Schedule

Release 1.0• March 98, Final

Release 1.1• May 99, Public Draft• Q3 99, Public Release• Q4 99, Final Release

Release 2.0• Year 2000

SEI/CBS Initiative




EJB Summary and Conclusions


EJB Summary

EJB server implementations lag behind proprietary application servers in• support for distributed transactions• security

EJB supports development of “Write Once, Run AnywhereTM” Java applications• issues exist porting between EJB servers


What are the Alternatives?

Microsoft Transaction Server (MTS)Vendor suites• database vendors (I.e., Oracle, Sybase)• transaction manager (I.e., BEA Tuxedo)• Web vendors (I.e., Netscape)

Custom integration of Java technologiesEnterprise Resource Planning (I.e., SAP, PeopleSoft, Baan, IBM San Francisco)


Microsoft Transaction Server (MTS)Microsoft proprietary solution• only runs on Windows NT• based on the Component Object Model (COM)• interfaces to broad range of databases• Active directory, security and clustering

extensions added in Windows 2000

Efficient, low-cost solution on Microsoft platform• “feel the power of the dark side of the force”


Vendor Suites

Application servers that do not adhere to an EJB specification• application programming language usually C++

but may also be Java• typically provides support for distributed

transactions, security, failover, replication• database, transactions, Web vendors have

different strengths

Allows the development of large, complex enterprise systems• risk of vendor lock


Custom Integration

Best-of-breed integration of components• control own architecture• allows flexibility in selection of components

that meet specific requirements• components can be incrementally upgraded

Greater degree of control and flexibility but• requires greater expertise in infrastructure

technologies• greater investment in time and $$$• integrating products from different vendors can

be problematic


Enterprise Resource Planning (ERP)Vertically integrated domain-specific frameworks• includes business processes• often difficult to integrate with legacy systems• usually does not consist of the latest and

greatest technologies

Offers business solution• may require the adoption of business

processes• trades flexibility for complete solution


Conclusion

EJB can be used to build scalable, platform-neutral, multi-tier applications, but only if you avoid product-specific features

EJB is still rapidly evolving -- look for stability elsewhere

EJB is the keystone of Sun’s Java 2 Enterprise Edition

SEI/CBS Initiative Software Engineering Institute Carnegie Mellon University Pittsburgh, PA...

Documents

Transcript of SEI/CBS Initiative Software Engineering Institute Carnegie Mellon University Pittsburgh, PA...