J2EE Clients
- J2EE Clients
- Types of J2EE Clients
- Servicing Stand-alone Java Client Applications
- Servicing EJB Clients from Other J2EE/EJB Servers
- Servicing CORBA clients from CORBA Object Request Brokers
- Servicing Legacy System Clients (ERP/CRM/Mainframes)
- Servicing JMS Clients
- Servicing Windows/.Net Clients
- Servicing Web service client
- Servicing Clients from Other Environments
- Conclusions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In this article, we look at different types of clients that access enterprise J2EE environment—ranging from Web browser and mobile devices to CORBA and JMS applications.
J2EE provides a robust platform for developing application components that can service wide-ranging Java or non-Java clients.
We also take a brief look at how Java clients are often more powerful than their non-Java counterparts, and the influence of Web services in accessing J2EE services.
J2EE Clients
J2EE clients are those applications, components, systems, and services that access the J2EE environment to fulfill a request or access a service. Depending upon the scope and horizons of a given enterprise J2EE environment, they can range from simple HTTP requests to complex interactions between several J2EE servers across the networks.
By enterprise J2EE environment, we mean the enterprise distributed application backbone over which all of the system components are deployed. Because the platform is distributed across several servers and network(s), there could be wide-ranging adaptations of J2EE services by various back office and front office applications within a given enterprise environment.
Types of J2EE Client Access
We can summarize the types of client access in J2EE environment as follows.
Accessing business logic services in EJB: This is perhaps the most popular form of client access in any given J2EE environment. If the core business logic rules can be encapsulated into loosely coupled EJBs or Java components, then they can be reused over and over across several applications, within and even outside the enterprise. Sometimes, enterprises set forth far-reaching ambitions in building their J2EE components and services (for example, evolving global business logic repositories or common EIS access gateways). In such cases, business logic modules are carefully designed and crafted under the supervision of experienced architects, so that reusability and encapsulation are best evolved.
Example: A bank's funds transfer service, which transfers money from one account to another. This service, when implemented as an EJB (or group of EJBs behind a façade), can be reused by different types of clients—such as a bank's back office application, an Internet banking Web site, and mobile banking services; and even by its sister companies, associates, and other subsidiary banks.
Accessing presentation logic services: Presentation logic services are very specific to certain types of client front ends; hence, they are hardly reused across different applications. There are certain architectures and designs available, however, by which we can segregate what is being presented from how it is presented. A typical methodology is to use XML and XSLT pages, which ensure the clear-cut demarcation of presentation logic (XSLT) from data (XML).
Example: Consider the same funds-transfer application that was described earlier. Let us say that we need to send an acknowledgment and balance account status after the successful execution of the service. The data that is presented across different clients is the same (status of transfer + balance account). In a Web page, it may be presented with an image, but not in the case of a mobile client. In such scenarios, if the presentation elements (images, fonts, etc.) are defined in separate XSLT pages (web.xsl, mobile.xsl, etc.), and the two are combined either at the server end or at the client end, then we achieve significant levels of segregation between presentation data and presentation logic. Browsers such as Internet Explorer 5 help further by comprehending and combining XSL and XML only during rendering time.
Accessing enterprise services: There are situations in which components outside the J2EE realm might wish to access one or more enterprise services available in the platform. This is more pronounced when the enterprise architects build the J2EE environmental services so they are available to a wide variety of applications and components.
For example, we can have a common gateway over J2EE enterprise e-mail services. Thus, they are available not only to other peers in the J2EE platform, but also to a whole range of enterprise applications that need to send and receive email. Similarly, all database access calls can be centralized inside the J2EE environment. Such arrangements enable exercising greater control and collaboration on the usage of infrastructure services across the enterprise.
Accessing EIS services through J2EE: Apart from exposing its own application components to different types of client access, J2EE can also serve as a centralized facade for accessing one or more enterprise information system resources in the back end. This is particularly useful if the back end systems are bulky, complex, or are not directly accessible by many other applications.
Example: Let us say we have a Siebel CRM system in the back end, and we access the resources through messaging systems/Siebel adapters. It is possible to construct access gateways inside J2EE—by making use of JMS, EJBs, and other Java libraries—so that Siebel resources can be accessed by a wide variety of Java clients and other applications in a consistent manner.