Ann. Telecommun. (2012) 67:91–107 DOI 10.1007/s12243-011-0264-9

Design and implementation for integrated services orchestration bus using SCA over heterogeneous networks Cheng Bo & Zhang Yang & Ye Bo & Zhou Peng & Chen Junliang

Received: 13 January 2011 / Accepted: 22 April 2011 / Published online: 10 May 2011 # Institut Télécom and Springer-Verlag 2011

Abstract As the telecom and IT industries converge, pressure is mounting for convergence of service across the two domains, and future integrated services in the telecom domain are subject to specific requirements such as support for end-to-end communication sessions and mechanisms for service interaction across technological borders including telecom, enterprise, and Internet services. This paper provides an integrated services orchestration bus to handle the interoperation and compositions of services from the different domain and focus on the components lifecycle management, normalized message routing, normalized message parsing and mapping, events serialization processing, JNDI register management, and deploy unit. The multimedia conferencing-use case scenario is illustrated, and also the performance is measured and analyzed. Finally, we give the conclusions and future work. Keywords Integrated services . Orchestration bus . Service component architecture . Heterogeneous networks

C. Bo (*) : Z. Yang : Y. Bo : Z. Peng : C. Junliang State Key Laboratory of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing, China e-mail: [email protected] Z. Yang e-mail: [email protected] Y. Bo e-mail: [email protected] Z. Peng e-mail: [email protected] C. Junliang e-mail: [email protected]

1 Introduction Telecom service providers are seeking the development of value-added services or next-generation services that leverage both on the Internet and on telephony networks, i.e., the convergence and integration of services offered by IT providers with telecom operators ones [1, 2]. The reuse and integration of existing IT services in value-added ones is even made difficult both by the increasing software systems complexity and the different middleware standards used for communication [3, 4]. This requires a new, more flexible, and integrated service orchestration bus that will support interoperability between those diverse worlds. Java Business Integration (JBI) [5] is a Java standard for structuring business integration systems along with serviceoriented architecture (SOA). JBI is built on a Web services model and provides a pluggable architecture for a container that hosts service producer and consumer components. Services connect to the container via binding components (BC) or can be hosted inside the container as part of a service engine (SE). The services model used is Web services Description Language (WSDL) 2.0. The central message delivery mechanism, the normalized message router (NMR), delivers normalized messages via message exchange patterns. JBI also defines the standardized packaging for the BCs and SEs and allows the components to be portable to any JBI implementation without modification. The Business Process Execution Language (BPEL) [6] is an XML-based Web services orchestration language, which provides a Web service interface and calls other Web services to do the actual work. The latest version of BPEL 2.0 is an OASIS Committee standard as of April 2007. BPEL defines a model and a grammar for describing the behavior of a business process based on interactions between the process and its partners. The interaction with

92

each partner occurs through Web service interfaces, and the structure of the relationship at the interface level is encapsulated in what called a partner link. The BPEL process defines how multiple service interactions with these partners are coordinated to achieve a business goal, as well as the state and the logic necessary for this coordination. At the core of the BPEL, process model is the notion of peerto-peer interaction between services described in WSDL, both the process and its partners are modeled as WSDL services. Apache Orchestration Director Engine executes business processes written following the BPEL standard. It talks to web services, sending and receiving messages, handling data manipulation and error recovery as described by your process definition. It supports both long and short living process executions to orchestrate all the services that are part of your application. JAIN SLEE [7] concept was brought in as a container for communication services, within the intelligent network architecture. JAIN SLEE is the Java standard for a service logic execution environment, which is a known concept in the telecommunication industry to denote a low-latency, high-throughput event processing environment. The JAIN SLEE activity specifies a Java-based, event-oriented container for the execution of carrier-grade telecom services. The service logic is implemented as a distributed structure made of so called Service Building Blocks (SBB). A service may be composed by different SBBs linked together in a parent child relation. SBBs operate asynchronously by receiving, processing and firing events they are entitled to handle. To this aim, they are attached to streams of events called activity contexts that act like a bus. Also, ContainerManaged Persistence fields are used to store SBB-instance state information. Mobicents [8] is the first and only Open Source Platform certified for JAIN SLEE compliance, which enables the convergence of voice, video, instant messaging, and data in next generation intelligent applications. In this paper, we propose a novel-integrated service orchestration bus approach that integrates the IT resources and telecom functionalities using service components architecture, trying to overcome the limitations like the existence of heterogeneous communication protocols, the extensive use of event driven and asynchronous interaction, and the real-time messages delivery requirements. The main innovation in our solution is to integrate a BPEL-based workflow engine and JAIN/SLEE-based telecom service engine using the JBI service engine technology into the integrated services orchestration bus. In this way, we can create an integrated service orchestration process with deployable BPEL scripts to control the service logics and to invoke the SBB-based service logics in the telecom service engine via SOAP and SIP protocol. The remainder of this paper is structured as follows. In Section 2, we discuss the related works. In Section 3, we

