1 / 31

Component Models II

Component Models II. Agenda. Components, Take II Component Models Introduction DCOM/MTS CORBAcomponent Model Enterprise JavaBeans Java 2, Enterprise Edition architecture development. Component Rationale. From: Component Primer , J. Hopkins, CACM V43N10 central idea:

lgunn
Download Presentation

Component Models II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Component Models II

  2. Agenda • Components, Take II • Component Models Introduction • DCOM/MTS • CORBAcomponent Model • Enterprise JavaBeans • Java 2, Enterprise Edition • architecture • development

  3. Component Rationale From: 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)

  4. 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"

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. J2EE: Primary APIs from: 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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)

  21. 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

  22. 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

  23. 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

  24. 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)

  25. Entity and Stateful Session Beans

  26. 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

  27. 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

  28. 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

  29. 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.

  30. 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()

  31. 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

More Related