Monday, June 11, 2007

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.