Ann. Telecommun. (2012) 67:91–107

describe the framework of the integrated services orchestration bus over heterogeneous networks, in Section 4, we describe the multimedia conferencing service system, and in Section 5, we describe the implementation; we describe the performance measurement and analysis in Section 6. Finally, in Section 7, we present our conclusions.

2 Related works Although there is much work on standardization and reference frameworks standalone over the heterogeneous networks, there appears to be little work on integrated service orchestration platforms and their deployment characteristics with respect to services and service growth. TeamCom [9] project aims to enabling fast, easy, and cost-efficient provisioning of value-added services, in particular B2B services. TeamCom project presents a service creation environment that supports the application developer to compose a service based on reusable components and to describe the business process. However, BPEL has not been developed for control of specific, in particular real-time, communication services in heterogeneous networks. Especially, presents a parser for translating the business process description into Java code and supporting the deployment of the service in a service execution environment. The provided elementary communication service components hide the underlying heterogeneous communication networks. Thereby, the developer does not need any detailed knowledge of communication protocols and is able to focus on the application logic instead. Service Platform for Innovative Communication Environment (SPICE) [10] project aims to develop an extendable overlay architecture and framework to support easy and quick creation, test, and deployment of intelligent mobile communication and information services. The approach to service creation in SPICE is driven by the constraint of being able to address heterogeneous target execution environments, where the technologies range from general information technology to very specific telecom ones. In such a heterogeneous environment, the approaches to service creation should be as general as possible, supporting a stepwise approach that drives the developer from abstract to concrete definitions targeting a specific service execution environment. SPATEL [11] language is proposed to allow the specification of services in a platform independent manner, including annotations concerning semantic and nonfunctional properties. Such annotations are imperative in the context of automatic service composition. StarSLEE [2] platform extends JAIN-SLEE in order to compose JAIN-SLEE services with Web services, together with a graphical service creation environment for helping

Ann. Telecommun. (2012) 67:91–107

IT developers in creating value-added services and communication Web services, and also defined a specific service description language StarSDL to used for describing an event-oriented service scenario, which well suits the telecommunication service domain, StarSLEE can actually behave as a web service orchestration engine. Hybrid service execution environment [12] presents a novel architecture and design considerations for a service orchestration environment suitable for telecom and Internet applications. The main innovation in our solution is to integrate a workflow engine using BPEL inside a JAIN/ SLEE container. In this way, we create an orchestrated service environment that uses fast deployable BPEL scripts to control service-building blocks or external entities via a variety of protocols such as SIP, intelligent network application part, or SOAP. SewNet [13] is a framework for creating applications exploiting Telecom functionality exposed over a converged IP network. SewNet Faced to the operators can take advantage of their core functionalities like Location, Call Control, etc. by exposing them as services to be composed by developers with third-party offerings available over the Web. To hide the complexity of underlying Telecom protocols from application developers, the operators are steadily adopting SOA and reference standards like ParlayX and IMS. More specifically, SewNet provides an abstraction model for encapsulating invocation, coordination, and enrichment of the Telecom functionalities. SewNet renders a service creation environment on top of this model, and SewNet caters to various different categories of developers.

93

Fig. 1 Integrated service bus over heterogeneous networks

3 Integrated services orchestration bus

Here, the SEs provides the business logic and transformation services to other components, as BPEL SE and Mobicents SE. The integrated services orchestration bus provides primary function is to route normalized message exchanges from one component to another. It is vital to integrate the Mobicents as a service engine into the integrated services orchestration bus seamlessly to provide the capability for the hybrid services execution in platform. The framework of integration layer for the service engine into the bus is shown as Fig. 2. Here, the integration layer for the services orchestration bus contains six main modules, such as message processing, deployment unit, Lifecycle manager, Java naming, and directory and H2 memory database.

As services intrinsically differ from each other, they are often required to be hosted in an appropriate execution server in order to run efficiently. Integrated services orchestration bus has been designed to cater for the different kinds of services and their associated characteristics both in IT and Telecom domain. The integration service orchestration bus is based upon the JBI 1.0 standard, and JBI specifies a container model for integration and defines an architecture that allows the construction of integration systems from the plug-in components. An outline of our integrated services orchestration bus using the service components architecture is shown in Fig. 1. The proposed integrated architecture comprising a Mobicents container with SIP and IN resource adaptors, and a BPEL container, both core components are connected to the normalized message router. Here, the integrated service orchestration bus provides the pluggable infrastructure for adding service engines (SEs) and protocol BCs.

