Component Models II

Agenda Components, Take II Component Models Introduction

DCOM/MTS CORBAcomponent Model Enterprise JavaBeans

Java 2, Enterprise Edition architecture development

Component RationaleFrom: Component Primer, J. Hopkins, CACM V43N10

central idea: complex systems can be built from simpler components and glue

software want reuse of existing components to create easier to

maintain systems must be some well-built, applicable components to reuse must have a component model to support assembly and

interaction must be a process and architectures to support

component-based development (CBD)

Component Definition component as a refinement of OO techniques "component is a physical manifestation of an

object that has a well-defined interface and a set of implementations for that interface"

Component Communication components can communicate if they share a mechanism

for finding each other and sending messages a reference model is such a mechanism, providing means of

defining interfaces invoking functions exchanging data

XML (eXtensible Markup Language) may become the integration and data transfer mechanism

component becomes only dependent upon XML-formatted msgs for low-frequency, high semantic content exchanges e.g., purchase orders, patient records, complex requests

Components and Modeling UML has component modeling support provides component view of system traceability between class model, component model

and deployment model integration is key, so accurate models needed, esp.:

interface, state model, use cases otherwise, need access to source code must also support extension points

Component Granularity intercomponent communication is expensive

causes larger components larger components

more complex to understand more sensitive to change less flexible in allowing for replaceability

minimizing coupling works against good cohesion

existing apps are wrapped to look like components

Component Specificity specificity: how closely-related component is to

task for which it will be used more closely-related to task, less modification

required more specific yields more components

family of solutions helps address additional complexity

Components and the Present/Future

vision: net-based systems with large sets of services (interfaces) implemented in a widely distributed components supported by specialized vendors interconnected by platform-independent technology

like XML

Component Models explicit support for components, e.g.:

interface definitions location transparency dynamic assembly

model defines architecture of components component interfaces interaction with component execution environment

we’ll deal with server-side component models

DCOM & MTS DCOM: distributed component service MTS

Microsoft Transaction Server server-side component model

transaction management, concurrency, resource management, etc. property sheets change how business objects interact with services

proprietary platform stateless components only

high performance but limited flexibility

CORBA The non-proprietary distributed object service ORBs

language, platform, OS, communication independence but, developer had to code to complex, low-level API

CORBAcomponent Model (CCM) Enterprise Javabeans with language independence

Enterprise JavaBeans a standard server-side component model adaptable to existing products, e.g.:

naming servers transaction processing monitors DBMSes

wanted flexible integration and solid support for mission-critical app development

wanted to defuse fear of locking into a vendor

Java 2, Enterprise Edition: J2EE collection of core specifications and APIs to assist in

enterprise application development an approach to:

developing server-side components accessing infrastructure standardizing infrastructure functionality

used in conjunction with Java 2, Standard Edition language-specific features, but:

interfaces with objects written in other languages allows external access to its capabilities

J2EE: Primary APIsfrom: Applying Enterprise JavaBeans, V. Matena & B. Stearns, Addison-Wesley, 2001

Enterprise JavaBeans(EJB) server component model; provides infrastructure or

access to it JavaServer Pages (JSP) and servlets:

dynamic HTML generation and session management for browser clients

J2EE: Secondary APIs JNDI (Java Naming and Directory Interface)

access to various naming and directory services RMI-IIOP (Remote Method Invocation over

Internet InterOrb Protocol) access Java and non-Java objects

JDBC (Java DataBase Connectivity) uniform access to relational DBs

JTS (Java Transaction Service) access to distributed transaction services via CORBA OTS

JTA (Java Transaction API) explicit means of marking transaction boundaries

JMS (Java Messaging Service) access to asynchronous, reliable messaging systems

Enterprise Beans enterprise beans are components that

encapsulate business logic communicate with resource managers

e.g., DBMS, other enterprise beans clients access enterprise beans to use logic

clients can be application clients, other enterprise beans, web applications, servlets, etc.

at runtime, enterprise beans reside in containers containers provide deployment and runtime environment deployment is process of installing bean in container

Enterprise Application (EJB View) enterprise application consists of:

one or more enterprise beans either all in one container or in multiple containers

