Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this


  1. 1. J2EE - ENTERPRISE DEVELOPMENT AND INTEROPERABILITY WITH NON-J2EE CLIENTS presented by Sudha Balla, Betsy Cherian and Lance Fiondella Semester Project CSE333 – Distributed Component Systems (FALL 2002) Instructor Prof. Steven A. Demurjian Department of Computer Science and Engineering University of Connecticut [email_address] [email_address] [email_address]
  2. 2. Organization of presentation <ul><li>Introduction and Motivation(Lance) </li></ul><ul><li>Server-side component architectures(Sudha) </li></ul><ul><li>J2EE Platform overview(Lance) </li></ul><ul><li>J2EE Standardized Services(Betsy) </li></ul><ul><li>EJB/CORBA(Sudha) </li></ul><ul><li>J2EE Patterns(Betsy) </li></ul><ul><li>The Department of Motor Vehicles Prototype(Sudha) </li></ul><ul><li>Conclusion(Sudha) </li></ul>
  3. 3. Introduction - Assessment <ul><li>Java has been around for over 7 years now. </li></ul><ul><li>Server-side component architectures </li></ul><ul><li>Microsoft’s .NET product </li></ul><ul><li>Sun Microsystems’ Java2 Platform Enterprise Edition (J2EE) standard </li></ul><ul><li>Object Management Group’s CORBA standard </li></ul>
  4. 4. Introduction - Benefits <ul><li>Enterprise JavaBeans includes both Java/RMI and RMI – IIOP as middleware options. </li></ul><ul><li>Sun and OMG support EJB/CORBA interoperability and have produced standards for the same. </li></ul><ul><li>The EJB/CORBA mapping specification and RMI-IIOP relieve EJB from being restricted to the Java platform, enabling EJB components to be exposed as CORBA objects making them well suited for cross-language interoperability . </li></ul>
  5. 6. Motivation – SE to EE <ul><li>Large organizations utilize J2EE. </li></ul>
  6. 7. Motivation - …
  7. 8. Motivation – Academic perspective <ul><li>Maintain an objective research perspective on the state of development of Java2 Enterprise Edition and Java technologies in general. </li></ul><ul><li>Determine the role Java plays as an educational language, problem-solving skill for the workplace, and research tool for academia. </li></ul><ul><li>Focus on the classical facilities provides insight into the true maturation of Java. </li></ul>
  8. 9. Server-side Component Architectures ( Overview ) <ul><li>Issues surrounding server-side development </li></ul><ul><li>The need for standardized architecture </li></ul><ul><li>Popular server-side architecture standards </li></ul><ul><li>Similarities and differences between J2EE and other competing technologies </li></ul><ul><li>Enterprise Application Development and these technologies </li></ul>
  9. 10. Server-side Component Architectures ( Software Components ) <ul><li>What are software components? </li></ul><ul><li>What is a component architecture? </li></ul><ul><li>Divide-and-conquer approach and its advantages </li></ul><ul><ul><li>Saves development and deployment time </li></ul></ul><ul><ul><li>Services could be simply outsourced </li></ul></ul><ul><ul><li>Users save time by buying instead of building </li></ul></ul><ul><ul><li>Deployment is strengthened as the common products are developed by domain experts </li></ul></ul>
  10. 11. Server-side Component Architectures ( Server-side Components ) <ul><li>What is a server-side deployment? </li></ul><ul><li>Logical layers in the deployment </li></ul><ul><ul><li>Presentation Layer </li></ul></ul><ul><ul><li>Business logic Layer </li></ul></ul><ul><ul><li>Data Layer </li></ul></ul><ul><li>Layers are pure abstractions and may or may not correspond to physical distribution </li></ul><ul><li>a N-tier architecture deployment is one where there is a physical separation between each of the layers </li></ul><ul><li>Each of the layers could further be decomposed to allow various parts of the system to scale independently </li></ul>
  11. 12. Server-side Component Architectures ( Three-tier Web-based Application Architecture ) Presentation layer Business logic Layer Data layer WEB SERVER APPLICATION SERVER WITH COMPONENT CONTAINER Database Secure zone Insecure Firewall + tier boundary tier boundary
  12. 13. Server-side Component Architectures ( N-Tier Architectures ) <ul><li>PRO: </li></ul><ul><li>Deployment costs are low </li></ul><ul><li>Database switching costs are low </li></ul><ul><li>Low costs in business logic migration </li></ul><ul><li>Securing deployments using firewalls is possible </li></ul><ul><li>Resource pooling is possible </li></ul><ul><li>Performance slowdown is localized </li></ul><ul><li>Errors are localized </li></ul><ul><li>CON: </li></ul><ul><li>Communication performance suffers </li></ul><ul><li>Maintenance costs are high </li></ul>
  13. 14. Server-side Component Architectures (Demands of a multi-tier deployment) <ul><li>Handle lifecycle of the components </li></ul><ul><li>Perform resource pooling </li></ul><ul><li>Broker method requests </li></ul><ul><li>Handle the logic to load-balance communications between each tier </li></ul><ul><li>Deal with ramifications of two or more clients concurrently accessing the same component </li></ul><ul><li>Reroute client requests to other machines in case of failure </li></ul><ul><li>Provide secure environment and deal with unauthorized accesses </li></ul><ul><li>APPLICATION SERVERS WERE BORN AS A SOLUTION TO THESE ISSUES </li></ul>
  14. 15. Server-side Component Architectures (Role of Application Servers) <ul><li>provide the middleware services </li></ul><ul><li>allow enterprises buy the services </li></ul><ul><li>aid in rapid the application development </li></ul><ul><li>Anomalies and problems: </li></ul><ul><li>Vendor specific middleware services </li></ul><ul><li>Once an application sever is chosen the code is locked to that particular vendor’s solution </li></ul><ul><li>Reduces portability </li></ul><ul><li>Hampers commerce of components </li></ul>
  15. 16. Server-side Component Architectures (Need for a standard) <ul><li>The standard would describe a well-formed interface between the application server and the components themselves </li></ul><ul><li>Components could be managed in a portable way </li></ul><ul><li>Components could be switched between various application servers </li></ul><ul><li>Component vendors could be relieved of issues about external overhead such as resource pooling, networking, security etc. </li></ul><ul><li>Necessary elements of enterprise-class deployments are externalized to application server vendors, providing common services to all component developers </li></ul>
  16. 17. Server-side Component Architectures (Standards) <ul><li>OMG’s CORBA Standard </li></ul><ul><li>Sun Microsystem’s J2EE Standard </li></ul><ul><li>Microsoft’s .NET Architecture </li></ul>
  17. 18. Server-side Component Architectures (Standards – J2EE vs .NET) Java Client Application Business System Web Client Container Servlets and JSPs EJBs Connectors Legacy Systems or Databases or Other Business Systems The J2EE Server-side Architecture
  18. 19. Server-side Component Architectures (Standards – J2EE vs .NET) Business System Rich Client Application Web Client Container ASP.NET .Net Managed Components Host Integration Server 2000 Legacy Systems or Databases or Other Business Systems The .NET Server-side Architecture
  19. 20. Server-side Component Architectures (Standards – J2EE vs .NET) <ul><li>J2EE was found advantageous over .NET: </li></ul><ul><li>a proven platform while .NET is a rewrite of Microsoft’s previous technologies and introduces risk as with any first-generation technology </li></ul><ul><li>lets enterprises take advantage of existing hardware they may have </li></ul><ul><li>gives platform neutrality, including Windows and good portability </li></ul><ul><li>has a better legacy integration through the Java Connector Architecture (JCA) </li></ul><ul><li>lets the use of any operating system enterprises prefer, such as Windows, UNIX, or mainframe </li></ul>
  20. 21. J2EE Platform Overview - Environment
  21. 22. J2EE Platform Overview - Components and Containers
  22. 24. J2EE Platform Overview – Java Servlet Technology(1) <ul><li>Mechanism for generating dynamic web content. </li></ul><ul><li>They may be thought of as Java applets for servers . </li></ul><ul><li>platform independent, pleasant user interfaces, better performance due to persistent well-defined API for flexibility. </li></ul>
  23. 25. J2EE Platform Overview – Java Servlet Technology(2) <ul><li>Web browser  HTTP request  web server </li></ul><ul><li>Web server  gives request to servlet container  gives request to specific servlet </li></ul><ul><li>Servlet receives request object. </li></ul><ul><li>Servlet processes. (may return a response object) </li></ul><ul><li>During process, servlet may use a context object to save information usable by other servlets, and read a session object to determine a client state . </li></ul>
  24. 26. J2EE Platform Overview – JavaServer Pages(1) <ul><li>Utilize Java Servlet technology to simplify well organized dynamic web content. </li></ul><ul><li>JSP pages define the static HTML template, and embeds invocations to Java code. </li></ul><ul><li>Useful and routine operations like embedding dynamic distributed database queries and generation of their associated reports. </li></ul><ul><li>Hides the complexity of programming in Java from the page designer </li></ul>
  25. 27. Enterprise JavaBean Components(1) <ul><li>A server-side technology for developing and deploying components containing the business logic of an enterprise application. </li></ul><ul><li>Allows encapsulation of legacy technologies. </li></ul><ul><li>EJB is a client-neutral standard. </li></ul>
  26. 28. Enterprise JavaBean Components – Entity Beans <ul><li>Represent persistent objects like database entries. </li></ul><ul><li>EJB specification indicates that a bean and its references survive a crash of its container. (achieved by storing the state in the database or through serialization) </li></ul><ul><li>Container provides a class in order to provide meta-data to the client. </li></ul>
  27. 29. Enterprise JavaBean Components - Message-Driven Beans <ul><li>A basis for constructing loosely coupled applications capable of communicating indirectly using the queuing and subscription models supported by JMS . </li></ul><ul><li>More flexible and realistic for heavily congested networks. </li></ul>
  28. 30. Enterprise JavaBean Components - Session Beans <ul><li>Limited lifetime as the name suggests </li></ul><ul><li>If stateless won’t preserve state between calls </li></ul><ul><li>Saving and restoring state are properties of stateful session beans </li></ul>
  29. 31. J2EE Technology Suite
  30. 32. J2EE Standardized Services <ul><li>The containers supporting the J2EE components provide three types of services : </li></ul><ul><ul><li>Communication </li></ul></ul><ul><ul><ul><li>RMI-IIOP </li></ul></ul></ul><ul><ul><ul><li>Java IDL </li></ul></ul></ul><ul><ul><ul><li>JMS </li></ul></ul></ul><ul><ul><ul><li>Java Mail </li></ul></ul></ul><ul><ul><li>Enterprise </li></ul></ul><ul><ul><ul><li>JDBC </li></ul></ul></ul><ul><ul><ul><li>JTA </li></ul></ul></ul><ul><ul><ul><li>JNDI </li></ul></ul></ul><ul><ul><ul><li>JCA </li></ul></ul></ul><ul><ul><li>Internet </li></ul></ul><ul><ul><ul><li>HTTP </li></ul></ul></ul><ul><ul><ul><li>TCP/IP </li></ul></ul></ul><ul><ul><ul><li>SSL </li></ul></ul></ul><ul><ul><ul><li>XML </li></ul></ul></ul>
  31. 33. Communication Services <ul><li>JavaIDL, RMI-IIOP </li></ul><ul><ul><li>Allows objects written in Java to to invoke CORBA objects using IIOP. Provides interoperability with CORBA objects. </li></ul></ul><ul><li>JMS </li></ul><ul><ul><li>API for asynchronous messaging </li></ul></ul><ul><li>JavaMail: </li></ul><ul><ul><li>Provides an API for electronic mail </li></ul></ul>
  32. 34. Enterprise Services <ul><li>JDBC </li></ul><ul><ul><li>API for DB independent connectivity between J2EE and other datasources </li></ul></ul><ul><li>JTA </li></ul><ul><ul><li>The transaction API for J2EE which guarantees transactional integrity </li></ul></ul><ul><li>JNDI </li></ul><ul><ul><li>Provides a naming environment, & facilitates directory operations </li></ul></ul><ul><li>JCA </li></ul><ul><ul><li>Mandatory with v.1.3 of J2EE. Helps to integrate different EJB containers with different EIS. </li></ul></ul>
  33. 35. Internet Services <ul><li>For access to Internet services, J2EE supports the following protocols: </li></ul><ul><ul><li>TCP/IP </li></ul></ul><ul><ul><li>HTTP </li></ul></ul><ul><ul><li>SSL </li></ul></ul><ul><li>XML </li></ul><ul><ul><li>J2EE v.1.3. supports XML functionality. </li></ul></ul>
  34. 36. EJB – CORBA INTEROPERABILITY (Overview) <ul><li>how EJB and CORBA complement each other </li></ul><ul><li>where EJB gets its edge over CORBA </li></ul><ul><li>where CORBA would be still depended on </li></ul><ul><li>benefits of EJB / CORBA interoperability </li></ul><ul><li>interoperability scenarios </li></ul>
  35. 37. EJB – CORBA INTEROPERABILITY ( CORBA Overview) CLIENT CORBA Stub ORB ORB CORBA Skeleton CORBA Object Implementation Network via IIOP CORBA Architecture CORBA Object Interface
  36. 38. EJB – CORBA INTEROPERABILITY ( CORBA Services) <ul><li>COS Naming </li></ul><ul><li>CORBA Event Service </li></ul><ul><li>Object Transaction Service (OTS) </li></ul><ul><li>Concurrency Control Service </li></ul><ul><li>Security Service </li></ul>
  37. 39. EJB – CORBA INTEROPERABILITY ( CORBA ) <ul><li>Advantages: </li></ul><ul><li>not controlled by one organization </li></ul><ul><li>language-independent </li></ul><ul><li>Disadvantages: </li></ul><ul><li>Slow-moving </li></ul><ul><li>Steep learning curve </li></ul>
  38. 40. EJB – CORBA INTEROPERABILITY ( OMG’s CCM Specification ) <ul><li>adds component features to CORBA objects </li></ul><ul><li>similar to EJBs </li></ul><ul><li>intention that CORBA components and EJBs can reside together </li></ul><ul><li>a CORBA component could appear as if it were an EJB </li></ul><ul><li>an EJB could appear as if it were a CORBA component </li></ul>
  39. 41. EJB – CORBA INTEROPERABILITY ( Why is CORBA important for EJBs? ) <ul><li>Legacy Integration </li></ul><ul><li>Advanced middleware services </li></ul><ul><li>EJBs exposed to CORBA clients (the highlight of this interoperability section) </li></ul>
  40. 42. EJB – CORBA INTEROPERABILITY ( RMI and IIOP) <ul><li>Remote Method Invocation(RMI) is a communications package for performing distributed computing in Java </li></ul><ul><li>default protocol layer for communication used by RMI is Java Remote Method Protocol(JRMP) </li></ul><ul><li>CORBA uses Internet Inter-ORB Protocol(IIOP) as its default protocol layer for communications </li></ul><ul><li>RMI and CORBA are very similar technologies </li></ul>
  41. 43. EJB – CORBA INTEROPERABILITY ( RMI and CORBA) <ul><li>Problems: </li></ul><ul><li>RMI - built specifically for Java and CORBA – built to allow language interoperability </li></ul><ul><li>two technologies are highly incompatible </li></ul><ul><li>major portion of a program coded for the RMI API needs to be rewritten if there is a need to switch to CORBA and vice versa </li></ul><ul><li>prohibits code reuse </li></ul><ul><li>Ideal Scenarios: </li></ul><ul><li>Combine client-side Java RMI with server-side CORBA </li></ul><ul><li>Combine client-side CORBA with server-side Java RMI </li></ul><ul><li>Need: bridge between RMI and CORBA </li></ul><ul><li>Solution: RMI over IIOP </li></ul>
  42. 44. EJB – CORBA INTEROPERABILITY ( RMI and CORBA – Ideal Scenarios) RMI CLIENT RMI Stub ORB ORB CORBA Skeleton CORBA Object Implementation RMI Remote Object Interface Network via IIOP CORBA CLIENT CORBA Stub ORB ORB RMI Skeleton RMI Object Implementation Network via IIOP CORBA Object Interface Scenario #1 Scenario #2
  43. 45. EJB – CORBA INTEROPERABILITY ( RMI over IIOP) <ul><li>unification of RMI and CORBA </li></ul><ul><li>RMI run over IIOP (instead of JRMP) </li></ul><ul><li>delivers CORBA distributed computing capabilities to the Java2 platform </li></ul><ul><li>speeds distributed application development completely in Java </li></ul><ul><li>code reusability of programs coded with the RMI API and the CORBA API </li></ul><ul><li>lessens the impact of switching between the two technologies </li></ul><ul><li>IIOP eases legacy application and platform integration </li></ul><ul><li>IIOP makes RMI more robust </li></ul>
  44. 46. EJB – CORBA INTEROPERABILITY ( RMI over IIOP : Combinations) <ul><li>CLIENT </li></ul><ul><li>RMI client with RMI-IIOP Stub </li></ul><ul><li>RMI client with RMI-IIOP Stub </li></ul><ul><li>CORBA client </li></ul><ul><li>CORBA client </li></ul><ul><li>SERVER </li></ul><ul><li>RMI Server with RMI-IIOP skeleton </li></ul><ul><li>CORBA object implementation </li></ul><ul><li>RMI Server with RMI-IIOP skeleton </li></ul><ul><li>CORBA object implementation </li></ul>
  45. 47. EJB – CORBA INTEROPERABILITY ( EJB Specification) <ul><li>EJB components must be able to run over both RMI and RMI-IIOP </li></ul><ul><li>RMI-IIOP as an on-the-wire protocol for EJB components </li></ul><ul><li>Advantages to J2EE: </li></ul><ul><li>greatly assist the integration of the J2EE environment into existing corporate infrastructures, most of which are quite CORBA intensive </li></ul><ul><li>EJBs could be exposed as CORBA components that could be accessed by non-Java Clients </li></ul><ul><li>relieves EJBs off the constraint that they could be only Java based </li></ul>
  46. 48. EJB – CORBA INTEROPERABILITY ( Scenarios) RMI-IIOP CLIENT RMI – IIOP Stub ORB ORB RMI-IIOP Skeleton EJB Object Implementation EJB Remote Object Interface Network via IIOP CORBA CLIENT CORBA Stub ORB ORB RMI-IIOP Skeleton EJB Object Implementation Network via IIOP EJB Remote Object Interface Scenario #1 Scenario #2
  47. 49. Patterns - Definition <ul><li>Definition </li></ul><ul><ul><li>“ .. are a collection of J2EE based solutions to common problems... They extract the core issues of each problem, offering solutions that represent an applicable distillation of theory and practice”. </li></ul></ul><ul><ul><li>“ a recurring solution to a problem in a context ” </li></ul></ul><ul><li>Repository of patterns is called the Design Pattern Catalog </li></ul><ul><li>Documented according to a template </li></ul><ul><li>Organized in tiers </li></ul>
  48. 50. Patterns - Tiers <ul><li>Presentation Tier </li></ul><ul><ul><li>Contains the patterns related to Servlets and JSP technology. </li></ul></ul><ul><li>Business Tier </li></ul><ul><ul><li>Contains the patterns related to the enterprise beans technology </li></ul></ul><ul><li>Integration Tier </li></ul><ul><ul><li>Contains the patterns related to JMS and JDBC </li></ul></ul>
  49. 51. J2EE Pattern Relationships
  50. 52. Presentation Tier Combines a Dispatcher component in coordination with the FrontController and View Helper Patterns, deferring many activities to View processing. Dispatcher View Combines a Dispatcher component in coordination with the FrontController and View Helper Patterns. Service to Worker Creates an aggregate View from atomic sub-components Composite View Encapsulates logic that is not related to presentation formatting into Helper components View Helper Provides a centralized controller for managing the handling of a request Front Controller Facilitates pre and post-processing of a request Decorating Filter Brief Synopsis Pattern Name
  51. 53. Business Tier Hides complexity of business service lookup and creation, locates business service factories. Service Locater Manages query execution, results caching and result processing. Value List Handler Builds composite value object from multiple data sources. Value Object Assembler Represents a best practice for designing coarse-grained entity beans. Aggregate Entity Hides business object complexity, centralizes workflow handling. Session Facade Exchanges data between tiers. Value Object Decouples presentation and service tiers, and provides a façade and proxy interface to the services. Business Delegate
  52. 54. Integration Tier Facilitates asynchronous processing for EJB components. Service Activator Abstracts data sources, provides transparent access to data. Data Access Object
  53. 55. Use of Patterns in DMV App <ul><li>The following patterns were used in the DMV Application: </li></ul><ul><ul><li>Front Controller </li></ul></ul><ul><ul><li>View Helper </li></ul></ul><ul><ul><li>Session Façade </li></ul></ul><ul><ul><li>Transfer Object </li></ul></ul><ul><ul><li>Transfer Object Assembler </li></ul></ul><ul><ul><li>Data Access Object </li></ul></ul>
  54. 56. Application Prototype (Overview) <ul><li>JBuilder7 Enterprise </li></ul><ul><li>JDataStore </li></ul><ul><li>BES 5 </li></ul><ul><li>MS VC++ 5.0 (for non-Java Client) </li></ul><ul><li>MVC architecture </li></ul>CONTROLLER (SERVLET & HANDLER) MODEL (EJBs & Domain classes) VIEW (JSPs & HELPER)
  55. 57. Application Prototype Use Case Diagram
  56. 58. Application Prototype Deployment Diagram
  57. 59. Application Prototype EJBs in the DMV Application
  58. 60. Application Prototype Class Diagram
  59. 61. Application Prototype Application Flow and Patterns(1) This flow is followed by the Login, Registration and License Modules
  60. 62. Application Prototype Application Flow and Patterns(2) This flow is followed by the Report Module
  61. 63. Application Prototype EJB exposed to non-Java Clients Non-Java Client (C++ Application) TrafficViolationSB (Session Bean) LicenseEB (Entity Bean) Looks up the SB as a CORBA component Finds the License and increments its points DMV Database Updates the database TrafficViolation Application DMV Application
  62. 64. Application Prototype EJB exposed to non-Java Clients
  63. 65. Application Prototype Screen shots(1)    
  64. 66. Application Prototype Screen shots(2)