Fig. 2 Integration layer for service engine to the bus

94

Each component has a life cycle that begins when the component is installed, which puts the component into the “installed” state. All execution states of the component are considered to be substates of the “installed” state. Traditionally, components start life in an empty state. The component and the JBI environment have no knowledge of each other. Once the component is installed into the JBI environment, the component enters the shutdown state. In this state, the JBI environment initializes any resources needed by the component. From the shutdown state, a component can be initialized and moved into the stopped state. In the stopped state, a component is fully initialized, and all of its resources are loaded into the JBI environment. When a component is ready to process messages, it is moved into the started state. In this state, the component, and any service units deployed into the component, can participate in message exchanges. Figure 3 illustrates this by adding a single “paused” substate to the standard “Started” state [5].

start() Shutdown

shutDown()

Paused

stop()

Stopped Execution State

start()

Installed State

resume()

3.1 Components lifecycle management

Installation State

pause()

Lifecycle management module mainly controls all the other modules and to collaborate with each other and is charge of startup the Mobicents kernel. When a service engine or binding component is installed, it then can be started and stopped using MBean interfaces defined in this specification. The normalized messages are the messages of an integrated service orchestration bus message exchange. Generally, the messages are events in mobicents service engine. Hence, the message mapping module deals with the messages from the BPEL service engine to invoke the external Web services, and then routing to proper messages parser for further handling to map the NMR messages into the events type. JNDI registration module provides the Application Program Interface (API) for the registration with JNDI for some classes in Resource Adaptor RA/SBB, as well as management for necessary objects, defined by JAIN-SLEE, to register with JNDI. This would facilitate finding objects at run time for the RA/SBB. Unit deployment module provides hot deploy for deployable unit, such as SBB deploy unit, RA deploy unit, by monitoring a specific folder of jar package, if any valid jar package is added into the folder. The unit deployment module will deploy those units to the integrated services orchestration bus. Database configuration module is charge of reading the configuration file to create the appropriate connection pool to provide the convenience for the Java Database Connection (JDBC) database. H2DB is the in memory database, which stores the temporary status variables in the runtime.

Ann. Telecommun. (2012) 67:91–107

Running

Started

Extension State

Legend

Uninstalled State

Fig. 3 Extended component life cycle state diagram

This extra substate is accessed through use of a “pause” control supplied by the extension MBean. Note that on restart of the JBI environment, the JBI implementation MUST attempt to restore all components to their previous standard running state. If a component wishes to instead restart in a different, extended substate of the “Started” state, it must supply its own mechanisms to persist the extending running state, and restore it during restart of the component by JBI. All life cycle extensions are considered substates of the started state. Here, we choose to start and stop the component process flows separately to illustrate the components lifecycle management. Especially, it is important to start the components, which can make those components ready to process the messages. This process is called after the components initiate, both when the component is being started for the first time and when the component is being restarted after a previous call to shut down. If stop process was called previously but shut down process was not, start process can be called again without another call to initiation. If the component is unable to start, the startup process will throw the JBI exception. Figure 4 shows the process to start the component. To stop the component can make the component stop accepting messages for processing. Figure 5 shows the process to stop the component. It is obvious that after a call to this process, to start the process may be called again without first calling initiation. If the component is unable to stop, the process flow to stop the component will throw the JBI exception. 3.2 Normalized message routing The NMR is the part of the JBI environment that is responsible for mediating messages between JBI components. The JBI components never send messages directly between each other. Instead, they pass messages to the NMR. The NMR is responsible for delivering the messages to the correct JBI endpoints. This allows the JBI compo-

Ann. Telecommun. (2012) 67:91–107

95

Fig. 4 Process flow to start the component

nents, and the functionality they expose, to be locationindependent. The activity diagram in Fig. 6 depicts a oneway service invocation between BPEL and Mobicents SEs, including a message exchange instance. Here, BPEL SE acts as a service consumer, invokes the desired service by creating and establishing a request message exchange, containing the request message. BPEL SE then sends the message exchange instance to the NMR. This is shown by the message process flow between the BPEL SE and NMR. The NMR determines which service provider should provide the requested service and operation and routes the message exchange

Startup state is

True

Y Close the Receiver thread

Invoke the stop() method in Mbean Stop the Mbeans in SleeContainer

N Set startup state to

False

End

Fig. 5 Process flow to stop the component

instance for delivery to the provider. This is shown by the message process flow between the NMR and the Mobicents SE. Especially, on the one hand, the Mobicents SE can process the corresponding messages from the BPEL SE, and on the other hand, the Mobicents SE can be event-driven, to send and receive the message exchanges can take place at the same time, as shown in the activity diagram in Fig. 6. Figure 7 depicts a request– response invocation between a JBI-hosted BPEL Service Engine and an external Web service provider. The BPEL SE creates and initializes an in–outpatterned message exchange instance. BPEL SE sends this to the NMR; it is important to determine which service provider should process this invocation. Under this circumstance, the binding SOAP BC is selected. When SOAP BC receives the message exchange and then denormalizes the request message to the external provider using its communications protocol. Web service providers process the request and return the normal response message. Then, the SOAP BC normalizes the response message and adds it to the message exchange. The message exchange is then sent to the NMR, which routes it back to the consumer, BPEL SE. 3.3 Normalized message parsing and mapping Real-time communication component services are usually triggered by signaling messages like a SIP message instead communication Web services are usually Web service interfaces of common telecom functionalities which are triggered by a SOAP message. The service messages adaptor provides the functionality to parse soap message from the service bus and transferred into internal control commands that defined by service component. Therefore, the message process could be divided into two parts as Fig. 8 shows. It is obvious that the left part is message parsing from service bus and the right part is event triggering defined by SBBs. Therefore, the service messages mapping acts as a communication bridge between a component service and its correspondent Web service implementation. Thus, a SOAP event has been introduced to represent information coming from whichever Web service implement. Here, the XML DOM is adopted as a standard way for accessing and manipulating XML documents, and the XML DOM views an XML document as a tree-structure. All nodes can be accessed via the tree. Their contents can be modified or deleted, and new elements can be created. The node tree shows the set of nodes and the connections between them. The tree starts at the root node and branches out to the text nodes at the lowest level of the tree. The SOAP request in the NMR is listed as follows

96

1 active 2009-06-10T19:30:00.530Z true 1 true 2 2

Here, it is important to get the normalized message from the message exchange which is defined in the integrated services orchestration bus, and then to parse it from the NM to get DOM document recursively, and the whole structure tree of the document object in memory is shown as Fig. 9. After getting the document object, it is necessary to traverse the tree and save the related information into the hash table. More details are described as follows:

Element root = document.getDocumentElement(); String namespaceURL = root.getNamespaceURI(); elementmap.put("namespaceURL", namespaceURL); String eventName = root.getNodeName(); elementmap.put("eventname", eventName); NodeList nodelist = root.getChildNodes(); parseChild(nodelist,elementmap);

The following parseChild methods are used to resolve a list of child nodes for each node, if the child still has a child Fig. 6 Service invocation between BPEL and Mobicents SEs

Ann. Telecommun. (2012) 67:91–107

node, then recursively call the method until the child no longer has child nodes.

public parseChild(NodeList nodelist, HashMap emap) { for(int i=0; i < nodelist.getLength(); i++) Node node = nodelist.item(i); String name = elementNode.getNodeName(); String content = elementNode.getTextContent(); elementmap.put(name, content); parseChild(elementNode.getChildNodes(),emap); }

The second step is to get the event name from the HashMap and then to match the event name with the corresponding event name that got in the deploy section. When matched, get the object of concrete service’s class by the reflect method and set the event attribute by invoking the concrete service’s method. At this time, to generate the event with the pattern of factory method and to get the event from the activity and eventually trigger the event in JSLEE. Therefore, multimedia conferencing service messages adaptor acts as a communication bridge between a component service and its correspondent Web service implementation. Thus, a SOAP event has been introduced to represent information coming from whichever Web service implementation. The activity in the SLEE specification is defined as an abstract stream of events, namely, a finite state machine which can send the event in accordance with a change of state. There is an implicit state variable associated with each activity context that indicates the state of the activity context. SBB entity obtained the event from the ActivityContext. It can be understood as an event bus; the SBB entities can obtain different ActivityContext event triggers

Ann. Telecommun. (2012) 67:91–107 Fig. 7 BPEL SE invokes external Web service

Fig. 8 Messages process for service message adaptor

97

98

Ann. Telecommun. (2012) 67:91–107

Fig. 9 Document object tree

the appropriate action in accordance with its binding and make the appropriate response actions. First of all, take out the eventName from the elemap and then invoke the related methods via the service name, in the invoke() methods, with the useful information in the passed out message as parameters to set the servicemixMessage object properties, then invoke the factory method to create ServicemixEvent object based on the servicemixMessage, the next step according to the confID elemap or PartID has been taken from the HashMap with the corresponding activity (if not the new), and finally invoke the postEvent method to send to the corresponding event to the corresponding activity. 3.4 Events serialization processing For the routing messages from the JBI, NMR needs to be mapped to the event type corresponding Mobicents activity. More than one continuous message may correspond to the same activity for the message received from NMR is concurrent. The message corresponding to the same activity need to be serialized and only when previous message’s respond sends back to NMR, the next message can be processed because the activity’s shared properties may be reset by the concurrent message. In order to implement the serialization of the message, a flag bit and a waiting queue of the message needs to be maintained in the activity. Initialize the flag to 0. When receiving the message, if the flag is 1, push the properties to be set and the event to be sent into the queue; else, send the event and set the flag as 1. In the respond side, check the queue after sending the respond message back. If the queue is not empty, then set the properties, send the event pulling from the queue, and set the flag as 1; else, set flag as 0. Figure 10 shows the whole events serialization processing. Because sending and replying belong to two threads, if the replying thread completes the sending response and setting the busyflag to 0, and then CPU is occupied by the

sending thread, and sending thread will determine busyflag as 0 to send events. The CPU will be occupied by the replying threads and remove the head of the queue, and by sending the event, the results could not be estimated. It will also need to synchronize the sending and replying threads with the synchronized keyword. 3.5 In memory database service engine H2 [14] is a Structured Query Language (SQL) database engine written in Java that implements the JDBC API, which can work as embedded database or in server mode and is a browser based console application, as well as strong security features and disk based/in-memory databases tables. Here, it is necessary for the integrated service orchestration-use cases as high performance operations, read-only databases, may not be required to persist data or persist changes to the data. The SQL used is standard SQL with some addition to support the features of H2 and can create three types of tables. A cached table is the default type of table. The data are persistent and not limited by the memory. A memory table is also persistent, but the index of data is kept in the memory, so memory table cannot be too large. A temporary table is deleted when closing the database. H2 database engine supports the in-memory mode, where the data is not persisted. In this circumstance, the database URL is jdbc:h2:mem:. In this case, the database URL must include a name such as jdbc:h2:mem: db1. Accessing the same database using this URL only works within the same virtual machine and class loader environment. To access an in-memory database from another process or from another computer, there is a need to start a TCP server in the same process as the in-memory database was created. The other processes then need to access the database over TCP/IP, using a database URL as: jdbc:h2:tcp://localhost/mem:db1. Especially, all the data manipulation operations in H2 are transactional and twophase commit protocol is supported as well. Here, we

Ann. Telecommun. (2012) 67:91–107

99

Fig. 10 Events serialization processing

described the initiation and startup of the H2 service engine. To initialize the H2 component, which means to perform the initialization required by the H2 component but does not make it ready to process messages, the more detailed steps are described as follows:

5. Invokes the start() method for the dbConfigManager to configure the JDBC connection pool. 6. Open the message Receiver 7. Set the startup token value, __started=true.

1. Configure the H2 context with the input parameter. 2. Instantiate the dbConigManager class to manage the JDBC connection. 3. Read the H2 in memory database configuration files with the dbConfigManager instance. 4. Create a TCPServer instance for the org.tools.Server class to open the H2 database. 5. Initiate the H2SUManager with the context of H2

3.6 JNDI register management

To start the H2 memory database component, which means to make the H2 component ready to process messages, this process is called after initiation, both when the component is being started for the first time and when the component is being restarted after a previous call to shut down. If the stop() method was called previously but shut down method was not, start method can be called again without another call to initiate. 1. To check whether the H2 components is started, if started successfully, and return back. 2. To check whether the H2 components initiated successfully, if not, and throw the JBIException. 3. To check whether the components get the delivery channel from the H2, if not, and throws JBIExcepton. 4. Start the H2 TCPServer

The JNDI is a Java API for a directory service that allows Java software clients to discover and look up data and objects via a name. Like all Java APIs that interface with host systems, JNDI is independent of the underlying implementation. Additionally, it specifies a service provider interface that allows directory service implementations to be plugged into the framework. JNDI register is embedded in the Mobicents kernel to discover and look up data and objects via a name in the ServiceMix environment. Although there is a set of JNDI mechanism, but some API is invalidation, it is vital to revise the mobicents kernel mechanism to support the corresponding API invocation under the ServiceMix environment. Also, it is important to modify the (NamingContext)# createSubcontext method to the (NamingContext)# bind method in the mobicents kernel to support to discover and look up data and objects via a name. To the former (NamingContext)# createSubcontext method, the createSubcontext means the empty directory explicitly in the JNDI, while the NamingContext in the ServiceMix cannot support this method, which creates the directory implicit and bind an object via name immediately in this directory.

100

And also, to add the newRef method in the MobicentsSbbDescriptorInternalImpl class is needed, and the implementation is described as follows:

