Applicability of Java EE Technology


Modular Design using Java EE

Since Java EE specifically supports separation of concerns in design, it can be used to split applications into independent tiers. Presentation logic is handled in the presentation layer, business logic is handled in the business tier, and integration is handled in its tier.

The web presentation tier can be implemented in a servlet container, which allows functionality to be broken into web applications (WAR files). Within a web application, bits of functionality can be encapsulated into servlets.

The business logic tier is hosted in an EJB container, which also allows separate application modules to be loaded (EAR files or EJB zip files). Within each application, EJBs represent major modules of functionality.


Service Oriented Architecture with Java EE

In a Service Oriented Architecture (SOA), the enterprise is decomposed into independent but interoperable services. Essential qualities of these services is that they be “discoverable” and “interoperable”. The aim is a loose coupling of services with operating systems, programming languages and other technologies which underlie applications. The SOA pattern was designed to unite disparate services, which might be owned by entirely different business units. It allows the enterprise to define an appropriate level of governance, balancing central management with local independence.

SOA typically describes IT infrastructure which allows different applications to exchange data with one another as they participate in business processes. As the enterprise grows, an important function within the SOA will become centralized management, especially for security, routing, deployment, etc.

An SOA could be built up with many different technologies, but it is common to standardize on SOAP for communication and WSDL to communicate service definitions. SOA sometimes uses UDDI as a standard for service registries.

Java EE supports creation of SOAP services using the Java API for XML Web Services (JAX-WS). JAX-WS allows web service configuration to be embedded into any POJO class using annotations. It allows any stateless session bean to be deployed as a SOAP service.

JAX-WS services automatically generate WSDL descriptions. Service code may be written as Java POJOs (code first development) or shell code may be generated based on the service description (WSDL first development).

JAX-WS also provides a standard for writing SOAP clients which consume web services, even if these web services are provided by non-Java applications. Like services, JAX-WS clients may make use of annotations. Client code may be hand coded or generated WSDL-first.

Sun developed the JAXR API as a standard interface to UDDI and ebXML repositories. Current writing on SOA deemphasizes repositories, but JAXR is still available in JEE.

There is no Java EE standard for SOA management, but management is often organized around an Enterprise Service Bus (ESB). Sun is promoting a standard for ESB modules called Java Business Integration (JBI), but this is not part of the Java EE suite.


Managing Non-functional Requirements

Critical non-functional requirements are often service level requirements, such as performance, availability, or scalability.

These performance statistics can be measured within the application, saving data in Java standard loggers or to JMX beans. Statistics can also be gathered at interfaces between tiers, either in hardware (routers, firewalls, or load balancers) or software interceptor layers. There may also be utilities within the app servers or database servers for gathering performance statistics.

Monitoring performance is an essential part of system management. It can be used to spot problems. or when refactoring the system. Fine grained statistics allow operators to find bottle-necks and single-points of failure. They allow us to refactor and tune the architecture.

%d bloggers like this: