Workflow Engine Integration in JSLEE AS - Semantic Scholar

IEEE COMMUNICATIONS LETTERS, VOL. 15, NO. 12, DECEMBER 2011

1405

Workflow Engine Integration in JSLEE AS Mauro Femminella, Member, IEEE, Emanuele Maccherani, and Gianluca Reali, Member, IEEE

Abstract—This letter proposes a new architectural solution for service creation in JSLEE-compliant platforms, where service business logic can be separated by implementation issues and designed by non JSLEE experts. The novelty consists of integrating a workflow engine inside the development environment of the JSLEE platform, thus allowing simplified management in the development of advanced services and reduction of the time to market of new services. Index Terms—JAIN SLEE, jBPM, performance evaluation.

I. I NTRODUCTION

S

ervice Logic Execution Environment (SLEE) is an application server (AS) architecture for asynchronous services with real-time constraints [1]. The Java Community has provided a set of specifications for the implementation of a SLEE container called JAIN SLEE (JSLEE) [2]. The usage of the JSLEE ASs capabilities has a high learning curve [1]. Its service logic is implemented within software components called Service Building Blocks (SBBs). The SBB composition is not that easy, since [2] specifies a mandatory declaration of interfaces and methods in order to make components (SBB, profiles, etc) aware of each other, and each of them has to be supplied with a deployment descriptor (DD) XML file. We have created a development architecture that consists of the integration of a workflow management system (WFMS) inside the JSLEE AS. The WFMS acts as an intermediary between business analysts and developers, by giving them a common process definition language. The implementation platform is Mobicents [3], an open source JSLEE AS (MSLEE) including also a media server (MS), hosted on top of the JBoss AS. As for the WFMS [4], our choice is JBoss jBPM, since: (i) it has a graphical design tool; (ii) its engine core scheduling mechanism is flexible and there are a variety of action states at a node; (iii) it is open source and offers a strong integration in Java environments. In this way, each JSLEE service is able to call jBPM APIs to create a new process instance and manage it. We have evaluated the effectiveness of our proposal by implementing a complex VoIP service on the MSLEE, and analyzed the relevant performance in terms of call throughput, latency, and development effort. II. P ROPOSED A RCHITECTURE The use of a workflow engine allows both introducing a state machine architecture and using a graphical development Manuscript received April 21, 2011. The associate editor coordinating the review of this letter and approving it for publication was H. Yomo. Authors are with the Dipartimento di Ingegneria Elettronica e dell’Informazione (DIEI), University of Perugia, via G. Duranti 93, 06125 Perugia, Italy (e-mail: {femminella, maccherani, reali}@diei.unipg.it). Digital Object Identifier 10.1109/LCOMM.2011.093011.110851

and visualization tool (called GPD, an Eclipse IDE plugin) to ease and speed up the JSLEE service creation. Our framework achieves these goals by utilizing a single SBB as a starting point for state event delivery. According to the JSLEE specifications, all events generated by resource adaptors (RAs, [2]) must be routed by a component, called event router, to the appropriate SBB. Since any service can be decomposed in states connected by transitions, it is represented as a graph. In this way, a service can be designed as a workflow, utilizing GPD, also by people who do not know JSLEE specifications. GPD creates an XML file that represents the service’s process definition. Each state/node of a graph is represented by a Java class that must both implement the ActionHandler interface and extend the AbstractState class. A single SBB does not include any service code, but rather implements a listener for events generated by RAs and forwards them to the appropriate workflow Java class, according to the service state occupied at that time. This SBB listens for the initial event (e.g. an INVITE message in SIP [5]) and creates a new process instance by reading the XML service process definition. Due to the state design pattern and polymorphism, each subsequent event is delivered to the suitable Java state class. By invoking specific jBPM methods within a Java state class, a developer is able to change the service state through the graph. When the process changes its state, the execute() callback method of the new state Java class is called. Within it, we can retrieve the service state, the needed variables and continue with the service code execution. Through this architecture we can split the business logic in several phases or states, each one able to listen for expected events and to run state-specific logic code. A. Core implementation features The main features of our architecture are: ∙ State machine architecture for service creation. ∙ Single SBB implementation, thus avoiding all issues related to SBB message exchange, which must use the SBB Activity Context Interfaces (ACIs) when SBBs are part of different entity tree, and the SBB Local Interfaces (LIs) when SBBs are in the same tree. ∙ Single Container Managed Persistence (CMP) field. Usually, several CMPs are used to retrieve the persistence of session states and service variables when an SBB event callback is invoked. We need one CMP only, declared in the single SBB, in which we store a StateContext object. ∙ Use of jBPM transient variables to propagate information over the Java path classes through the service graph; they are retrieved by the StateContext object, stored in a CMP. Fig. 1 shows the design approach. In the traditional, plain JSLEE implementation, an initial SIP INVITE event instanti-

c 2011 IEEE 1089-7798/11$25.00 ⃝

1406

IEEE COMMUNICATIONS LETTERS, VOL. 15, NO. 12, DECEMBER 2011

JBoss AS

200 OK

Process Instance

1 SIP RA

