Recruiting & HR

An Orchestrated Execution Environment for Hybrid Services

Description
An Orchestrated Execution Environment for Hybrid Services
Published
of 13
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  An Orchestrated Execution Environment forHybrid Services Sandford Bessler 1 , Joachim Zeiss 1 , Rene Gabner 1 , Julia Gross 2 1 Telecommunications Research Center Vienna (ftw.), 2 Kapsch CarrierCom Abstract.  Influenced by the success of web service technologies for thedevelopment and deployment of IT services, the telecommunications R&Dcommunity starts adapting and building similar service delivery platforms,trying to manage the hard constraints of telco domains, such as: existenceof heterogeneous protocols, extensive use of asynchronous communicationsand real-time delivery requirements.In this work we present a detailed analysis of an enhanced JAIN/SLEE ar-chitecture in which a workflow engine has been seamlessly integrated, beingcapable to orchestrate service entities from both telecom and IT domains. 1 Introduction Given the intense competition in the telecommunication industry, the service provi-ders have to decrease the time to market of new created services from eighteento three months. In the IT world, techniques such as the web service compositionhave been increasingly used to create new services in a short time, even in a semi-automated way (see [3],[5] for composition approaches). In telecommunications, ser-vice development in the Intelligent Network environment has been busy for decadesto solve the service or feature interaction problem: how to correctly react to a callevent that would trigger several service features a user has subscribed to. With theapparition of new service delivery platforms for hybrid services such as Parlay or theIP Multimedia Subsystem, new entities to orchestrate services have been proposedsuch as Service Brokers (Parlay) or SCIM (Service Capability Interaction Managerin IMS).In this paper we propose a novel service orchestration approach in a hybridservice environment that integrates IT resources and telco functionalities, trying toovercome obstacles like the existence of heterogeneous protocols, the extensive useof asynchronous methods (callbacks, events), and real-time delivery requirements.The main innovation in our solution is to integrate a workflow engine usingBPEL (business process execution language) inside a JAIN/SLEE (see section 2.2)container. In this way, we create an orchestrated service environment that uses fastdeployable BPEL scripts to control service building blocks or external entities viaa variety of protocols such as SIP (session initiation protocol), INAP (intelligentnetwork application part) or SOAP. The performance increase compared to thestandard composition of web services stems from the low latency in the communi-cation between internal service components. Much flexibility is gained as well be-cause, from the perspective of the service composition engine, it makes no differencewhether the orchestrated parties are external web services or service building blocksrunning locally in the SLEE container. In contrast to that, a BPEL engine runningexternally to the SLEE container would use either SOAP or a remote protocol andwould need converters to connect to SLEE service building blocks.A common drawback of heterogeneous platforms is that the service logic is dis-tributed and it is difficult to package it in one single deployable unit. Our approach  makes this possible that internal SBBs and BPEL scripts can be deployed together.Third party service enablers remain external but are represented as business processpartners in the deployed scripts.To our knowledge, no work published at the time of writing has conceivedthe proposed integrated architecture using a full standardized environment suchas JAIN/SLEE with a standardized process scripting language such as BPEL, toprocess hybrid (Telco-IT) services.In the literature we find quite a few works devoted to the orchestration of telcoservices: the authors in [4] present a service architecture comprising an orchestrationfunction using BPEL, without mentioning the use of a standardized platform. Allthe service components expose web service interfaces. In [2] the authors consider aSLEE environment (StarSLEE) as well and analyze composition using BPEL, butthey seem to reject the idea of integrating an existing BPEL engine.Our orchestrated service platform can be optimally deployed in an IP Multi-media Subsystem (IMS) service context. Although other service platforms exist forintegrating SIP, IN and web based protocols (such as OSA/Parlay and Parlay X),the native SIP application servers provide more flexibility. Thus, they can processa SIP message with extended headers or body information without having to fitit to a certain service capability function like call control, presence or messaging.Indeed, a SIP message from a user client can convey additional information to startor control a service application; therefore, any server on the signalling path has tomake sure that this information can reach the application. Among native SIP appli-cation servers, an alternative solution is based on the SIP servlet API, which usesthe well known programming model of HTTP servlets. We decided however to usethe JAIN/SLEE technology because of the flexible resource adaptor concept thatcan be applied to other protocols than SIP or SOAP, and because of the powerfulevent model, as we will see in the architecture section. 1.1 A motivating example A real time scenario that demonstrates the service composition benefits is called”Expert on Call” and has been described in [1] in the context of an IMS environment.In this scenario, a technician is debugging a problem somewhere on site. In case heencounters difficulties in the process of solving the problem, he activates the ”Experton Call” application and asks advice either from a colleague who is working nearbyor from one of the expert group back in the office. Before putting the call through toa colleague nearby (using a location service (LS) to determine who is nearby) or toan expert, the application determines the availability information of the potentialhelpers (using the presence service, PS). In the ”Expert on Call” the service hasto be provided in real time, i.e. in one and the same service call initiated by thetechnician. Once a voice connection has been established, other services can beadded to the session: video and/or file transfer to help to eliminate the problem,voice/video/data conferencing with several colleagues or experts, etc.The rest of the paper is organized as follows: in the next section we describeshortly the SIP, SLEE and BPEL technologies, then, in the main section 3, the pro-posed architecture and the basic interactions are introduced. Based on the example,we illustrate the operation of the system in section 4, present preliminary perfor-mance results and discuss a number of lessons learned from using the technologies,in section 5. 2 Technological environment In this section we introduce the main technologies needed to build the orchestratedservice environment.  2.1 SIP The Session Initiation Protocol is an IETF standard [8] used in telecommunicationservices to control multimedia sessions. SIP has been adopted by the 3GPP inthe definition of the IP Multimedia Subsystem(IMS), a SIP overlay network ontop of the UMTS packet domain. Therefore, SIP is an important protocol whichwill be implemented in most mobile phones and which will be the main way toasynchronously notify a user about an event or a message, replacing SMS and WAPpush. Besides signalling and preparing other protocol channels to be used by theterminal application via HTTP for example, SIP can convey payload in its messages(INVITE, OK, SUBSCRIBE, NOTIFY, MESSAGE) and communicate in this waywith the service without the need of another application protocol (at least for simpleapplications). 2.2 JAIN/SLEE JAIN SLEE [9] is the Java standard for a Service Logic Execution Environment(SLEE), which is a known concept in the telecommunication industry to denote alow latency, high throughput event processing environment. Standardized by theJava Community Process JSR22 in 2004, the SLEE architecture emerged from theJ2EE container in which Enterprise Java Beans perform application logic, howeverthe new SLEE container and the components had to be adapted to the require-ments of telecom services: support of asynchronous events, low latency, support of heterogeneous protocols such as SIP, INAP, SOAP, etc. The resulted SLEE entitiesas shown in Fig. 1 below are: –  Service Building Blocks (SBBs), software components in the sense of EJBs,which can be cascaded to build hierarchical structures and support event com-munication, –  Resource Adaptors (RAs) that conform a certain resource adaptor type andmap a certain protocol or resource actions to SLEE events. Specifically thecommunication from RA to SBB is synchronous, whereas communication fromRA to SBB is event based. –  Activity and Context objects are needed to share session state informationbetween SBB and RA across multiple events. This represents a state machine,a typical requirement for most telecom applications. 2.3 BPEL The Business Process Execution Language (BPEL)[10] is an XML construct fordescribing business process behaviour. BPEL is layered on top of other Web tech-nologies such as WSDL 1.1, XML Schema 1.0, XPath 1.0, and WS Addressing. TheBPEL notation includes flow control, variables, concurrent execution, input andoutput, transaction scoping/compensation and error handling.Business Processes described with BPEL usually use external Web services toperform functional tasks. Since in our case the BPEL process is inside the SLEEplatform, it has to be able to fire JAIN/SLEE events to the SBBs and RAs. Theseweb services are described by WSDL files, refer to partners, and their link types.The WSDL files describe the structure of messages (data containers), operations(method calls), and port types (operations and input, output, and error messages).They also bind port types to particular protocols such as SOAP, operation callmethods such as RPC, or in our case the definitions of JAIN/SLEE events.There are several reasons to select BPEL as orchestration language:  JAIN Application Interface Framework Component ModelRATypeStack Event RouterProfilesTrace ... ... SBB   SBB   SBB Activity <<create>><<modify>>fire(event,activity)deliver(event)<<access>>invoke() Activity ContextEvent Resource Adaptor(RA)SLEEManagement MBeansDeploymentService Mgt.Profile Mgt. ... ... SBBSBB Fig.1.  Main Entities of a JAIN/SLEE service environment –  It offers a generic representation of a business process (possible to re-deploy ondifferent platforms). –  It offers high level abstraction (programming in large) for rapid process creation.It therefore allows network operators, sales person or even subscribers to definesmall business processes. Existing visual BPEL design tools simplify this task. –  A scripting language offers easy development, maintenance and adaptation of abusiness process (no need to re-compile the software in case of changes). –  Its underlying infrastructure supports exception handling, transactions, com-pensation mechanisms, service selection and binding, etc. These functionalitiesare supported by BPEL and are normally provided by the composition engine. 3 Architecture of the orchestrated service executionenvironment Having shortly reviewed the main technologies involved in the execution environ-ment, we proceed with the proposed integrated architecture comprising a SLEEcontainer with SIP and IN resource adaptors, a new kind of resource adaptor host-ing the BPEL engine, and a number of service building blocks (SBBs).In order to integrate the BPEL engine in a SLEE container, we follow the par-adigms of the SLEE architecture. Therefore, the BPEL engine is wrapped in aresource adaptor (BPEL RA). When deployed into the SLEE, the resource adaptordefines the events it might fire, as well as a resource adaptor type interface that canbe called synchronously by SBBs. The communication from SBB to BPEL RA isdone via synchronous method calls, whereas in direction from BPEL RA to SBB,the resource adaptor fires events (see Fig. 1). The BPEL RA starts a servlet con-tainer which has the BPEL engine deployed. Into this engine any BPEL processscript can be deployed and accessed from inside the container via local Java callsor from outside the container via SOAP. In the following description we assume forthe sake of simplicity that the service logic in form of BPEL scripts is triggered by a
Search
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks