java Architecture tutorial

6 Sun recommendation: Java IDL should be used when accessing existing CORBA servers is the main purpose, whereas RMI-IIOP should be used when serving requests from CORBA clients is the main purpose. Development Process: Write interface in IDL, compile to Java (results in interface and several classes). Use interface in client programming. Descend server from generated ImplBase class (aka ‘implementation skeleton’). IDL-to-Java also generates ‘Stub’ class (client proxy), ‘Holder’ class (for out or inout parameters) and ‘Helper’ class (for narrowing and reading/writing). ORB interface (org.omg.CORBA.ORB) and implementations (e.g. com.sun.CORBA.iiop.ORB). Getting an ORB: static ORB.init. NamingContext in package org.omb.CosNaming. Object references: Temporary references (through proxy) and long-lived ‘stringified’ interoperable object references (IOR). JNI Java Native Interface (JNI) is a standard for linking Java to native programs written in other languages like C and C++. A good way to integrate a legacy application that is not written in Java into a distributed
Next Page
Previous Page



7

Design Patterns 1) State the benefits of using design patterns. Improves communication between designers by use of pattern names vs. the details of the patterns. Captures experience of solving a type of problem. Provide a way of reusing design. Provide a mechanism for making designs more reusable. Provides a mechanism for systematizing the reuse of things that have been seen before. Can be used to teach good design. 2) From a list, select the most appropriate design pattern for a given scenario. 3) State the name of a GOF design pattern given the UML diagram and/or a brief description of the pattern’s functionality. 4) Select from a list benefits of a specified GOF pattern. Identify the GOF pattern associated with a specified J2EE feature. Types of patterns Creational: Involved with the process of object creation. Structural: Deals with the composition of classes or objects. Behavioral: Characterize the ways in which classes or objects interact and distribute responsibility. Abstract Factory: (Creational) Provide an interface for creating families of related or dependent objects (products) without specifying
Next Page
Previous Page


EJB objects.

It isolates concrete classes. It makes exchanging product families easy. It promotes consistency among products. Supporting new kinds of products is difficult. Factory Method: (Creational) Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. J2EE technology uses this pattern for the EJB Home interface, which creates new EJB objects. Eliminates the need to bind application-specific classes into your code. Gives subclasses a hook for providing an extended version of an object being constructed. Prototype: (Creational) Specify the kinds of objects to create using a prototypical instance create new objects by copying this prototype Hides the concrete product classes from the client Allows adding and removing products at run-time Can specify new object by varying the values of an object’s variables. Singleton: (Creational) Ensure a class only has one instance, and provide a global point of access to it. Provides controlled access to a sole instance of a class.
Next Page
Previous Page


Permits a variable number of instances.

More flexible than static methods. Adapter: (Structural) Convert the interface of a class into another interface clients expect.


8 Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. Permits you to use an existing class that has an interface that does not match the one you need. You want to create a reusable class that cooperates with unrelated or unforeseen classes. The Object Adapter pattern can be used when you need to use several existing subclasses but it is impractical to adapt their interface by subclassing every one. Bridge: (Structural) Decouple an abstraction from its implementation so that the two can vary independently. Use when you want to avoid a permanent binding between an abstraction and its implementation. Use when both the abstractions and the implementations should be extensible by subclassing. Changes in the implementation should not impact clients. Composite: (Structural) Compose objects into tree structures to represent whole-part hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
Next Page
Previous Page


Allows clients to treat composite structures and individual objects uniformly.

Makes it easier to add new kinds of components. A disadvantage is that it can make a design overly general. Flyweight: (Structural) Use sharing to support large numbers of fine-grained objects efficiently. Decorator: (Structural) Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. In J2EE technology, The EJB object is a decorator for the bean because the bean’s functionality is expanded to include remote behavior. Proxy: (Structural) Provide a surrogate or placeholder for another object to control access to it. The EJB’s remote interface acts as a proxy for the bean. Proxy is also used in RMI. Façade: (Structural) Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use. Can use to achieve runtime binding without using inheritance. The Session Entity Façade pattern is a derivation of Façade that uses a Session bean as a façade for multiple Entity beans. Command: (Behavioral) Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. The Command pattern can be used to provide pluggable

Two options: Combine

Presentation with Business layer (Thick client), or some Business with DB layer (Thin client, use Stored Procs) Improved, graphical user interface More difficult to program because distribution, concurrency, transactions, security, resource management have to be understood and taken care of. The EJB architecture helps to reduce this overhead.


4 Single tier Two-tier Three- or Multi-tier Re-use difficult

A failure is a discrepancy between the desired or specified and the actual behaviour of a system.

