The present invention relates to middleware compatible with the Java platform. More particularly, the present invention relates to methods, a device and a computer program product for creating a design pattern compatible with the Java platform.
One of the advantages of mobile communications is the ability to access networks and applications that are located within those networks while maintaining mobility. In order to ensure that the network and application can communicate, efficient and competent middleware must be developed. Middleware is software which facilitates interoperability between often-conflicting network and application protocols. Nokia Mobility Middleware (NMM) is a suite of Java 2 platform, Enterprise Edition (J2EE) components that provide functionality enabling communication between the network and applications. The functionality that NMM provides has a particular emphasis on functionality used by mobile terminals, e.g. short messaging service (SMS) and multimedia messaging service (MMS).
The Java 2 platform, Enterprise Edition (J2EE) is a standard for developing component-based applications. The J2EE Connector Architecture (JCA) defines a way to integrate J2EE application servers with different Enterprise Information Systems (EIS) such as database management systems, short messaging service centres (SMSCs), multimedia messaging service centres (MMSCs), EISs which utilize Systems, Applications and Products in data processing (SAP) software, etc. JCA 1.5 is the latest version of JCA and is part of the J2EE 1.4 specification.
Resource adapters (RA) are JCA-compliant connectivity components which can connect application servers that utilize the J2EE protocol to different EISs. Therefore, connectivity between a network and application servers such as SMSCs and MMSCs can be realized using RAs.
Currently, the NMM messaging feature includes support for three different SMS messaging protocols and two MMS messaging protocols. Each protocol can be implemented in an RA. In J2EE applications, the technology for handling asynchronous events (such as an incoming message) is Message Driven Beans (MDBs). In order to receive messages, the SMS or MMS application must implement special objects i.e. MDBs and associate each MDB with a corresponding RA. One MDB per RA is needed since, in the current J2EE architecture, only RAs can pass messages to an MDB. Accordingly, in current systems, the SMSC or MMSC must have an accurate count of the number of RAs in the system. Therefore, installing additional RAs in the system later can be problematic as this hampers the ability of an application server to have an accurate count of the RAs in the system.
Currently, RAs are not hidden from the application since RAs interact directly with MDBs, which interact with applications. Therefore, RAs are required to be compatible with the application and must expend processing power to separately process incoming data from different protocols in different applications. RAs and mobile terminals must also be updated each time that an application protocol is updated.
Currently, in a clustered deployment of a J2EE application server, in which a set of different processes are potentially running on different machines or nodes but accessing the same EIS, an RA must be associated with each node. This can be problematic since in some cases, the EIS is controlled by a third-party that has placed a limit on the number of RAs that can connect to it. This limits the number of nodes that can be included in the cluster and accordingly limits the benefits of clustering, which include scalability and an increased availability of resources. Current design patterns such as the Facade and the Proxy design patterns fail to provide clustering benefits.
Thus, there is a need for a design pattern that can reduce application processing by reducing the need to maintain an accurate count of each RA in the system, and correspondingly allows for the seamless addition of RAs to a system. There is also a need for a design pattern which allows for seamless modification and addition of new protocols in the applications. There is also a need for a design pattern which can reduce the amount of processing power expended by the RA and the mobile terminal by hiding the different protocols by which incoming data arrives. Finally, there is a need for a design pattern which allows a system to obtain the full benefits of clustering in J2EE clustered deployment.
The present invention is directed to a method, device and a computer program product for a JCA 1.5-compliant cover resource adapter (CRA) design pattern which can collect and hide a number of resource adapters (RAs) by creating a single virtual resource adapter. Accordingly, the CRA can make application development and management less complex since the client application need only interact with the CRA, as opposed to interacting with multiple RA components.
The CRA alleviates the need for an application to maintain an accurate count of each RA in the system. Accordingly, the CRA allows additional RAs to be added to the network seamlessly. The CRA can also allow reduced processing at the RAs and mobile terminals by hiding the protocols by which data arrives, enabling the seamless addition of new and different protocols in the applications. The CRA can also enable receipt of the full benefits of clustering in clustered J2EE deployment by reducing the number of RAs that the EIS perceives as attached, thereby allowing an increased number of RAs to attach to the application. The CRA also enables the realization of different RA clustering schemes. In clustered J2EE deployment, CRAs also make the client less susceptible to artificial limits that a third-party EIS may place on the number of connections that can be made to the EIS.
These and other objects, advantages and features of the invention, together with the organization and manner of operation thereof, will become apparent from the following detailed description when taken in conjunction with the accompanying drawings, wherein like elements have like numerals throughout the several drawings described below.
For exemplification, the system 100 shown in
The Internet 28 may include an enterprise application 30, written according to J2EE specifications in one embodiment of the invention, which runs on top of an application server and is disposed to carry out processing in order to perform a specific function for the mobile terminal. In an embodiment of the present invention, functions may include, but are not limited to, those utilizing with messaging applications and authentication of the mobile terminal. The enterprise application 30 may be operatively connected to a device which contains a processor to implement the functionality of a covered resource adapter design pattern 32 (“Covered Resource Adapter” i.e. “CRA”). The application server serves as a contain for both the resource adapter (whether covered or not) and the enterprise application 30 and manages their life cycle, interactions, etc.
The CRA 32 may be connected to the enterprise application 30 and application server via a device which contains a processor to implement the functionality of a message driven bean object 34 (“Application Message Driven Bean” i.e. “APP MDB”). The CRA 32 may also be connected to one or more devices which contain a processor to implement the functionality of message driven bean objects for corresponding resource adapters 36 (“Covered Resource Adapter Message Driven Bean” i.e. “CRA MDB”). The CRA 32 operates in a like fashion to that of the resource adapters, whose operation is dictated according to the J2EE Connector Architecture Specification, version 1.5.
Each CRA MDB 36 may be connected to a device which contains a processor to implement the functionality of a corresponding resource adapter 38 (“Resource Adapter” i.e. “RA”). Each RA 38 may be connected to a corresponding device which contains a processor to implement the functionality of an Enterprise Information System 40 (“Enterprise Information System” i.e. “EIS”). EISs may include, but are not limited to, systems such as SAP, database management systems, SMSCs and MSMCs. The CRA 32, APP MDB 34, CRA MDB 36, RA 38 and EIS 40 may be implemented in hardware or software.
The exemplary communication devices of the system 100 may include, but are not limited to, a mobile telephone 12, a combination PDA and mobile telephone 14, a PDA 16, an integrated messaging device (IMD) 18, a desktop computer 20, and a notebook computer 22. The communication devices may be stationary or mobile as when carried by an individual who is moving. The communication devices may also be located in a mode of transportation including, but not limited to, an automobile, a truck, a taxi, a bus, a boat, an airplane, a bicycle, a motorcycle, etc. Some or all of the communication devices may send and receive calls and messages and communicate with service providers through a wireless connection 25 to a base station 24. The base station 24 may be connected to a network server 26 that allows communication between the mobile telephone network 11 and the Internet 28. The system 100 may include additional communication devices and communication devices of different types.
The communication devices may communicate using various wireline or wireless transmission technologies including, but not limited to, Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Transmission Control Protocol/Internet Protocol (TCP/IP), Bluetooth, IEEE 802.11, etc. A communication device may communicate using various media including, but not limited to, radio, infrared, laser, cable connection, and the like.
At step 620, one or more CRAs 32 are clustered. CRAs 32 can be clustered according to any number of different types of criteria as dictated by the goal of clustering and the system operation. At step 630, one or more clusters of RAs 38 that were formed at step 610 communicate with one or more clusters of CRAs 32 that were formed at step 620. At step 640, each CRA 32 communicates with its respective APP MDB 34. At step 650, each APP MDB 34 communicates with its respective client application, which operates as dictated by the enterprise application 30.
An embodiment of the present invention can be described in the general context of method steps, as illustrated in
The memory 530 is the electronic holding place for the operating system so that the information can be accessed by the processor 520. The device may have a plurality of different types of memories 530 using different technologies including, but not limited to, Random Access Memory (RAM), Read Only Memory (ROM) and flash memory.
The communication interface 510 allows the CRA 32 to communicate with the outside world and other networked devices including, but not limited to, the APP MDB 34 and the CRA MDB 36. A communication interface can include, but is not limited to a serial port, an antenna, a screen with an electronic keypad, a physical keypad or a serial port. The communication interface can be accessed by a user or another device. The internal clock 540 determines how fast the processor operates; the shorter the cycle, the faster the processor operates.
The foregoing description of embodiments of the present invention have been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the present invention to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the present invention. The embodiments were chosen and described in order to explain the principles of the present invention and its practical application to enable one skilled in the art to utilize the present invention in various embodiments and with various modifications as are suited to the particular use contemplated.