系统架构设计

Web Application with Business component interfaces

       In most cases, J2EE is used to build web applications. Thus, a J2EE web container can provide the
entire infrastructure required by many applications.
        J2EE web applications enjoy virtually the same access to enterprise APIs as EJBs. They benefit from the
J2EE server's transaction management and connection pooling capabilities and can use enterprise services such as JMS, JDBC, JavaMail, and the Java Connector API. All data access technologies are available with the exception of entity beans.
     The web tier and middle tier of a web application run in the same JVM. However, it is vital that they
are kept logically distinct. The main design risk in web applications is that of blurred responsibilities between UI components and business logic components.
     The business interface layer will consist of Java interfaces implemented by ordinary Java classes.

 

 

Strengths
     This architecture has the following strengths:
             ❑ Simplicity. This is usually the simplest architecture for web applications. However, if transaction management or threading issues require the development of unduly complex code,it will probably prove simpler to use EJB.
            ❑ Speed. Such architectures encounter minimal overhead from the J2EE server.
            ❑ OO design isn't hampered by J2EE component issues such as the implications of invoking EJBs.
            ❑ Easy to test. With appropriate design, tests can be run against the business interface without the web tier.
            ❑ We can leverage the server's transaction support.
            ❑ Scales well. If the web interface is stateless, no clustering support is required from the container.
However, web applications can be distributed, using server support session state replication.

Weaknesses
       The following drawbacks should be kept in mind:
             ❑ This architecture supports only a web interface. For example, it cannot support standalone GUI clients. (The middle tier is in the same JVM as the web interface.) However, a layer of web services can be added, as we shall see later.
            ❑ The whole application runs within a single JVM. While this boosts performance, we cannot allocate components freely to different physical servers.
            ❑ This architecture cannot use EJB container transaction support. We will need to create and manage transactions in application code.
            ❑ The server provides no support for concurrent programming. We must handle threading issues ourselves or use a class library such as util.concurrent that solves common problems.
            ❑ It's impossible to use entity beans for data access. However, this is arguably no loss.

 

Web Application that Accesses Local EJBS

In this architecture, the web tier is identical to that of the web application architecture we've justconsidered. The business interfaces are also identical; the difference begins with their implementation,which faces the EJB tier. Thus the middle tier is divided into two (business interfaces running in the web container and EJBs), but both parts run within the same JVM.
Two approaches can be used to implement the business interfaces:
        ❑ A proxy approach, in which a local EJB implements the business interface directly   and webcontainer code is given a reference to the EJB's local interface, without needing to handle the
necessary JNDI lookup.
       ❑ A business delegate approach, in which the web-container implementation of the businessinterfaces explicitly delegates to the appropriate EJB. This has the advantage of permittingcaching and allowing failed operations to be retried where appropriate.
We don't need to worry about catching java.rmi.RemoteException in either case. Transport errors cannot occur.
In this architecture, unlike an architecture exposing a remote interface via EJB, the use of EJB is simplyan implementation choice, not a fundamental characteristic of the architecture. Any of the businessinterfaces can be implemented without using EJB without changing the overall design.
This is an effective compromise architecture, made possible by the enhancements in the
EJB 2.0 specification:

 

 

Strengths
     This architecture has the following strengths:
           ❑ It's less complex than a distributed EJB application.
           ❑ EJB use doesn't alter the application's basic design. In this architecture, only make thoseobjects EJBs that need the services of an EJB container.
           ❑ EJB use imposes relatively little performance overhead as there is no remote methodinvocation or serialization.
           ❑ It offers the benefits of EJB container transaction and thread management.
           ❑ It allows the use of entity beans if desired.

Weaknesses
       Its drawbacks are as follows:
           ❑ It's more complex than a pure web application. For example, it encounters EJB deployment and class loading complexity.
           ❑ It still cannot support clients other than a web interface unless we add a web services layer.
           ❑ The whole application still runs within a single JVM, which means that all components must run on the same physical server.
            ❑ EJBs with local interfaces are hard to test. We need to run test cases within the J2EE server(for example, from servlets).
           ❑ There is still some temptation to tweak object design as a result of using EJB. Even with local interfaces, EJB invocations are slower than ordinary method calls, and this may tempt us to modify the natural granularity of business objects.

 

 

Distributed Application with Remote EJBs
        This is widely regarded as the "classic" J2EE architecture. It offers the ability to split the middle tier physically and logically by using different JVMs for EJBs and the components (such as web components) that use them. This is a complex architecture, with significant performance overhead:

 

Strengths
     This architecture has the following unique strengths:
           ❑ It can support all J2EE client types by providing a shared middle tier.
           ❑ It permits the distribution of application components across different physical servers. This works particularly well if the EJB tier is stateless, allowing the use of stateless session EJBs. Applications with stateful UI tiers but stateless middle tiers will benefit most from this deployment option and will achieve the maximum scalability possible for J2EE applications.

Weaknesses
      The weaknesses of this architecture are:
           ❑ This is the most complex approach we've considered. If this complexity isn't warranted by the business requirements, it's likely to result in wasted resources throughout the project lifecycle and provide a breeding ground for bugs.
          ❑ It affects performance. Remote method calls can be hundreds of times slower than local calls by reference. The effect on overall performance depends on the number of remote calls necessary.
          ❑ Distributed applications are hard to test and debug.
          ❑ All business components must run in the EJB container. While this offers a comprehensive interface for remote clients, it is problematic if EJB cannot be used to solve every problem posed by the business requirements. For example, if the Singleton design pattern is a good fit, it will be hard to implement satisfactorily using EJB.
          ❑ OO design is severely hampered by the central use of RMI.
          ❑ Exception handling is more complex in distributed systems. We must allow for transport failures as well as application failures

Web Application Exposing Web Services Interface
        The emergence of web services standards such as SOAP means that J2EE applications are no longer tied to using RMI and EJB to support remote clients. The following architecture can support non-J2EE clients such as Microsoft applications:

This architecture differs from the distributed EJB architecture we've just described not only in remotingprotocol, but in that remote interfaces are typically added onto an existing application, rather than built into the structure of the application.

Strengths
         These are the strengths of this architecture:
                  ❑ SOAP is more open than RMI/IIOP. This architecture can support clients other than J2EEtechnology clients, such as VB applications.
                  ❑ Exposing a web services interface may be more beneficial for business than exposing an RMI/IIOP interface.
                  ❑ Web services transport protocols run over HTTP and are more firewall-friendly and humanreadable than RMI.
                  ❑ The delivery of remote access is an add-on that doesn't dictate overall architecture. For example, we can choose whether to use EJB, based on the best way of implementing anapplication, rather than how it will be accessed.

Weaknesses
         The weaknesses of this architecture are:
                 ❑ Performance. The overhead of passing objects over an XML-based protocol such as SOAP is likely to be higher than that of RMI.
                ❑ If all client types use J2EE technology, this architecture is inferior to a distributed EJB architecture. In such cases, there's little justification for using a platform-independent remoting protocol.
                ❑ Marshaling and unmarshaling of complex objects may require custom coding. Objects will be passed down the wire in XML. We may have to convert Java objects to and from XML.
                ❑ Even though SOAP is now widely accepted, there is currently no standardization of Java web services support comparable to the EJB specification.