NewRef () throws Exception: NamingException Parameter: String string, means the global name in the java:slee directory, such as “java:slee/activity/nullactivity”. Return: The bind object that JNDI referenced Exception, which means not to find the assigned name in the JNDI directory. 1. Get the substring after the “/” charater in input parameter. 2. Assigned the string before “/” to the stringhead variable. 3. Generate the “java:comp/env/slee“ + substring fullname. 4. Lookup the sleectx directory with the strinhead from the initiation context in JNDI. 5. Lookup the new object newref that the substring in string binds in the sleectx directory. 6. Re-bind the object with the fullname and newref in the NonSerializableFactory

3.7 Deploy unit Deployable unit is a Jar file that can be installed in the integrated service bus. A deployable unit may contain services, SBB jar files, event jar files, Profile Specification jar files, resource adaptor type jar files, and resource adaptor jar files. Each of these jar files contains the Java class files and the deployment descriptors of one or more of these components. There contain two kinds of deploy unit, that is SBB deploy unit and RA deploy unit. To the SBB service management, which is faced to the top applications, in other words, which is the main parts for the service block building construction and deployment, contains the object persistence, and the data objects like components lifecycle and database connection are persisted by the SLEE container automatically. SBB can be divided into SBB entity and SBB object. To the whole SBB service, management unit contains the SBB factory, persistence management, SBB objects pool management, service deployer, and all of these are invisible to the actual users. To the users, the deploy file is sbb.jar, and the service description file is service.xml. To the Resource Adaptor, resources are entities that represent and interact with other systems outside the SLEE, such as network devices, protocol stacks, directories, and databases. Resource adaptors adapt particular resources to the requirements of the SLEE. Here, the mobicents–http-consumer-su should be deployed. There is a need to configure the servicemix-http binding component as the service consumer to the service unit in order to invoke some service. Especially, the role of

Ann. Telecommun. (2012) 67:91–107

the BC is configured as a consumer to invoke the test service in the mobicents service engine.

Next, the mobicents–http-provider-su should also be deployed to the integrated services bus, and the corresponding xbean.xml is described as follows.

Service units include a deployment descriptor that indicates the component into which each SU is to be deployed. Often, multiple deployments are required to create a new service or consumer application within a JBI environment. To support this directly, JBI provides a composite deployment capability, where deployments meant for different components can be grouped into a service assembly, or SA. Such an assembly includes a composite service deployment descriptor, detailing to which component each Service Unit contained in the SA is to be deployed. Some dependencies should be added to the mobicents–sa/pom.xml as follows. org.mobicents.core mobicents-su 1.0-SNAPSHOT org.mobicents.core mobicents-http-consumer-su 1.0-SNAPSHOT org.mobicents.core mobicents-http-provider-su 1.0-SNAPSHOT

Ann. Telecommun. (2012) 67:91–107

Thus, the mobicents service engine exposes the services via the service provider role, in the similar, also which can invoke the external multimedia conference services. 4.0.0 org.mobicents.core mobicents pom 1.0-SNAPSHOT Mobicents JBI Component mobicents-sa mobicents-su mobicents-http-consumer-su mobicents-http-provider-su

Now, the mobicents–su, mobicents–http-consumer-su, mobicents–http-provider-su, mobicents–sa, and pom.xm created. At this time, the maven clean install command should be entered, then the build successful appeared, and the service assembly created successfully, and which can be deployed.

4 Mobicents SE implementation class diagram Integrated service orchestration bus provides many components, such as HTTP BC, JMS BC, and so on. To the service engine, such as BPEL SE, Mobicent SE and H2 SE, and so on, which implementation is based on the JBI specification standard, here, we illustrated the event-driven telecom service engine, in another words, the Mobicents SE into the integrated service bus over the heterogeneous networks. The other service engines implementation is similar. The static relationship for the class diagram of the Mobicents service engine is illustrated as Fig. 11. Especially, to the javax.jbi.component.ComponentLifeCycle interface, it must be implemented by a JBI component to provide initialization, start, stop, and shutdown life cycle processing. The javax.jbi.component.Component interface is implemented by component implementations; it allows the JBI implementation to query the component for various types of information. Here, MComponent implements javax.jbi.Component interface, creates a new component life cycle instance at the initialization moment and provides methods to get the ComponentLifeCycle and ServiceUnitManager instance. MLifeCycle implements javax.jbi.ComponentLifeCycle interface. When the service engine is deployed into ServiceMix, the construction of MComponent will start a new life cycle of this component.

101