one or more non-enterprise bean components such as a browser client or a web application

client-view API provides consistent, location-transparent access to bean from any kind of client -- same API

Business Entities business entity is a business object

represents some information maintained by enterprise has state that is persisted, usually to a database

business rules constrain state maintain relationships among business entities

e.g., conditions for making and changing associations, the impact of deleting associations

Business Processes business process is a business object

encapsulates interaction of process user with business entities (a.k.a. workflow)

may change state of business entity may be persistent or transient

persistence used when multiple steps involved and possibly multiple actors

e.g., processing a loan application transience used when process can be completed by one

actor via one conversation (e.g., ATM withdrawal)

Business Rules implemented after identifying entities and processes those applying to state should be implemented in the

component representing that entity keeps business processes separate from state e.g., account entity handles preventing negative balances

those applying to process should be implemented in the component representing that process

e.g., ATM withdrawal process specifies withdrawals in units of twenty dollar bills

Enterprise Beans and Business Entities/Processes

beans represent business entities and processes types of beans and their typical application

session beans (EJB 1.1) conversational business processes

entity beans (EJB 1.1) all other business processes and most business entities

message beans (EJB 2.0) ???

different life cycles, persistence criteria, programming styles

Session Beans stateful or stateless (i.e., container-wise)

think “verb” stateful

retains state associated with client across multiple methods state does not persist -- goes away after timeout expires

e.g., shopping cart in web shopping process stateless

no client-specific/visible state retained across methods all state needed must be passed in or accessed from resources

like old procedures: do job, return result, forget state e.g., validating a credit card

Entity Beans always maintains state/persistence

think “noun” state must be:

loaded stored synchronized when changed after loaded

who does it? container: specifics in deployment information

CMP (Container-Managed Persistence) bean: specifics coded in bean

BMP (Bean-Managed Persistence)

Entity and Stateful Session BeansFunctional Area Session Bean Entity Bean

Object state container-managed inRAM, passivated whendeactivated

managed by resource(e.g., DBMS), oftencached in RAM

Object sharing one client per session object multiple clients per entityobject; can pass entityobject references

State externalization not externalized; knownonly to container and not toother programs

typically externalized toDB; other programs canaccess state

Transactions session object state can besynchronized withtransaction, but is notrecoverable

entity object state istypically synchronizedwith transaction and isrecoverable

Failure recovery not guaranteed to survivecontainer failure and restart;references to objectsbecome invalid

survives failure andrestart of its container;references to objects stillvalid after containerrestarts

Enterprise Beans and EJB goal: free developer from system-level concerns to

focus on business logic enterprise bean class:

implements business methods implements any bean object life cycle methods may use any other classes

enterprise bean client-view API home interface (life-cycle interface) remote interface (business method interface)

deployment descriptor declaration about bean and its environment

Naming Conventions enterprise bean class name:

business entity/process name and “Bean” suffix home interface

business entity/process name and “Home” suffix remote interface

business entity/process name name of enterprise bean as a whole

business entity/process name and “EJB” suffix Example:

Account (business entity), AccountBean, AccountHome, AccountEJB

Home Interface extends javax.ejb.EJBHome controls life cycle:

create (defined in enterprise bean class) find (defined in enterprise bean class) remove (inherited)

multiple create and find methods allowed find methods always start with “find”

e.g., findByPrimaryKey() session beans don’t have find methods

throw exceptions: RemoteException, CreateException, FinderException

Remote Interface extends javax.ejb.EJBObject defines business methods

must throw RemoteException arguments and return values must conform to RMI-IIOP

inherit getEJBHome() returns reference to object’s home interface getPrimaryKey() returns primary key associated with the

entity object (remote object must be entity bean) etc.

Enterprise Bean Class implements javax.ejb.xxxxBean

NOT remote interface! allows compile-time vs. runtime checking of interface

implementation of: life cycle methods defined in home interface business methods defined in remote interface container callback methods

e.g., ejbPassivate(), ejbLoad()

Deployment Descriptors as of EJB 1.1, tags in XML files part of an ejb-jar file, which defines EJB app declares behavior externally vs. inside code allows deployer to change way code works by

changing environment, including naming lists dependencies groups beans