This action might not be possible to undo. Are you sure you want to continue?
Chapter 1. Application Design Concepts and Principles Part I. Exam Objectives
Chapter 1. Application Design Concepts and Principles Explain the main advantages of an object oriented approach to system design including the effect of encapsulation, inheritance, delegation, and the use of interfaces, on architectural characteristics.
[JAVA_DESIGN] Chapter 1.
There are three major features in object-oriented programming: encapsulation, inheritance and polymorphism. 1. Encapsulation Encapsulation enforces modularity. Encapsulation refers to the creation of self-contained modules that bind processing functions to the data. These user-defined data types are called "classes," and one instance of a class is an "object." For example, in a payroll system, a class could be Manager, and Mikalai and Volha could be two instances (two objects) of the Manager class. Encapsulation ensures good code modularity, which keeps routines separate and less prone to conflict with each other. 2. Inheritance Inheritance passes "knowledge" down. Classes are created in hierarchies, and inheritance allows the structure and methods in one class to be passed down the hierarchy. That means less programming is required when adding functions to complex systems. If a step is added at the bottom of a hierarchy, then only the processing and data associated with that unique step needs to be added. Everything else about that step is inherited. The ability to reuse existing objects is considered a major advantage of object technology. 3. Polymorphism Polymorphism takes any shape. Object-oriented programming allows procedures about objects to be created whose exact type is not known until runtime. For example, a screen cursor may change its shape from
an arrow to a line depending on the program mode. The routine to move the cursor on screen in response to mouse movement would be written for "cursor," and polymorphism allows that cursor to take on whatever shape is required at runtime. It also allows new shapes to be easily integrated.
Open Closed Principle (OCP) Classes should be open for extension but closed for modification. The Open Closed Principle (OCP) is undoubtedly the most important of all the class category principles. In fact, each of the remaining class principles are derived from OCP. OCP states that we should be able to add new features to our system without having to modify our set of preexisting classes. One of the benefits of the object-oriented paradigm is to enable us to add new data structures to our system without having to modify the existing system's code base. One of the principle of OCP is to reduce the coupling between classes to the abstract level. Instead of creating relationships between two concrete classes, we create relationships between a concrete class and an abstract class, or in Java, between a concrete class and an interface. When we create an extension of our base class, assuming we adhere to the public methods and their respective signatures defined on the abstract class, we essentially have achieved OCP.
Liskov Substitution Principle (LSP) Subclasses should be substitutable for their base classes. We mentioned that OCP is the most important of the class category principles. We can think of the Liskov Substitution Principle (LSP) as an extension to OCP. In order to take advantage of LSP, we must adhere to OCP because violations of LSP also are violations of OCP, but not vice versa. In its simplest form, LSP is difficult to differentiate from OCP, but a subtle difference does exist. OCP is centered around abstract coupling. LSP, while also heavily dependent on abstract coupling, is in addition heavily dependent on preconditions and postconditions, which is LSP's relation to Design by Contract, where the concept of preconditions and postconditions was formalized. A precondition is a contract that must be satisfied before a method can be invoked. A postcondition, on the other hand, must be true upon method completion. If the precondition is not met, the method shouldn't be invoked, and if the postcondition is not met, the method shouldn't return. The relation of preconditions and postconditions has meaning embedded within an inheritance relationship that isn't supported within Java, outside of some manual assertions or nonexecutable comments. Because of this, violations of LSP can be difficult to find.
Dependency Inversion Principle (DIP)
Depend upon abstractions. Do not depend upon concretions. The Dependency Inversion Principle (DIP) formalizes the concept of abstract coupling and clearly states that we should couple at the abstract level, not at the concrete level. In our own designs, attempting to couple at the abstract level can seem like overkill at times. Pragmatically, we should apply this principle in any situation where we're unsure whether the implementation of a class may change in the future. But in reality, we encounter situations during development where we know exactly what needs to be done. Requirements state this very clearly, and the probability of change or extension is quite low. In these situations, adherence to DIP may be more work than the benefit realized. At this point, there exists a striking similarity between DIP and OCP. In fact, these two principles are closely related. Fundamentally, DIP tells us how we can adhere to OCP. Or, stated differently, if OCP is the desired end, DIP is the means through which we achieve that end. While this statement may seem obvious, we commonly violate DIP in a certain situation and don't even realize it. Abstract coupling is the notion that a class is not coupled to another concrete class or class that can be instantiated. Instead, the class is coupled to other base, or abstract, classes. In Java, this abstract class can be either a class with the abstract modifier or a Java interface data type. Regardless, this concept actually is the means through which LSP achieves its flexibility, the mechanism required for DIP, and the heart of OCP.
Interface Segregation Principle (ISP) Many specific interfaces are better than a single, general interface. Any interface we define should be highly cohesive. In Java, we know that an interface is a reference data type that can have method declarations, but no implementation. In essence, an interface is an abstract class with all abstract methods. As we define our interfaces, it becomes important that we clearly understand the role the interface plays within the context of our application. In fact, interfaces provide flexibility: They allow objects to assume the data type of the interface. Consequently, an interface is simply a role that an object plays at some point throughout its lifetime. It follows, rather logically, that when defining the operation on an interface, we should do so in a manner that doesn't accommodate multiple roles. Therefore, an interface should be responsible for allowing an object to assume a SINGLE ROLE, assuming the class of which that object is an instance implements that interface.
Composite Reuse Principle (CRP) Favor polymorphic composition of objects over inheritance. The Composite Reuse Principle (CRP) prevents us from making one of the most catastrophic mistakes that contribute to the demise of an object-oriented system: using inheritance as the primary reuse mechanism.
Inheritancecan be thought of as a generalization over a specialization relationship That is, a class higher in the inheritance hierarchy is a more general version of those inherited from it. In other words, any ancestor class is a partial descriptor that should define some default characteristics that are applicable to any class inherited from it. Any time we have to override default behavior defined in an ancestor class, we are saying that the ancestor class is not a more general version of all of its descendents but actually contains descriptor characteristics that make it too specialized to serve as the ancestor of the class in question. Therefore, if we choose to define default behavior on an ancestor, it should be general enough to apply to all of its descendents. In practice, it's not uncommon to define a default behavior in an ancestor class. However, we should still accommodate CRP in our relationships.
Principle of Least Knowledge (PLK) For an operation O on a class C, only operations on the following objects should be called: itself, its parameters, objects it creates, or its contained instance objects. The Principle of Least Knowledge (PLK) is also known as the Law of Demeter. The basic idea is to avoid calling any methods on an object where the reference to that object is obtained by calling a method on another object. Instead, this principle recommends we call methods on the containing object, not to obtain a reference to some other object, but instead to allow the containing object to forward the request to the object we would have formerly obtained a reference to. The primary benefit is that the calling method doesn't need to understand the structural makeup of the object it's invoking methods upon. The obvious disadvantage associated with PLK is that we must create many methods that only forward method calls to the containing classes internal components. This can contribute to a large and cumbersome public interface. An alternative to PLK, or a variation on its implementation, is to obtain a reference to an object via a method call, with the restriction that any time this is done, the type of the reference obtained is always an interface data type. This is more flexible because we aren't binding ourselves directly to the concrete implementation of a complex object, but instead are dependent only on the abstractions of which the complex object is composed. This is how many classes in Java typically resolve this situation.
Package Dependency If the contents of package A are dependent on the contents of package B, then A has a dependency on B; and if the contents of B change, this impact may be noticeable in A. Therefore, the relationships between packages become more apparent, and we can conclude the following: If an element in package A uses an element in package B, then package A depends on package B.
if a client wishes to utilize the services of a class. the service class is in a different package. applying it can be difficult because the only way that we can group classes together in this manner is when we can predictably determine the changes that might occur and the effect that those changes might have on any dependent classes. it's preferred that these two classes be placed in the same package. Conceptually. Functional cohesion emphasizes well-written methods that are more easily maintained. however. we can reference that class using the simple name. CCP may be easy to understand. Predictions often are incorrect or aren't ever realized. Because the package is deployed. Class cohesion stresses the importance of creating classes that are functionally sound and don't cross responsibility boundaries. emphasizing the overall services offered by entire packages. we can utilize the services offered by any public class within the package. our unit of release is our unit of reuse. The basis for the Common Closure Principle (CCP) is rather simple. Therefore. . but we must also explicitly make reference to the containing package. belong together. when a change to one class may dictate changes to another class. we must be sure the containing package is deployed. If. and it should now be apparent that the packages into which classes are placed have a tremendous impact on reuse. however. Whenever a client class wishes to use the services of another class. Consequently. resulting in the Release Reuse Equivalency Principle (REP). Adhering to fundamental programming best practices should take place throughout the entire system. to deploy any class. then any references to that class must be done using the class' fully qualified name. And package cohesion focuses on the classes within each package. we must reference the class offering the desired services. Careful consideration must be given to the allocation of classes to packages. not only must we reference the class. Therefore. the services of all classes are available to us.y Release Reuse Equivalency Principle (REP) The granule of reuse is the granule of release. which includes the name of the package. During development. This leads us to the basis for this principle. Regardless. While we may presently need the services of only a single class in the containing package. y Common Closure Principle (CCP) Classes that change together. Failure to do so results in compile-time errors. Any Java class may reside in only a single package. If the class offering the service is in the same package as the client.
placement of classes into respective packages should be a conscious decision that is driven not only by the relationships between classes. y Acyclic Dependencies Principle (ADP) The dependencies between packages must form no cycles. changing the behavior of any class within the service package has the potential to break the client. depending on CCP. separating a set of classes based on their likelihood to change together should be given careful consideration. In striving to adhere to CCP. Even if the client doesn't directly reference the modified class in the service package. . they may not always change together. then it is dependent on all classes in that package. If we need the services offered by a class. Whereas REP and Common Reuse Principle (CReP) emphasize reuse. Experience tells us that adhering to one of these principles may impact the ability to adhere to another. we also may utilize the services offered by any public class within the package. Of course. Packages should form a directed acyclic graph (DAG). albeit indirectly. It doesn't hold true that classes that are reused together should reside together. This principle has a negative connotation. this impacts REP because now multiple packages must be deployed to use this functionality. Cycles among dependencies of the packages composing an application should almost always be avoided. other classes in the service package being used by clients may reference the modified class. but also by the cohesive nature of a set of classes working together. we must import the package containing the necessary classes. when we import a package. CCP emphasizes maintenance. e can state the following: If a class is dependent on another class in a different package. y Common Reuse Principle (CReP) Classes that aren't reused together should not be grouped together. This creates indirect dependencies between the client and the modified class that can be the cause of mysterious behavior. In addition. Even though classes may always be reused together. As we stated previously in our discussion of REP (Release Reuse Equivalency Principle).
the should also be deployable as well. . Factoring out the classes that caused the cyclic dependencies has a positive impact on reuse: Acyclic Dependencies Principle (ADP) is important from a deployment perspective. Just as in the class design. Along with packages being reusable and maintanable. the easiest way to resolve them is to factor out the classes that cause the dependency structure.If we do identify cyclic dependencies. y Stable Dependencies Principle (SDP) Depend in the direction of stability. the package design should have defined dependencies so that it is deployment-friendly.
We can state the following: More stable packages. Therefore. Any packages containing all abstract classes with no incoming dependencies are utterly useless. On the other hand. should be heavily depended upon. These more stable packages are difficult to change because of the far-reaching consequences the change may have throughout all other dependent packages. packages with fewer incoming. the means through which we can depend in the direction of stability. Stability doesn't provide any implication as to the frequency with which the contents of a package change. Those packages with many incoming dependencies have many other components in our application dependent on them. and dependency management. A package with no incoming or outgoing dependencies is useless and isn't part of an application because it has no relationships. Combining the concepts of stability. frequency of change. we can extend these abstract classes and provide new system functions without having to modify existing system structure. and more outgoing dependencies. or interfaces. On the other hand. the degree of coupling to other packages has a dramatic impact on the ease of change. Consequently. o . are less stable. packages containing all concrete classes with many incoming dependencies are extremely difficult to maintain. o Packages likely to experience infrequent change may be more stable. or interfaces.Stability implies that an item is fixed. Those packages with few incoming dependencies most likely will have more outgoing dependencies. Stable Abstractions Principle (SAP) o y Stable packages should be abstract packages. packages with few incoming dependencies are easier to change. By coupling concrete classes to abstract classes. implying more incoming dependencies and fewer outgoing dependencies. Those packages having a tendency to change more often should be the packages that are less stable in nature. should not be heavily depended upon. is to place abstract classes. we're able to conclude the following: Packages likely to experience frequent change should be less stable. and it's in this direction that we should find the dependency relations flowing. and help ensure that these more depended-upon packages exhibit a higher degree of stability. in the more stable packages. Attempting to change an item that is stable is more difficult than inflicting change on an item in a less stable state. The high degree of resiliency and maintainability is achieved through abstract coupling. containing a higher number of abstract classes. and unvarying. containing a higher number of concrete classes. permanent. o Less stable packages. One of the greatest benefits of object orientation is the ability to easily maintain our systems. On the other hand. implying fewer incoming dependencies and more outgoing dependencies. Aside from poorly written code. packages unlikely to experience change may be more stable.
Application Design Concepts and Prev Next Principles The Java EE platform uses a distributed multitiered application model for enterprise applications. Application logic is divided into components according to function. Java EE multitiered applications are generally considered to be three-tiered applications because they are distributed over three locations: client machines. Tiers include client (both GUI and web). and the various application components that make up a Java EE application are installed on different machines depending on the tier in the multitiered Java EE environment to which the application component belongs. web (web container).Describe how the principle of "separation of concerns" has been applied to the main system tiers of a Java EE application. and the database or legacy . business (EJB container). integration. Web-tier components run on the Java EE server. Figure below shows two multitiered Java EE applications divided into the tiers described in the following list: y y y y Client-tier components run on the client machine. the Java EE server machine. Chapter 1. and resource tiers. Enterprise information system (EIS)-tier software runs on the EIS server. Although a Java EE application can consist of the three or four tiers. Business-tier components run on the Java EE server.
Also. services. Enterprise JavaBeans (EJB) components (enterprise beans) are business components that run on the server. Java EE applications are made up of components. such heavyweight operations are off-loaded to enterprise beans executing on the Java EE server.machines at the back end. speed. Thin clients usually do not query databases. XML. where they can leverage the security. Three-tiered applications that run in this way extend the standard twotiered client and server model by placing a multithreaded application server between the client application and back-end storage. and JavaServer Pages (JSP) technology components are web components that run on the server. o Web browser. When you use a thin client. Web components (Servlets. Java EE Clients y Web Clients A Web Client consists of two parts: o Dynamic web pages containing various types of markup language (HTML. However. JSF or JSP) are the preferred API for creating a web client program because no plug-ins or security policy files are needed on the client systems. A Java EE component is a self-contained functional software unit that is assembled into a Java EE application with its related classes and files and that communicates with other components. execute complex business rules. A web page received from the web tier can include an embedded applet. An applet is a small client application written in the Java programming language that executes in the Java virtual machine installed in the web browser. A Web Client is sometimes called a thin client. client systems will likely need the Java Plug-in and possibly a security policy file for the applet to successfully execute in the web browser. and reliability of Java EE server-side technologies. and so on). y Application Clients . The Java EE specification defines the following Java EE components: y y y Application clients and applets are components that run on the client. which are generated by web components running in the web tier. Personnel involved in web page design thus do not need to understand Java programming language syntax to do their jobs. JavaServer Faces. which renders the pages received from the server. Java Servlet. web components enable cleaner and more modular application design because they provide a way to separate applications programming from web page design. or connect to legacy applications.
keeping more functionality on the client can make for a better perceived user experience. The client communicates with the business tier running on the Java EE server either directly or. if application requirements warrant it. Servlets are Java programming language classes that dynamically process requests and construct responses. an application client can open an HTTP connection to establish communication with a servlet running in the web tier. by going through JSP pages or servlets running in the web tier. It typically has a graphical user interface (GUI) created from the Swing or the Abstract Window Toolkit (AWT) API. JavaServer Faces . the easier it is to distribute. and non-Java languages. and manage the application. Application clients written in languages other than Java can interact with Java EE 5 servers. clients.An application client runs on a client machine and provides a way for users to handle tasks that require a richer user interface than can be provided by a markup language. Application clients directly access enterprise beans running in the business tier. deploy. you should be aware of the trade-offs between keeping functionality on the client and close to the user (thick client) and off-loading as much functionality as possible to the server (thin client). Your Java EE application uses a thin browser-based client or thick application client. Web Components Java EE web components are either servlets or pages created using JSP technology (JSP pages) and/or JavaServer Faces technology. Figure below shows the various elements that can make up the client tier. however. enabling the Java EE 5 platform to interoperate with legacy systems. but a command-line interface is certainly possible. JSP pages are text-based documents that execute as servlets but allow a more natural approach to creating static content. as in the case of a client running in a browser. However. In deciding which one to use. The more functionality you off-load to the server.
processes it (if necessary). are not considered web components. Business Components Business code. and sends it back to the client program. like HTML pages. Static HTML pages and applets are bundled with web components during application assembly but are not considered web components by the Java EE specification. or finance. As shown in figure below. retail. the web tier. An enterprise bean also retrieves data from storage. processes it (if necessary). like the client tier. is handled by enterprise beans running in the business tier. . which is logic that solves or meets the needs of a particular business domain such as banking. Server-side utility classes can also be bundled with web components and. might include a JavaBeans component to manage the user input and send that input to enterprise beans running in the business tier for processing.technology builds on servlets and JSP technology and provides a user interface component framework for web applications. Figure below shows how an enterprise bean receives data from client programs. and sends it to the enterprise information system tier for storage.
Java EE Application A Java EE application is packaged into one or more standard units for deployment to any Java EE platform-compliant system. For example. Application Design Concepts and Prev Next Principles The image part with relationship ID rId19 was not found in the file. servlet. Each unit contains: y A functional component or components (enterprise bean. Java EE application components might need access to enterprise information systems for database connectivity. [JEE_5_TUTORIAL] Chapter 2. and the networking infrastructure layers. Chapter 1. enterprise services (operating system and virtualization). Layers include application. compute and storage. applet. etc. JSP page. virtual platform (component APIs).) . mainframe transaction processing. and other legacy information systems. Describe how the principle of "separation of concerns" has been applied to the layers of a Java EE application.The enterprise information system (EIS) tier handles EIS software and includes enterprise infrastructure systems such as enterprise resource planning (ERP). database systems. application infrastructure (containers). y y [JEE_5_TUTORIAL] Chapter 1.
Web modules are packaged as JAR files with a . such as a list of local users that can access it and the name of the local database.jar extension. and a web application deployment descriptor.xml extension that describes the deployment settings of an application. Using EAR files and modules makes it possible to assemble a number of different Java EE applications using some of the same components. Application client modules. Java EE 5 APIs . these implement the Connector architecture (J2EE Connector Architecture) for a particular EIS. Application client modules are packaged as JAR files with a . it is ready to be deployed. and other documentation.rar (resource adapter archive) extension. A deployment descriptor is an XML document with an . along with the resource adapter deployment descriptor. A Java EE application is delivered in an Enterprise Archive (EAR) file. or component accordingly. Once deployed on a local platform. which contain all Java interfaces. Web modules. A Java EE module without an application deployment descriptor can be deployed as a stand-alone module. module. the Java EE server reads the deployment descriptor and acts upon the application. An EAR file contains Java EE modules and deployment descriptors.y An optional deployment descriptor that describes its content Once a Java EE unit has been produced.war (Web ARchive) extension. a module. Together. native libraries. which contain class files for enterprise beans and an EJB deployment descriptor. No extra coding is needed. JSP files. declares transaction attributes and security authorizations for an enterprise bean. A Java EE module consists of one or more Java EE components for the same container type and one component deployment descriptor of that type. which contain class files and an application client deployment descriptor. EJB modules are packaged as JAR files with a . classes. Resource adapter modules are packaged as JAR files with an .jar extension. Because deployment descriptor information is declarative. the application is ready to run. At runtime. or a component. Resource adapter modules. The four types of Java EE modules are as follows: y y y y EJB modules. Deployment typically involves using a platform's deployment tool to specify location-specific information. supporting class files. it is only a matter of assembling (or packaging) various Java EE modules into Java EE EAR files. a standard Java Archive (JAR) file with an . GIF and HTML files.ear extension. it can be changed without the need to modify the source code. which contain servlet class files. An enterprise bean module deployment descriptor. for example.
is a body of code having fields and methods to implement modules of business logic. y JavaServer Pages Technology . or if the server shuts down. the persistence manager ensures that the entity data is saved. If the client terminates. they are commonly used to extend the applications hosted by web servers. the session bean and its data are gone. Although servlets can respond to any type of request. A servlet class extends the capabilities of servers that host applications that are accessed by way of a request-response programming model. A message-driven bean combines features of a session bean and a message listener. entity beans have been replaced by Java persistence API entities. or enterprise bean. A session bean represents a transient conversation with a client. An entity represents persistent data stored in one row of a database table.y Enterprise JavaBeans Technology An Enterprise JavaBeans (EJB) component. Commonly. allowing a business component to receive messages asynchronously. these are Java Message Service (JMS) messages. When the client finishes executing. y Java Servlet Technology Java servlet technology lets you define HTTP-specific servlet classes. You can think of an enterprise bean as a building block that can be used alone or with other enterprise beans to execute business logic on the Java EE server. There are two kinds of enterprise beans: session beans and message-driven beans. In Java EE 5.
A JSP page is a text-based document that contains two types of text: static data (which can be expressed in any text-based format such as HTML.JavaServer Pages (JSP) technology lets you put snippets of servlet code directly into a text-based document. The main components of JavaServer Faces technology are as follows: A GUI component framework. y JavaServer Faces JavaServer Faces technology is a user interface framework for building web applications. It enables distributed communication that is loosely coupled. you employ a single. receive. and asynchronous. tags for manipulating XML documents. and read messages. o o The following features support the GUI components: o o o o o Input validation Event handling Data conversion between model objects and components Managed model object creation Page navigation configuration All this functionality is available using standard Java APIs and XML-based configuration files. Instead of mixing tags from numerous vendors in your JSP applications. and commonly used functions. . A flexible model for rendering components in different kinds of HTML or different markup languages and technologies. y JavaServer Pages Standard Tag Library The JavaServer Pages Standard Tag Library (JSTL) encapsulates core functionality common to many JSP applications. standard set of tags. A Renderer object generates the markup to render the component and converts the data stored in a model object to types that can be represented in a view. WML. and XML) and JSP elements. y Java Message Service API The Java Message Service (JMS) API is a messaging standard that allows Java EE application components to create. internationalization tags. o A standard RenderKit for generating HTML/4.01 markup. JSTL has iterator and conditional tags for handling flow control. which determine how the page constructs dynamic content. This standardization allows you to deploy your applications on any JSP container that supports JSTL and makes it more likely that the implementation of the tags is optimized. reliable. send. tags for accessing databases using SQL.
and a service provider interface. and create the appropriate JavaBeans component to perform those operations.y Java Transaction API The Java Transaction API (JTA) provides a standard interface for demarcating transactions. y JavaBeans Activation Framework The JavaBeans Activation Framework (JAF) is included because JavaMail uses it. The Java EE platform includes JavaMail with a service provider that allows application components to send Internet mail. y Java API for XML Web Services (JAX-WS) The JAX-WS specification provides support for web services that use the JAXB API for binding XML data to Java objects. The JAX-WS specification defines client APIs for accessing web services as well as techniques for implementing web service endpoints. discover the operations available on it. rolls back. encapsulate access to it. and Extensible Stylesheet Language Transformations (XSLT). Simple API for XML (SAX). The Java EE architecture provides a default auto commit to handle transaction commits and rollbacks. An auto commit means that any other applications that are viewing data will see the updated data after each database read or write operation. However. part of the Java SE platform. y JavaMail API Java EE applications use the JavaMail API to send email notifications. . The EJB and servlet specifications also describe aspects of such deployment. JAXP enables applications to parse and transform XML documents independent of a particular XML processing implementation. if your application performs two separate database access operations that depend on each other. supports the processing of XML documents using Document Object Model (DOM). Designed to be flexible. including both operations. JAF provides standard services to determine the type of an arbitrary piece of data. begins. which lets you work with schemas that might otherwise have naming conflicts. JAXP lets you use any XMLcompliant parser or XSL processor from within your application and supports the W3C schema. It must be possible to deploy JAX-WS-based applications using any of these deployment models. The JavaMail API has two parts: an application-level interface used by the application components to send mail. y Java API for XML Processing The Java API for XML Processing (JAXP). and commits. The Web Services for J2EE specification describes the deployment of JAX-WS-based services and clients. JAXP also provides namespace support. you will want to use the JTA API to demarcate where the entire transaction.
developers can learn a single API and gain access to both of these important registry technologies. Standards groups have developed schemas for particular kinds of XML documents. two businesses might. JAXR supports the ebXML Registry and Repository standards and the emerging UDDI specifications. are treated in the same way as message handlers. these message handlers execute in the same container and with the same privileges and execution context as the JAX-WS client or endpoint component with which they are associated. if supported. y Java Architecture for XML Binding (JAXB) The Java Architecture for XML Binding (JAXB) provides a convenient way to bind an XML schema to a representation in Java language programs. Because a resource adapter is specific to its resource manager. both parties can use JAXR to access it. where it provides a standard data binding for web service messages. agree to use the schema for their industry¶s standard purchase order form. All Java EE application client containers. y Java API for XML Registries The Java API for XML Registries (JAXR) lets you access business and general-purpose registries over the web. Because the schema is stored in a standard business registry. Additionally. for example. By using JAXR. businesses can submit material to be shared and search for material that others have submitted. In general. web containers. and EJB containers support the JAXB API.The JAX-WS specification describes the support for message handlers that can process message requests and responses.1 specification and SOAP with Attachments note. y SOAP with Attachments API for Java The SOAP with Attachments API for Java (SAAJ) is a low-level API on which JAX-WS and JAXR depend. . instead using the higherlevel JAX-WS API. y J2EE Connector Architecture (JCA) The J2EE Connector architecture is used by tools vendors and system integrators to create resource adapters that support access to enterprise information systems that can be plugged in to any Java EE product. JAXB can be used independently or in combination with JAX-WS. Most developers do not use the SAAJ API. Custom serializers and deserializers. A resource adapter is a software component that allows Java EE application components to access and interact with the underlying resource manager of the EIS. typically there is a different resource adapter for each type of database or enterprise information system. These message handlers have access to the same JNDI java:comp/env namespace as their associated component. SAAJ enables the production and consumption of messages that conform to the SOAP 1.
You can also use the JDBC API from a servlet or a JSP page to access the database directly without going through an enterprise bean. Existing applications and EISs integrated through the J2EE Connector architecture into the Java EE platform can be exposed as XML-based web services by using JAX-WS and Java EE component models. scalable. enabling applications to access multiple naming and directory services. such as associating attributes with objects and searching for objects using their attributes. Persistence uses an object-relational mapping approach to bridge the gap between an object oriented model and a relational database. Java EE naming services provide application clients.The J2EE Connector architecture also provides a performance-oriented. It provides applications with methods for performing standard directory operations. secure. y Java Database Connectivity (JDBC) API The Java Database Connectivity (JDBC) API lets you invoke SQL commands from Java programming language methods. You use the JDBC API in an enterprise bean when you have a session bean access the database. and web components with access to a JNDI naming environment. enterprise beans. Thus JAX-WS and the J2EE Connector architecture are complementary technologies for enterprise application integration (EAI) and end-to-end business integration. A naming environment allows a component to be customized without the need to access or change the component's source code. The JDBC API has two parts: an application-level interface used by the application components to access a database. Java Persistence consists of three areas: The Java Persistence API The query language Object/relational mapping metadata Java Naming and Directory Interface (JNDI) o o o y The Java Naming and Directory Interface (JNDI) provides naming and directory functionality. allowing Java EE applications to coexist with many legacy applications and systems. and a service provider interface to attach a JDBC driver to the Java EE platform. and message-based transactional integration of Java EE-based web services with existing EISs that can be either synchronous or asynchronous. NDS. A container implements the component's environment and provides it to the component as a JNDI naming context. including existing naming and directory services such as LDAP. and NIS. Using JNDI. DNS. y Java Persistence API (JPA) The Java Persistence API is a Java standards-based solution for persistence. y Java Authentication and Authorization Service . a Java EE application can store and retrieve any type of named Java object.
which extends the Java Platform security architecture to support user-based authorization. it must be assembled into a Java EE module and deployed into its container. a client invokes methods on it as if it were in the same virtual machine. an enterprise bean can have security settings that allow it a certain level of access to database data in one production environment and another level of database access in another production environment. Container Services Containers are the interface between a component and the low-level platform-specific functionality that supports the component. The assembly process involves specifying container settings for each component in the Java EE application and for the Java EE application itself. Here are some of the highlights: y y y y The Java EE security model lets you configure a web component or enterprise bean so that system resources are accessed only by authorized users. The container also manages nonconfigurable services such as enterprise bean and servlet life cycles. Before a web. database connection resource pooling. After an enterprise bean is created. For example. The Java EE remote connectivity model manages low-level communications between clients and enterprise beans. application components within the same Java EE application can behave differently based on where they are deployed. JNDI lookup services provide a unified interface to multiple naming and directory services in the enterprise so that application components can access these services. data persistence. including services such as security. Communication Technologies Communication technologies provide mechanisms for communication between clients and servers and between collaborating objects hosted by different servers. Container settings customize the underlying support provided by the Java EE server. and access to the Java EE platform APIs. JAAS is a Java programming language version of the standard Pluggable Authentication Module (PAM) framework. or application client component can be executed. The J2EE specification requires support for the following types of communication technologies: . The Java EE transaction model lets you specify relationships among methods that make up a single transaction so that all methods in one transaction are treated as a single unit. Java Naming and Directory Interface (JNDI) lookups. and remote connectivity.The Java Authentication and Authorization Service (JAAS) provides a way for a Java EE application to authenticate and authorize a specific user or group of users to run it. Because the Java EE architecture provides configurable services. transaction management. enterprise bean.
RMI uses Java language interfaces to define remote objects and a combination of Java serialization technology and the Java Remote Method Protocol (JRMP) to turn local method invocations into remote method invocations. a library that enables CORBA objects to locate and communicate with one another. the basic protocol of the Internet. ORBs communicate with each other using the Internet Inter-ORB Protocol (IIOP). IP makes no guarantees as to whether the packet will be delivered. An application component provider defines the interface of a remote object in IDL and then uses an IDL compiler to generate client and server stubs that connect object implementations to an Object Request Broker (ORB). or if multiple packets will arrive in the order they were sent. Remote Method Invocation Protocols o y Remote Method Invocation (RMI) is a set of APIs that allow developers to build distributed applications in the Java programming language. These two protocols provide for the reliable delivery of streams of data from one host to another.Hypertext Transfer Protocol. The protocol allows client-server applications to communicate in a way that cannot be eavesdropped or tampered with. The Transport Control Protocol (TCP) adds the notions of connection and reliability.Secure Socket Layer. The Internet protocol used to fetch hypertext objects from remote hosts.y Internet protocols Internet protocols define the standards by which the different pieces of the J2EE platform communicate with each other and with remote entities. o Java IDL Java IDL allows Java clients to invoke operations on CORBA objects that have been defined using IDL and implemented in any language with a CORBA . CORBA objects are defined using the Interface Definition Language (IDL). y Object Management Group Protocols Object Management Group (OMG) protocols allow objects hosted by the J2EE platform to access remote objects developed using the OMG's Common Object Request Broker Architecture (CORBA) technologies and vice versa. Internet Protocol (IP). how long it will take.0 .Transport Control Protocol over Internet Protocol. the transport mechanism for communication between objects in the Java language in different address spaces. o SSL 3. The OMG technologies required by the J2EE platform are Java IDL and RMI-IIOP. enables the unreliable delivery of individual packets from one host to another. A security protocol that provides privacy over the Internet. Servers are always authenticated and clients are optionally authenticated. The J2EE platform supports the JRMP protocol.0 . HTTP messages consist of requests from client to server and responses from server to client. The J2EE platform supports the following Internet protocols: TCP/IP . o HTTP 1.
The Java client is linked with the stub and uses the CORBA API to access the CORBA object. o Java Message Service API The Java Message Service (JMS) API allows J2EE applications to access enterprise messaging systems such as IBM MQ Series and TIBCO Rendezvous. The remote interface can be converted to IDL and implemented in any other language that is supported by an OMG mapping and an ORB for that language. JMS is preferred when speed and reliability are a primary requirement. Clients and servers can be written in any language using IDL derived from the RMI interfaces. RMI-IIOP allows application component providers to write remote interfaces in the Java programming language. and transports. o JavaMail API The JavaMail API provides a set of abstract classes and interfaces that comprise an electronic mail system. or events that are consumed by enterprise applications. Although either API can be used for asynchronous notification. JMS messages contain well-defined information that describe specific business actions. y Data Formats Data formats define the types of data that can be exchanged between components. Many simple applications will only need to interact with the messaging system through these base classes and interfaces. The abstract classes and interfaces support many different implementations of message stores. The J2EE platform requires support for the following data formats: . The JavaMail API provides an interface for sending and receiving messages intended for users. RMI over IIOP provides interoperability with CORBA objects implemented in any language. Through the exchange of these messages. o RMI-IIOP RMI-IIOP is an implementation of the RMI API over IIOP. When remote interfaces are defined as Java RMI interfaces. Java IDL is part of the J2SE platform.mapping. applications track the progress of enterprise activities. An application component provider uses the idlj IDL compiler to generate a Java client stub for a CORBA object defined in IDL. The JMS API supports both point-to-point and publishsubscribe styles of messaging. The Java Message Service API provides an interface for handling asynchronous requests. It consists of a CORBA API and ORB. reports. y Messaging Technologies Messaging technologies provide a way to asynchronously send and receive messages. formats. JMS messages are used to coordinate these applications.
But unlike HTML.and consists of a stream of 8-bit bytes. Each class file contains one Java language type . When multiple applications share XML data.A text-based markup language that allows you to define the markup needed to identify the data and text in structured documents. HTML enables the embedding of images. In the same way that you define the field names for a data structure.o o o o o HTML . XML . references to other HTML documents. XML tags describe the data. they have to agree on the tag names they intend to use. a protocol for the online transmission and interchange of raster graphic data.The markup language used to define hypertext documents accessible over the Internet. As with HTML.The format of a compiled Java file as specified in the Java Virtual Machine specification. you are free to use any XML tags that make sense for a given application. video streams. JAR file . and basic text formatting. form fields. sounds.The J2EE platform supports two formats for image files: GIF (Graphics Interchange Format). Image files . . Class file . a standard for compressing gray-scale or color still images. rather than the format for displaying it. you identify data using tags.either a class or an interface . and JPEG (Joint Photographic Experts Group).A platform-independent file format that permits many files to be aggregated into one file. HTML documents have a globally unique location and can link to one another.
y Extensibility The ability to economically modify or add functionality. Can be improved through location independence of application code: . y Flexibility The ability to support architectural and hardware configuration changes. (time available) / (time possible) Example ± 201 seconds down/week. manageability. Is the key to an available. maintainability. This aspect of a system is often coupled with measures of its performance. performance. Common Architectures Part I. reliability. y Capacity The ability to run a number of jobs per unit time. and security. reliable. Capabilities y Availability The assurance that a service/resource is always accessible. Common Architectures Explain the advantages and disadvantages of two tier architectures when examined under the following topics: scalability. Exam Objectives Next Chapter 2. and scalable application. The ability to change architecture to meet new requirements in a cost-efficient manner. availability. extensibility.Prev Chapter 2.
English to German) ? o What must change to add a "fat client" for intense use ? o The effect of flexibility: y Manageability The ability to manage the system to ensure the continued health of a system with respect to the other capabilities. Metric example ± Number of staff hours per month to perform normal upgrades. y Reliability .Allows you to change what is affected by changing the presentation language (for example.
Performance o The ability to execute functions fast enough to meet performance goals. Identify and control access to expensive process and network boundaries: . Improving Reliability: Assume a web server has a Mean Time Between Failures (MTBF) of 100. Example ± Users will experience failed sessions no more than 1 time in 1000 attempts (99. State performance goals before implementing. Measurement is made at company external firewall.9 percent reliability). 95 percent of the time. o What is the reliability of the following ? o y Availability increases. Example ² first visible response in browser under maximum specified load occurs in less than 3 seconds.000 hours. Identify and control expensive calls.The ability to ensure the integrity and consistency of the application and all of its transactions. Response time is important to an application.
CPUs) to existing servers.y Scalability The ability to support the required quality of service as load increases: Vertical scalability comes from adding capacity (memory. o o Makes fewer demands on the architecture Is constrained by resource limits Horizontal scalability comes from adding servers: .
process enactment. dialog. Two Tier Software Architectures Two tier architectures consist of three components distributed in two layers: client (requester of services) and server (provider of services).y Distributed state. process monitoring. and process resource services) Database Management (such as data and file services) . load balancing All Web servers or all application servers must fail for a system failure to occur Security o o The ability to ensure that information is neither modified nor disclosed except in accordance with the security policy. y Testability The ability to determine what the expected results should be. text input. and display management services) Processing Management (such as process development. The three components are: y y y User System Interface (such as session.
The database management server usually provides the portion of the processing related to accessing data (often implemented in store procedures). The two tier architecture works well in relatively homogeneous environments with processing rules (business rules) that do not change very often and when workgroup size is expected to be fewer than 100 users. In general. It should be noted that connectivity between tiers can be dynamically changed depending upon the user's request for data and services. y Scalability The most important limitation of the two-tier architecture is that it is not scalable. the user system interface client invokes services from the database management server. It appears that beyond this number of users. It places database management on the server and splits the processing management between client and server. Implementing business logic in stored procedures can limit scalability because as more application logic is moved to the database management server. because each client requires its own database session. In many two tier designs. The two tier design will scale-up to service 100 users on a network. such as in small businesses. This is because the client and server exchange "keep alive" messages continuously. This design is used frequently in decision support systems where the transaction load is light. the performance capacity is exceeded. and this will ultimately reduce the number of users that can be accommodated.The two tier design allocates the user system interface exclusively to the client. the need for processing power grows. Two tier software architectures are used extensively in non-time critical information processing where management and operations of the system are not complex. Clients commonly communicate with the server through SQL statements or a call-level interface. y Interoperability . Each client uses the server to execute some part of its application code. thereby saturating the network. even when no work is being done. creating two layers. Two tier software architectures require minimal operator intervention. most of the application portion of processing is in the client environment.
k. This middle tier provides process management where business logic and rules are executed and can accommodate hundreds of users (as compared to only 100 users with the two tier architecture) by providing functions such as queuing. The three tier architecture is used when an effective distributed client/server design is needed that provides (when compared to the two tier) increased performance. The client is typically tied up until the batch job finishes. Moreover. and database staging. even if the job executes on the server. application execution. This means that to change or interoperate with more than one type of database management system. while hiding the complexity of distributed processing from the user. reliability. database management system's proprietary languages are generally not as capable as standard programming languages in that they do not provide a robust programming environment with testing and debugging.The two tier architecture limits interoperability by using stored procedures to implement complex processing logic (such as managing distributed database integrity) because stored procedures are normally implemented using a commercial database management system's proprietary language. Common Architectures The three tier software architecture (a. maintainability. version control. flexibility. and security. and scalability. every upgrade must be delivered. . The third tier (middle tier server) is between the user interface (client) and the data management (server) components. the batch job and client users are negatively affected. y System administration and configuration Two tier architectures can be difficult to administer and maintain because when applications reside on the client. Prev Next Chapter 2. and library management capabilities. three layer architectures) emerged to overcome the limitations of the two tier architecture. extensibility. Explain the advantages and disadvantages of three tier architectures when examined under the following topics: scalability. installed. reusability. availability. manageability. performance. thus. maintainability. and tested on each client. The typical lack of uniformity in the client configurations and lack of control over subsequent configuration changes increase administrative workload.a. applications may need to be rewritten. y Batch jobs The two tiered architecture is not effective running batch programs.
and replication. text input. maintainability. while hiding the complexity of distributed processing from the user. and scalability. A three tier distributed client/server architecture includes a user system interface top tier where user services (such as session. and display management) reside.The three tier architecture is used when an effective distributed client/server design is needed that provides (when compared to the two tier) increased performance. consistency. The data management component ensures that the data is consistent throughout the distributed environment through the use of features such as data locking. The third tier provides database management functionality and is dedicated to data and file services that can be optimized without using any proprietary database management system languages. . dialog. flexibility. reusability. It should be noted that connectivity between tiers can be dynamically changed depending upon the user's request for data and services.
and security. maintainability. and thereby improves scalability and flexibility as system components are added or moved. Explain the advantages and disadvantages of multi-tier architectures when examined under the following topics: scalability. availability. flexibility. extensibility.The middle tier provides process management services (such as process development. maintainability. Prev Next Chapter 2. a change to a function (service) would need to be written into every application. reliability. process monitoring. Centralized process logic makes administration and change management easier by localizing system functionality so that changes must only be written once and placed on the middle tier server to be available throughout the systems. Common Architectures . the middle process management tier controls transactions and asynchronous queuing to ensure reliable completion of transactions. reusability. and scalability by centralizing process logic. It provides access to resources based on names instead of locations. In addition. The middle tier manages distributed database integrity by the two phase commit process. and process resourcing) that are shared by multiple applications. The middle tier server (also referred to as the application server) improves performance. process enactment. performance. manageability. With other architectural designs.
a Java or other application. but they produce UI elements.A J2EE platform (and application) is a multitiered system. a network application. most business processing for the application is centralized into this tier. a Java applet. constructs the responses. A tier is a logical partition of the separation of concerns in the system. and delivers the responses to the client. The tier contains the business data and business logic. Servlets and JSP reside in this tier. Each tier is loosely coupled with the adjacent tier. a WAP phone. Typically. conducts session management. Enterprise bean components are the usual and preferred solution for implementing the business objects in the business tier. . due to legacy systems. y Business Tier This tier provides the business services required by the application clients. We view each tier as logically separated from one another. A client can be a Web browser. some business processing may occur in the resource tier. It could even be a batch process. Note that servlets and JSP are not themselves UI elements. we view the system in terms of tiers. y Presentation Tier This tier encapsulates all presentation logic required to service the clients that access the system. It is possible that. or some device introduced in the future. controls access to business services. The presentation tier intercepts the client requests. We represent the whole system as a stack of tiers: y Client Tier This tier represents all device or system clients accessing the system or the application. Each tier is assigned its unique responsibility in the system. provides single sign-on.
y Integration Tier This tier is responsible for communicating with external resources and systems such as data stores and legacy applications. A well-designed enterprise application must address these issues. when clients connect over the Internet. Prev Next Chapter 2. For example. or some proprietary middleware to work with the resource tier. which constrain how clients connect to an enterprise. it cannot be programmed as such because it is part of a distributed application. Bandwidth is finite. Client Considerations y Network Considerations The client depends on the network. The presence of a firewall that is . The business tier is coupled with the integration tier whenever the business objects require data or services that reside in the resource tier. y Security Considerations Different networks have different security requirements. they usually communicate with servers through a firewall. Explain the benefits and drawbacks of rich clients and browser-based clients as deployed in a typical Java EE application. business-to-business (B2B) integration systems. Although the client appears to be a stand-alone entity. The components in this tier can use JDBC. starting with the client. Common Architectures Explain the benefits and drawbacks of rich clients and browser-based clients as deployed in a typical Java EE application. and the network is imperfect. The network is not always reliable. The ideal client connects to the server only when it has to. and services such as credit card authorization. transmits only as much data as it needs to. J2EE connector technology. Three aspects of the network: o o o Latency is non-zero. and works reasonably well when it cannot reach the server. y Resource Tier This is the tier that contains the business data and external resources such as mainframes and legacy systems.
Rather. They are very similar to the stand-alone applications that run on traditional desktop computers. it should be restricted to items like the user's login and preferences for using the site. a server sends a browser client a key that identifies session data (using cookies or URL rewriting). so any sensitive information (passwords. and MIDlets. in which case Java Web Start technology takes care of downloading the appropriate files). but are less dependent than browser clients. servers should manage session state for browsers. these clients should not maintain session state. Encrypting the data stored on the client might solve this problem. If the browser caches any information beyond a session key. etc. When a user running Java Web Start requests the JNLP file (normally by clicking a link in a Web browser). such items do not need to be manipulated. y Application Clients Application clients execute in the Java 2 Runtime Environment. Both cookies and pages containing rewritten URLs are vulnerable to unauthorized access. They are typically more dependent on a server than are application clients. . although they can execute in other applications or devices that support the applet programming model. as long as the data is not intended for display. credit card numbers. Because of the limitations of caching session state on browser clients. Under this arrangement. Preparing an application client for Java Web Start deployment involves distributing its JAR with a Java Network Launching Protocol (JNLP) file. As such. Application clients are packaged inside JAR files and may be installed explicitly on a client's machine or provisioned on demand using Java Web Start technology. and they can be easily stored on the client.) they contain is vulnerable to abuse by anyone else who can access this data. Browsers usually retain cookies and pages in the local file system. Design Issues and Guidelines for Java Clients Java clients can be divided into three categories: applications. applets. thereby increasing the size of the response sent back to the client. they typically depend much less on servers than do browsers. contact information. y Applet Clients Applet clients are user interface components that typically execute in a Web browser. It then caches the files so the user can relaunch the application without having to download them again (unless they have changed. Java Web Start automatically downloads all necessary files. and the browser sends the key back to the server whenever it wants to use the session data.in its response (the HTML page). Standard Edition (JRE).
Java client interfaces offer a richer user experience. which contains the application's class and resource files. Java clients realize a more responsive interface because they do not have to download validation logic from the server. The Java client. Java clients can be programmed to make fewer connections than a browser to a server. In contrast.Like application clients. Implementing the user interface for a Java client usually requires more effort to implement than a browser interface. gets the data and nothing more. y MIDlet Clients MIDlet clients are small applications programmed to the Mobile Information Device Profile (MIDP). y Validating User Inputs Like presentation logic. Furthermore. two-way pagers. Accompanying the JAR file is a Java Application Descriptor (JAD) file. a set of Java APIs which. y Presenting the User Interface Java applet and application clients may use the Java Foundation Classes (JFC)/Swing API. the Java client consumes less bandwidth. with programmable GUI components. A MIDP application is packaged inside a JAR file. full programmability makes Java clients much more responsive than browser interfaces. provides a complete Java 2 Micro Edition (J2ME) runtime environment for cellular phones. Second. and perhaps more importantly. on the other hand. First. applet clients are packaged inside JAR files. but the benefits are substantial. which have more to gain than browser clients from client-side input validation. together with the Connected Limited Device Configuration (CLDC). When a Java client and a browser client request the same data. Standard Edition (instead of. input validation logic may also be programmed on Java clients. This technology allows applets to be run using Sun's implementation of the Java 2 Runtime Environment. when a browser requests a list of orders and a Java client requests the same list. This JAR file may be pre-installed on a mobile device or downloaded onto the device (usually over the air). However. a comprehensive set of GUI components for desktop clients. you can create more natural interfaces for the task at hand. and palmtops. a browser's default JRE). . which describes the application and any configurable application properties. the response is larger for the browser because it includes presentation logic. say. Recall that browser clients have to trade off the benefit of fewer connections (from detecting bad inputs before they get to the server) for the cost of using more bandwidth (from downloading validation code from the server). For example. applets are typically executed using Java Plug-in technology.
event responses into HTTP responses. Like browser clients. it is straightforward to write input validation logic. and HTTP is one of the few protocols most firewalls allow through. for example. and HTTP responses into view updates. o EJB Clients When using Web clients. Java Web clients connect over HTTP to theWeb tier of a J2EE application. Java Web clients carry out secure communication over HTTPS. you do not need to write such code because the clients . A side benefit of using XML messages is that alternate clients are easier to support. HTTP requests into application events.With Java clients. as XML is a widely-accepted open standard. where HTTP communication is typically the only way a client can reach a server. Binary messages consume little bandwidth. you must write code for translating user gestures into HTTP requests. Whereas browsers have built-in mechanisms that translate user gestures into HTTP requests and interpret HTTP responses to update the view. where every byte counts. You can use XML to encode messages from a variety of clients. when using EJB clients. These technologies. Many servers are separated from their clients by firewalls. or EIS clients (connecting to the EIS tier). EJB clients (connecting to the EJB tier). Java clients must be programmed to perform these actions. Java technologies for XML alleviate some of the burdens experienced with binary messaging. which include the Java API for XML Processing (JAXP). Unlike browser clients. could use a SOAP toolkit to make remote procedure calls (RPC) to a J2EE application. o Web Clients Like browser clients. Java clients may send and receive messages in any format. This aspect of binary messages is especially attractive in low-bandwidth environments (such as wireless and dial-up networks). A key consideration when implementing such actions is the format of the messages between client and server. A C++ client. This aspect of Web clients is particularly important on the Internet. On the other hand. y Communicating with the Server Java clients may connect to a J2EE application as Web clients (connecting to the Web tier). automate the parsing and aid the construction of XML messages.
it may be acceptable for clients to access the EIS tier directly. the exact behavior for installing EJB clients is not completely specified for the J2EE platform. Furthermore. to manipulate data on a remote resource. a simple Java program could perform maintenance on database tables and be invoked every night through an external mechanism. Java clients should not connect directly to a J2EE application's EIS tier. Java clients can manage session state on their own. such as for administration or management tasks. where the user interface is small or nonexistent and the task is simple and well understood. using an EJB client is not an option. so the client-side container and deployment mechanisms for EJB clients vary slightly from application server to application server. MIDlets cannot connect to the EJB tier because RMI is not a native component of MIDP. First. and most firewalls usually block communication using that protocol. and JTA APIs) and is provided by the application server vendor. it is harder to share among multiple types of clients. you should distribute it with a client-side container and install the container on the client machine. non-trivial EIS clients must implement business logic. Consequently. connecting as an EJB client is not always possible. you could use an EJB client within a company intranet. and the client container is responsible for providing the appropriate authentication mechanisms.) Second. because they can cache and manipulate substantial amounts of state in memory. So. (At this time.connect directly to the EJB tier using Java Remote Method Invocation (RMI) calls. only applet and application clients may connect as EJB clients. such as the JDBC API. For example. RMI calls are implemented using IIOP. This container (usually a class library) allows the client to access middle-tier services (such as the JMS. Because the logic is attached to the client. When this interface is misused (by a buggy client you have implemented or by a malicious client someone else has hacked or built from scratch). as would be the case over the Internet. y Managing Conversational State Whereas browser clients require a robust server-side mechanism for maintaining session state. when a firewall separates a server and its clients. Java clients have the . However. o EIS Clients Generally. EIS clients require a powerful interface. However. Unfortunately. your data can be compromised. JDBC. In some circumstances. When deploying an applet or application EJB client. Clients should be authenticated to access the EJB tier. where firewalls generally do not intervene between servers and clients.
In this case. The application could continue by asking the second user if he or she wants the seats that the first user did not buy. or requiring users to enter search queries at the beginning of each session. For example. The application needs rules and mechanisms for resolving such a conflict. they need to know about the model and some or all of the business rules surrounding the data model.gets the tickets.ability to work while disconnected. clients manipulating enterprise data must duplicate logic on the server. by filtering on user preferences. . but you can reduce this cost by constraining what gets downloaded. When Java clients manipulate enterprise data. The initial cost of downloading such data can be high. they also apply well to Java clients in general. Generally. which is beneficial when latency is high or when each connection consumes significant bandwidth. For another example. the server's data trumps the client's data because whoever buys the tickets first .and hence updates the server first . the client must also prevent users from trying to select booked seats. Many applications for mobile devices already use such strategies. enforcing a business rule also implemented on the server. When Java clients manipulate enterprise data. To support a disconnected operation. another user may buy some or all of those seats. the client must understand the concept of booked and unbooked seats. a Java client must retrieve enough usable data for the user before going offline. and model that concept just like the server does. it could refresh the second user's display with an updated seating plan and have the user pick seats all over again. between the time when the user downloads the seating plan and the time when the user decides what seats he or she wants to buy. applications need to implement data synchronization schemes. because the server must enforce all business rules regardless of what its clients do. For example. Or.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.