2

Event Router

6

10 Service Container Service with jBPM architecture 4 200 OK Process Definition

5

3 SIP Invite

7

183 with SDP

8 11 12

Root SBB

MS

JSLEE

UAS

INVITE with SDP 100 Trying SRD

SIP Invite

UAC

jBPM Engine

JAIN SLEE

CRCX 200 (CRCX) MDCX with SDP 200 (MDCX) with SDP

SIP MGCP

RQNT 200 (RQNT)

RTP (g711u)

RTP

NTFY 200 (NTFY)

9

Service sends some vocal messages NTFY 200 (NTFY)

Fig. 1.

Architectural design and event flow for our jBPM design.

INVITE with SDP 200 OK with SDP ACK

200 OK with SDP ACK

ates a root SBB and a child SBB, which responds with a 200 OK. Then, another child SBB continues service processing. In our solution, the root SBB reads the process definition and creates a new process instance, where the processing of service business code is done through Java state classes. Our solution extends the scope of the SBB functions, like events handling, to plain Java classes used as nodes, without the effort of managing multiple SBBs. This permits an easy reutilization and manipulation of states, which can (i) be combined through the workflow graphic tool, (ii) interact by exchanging data, and (iii) follow a specific business behavior. Thus, a developer has to simply graphically design service lifecycle, define its states, and implement them as a Java class. Each class must extend our abstract classes and implement our interfaces, so Java state classes are handled as a normal SBB. B. Related work The OpenCloud Rhino platform [6] has an XDoclet module and the Finite State Machine (FSM) tool. The former is used to write the DD code in Java class files by utilizing special tags, but developers must still write all these data. The FSM tool [7] creates a state machine in the service. Even if this approach may appear similar to our solution, our proposal is more powerful. In fact, the FSM tool language is quite simple, with few pattern options, thus it is more difficult to create complex state machine diagrams. Instead, we have introduced a complete WFMS which can be easily used to implement advanced control-flow patterns and features. Additionally, [7] relies on JSLEE specifications for data exchange, whereas we can use only one CMP and jBPM transient variables. JNetX JSLEE [8] comes with an IDE tool, but, after an extensive search, we did not found any public document. The Ericsson Composition Engine is suited only for SIP Servlets, with much fewer capabilities than JSLEE ASs [1]. Bessler et al. [9] have integrated a business process engine within a JSLEE container, but with different purposes and architecture. They used it to orchestrate web services, integrating IT resources and telco capabilities. Falcarin et al. [10] have integrated web services in a JSLEE architecture. They have developed a SOAP RA and a service creation environment that permits, starting from the WSDL interface of a web service, to automatically build the correspondent SOAP client wrapper in a new SBB. Maes [11] focuses on service delivery platforms (SDPs) architectures, mainly for web service integration and a J2EEbased SDP implementation.

RTP (g711u) Credit finished BYE 200 OK

Fig. 2.

DLCX 200 (DLCX)

BYE 200 OK

Prepaid card service signaling flow.

III. P ERFORMANCE E VALUATION Due to space limitations we show the implementation of a single service, called Prepaid Card Service (PCS), having a complexity equivalent to commercial services. It has been implemented twice, by following a typical stateless JSLEE programming and through our jBPM-enabled architecture. Tests have been executed in a virtualized environment, by using for the MSLEE a virtual machine with 2 CPU cores, 3 GB of RAM, and the Centos 5.3 32-bit operating system. We used the MSLEE v.1.2.6 GA, deployed on the JBoss v.4.2.3 GA, running in the Java virtual machine v.1.6.0 16, configured to use the parallel garbage collector with a Java heap set to 2.5 GB. In the MSLEE configuration, we used the JAIN SIP RA v.1.2, increasing the number of threads to 192. Traffic is generated by the well known SIPp tool. A Gigabit Ethernet switch connects all network entities, including the MSLEE, the media server (MS), the SIP endpoints and a database (DB, implemented with MySql 5.1). The service handles billing and closes a call if the credit expires. When the service receives a call, it performs some checks and asks for user inputs, by using the interactive voice response facility of the MS. The MS captures DTMF tones sent by the customer device and notifies the MSLEE with them using the MGCP protocol [12]. Then, the MSLEE contacts the callee (user agent server, UAS), and, after that, caller (user agent client, UAC) and UAS can communicate. During their communication, the service implements the operator-defined billing rules and writes the remaining credit in the DB periodically. Fig. 2 shows the signaling flow of the service. The service is created by implementing event callback methods from the SIP and MGCP RA. When a new SIP INVITE arrives, a root SBB is instantiated and the included SDP is used to create a communication channel with the MS. To do this, our service sends Create Connection (CRCX) and Modify Connection (MDCX) MGCP commands to the MS including the UAC SDP. The MS reserves resources for this channel and generates its SDP, which is transmitted back to the MSLEE inside the MGCP response. This communication is done before the SIP call is established, by utilizing the Early

FEMMINELLA et al.: WORKFLOW ENGINE INTEGRATION IN JSLEE AS

1407

TABLE I P ERFORMANCE COMPARISON . Service PCS PCS jBPM

