Java

java Architecture tutorial

2007-08-07T14:57:00.000+05:30

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

2007-06-11T12:23:00.000+05:30

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.

java Architecture tutorial

2007-04-18T12:36:00.000+05:30

Poor, tight coupling Difficult, data access and Integrity – Data can only be modified in allowed ways Privacy – Data is disclosed to authorized entities in authorized ways Auditability – The system maintains logs of actions taken for later analysis Scalability - the ability to support the required quality of service as the load increases Maintainability - the ability to correct flaws in the existing functionality without impacting other components/systems Reliability - the assurance of the integrity and consistency of the application and all of its transactions. Reliability spans from the OS to the Application to the service provided. Availability - the assurance that a service/resource is always accessible Extensibility - the ability to add/modify additional fuctionality without impacting existing functionality Manageability - the ability to manage the system in order to ensure the continued health of a system with respect to scalability, reliability, availability, performance, and security. Effects The following table outlines some inherent properties of common architectures. Single tier Two-tier Three- or Multi-tier Scalability Very limited Still limited, DB connections Good. Resource pooling possible, hardware can be added if and when need arises. Maintainabil business logic are mixed Good, layers can be changed independently. Reliability OK, Data consistency is simple because one storage Availability Poor, single point of failure Poor, DB server is still single point of failure Excellent with appropriate redundancy architecture. Extensibility Poor, tight coupling Difficult, data access and business logic are mixed. Code is dependent on DB schema. Good, layers can be changed independently. Performance OK Poor, DB Server can become bottleneck. Each client requires a connection, no pooling. High network bandwidth required, because all data has to travel to Good. Because the system is scalable, performance can be influenced by choosing the right system components. Bottlenecks can be removed at the relevant layer. Manageabilit y Relatively easy Poor, complex client installation and maintenance OK Security OK Problematic, because client has too much control. Good. Only certain services can be accessed, no direct database access. Firewalls and authentication and authorization systems help to further control access.

java Architecture tutorial

2007-04-11T19:22:00.000+05:30

Some rough guidelines:
More than 25 top-level classes will lead to problems Every use case should be able to be implemented using domain model methods J2EE supports extensibility because it is component-based and allows you to separate the roles of an app. JSPs can handle presentation. Servlets can handle routing, and EJBs can handle business logic. Performance Architectural performance is concerned with creating an architecture that forces end-to-end performance. The purpose of an architecture that ensures performance is to control expensive calls and to identify bottlenecks. If you know the boundaries of the various parts of the system, the technologies, and the capabilities of the technologies you can do a good job of controlling performance. You want to minimize the number of network calls your distributed app makes – make a few “large” calls that get a lot of data vs. lots of calls that get small amounts of data. Try to minimize process-to-process calls because they are expensive. Use resource pooling to reduce the number of expensive resources that need to be created like network connections, database connections, etc. Performance involves minimizing the response time for a given transaction load. While a number of factors relating to the application design can affect this, adding additional resources in the following two ways, or a combination of both, can be used to good effect: Vertical scaling, which involves creating additional application server processes on a single physical machine in order to provide multiple thread pools, each corresponding to the JVM associated with each application server process. Horizontal scaling, which Manageability
Manageability refers to the ability to manage a system to ensure the health of the system. A single tier or monolithic app would be more manageable from a management perspective than a multitier system but this must be weighed against the possibility of a change rippling through a monolithic app. A simple architecture may not be as flexible or available as a more complex system but the amount of effort required to keep the system up & functioning will be less. A component-based architecture like J2EE offsets some of the manageability problems caused by a multitier system. Security Security ensures that info is neither modified nor disclosed except in accordance with the security policy. Tradeoffs: personal privacy, ease of use, and expense.
3 A highly secure system is: More costly Harder to define and develop Requires more watchdog activities Principles of Security: Identity – The user is correctly ID’d thru an authentication mechanism

java Architecture tutorial

2007-04-11T19:20:00.000+05:30

2 Availability Availability is about assuring that services are available to the required number of users for the required proportion of time. Availability requires that the topology provide some degree of process redundancy in order to eliminate single points of failure. While vertical scalability can provide this by creating multiple processes, the physical machine then becomes a single point of failure. For this reason a high-availability topology typically involves horizontal scaling across multiple machines. Hardware-based high availability: By providing both vertical and horizontal scalability the WebSphere Application Server runtime architecture eliminates a given application server process as a single point of failure. In fact the only single point of failure in the WebSphere runtime is the database server where the WebSphere administrative repository resides. It is on the database server that any hardware-based high availability (HA) solutions such as HACMP, Sun Cluster, or MC/ServiceGuard should be configured. Extensibility Ability to modify or add functionality without impacting the existing functionality. The key to an extensible

java Architecture tutorial

2007-02-22T09:33:00.000+05:30

Common Architectures Scalability: Scalability is the ability to economically support the required quality of service as the load increases. Two types: Vertical and Horizontal Vertical: Achieved by adding capacity (memory, CPUs, etc.) to existing servers. Requires few to no changes to the architecture of a system. Increases: Capacity, Manageability Decreases: Reliability, Availability (single failure is more likely to lead to system failure) Vertical scalability is usually cheaper than horizontal scalability. J2EE supports vertical scaling because of automatic lifecycle management. Adding more capacity to a server allows it to manage more components (EJBs, etc.). Horizontal: Achieved by adding servers to the system. Increases the complexity of the system architecture. Increases: Reliability, Availability, Capacity, Performance (depends on load balancing), Flexibility Decreases: Manageability (more elements in the physical architecture) J2EE supports horizontal scaling because the container and server handle clustering and load balancing. Availability and reliability are obtained through scalability. Scalability affects capacity. The more scalable Next topic
manageability costs.
Maintainability How related is this to Flexibility? Flexibility is the ability to change the architecture to meet new requirements in a cost-efficient manner. A flexible system should be more maintainable in the face of changes to the environment and/or to the application itself. While maintainability is somewhat related to availability, there are specific issues that need to be considered when deploying a topology that is maintainable. In fact some maintainability factors are at cross purposes to availability. For instance, ease of maintainability would dictate that one minimize the number of application server instances in order to facilitate online software upgrades. Taken to the extreme, this would result in a single application server instance, which of course would not provide a high availability solution. In many cases it is also possible that a single application server instance would not provide the required. Flexibility improves: Availability, Reliability, Scalability Flexibility slightly decreases: Performance, Manageability Flexibility is achieved via code that can be distributed across servers with load balancing that prevents one system from being overburdened. The use of a multi-tier architecture also helps achieve flexibility. Reliability The ability to ensure the integrity and consistency of the application and all of its transactions. You increase reliability through the use of horizontal scalability, i.e., by adding more servers. This only works up to a certain point, though. When you increase reliability you increase availability. Next Page
Throughput, while related to performance, more precisely involves the creation of some number of
application server instances (clones) in order to increase the number of concurrent transactions that can be accommodated. As with performance, the application server instances can be added through vertical and/or horizontal scaling.