Client-Server Architecture & J2EE Platform Technologies Overview Ahmed K. Ezzat Page 1 of 14
Roadmap Client-Server Architecture Introduction Two-tier Architecture Three-tier Architecture The MVC Architecture J2EE Platform Technologies Overview Component Technologies Platform Roles Platform Services Service Technologies Communication Technologies Page 2 of 14
1. Client-Server Architecture 1.1 Introduction: A network application is distributed among two or more hosts. This brings the question of how should the functionality of the application be partitioned among hosts? There are two aspects for this question: technology reasons and how organizations administer their network computing infrastructure & networked applications. 1.2 Two-tier Architecture: There are two basic alternatives as shown in Figure (1). Client-Server architecture and Peer-to-Peer architecture: Peer-to-Peer architecture Client-Server Architecture Page 3 of 14
1.2.1 Client-Server Architecture: Client-Server application is based on some hosts are specialized to interact with clients/users (desktop), and others are Servers that are specialized to manage large data repositories, processing the data and logic specific to the application. This gives Client-Server architecture an asymmetry of function, where client makes requests and the server satisfies the client requests. C/S architecture is most suitable for information management applications that are published on a server. OLTP applications are good example of traditional C/S type application. 1.2.2 Peer-to-Peer Architecture: Is an alternative to C/S architecture. There are no servers, only desktop computers. This architecture is attractive for some direct-immediate social applications where no centralized logic is needed. P2P is natural for audio & video conferencing. A distinct attribute in P2P is the symmetry of function. In general, architecture can mix C/S and P2P architectures together. For example, many direct-immediate social applications involve an information management and multi-user interaction aspects. A desktop can be a Client or a Peer; it is the software that defines the role of the host in the application. 1.3 Three-tier Architecture: Fundamentally 2-tier architectures do not recognize the special needs of a class of organizational applications that incorporate mission critical databases. An example is OLTP applications. Page 4 of 14
It is desirable to integrate these mission critical databases into C/S applications without sacrificing their desirable qualities; this is the 3-tier C/S architecture: First tier is the Client/user Second tier: is the application server where the application logic resides Third tier: is the database where the critical shared data needed by different applications reside Presentation Application logic Critical shared Data Client Application Server(s) Database(s) Motivations for this 3-tier architecture include: The presentation: dedicated to a single user Application logic: supports multiple users. It is inexpensive to support more users by adding more App Servers. Critical shared data: support multiple applications. The 3-tier C/S architecture has many-to-one relationship at each level. Clearly 3-tier can scale better than 2-tier architecture, hides from the Page 5 of 14
client the explicit heterogeneous database support, and provides better support to different communication protocols. 1.4 The MVC Architecture: Model-View-Controller (MVC) application architecture (Smalltalk) is a popular model for analyzing features of distributed applications. This abstraction helps in breaking an application into logical components for easier/cleaner distributed implementation. MVC divides the functionality among objects involved in monitoring and processing data in order to minimize the degree of coupling between these objects and hence in mapping these objects on a multi-tier architecture. Originally MVC was used to decouple: input, processing, and output tasks to a local GUI user interaction model. However, it is simple to map this model to a multi-tier web/enterprise application. Method Invocation Event State Query Change Notification View * Renders the models * Requests updates from model * Sends user gestures to Controller * Allows Controller to select View Model * Encapsulates app state * Responds to state queries * Exposes app functionality * Notifies Views of changes View Selection User Gestures Controller State Change * Defines application behavior * Maps user actions to model updates * Selects View for response * One for each functionality Model: manipulate the data. The Model notifies View when the data change. It allows Controller to access the application functionality encapsulated by the Model. Page 6 of 14
View: renders the content of the Model. It can query the Model about data and specifies how it should be rendered. Controller: defines the application behavior. It maps user gestures to actions to be performed by the Model. In standalone GUI client, user gestures can be pressing a button. In a web environment, it can be HTTP GET/POST request to the web tier. Typically, there is one Controller for each set of related functionality. Page 7 of 14
2. J2EE Platform Technologies Overview J2EE platform specifies technologies to support multi-tier enterprise applications. This include: components, service and communication. 2.1 Component Technologies: A component is an application-level software unit with well defined interfaces, and typically executes in a container/runtime support. 2.1.1 Applets: is a client component that executes in its own JVM. The applet container provides the applet programming model. J2EE client may use the Java Plug-in to provide the applet execution environment. 2.1.2 Web Component: typically generates the user interface GUI for a web-based application. J2EE supports 2 types: Servlets and JavaServer Pages (JSP). Servlet: is a java program that extends the functionality of the web server. It receives request from a client, dynamically generates the response back to the client as HTML or XML documents. JSP: provides an extensible way to generate (static + dynamic) content for a web client. JSP provides a template for the generated web document. JSP elements & scriptlets generate the dynamic content part of the generated web document. JSP typically use JavaBeans and/or EJB components to do the processing required by the application. Both Servlet/JSP containers support HTTP for request/response. JSP container additionally provides an engine that interprets and process JSP pages into Servlets. Page 8 of 14
2.13 Enterprise JavaBeans Components: EJB is a server side component of an enterprise application. EJB is a transactional and multi-user secure component. There are two types of EJB components: Session beans and Entity beans. EJB components are hosted by a container. EJB container provides transaction, persistence, security service, and access to other J2EE APIs. 2.2 Platform Roles: J2EE defines several distinct roles in the application development and deployment life cycle. Some of these roles use J2EE services (Application component provider, Application assembler, and Deployer). 2.2.1 J2EE Product Provider: typically an OS vendor, database vendor, or a web server vendor. They provide the component container and additional J2EE specs. Product provider also provides the application deployment and management tools. 2.2.2 Application Component Provider: provides the building blocks (reusable components) of a J2EE application. They typically have the business domain knowledge. 2.2.3 Application Assembler: they take set of components developed by the Application providers and assemble them into a complete J2EE application. They don t need to be familiar with the source code of the components. 2.2.4 Deployer: specific operational environment expert. Responsible for deploying components/applications into the specific platform environment. Page 9 of 14
2.2.5 System Administrator: responsible for the configuration and administration of the enterprise s computing infrastructure. He will also be responsible for overseeing the runtime well-being of the deployed J2EE application. 2.2.6 Tool Provider: provides set of tools used for the development and packaging of the application components. 2.3 Platform Services: J2EE platform services simplify application programming and allow components/applications to be customized at deployment time. 2.3.1 Naming Service: provides the different J2EE components access to JNDI naming environment. A naming environment allows a component to be customized without the need to access or change the source code. A container implements the component s environment, and provides it as JNDI naming context. A J2EE component locates its environment naming context using JNDI interface. J2EE component can access both named system-provided objects (i.e., JTA UserTransaction object, etc.) and user-defined objects (i.e., JDBC DataSource objects, etc.). 2.3.2 Deployment Services: this service allows components & applications to be customized at the time they are packaged and/or deployed. The application is packaged as a JAR file with an *.ear extension. The application deployment descriptor contains a list of the application modules. Deployment Modules: J2EE applications are deployed as a set of modules/units and an application descriptor. J2EE module consists of Page 10 of 14
one or more J2EE components for the container type and one component deployment descriptor of that type. Deployment descriptor is an XML-based text file whose elements declaratively describe how to assemble, deploy, and customize the platform services (e.g., tx and security) for the corresponding component/module into a specific environment. A J2EE module without an application deployment descriptor can be deployed as a standalone J2EE module. J2EE defines 3 types of modules: EJB module: class files and EJB deployment descriptors. Web module: JSP files, class files for Servlets, GIF and HTML files, and a web deployment descriptor with a *.war extension. Application client module: class files and an application client deployment descriptor. Application client modules are packaged as JAR files with a *.jar extension. Roles in the Deployment Process: each J2EE platform role performs specific activities related to deployment: Application component provider: specify component deployment descriptor elements and package components into modules. Application assembler: resolves references between modules and assemble into a single deployment unit. Deployer: creates links between entities referred to by the application and entities in the deployment environment. Page 11 of 14
2.3.3 Transaction Services: J2EE platform supports only flat transactions. J2EE platform supports propagating transaction context between distributed components, and a transaction can span multiple resource managers. Transaction API: JTA transactions are created and managed using the javax.transaction.usertransaction interface. Different components access the UserTransaction object in different ways: EJB: container starts automatically the JTA service. Bean managed transactions use the method EJBContext.getUserTransaction to acquire a reference. Applets and Application Clients: depending on the container, they may or may not be able to access the UserTransaction object. Web Components: use JNDI to lookup the UserTransaction object. A resource manager local transaction is a transaction that access one EIS system. They are typically managed in a manner specific to the particular connection to the specific EIS system. For example, each SQL statement executed on a JDBC connection has its own transaction. Web components are not transactional. However, a web component may need to demarcate transactions using the UserTransaction interface. This may have limitations in the propagation and state isolation as follows: Tx can be propagated between web component and an EJB component only if the tx started by the web component. Web component can keep state for the lifetime of a client session. However, because web components are not Page 12 of 14
transactional, their state can t be isolated based on transactions. For example, separate Servlets will see the same state of a client session even if each Servlet starts their own transaction. 2.3.4 Security Services: ensures that resources are accessed only by authorized users. Access control involves two steps: Authentication: an entity must establish its identity (called principal). A principal can be a user or another program. Authorization: when an authenticated principal tries to access a resource, the system/container determines if the principal is authorized to do so based on the security policy in force in the application s security policy domain. 2.4 Service Technologies: The J2EE platform service technologies allow applications to access a wide range of services in a uniform manner. These services include access to: JDBC API: allows application component provider to perform connection & authentication to a database server, manage transactions, execute stored procedure, query the database. J2EE expects JDBC 2.0 Core API and the JDBC 2.0 Extension API (row sets, connection naming, connection pooling, and distributed transaction support). Java Transaction API (JTA) and Service (JTS): JTA allows applications to access transaction in a platform independent manner. JTS implements JTA, implements Java mapping to OMG/OTS 1.1. Java Naming and Directory Interface (JNDI): provides naming and directory functionality (associate attributes with objects, Page 13 of 14
search for objects based on their attributes). With JNDI, an application can store and retrieve any named java object. Java Connector Architecture (JCA): an API to connect J2EE components to a non-relational Enterprise Information System (EIS), like CRM, ERP, and mainframes. 2.5 Communication Technologies: Provides multiple mechanisms for communication between clients and servers, and between collaborating objects hosted by different servers. Protocols required by J2EE include: IP, RMI, OMG (Java IDL, RMI/IIOP), Messaging technologies (JMS, JavaMail, JavaBeans Activation Framework - JAF), and support multiple Data Formats (HTML 3.2, GIF, JPEG, JAR, *.class, XML). Page 14 of 14