MContext includes some important service engine’s properties and provides methods to access these properties. MSUManager implements javax.ServiceUnitManager interface. When the service engine component starts, this object will do some initialization work. Receiver receives message from normalized message router and delivers it to the service engine for the further process. JbiMessageExchangeEventRouter routes the normalized JBI message from or to the delivery channel. MService plays a role of connecting JBI core and service engine. The message delivery direction is from JBI delivery channel to service engine. MConsumer plays a role of connecting JBI core and service engine. The message delivery direction is from service engine to JBI delivery channel. MMapper implements the conversion between JBI normalized message and the message that service engine can process. Especially, both service engines can serve as service consumers, service providers, or both. Here, we illustrated the Mobicents services engine can serve as a service consumer, and Fig. 12 shows the corresponding messages message sequence diagram. Now, the more details to invoke an external service process are introduced as follows: first, the implementation class of the activity interface invokes a certain methods in MessageHandler to get a message exchange from the DeliveryChannel then invokes the invokeService () method in MobicentsConsumer class to send service requests through the DeliveryChannel. The more details to receive a response from the external service process are introduced as follows: first, MobicentsComponent class creates a new life cycle object for the component, and begins to initialize the components with the method init (context) in MobicentsLifeCycle. Then, the object of MobicentsContext class begins to create the objects of JbIMessageExchangeEventRouter class and MobicentsConsumer class. Next, and to generate an object of Receiver class with the start() method in MobicentsLifeCycle.object, then this object of Receiver get a DeliveryChannel with the getChannel() method, and to start the thread to listening whether there was any message exchange in channel. If listening to the message exchange, and to invoke the onJbiMessageExchange() method in JbIMessageExchangeEventRoute class to judge the roles for the message exchange. And then, MobicentsConsumer create an object of MobicentsMapper class to parse the message exchange, and get the HashMap objects. Finally, it is to send the converted event type by invoking the MessageHandler processMessage () method. Similar to that described above, the message sequence diagram for the Mobicents services engine as a service providers is shown as Fig. 13.

102

Ann. Telecommun. (2012) 67:91–107

Fig. 11 Mobicents SE Implementation class diagram

When an external service consumer sends a service request bound to the particular protocol, to the binding component. The binding component converts the request to normalized form, as described in a WSDL model that describes the service exposed by the end point exposed by the BC to the consumer. The BC then creates a Message Exchange (ME), which is a container for messages involved in various simple message exchange patterns. It sets ME metadata describing the desired service and operation to be performed. Finally, the BC sends the ME, via its delivery channel, to the NMR for delivery to a service provider. After accepted the ME, the binding denormalizes the message into protocol and transport format,

and sends the message across the wire to the external service provider. As the message defined as “Event” in Mobicents, after parsing the normalized messages in NMR, and the event type must be created according to the requirement and the activity, which is defined as events flow in JAIN SLEE specification, also should be got from the NMR. Then trigger the event in the Mobicents service engine.

5 Multimedia conferencing service system The multimedia conference process allows the creation of a conference and the dynamic management of the

Ann. Telecommun. (2012) 67:91–107

103

Fig. 12 Sequence diagram for mobicents SE as a consumer

participants and media are involved. There contains some real-time Web service, such as multiple party call control, create conference and short message service, and also exists non real-time Web services, such as user authentication service and charging service. The architecture used is the same adopted and defined in the Parlay X approach. Especially, we illustrate the steps to create conference scenarios. Figure 14 shows the framework of integrated service orchestration bus based multimedia conferencing system. When the chairman sends a request to create conference to the multimedia conference server, it deployed the integrated service bus and then conference

server begins to receive the request messages, transfers the SOAP messages into normalized messages, and then routes the normalized message to the BPEL SE. At this time, BPEL SE receives the message from the integrated service bus, and invokes the BPEL flow to create conference which has been compiled. After some necessary process, BPEL engine invokes Web service provided by Mobicents SE to send the request message. Mobicents SE receives the request to create conference from the NMR. What do the first is to parse the normalized message, and then map the normalized message to the event which defined in the Mobicents SE, which begins to execute the logic of multimedia

104

Ann. Telecommun. (2012) 67:91–107

Fig. 13 Sequence diagram for mobicents SE as a provider

conferencing service. Mobicents SE interacts with media server by SIP RA to SIP serve. Finally, RTP or RTCP media channel is established between the participants and the media server.

6 Performance measurement and analysis Our performance measurements have been tested on an Intel Xeon E5420 2.5 GHz application server with the 10 G

RAM, under the RedHat Linux 9.0, in which integrated service orchestration bus and BPEL SE and Mobicents SE are deployed. Here, the loadRunner tool is used to measure the load and performance with multimedia conferencing scenarios that is running on the integrated service orchestration bus. Especially, the hit per second, and throughput and transaction summary are to evaluate the performance for the integrated service orchestration bus. The service sequence is S1: Create Conference, S2: Create Chairman Connection, S3: Get User Status, S4: Get Media, S5: Set

Ann. Telecommun. (2012) 67:91–107

Fig. 14 Prototype of multimedia conferencing system