Fig. 3.

Process definition graph.

Media procedure. Thus, the SDP of the MS is forwarded to the UAC inside the “183 Session in Progress” response relevant to the UAC’s INVITE. At this point, the business logic of the service running in the JSLEE AS can instruct the MS to play an audio message to the caller. This is done with the Notification Request (RQNT) MGCP message, which specifies the audio file to be played. In addition, this message specifies also which UAC inputs the MS has to listen to. Then the MS sends a Notify (NTFY) MGCP message to the MSLEE, containing the list of caller’s captured inputs. Based on this information, the business logic of the service can make its choices and apply its policies. Note that all the interactions between the MSLEE and the MS are managed by the RQNT and NTFY sequence of messages, so as to build complex audio menus able to retrieve information from the caller and play messages. When the UAC decides to call another user, through the audio menu he is asked for the destination number and the second phase of the service starts. The business logic receives this information and contacts the callee. When he answers, the two users can communicate and the billing starts. Connection is established through a back-to-back user agent architecture, used to control the call flow. When the destination number is selected, the service sends a SIP INVITE to the UAS that includes the UAC SDP. The UAS response is forwarded to the caller, thus the SDP exchange is complete and the two entities are in communication. During the entire call duration, our service supervises it, applies the operator-defined billing profiles, and records the remaining credit within the DB. The resulting service is rather complex, since it involves several entities that communicate through different protocols. The logic of the jBPM-based service has been split in eight different states. Fig. 3 shows the process definition graph. We have compared these implementations for evaluating the reduction of the service development effort of our proposal and its impact on the JSLEE AS performance, measuring: ∙ Development effort: number of source lines of code (SLOC). In our case, SLOC is significant since the two versions are written in the same programming language, in the same framework, by the same persons and, in particular, the jBPM implementation includes a subset of code lines of the other one. With SLOC, we can calculate the basic COCOMO model for organic projects to estimate the effort applied (in man-months). jBPM-based services also need an extra work to create the process specifications and the service graph. Nevertheless, this

SRD (ms) Avg 95𝑡ℎ pct 41 152 140 196

Throughput (cps) 13 13

SLOC 1298 723

Complexity COCOMO (mm) 3,16 1,71

work is very quick and easy since developers can utilize the GPD tool and, in addition, it is faster and less errorprone than creating DD XML files for each component. ∙ The maximum call throughput, defined as the rate of successfully established SIP calls with a minimum of 99% successfully handled calls. ∙ Set up latency, or, more formally, Session Request Delay (SRD). SRD is measured in the caller side and it is defined as the time interval from the initial INVITE to the first non-100 provisional response (see Fig. 2). It is used to measure the latency for setting up a call session. Table I reports the performance achieved. The jBPM engine overhead causes a slight increase of the average SRD, but in both cases the 95𝑡ℎ percentile of SRD is below 200 ms, which is acceptable. These delays are mainly due to the processing performed in the JSLEE AS and in the MS, since propagations delays are negligible. The maximum throughput is the same, whilst the development effort is almost halved. IV. C ONCLUSION We have shown an implementation architecture that can simplify the development of JSLEE based services, brings new integration capabilities, and reduces the service time to market. Service creation is abstracted as a state-based business process, and graphically designed also by non JSLEE expert developers. Performance penalties are negligible (just a little increase in set up latency), and largely compensated by a consistent reduction of service development effort. R EFERENCES [1] H. Khlifi and J.-C. Gregoire, “IMS application servers: roles, requirements, and implementation technologies,” IEEE Internet Comp., vol. 12, no. 3, 2008. [2] JSR 240, JAIN SLEE v1.1, http://jcp.org/en/jsr/detail?id=240. [3] Mobicents Web Site (April 2011), http://www.mobicents.org. [4] P. Wohed et al., “Patterns-based evaluation of open source BPM systems: the cases of jBPM, OpenWFE, and Enhydra Shark,” Inf. and Software Technol., vol. 51, no. 8, 2009. [5] J. Rosenberg et al.,“ SIP: Session Initiation Protocol,” IETF RFC 3261, June 2002. [6] Opencloud Rhino Web Site (April 2011), http://www.openclould.org. [7] Opencloud Rhino FSM Tool (April 2011), https://developer.opencloud.com/devportal/display/OCDEV/FSM+Tool. [8] Amdocs JNetX Web Site (April 2011), http://www.amdocs.com/Products/Service-Delivery/Convergent-ServicePlatform/Pages/index.aspx. [9] S. Bessler et al., “An orchestrated execution environment for hybrid services,” KiVS 2007, Feb. 2007. [10] P. Falcarin et al., “Communication web services and JAIN-SLEE integration challenges,” Int. J. of Web Services Research, vol. 5, no. 4, 2008. [11] S. H. Maes, “Service delivery platform as IT realization of OMA service environment: service oriented architectures for telecommunications,” WCNC 2007, Mar. 2007. [12] F. Andreasen and B. Foster, “Media Gateway Control Protocol (MGCP) version 1.0,” IETF RFC 3435, Jan. 2003.