【原创】The Design and Implementation of OO Model of Fetion Engine

最新推荐文章于 2021-03-20 01:58:03 发布

choclover

最新推荐文章于 2021-03-20 01:58:03 发布

阅读量1.1k

点赞数

分类专栏： JAVA / J2ME 文章标签： oo asynchronous transactions processing java ui

本文链接：https://blog.csdn.net/choclover/article/details/4500103

版权

JAVA / J2ME 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

The Design and Implementation of OO Model of Fetion Engine in CMCC Fetion Java Client

Ming He (Simon)

Abstract

A 3-tiered architecture is proposed for the Fetion Java client, including SIP-C stack, Fetion Engine and UI rendering task. The middle layer—Fetion Engine, functioning as the communication channel between the other two layers, can transform the UI actions to protocol packets for network (known as Request), and parse protocol packets from network to tell the UI task what to render (known as Response).

Since there are too many kinds of Request/Response and each one has its own processing logic, the Fetion Engine layer adopts an Object-Oriented model to handle each pair of Request/Response concurrently without interfering each other. And the Fetion Engine employs an “Event Queue” to communicate with the UI rendering task, so that every response packet from network is ensured to be acquired by the UI rendering task, even though they arrives at the Java client side almost at the same time.

Keywords : Fetion J2ME Rich Client

1 Introduction

CMCC [1] Fetion Service is an “Instant Messaging” service based on SIP-C [2] protocol, and MSG NJ Division Java team has been developing a series of J2ME applications running on Motorola mobile phones across different platforms. The Fetion Java client, which can be preloaded or downloaded on Motorola phones, leverages the popularity of J2ME application and the convenience of CMCC Fetion service.

The Fetion Java client is programmed in pure Java language, and its basic requirements are CLDC1.1, MIDP2.0, JSR-75 and with heap size no less than 800K. It does not require other supports of native library on a certain platform. Therefore, the Fetion Java client can be easily ported to different platforms of mobile phone without much effort. While undoubtedly, more Java heap size and better capability of phone’s CPU can improve the runtime performance of Fetion Java client remarkably, and ensure smooth and friendly user experience when user communicates with others.

2 Architecture of Fetion Java Client

Figure-1 shows the general architecture of Fetion Java client, a typical 3-tiered architecture, including SIP-C stack , Fetion Engine and UI rendering task .

1. Among them, the SIP-C stack is a pure J2ME implementation of SIP-C. It connects to the remote Fetion server via SOCKET or HTTP connection, and sends/receives protocol packet to communicate with the Fetion server.

2. The UI rendering task is responsible for drawing text, image, color and animation onto the screen, capturing key events of the keypad, interacting with the user according to commands from the Fetion Engine.

3. While the middle layer—Fetion Engine, functioning as the communication channel between the other two layers, can transform the UI actions to protocol packets for network (known as Request ), and parse protocol packets from network to tell the UI task what to render (known as Response ).

Fetion Engine communicates with the SIP-C stack in the mechanism of Set Listener and Callback . In this way, Fetion Engine do not have to inquire the SIP-C stack repeatedly, which would consume much CPU time, but wait the stack to call Fetion Engine and send packets as Response . On the other side, Fetion Engine communicates with the UI rendering task in two modes: Synchronous Invoke and Asynchronous Invoke . The former mode is used by some real-time actions, such as subscribe service and get system configuration; the latter mode is used by other typical Request/Response actions. An Event Queue and Event Pool are employed to ensure the Asynchronous Invoke can work well, which will be introduced in detail later.

Figure-1 Architecture of Fetion Java Client

3 Class Diagram of Fetion Engine

Figure-3 shows the class diagram of Fetion Engine. Fetion Engine consists of two parts: class FetionEngine , class FetionRequest and its sub-classes.

1. Class FetionEngine creates a FetionRequest and commands the request to execute then dis patches the corresponding response to the UI rendering task.

2. Class FetionRequest contains the concrete processing logic of each kind of transaction (including Request and Response ), and communicates with the Fetion SIP-C stack directly.

Since there are many kinds of transactions for the Fetion service and most of them have unique processing logic, the class FetionRequest derives many sub-classes. Each sub-class takes the processing work of some similar transactions, including composing the SIP-C packets (Request ) for SIP-C server, and parsing the Response from SIP-C server. Encapsulating the processing logic of transactions in different classes rather than a single class, can reduce the code complexity greatly and expand Fetion Engine to support new kinds of transaction easily.

In this way, not only each pair of Request/Response can be handled concurrently without interfering others, but also Fetion Engine can create Request and dispatch Response via unified interface, and support new kinds of transaction without modifying too much code. Thus, an Object-Oriented model is implemented for the Fetion Java client.

4 Event Queue and Event Pool

In order to process the Asynchronous Invoke in Fetion Engine more effectively, an Event Queue and Event Pool is introduced to construct the communication channel between Fetion Engine and the UI rendering task, as shown in Figure-2 .

Figure-2 Event Pool & Event Queue

The Event Queue and Event Pool is a typical Producer-Consumer model. Every time a protocol packet is transformed to a UI action, Fetion Engine applies a Fetion Event object from the Event Pool, set the Fetion Event’s data, and then appends it to the rear of the Event Queue. Correspondingly, the Fetion UI rendering task inquires the Event Queue repeatedly, and retrieves a Fetion Event object from the head then process it accordingly.

In order to reduce the runtime expense when instantiating a Fetion Event object from Event Pool, the Event Pool is built up with fixed size and filled with Fetion Event objects that are instantiated in advance. After a Fetion Event object has been processed by the UI rendering task, this Fetion Event object will be put back to the Event Pool for reuse. So that the Event Pool is able to employ the preset Fetion Event objects repeatedly, and performance of the Event Pool will get greatly improved.

5 Conclusion

The 3-tiered architecture and Object-Oriented model of the Fetion Java client are compact and concise in structure, and efficient for Fetion Engine to handle each pair of Request/Response concurrently without interfering others. Meanwhile, the “Event Queue/Event Pool” mechanism ensures smooth operation and in-time feed-back of the UI rendering task, and good communication with the GPRS network.

Generally speaking, Fetion Engine of the Fetion Java client is competent for supporting the CMCC Fetion service.

Figure-3 Class Diagram of Fetion Engine

------------------------------------------------------------

Acknowledgements

Our thanks go to MSG China NJ Division Java Fetion team. The team members contribute to the design and implementation of CMCC Fetion Java client.

And special thanks to Shi Qunfeng(a5412c), who implements the Event Pool and Event Queue, which greatly improves the performance of communication between Fetion Engine and the UI rendering task.