Chairman Media, S6: Play Voice, S7: Create New Chairman Connection, S8: Set New Chairman Media, S9: New Chairman Play, and S10: Change Chairman. Here, the virtual users (Vusers) is used to determinate the user load on the integrated service orchestration bus at any given moment. Here, we configure 25 Vusers to use the multimedia conferencing services, and the time last for 10 min as shown Fig. 15. Running Vuser is used to determine the Vuser numbers that load on the integrated service bus at any given moment. Figure 16 shows the corresponding Hit per Second with 25 Vusers. Here, the “hits per second” means the number of hits made on the integrated service bus by Vusers during each second of the load test. Hits per Second diagram can evaluate the amount of load Vusers generate in terms of the number of hits. From Fig. 16, it is observed that the number of hits per second is stable and keeps 112 hits per second. Figure 17 shows the corresponding throughput.

Fig. 15 Running Vuser for conference services

105

Here, the throughput displays the amount of throughput (in bytes) on the integrated service bus during the load test. Throughput represents the amount of data that the Vusers received from the server at any given second. Which can be evaluated the amount of load Vusers generate, in terms of server throughput. From Fig. 17, it is observed that we can draw a conclusion that the number of hits per second is stable and keeps 57,945 bps. The following Fig. 18 shows the corresponding multimedia conference service transaction summary. Here, the transaction summary means the number of transactions that passed, failed, stopped, or ended with errors. From Fig. 18, it is observed that the average number of the passed transactions is 7,023 while the number of failed transactions is only 11 within 10 min for different multimedia conferencing services. We find that the failed transaction is only caused when the request exceeds the processing capability for the load balancer.

7 Conclusions In this paper, we have proposed an integrated service orchestration bus using service component architecture aiming to address the supporting issue of flexible IT and Telecom Web services together. Based on this integrated service orchestration bus, we implement a novel hybrid Web service-based multimedia conference system and get some encouraging performance results. In the future work, we will put a focus on good performance and further improvement. We have deployed and run our integrated service orchestration bus together with the multimedia conference system in Beijing Unicom Corporation Ltd. and we plan to further improve the concurrency processing capability and the fault-tolerance proposal.

106 Fig. 16 Hit per second for conference services

Fig. 17 Throughput for conference services

Fig. 18 Transaction summary for conference services

Ann. Telecommun. (2012) 67:91–107

Ann. Telecommun. (2012) 67:91–107 Acknowledgment This study is supported by National Natural Science Foundation of China (Grant No. 61001118); “973” program of National Basic Research Program of China (Grant No. 2011CB302704).

References 1. Chou Wu, Li L, Liu F (2008) Web services for communication over IP. IEEE Commun Mag 46(3):136–143 2. Falcarin P, di Torino P, Venezia C (2008) Communication Web services and JAIN-SLEE integration challenges. Int J Web Serv Res 5(4):59–78 3. Gomez M, de Miguel TP (2007) Advanced IMS multipoint conference management using Web services. IEEE Commun Mag 45(7):51–57 4. Wu W, Foxl G, Bulut H, Uyar A, Huang T (2007) Service oriented architecture for VoIP conferencing. Int J Commun Syst 16(4):445–461 5. Sun Microsystems (2005) Inc. JSR 208, Java Business Integration 1.0 Final Release 6. Web services Business Process Execution Language Version 2.0, OASIS standard, 11 April, 2007. http://docs.oasis-open.org/ wsbpel/2.0/OS/wsbpel-v2.0-OS.html

107 7. JSR 240, JAIN SLEE v1.1 @ http://jcp.org/en/jsr/detail?id=240 8. Mobicents Project, Mobicents: The open source VoIP middleware platform. Online: https://mobicents.dev.java.net/ 9. Lehmann A, Eichelmann T, Trick U, Lasch R, Ricks B, Tönjes R (2009) TeamCom: a service creation platform for next generation networks. In: Proceeding of the Fourth International Conference on Internet and Web Applications and Services, Venice/Mestre, Italy 10. Cordier C et al (2006) Addressing the challenges of beyond 3G service delivery: the SPICE platform. In: Workshop on applications and services in wireless networks. ASWN, Berlin, Germany 11. Almeida JP, Baravaglio A, Belaunde M, Falcarin P, Kovacs E (2006) Service creation in the SPICE service platform. In: Proceedings of Wireless World Research Forum. Heidelberg, Germany 12. Bessler S, Zeiss J, Gabner R, Gross J (2007) An orchestrated execution environment for hybrid services. Fachtagung Kommunikation in Verteilten Systemen, pp 77–88 13. Mittal S, Chakraborty D, Goyal S, Mukherjea S (2008) SewNet—A framework for creating services utilizing telecom functionality. In: Proceedings of World Wide Web Conference, pp 875–884 14. H2 project, http://www.h2database.com/html/main.html