Section 6: Applicability of Java EE Technology
Given a specified business problem, design a modular solution that solves the problem using Java EE.
- Stand-Alone Client: Swing
- Web Container: JSP, Servlets, XML, JavaMail
- EJB Container: Enterpise Beans, JMS, JTA, JDBC
- EIS: RMDBS, legacy systems
JEE Application Scenarios
Architecture depends on requirements:
- Frequent changes in presentation
- Complex UI interfaction
- Heterogeneous clients
Multi-Tier Application Scenario
Stand-Alone Client Scenario
- EJB-clients: interacting directly with EJB server
- Stand-alone Java clients: rich clients directly connected to EIS
- Web-clients: consuming XML data from web container
- Commonly 3-tiers
- Communication between web containers: XML over HTTP(S)
- Communication between EJB containers: JMS, RMI-IIOP
Explain how the Java EE platform enables service oriented architecture (SOA) -based applications.
Service Oriented Architecture (SOA)
- Independent services
- Discoverable services
- Interoperable services
- Loose coupling
- Heterogeneous platforms
- Standard SOAP for communication
- WSDL for service definition
- UDDI for service registry
Java EE Technology for SOA
- JAX-WS (Java API for XML Web Services): to create SOAP web services, generate WSDL descriptions or classes from WSDL
- JAXP (Java API for XML Processing): validates and processes XML-data
- JAXB (Java Architecture for XML-Binding): map XML to classes and vice versa
- JAXR (Java API for XML Registries): provides interface to XML registries/repositories (ebXML and UDDI)
- SAX (Simple API for XML): parser for XML-data
- StAX (Streaming API for XML): streaming parser for XML-data
- SAAJ (SOAP with Attachments API for Java): for producing and processing SOAP messages
- JAX-RPC (Java API for XML-based RPC): transparant (object stubs) calling of web service
Explain how you would design a Java EE application to repeatedly measure critical non-functional requirements and outline a standard process with specific strategies to refactor that application to improve on the results of the measurements.
Log start and end time of requests between tiers to monitor bottlenecks in tiers. Standard logger classes can be used within the application. Filters and Interceptors can be used to implement this. An external application can be used to measure performance of external factors like hardware.
Use the time of the performance statistics to determine the user count at any given time and determine if the performance per request deteriorates when the user load increases.
Availability is measured externally using a web bot for web applications or a custom external application. Fire test requests in fixed intervals to measure performance, stability and availability.
Measure the time a developer needs to implement new functionality. Catagorize new functionality in complexity or estimated amount of time needed. Measure actual time used for implementation. Determine if there is an growing trend in actual time used, which indicates the deterioration of the extensibility.
Log failures or errors in remote invocations to and from other systems and determine the percentage of requests not successfully processed.
Use loosely coupled security checkpoints with Filters or Interceptors to check if user is allowed to invoke methods and if the invocation succeeds. Log violation using standard loggers.