Failures are external symptoms of faults (defects). Fault tolerance is the ability to prevent failures even when some of the system components have faults. The key to achieving fault tolerance is redundancy. Redundancy requires replication: Hot backup: Extra, live copies (replicas) of an object are serving client requests and synchronise continuously with the primary object. If the primary object fails, one of the copies takes over. Warm backup: Backup copies of an object run, but don’t serve clients. Synchronisation happens at certain, regular intervals. In case of a failure, a copy takes over from the last synchronisation point. Cold backup: The primary object synchronises with stable storage in certain intervals. In the case of a failure, a new object is instantiated and reads the storage for set-up. Fault handling includes service replication, fault detection, fault recovery, and fault notification. Fault detection is often done by using heartbeats (server sends periodical signal to monitor) or polling (monitor checks server once in a while). Fault handling in CORBA involves Replica Managers and Replica Service Agents. Active Replication: Every replica handles requests and replies. Interceptor has to block extra calls to third objects and extra responses (same as hot backup). Passive Replication: One primary replica handles requests and synchronises state with secondary replicas. Requests are also logged. For fail-over, a secondary replica becomes primary and processes all requests after the last synchronisation point (same as warm backup).
DNS Round Robin: Spreading incoming IP packets among a number of DNS addresses equally.

That means that each subsequent packet is sent to the next address in a list, until the end of the list is reached and the next packet is sent to the first address again. This is a simple load-balancing strategy. It does not take into account the actual load on the machines. Data Access Objects: Encapsulate the data access logic for a session bean or other component in a separate class. If you provide a common interface, multiple data access implementations can be provided, e.g. for different database systems. They simplify maintenance of code, make the path to CMP easier, and can be automatically generated by sophisticated tools. DAO’s are a bit like EJB’s, but don’t offer distributed access and transaction control. If these features are not needed, they are easier to use. There is a standard proposal for DAO’s called JDO (Java Data Objects). Legacy connectivity Options for integrating legacy systems include CORBA, RMI-IIOP, JNI, and Messaging. CORBA CORBA is a unifying standard for distributed object systems. CORBA is managed by OMG, and can be used with many platforms and languages. Disadvantages: Complex standard, slow-moving. In a CORBA architecture, objects communicate through ORBs, using IIOP as the protocol. Object Adaptor: Maps object references to implementations, activates object if necessary. Portable Object Adaptor (POA) now widely used. Repositories: Interface and implementation repositories are used by ORBs.
IDL: Interfaces are defined in the OMG IDL and can be compiled to a concrete language interface, e.g. Java, C, C++,COBOL, Ada, Smalltalk. IDL-to-Java Mapping defines details for Java. Invocation: Static invocation uses pre-compiled stubs and skeletons for a specific language and object. Dynamic invocation does not use stubs and skeletons, but discovers object and methods dynamically using the Dynamic invocation interface (DII) at the client and dynamic skeleton interface (DSI) at the server. There are similarities between DII and using COM’s IDispatch interface. Corba Object Services (COS): Naming, Event (asynchronous messages), Object Transaction Service (OTS), Concurrency control, Security RMI-IIOP Goal: Marry RMI and CORBA. Connect RMI clients to CORBA servers and vice versa. Benefits: Greater re-usability, legacy integration, robust firewall navigation. In the future support for transaction and security contexts can be added (new EJB/IIOP standard). Specification RMI-IIOP works with CORBA 2.3 ORBs. Required specs: Objects-by-value (IIOP does not traditionally support pass-by-value) and Java-to-IDL. Java-to-IDL mapping defines how RMI and IIOP work together and the necessary RMI restrictions that are known as RMI/IDL. The mapping enables Java-to-IDL compilers to be written that take a Java remote interface and produce a corresponding CORBA interface specification in IDL.
RMI Client OK OK Not possible

RMI-IIOP Client OK OK Restrictions apply CORBA Client Not possible OK OK EJB 1.1 mandates RMI-IIOP API to be present. However, there may still be two kinds of EJB servers: CORBA based and proprietary. The latter do not use CORBA, but implement communication differently (not using IIOP). Development changes Narrowing: Direct cast does not work on IIOP, PortableRemoteObject.narrow has to be used. In RMI direct cast works because Stub class can be loaded dynamically over the net. Two new packages for RMI-IIOP: javax.rmi (PortableRemoteObject) and javax.rmi.CORBA (internal) (Normal RMI package is java.rmi). No distributed garbage collection: Manually unregistering is necessary via unexportObject method. RMI-IIOP clients must use JNDI. RMI registries and COS Naming can be plugged into JNDI. Tools: Generation of RMI-IIOP stubs and skeletons: “rmic - iiop". IDL-to-Java compiler: “idlj”. Java-to- IDL-compiler: “rmi -idl”. Note: Making object public through both JRMP and IIOP at the same time is possible. Java IDL Java IDL embeds Java into the CORBA world. It includes a new Java IDL API (org.omg.CORBA, org.omg.CosNaming) and tools including an IDL-to-Java compiler (idltojava) and an ORB. The ORB includes the Java-to-IDL and Objects-by-Value specs (both mandated by CORBA 2.3 and lookup of parameters is possible.