 | Level: Intermediate Jim Conallen (jconallen@us.ibm.com), Senior Software Engineer, IBM
07 Aug 2007 The SIP Modeling Toolkit for IBM® Rational® Software Architect is a set of domain extensions to the Rational Software Architect platform. The toolkit provides the tooling necessary for you to leverage the Rational Software Architect platform in a natural way to design and develop the domain-specific technology for the Session Initiation Protocol (SIP). This article also demonstrates how you can integrate the Rational Software Architect platform with Domain Specific Language (DSL) elements to form a single development environment. The toolkit extensions include Unified Modeling Language (UML) profiles, reference models, custom user interface elements, transformations, and transformation extensions.
Introduction
The Session Initiation Protocol (SIP) is an Internet Engineering Task Force (IETF) specification (RFC3261) for connecting one or more multimedia participants (user agents) together over the Internet. User agents are typically phones (POTS, mobile phones, soft phones, IP-PBX devices, and so on), but can be any SIP-enabled device.
The protocol is responsible for creating, modifying, and terminating sessions, but is not actually involved with interpreting the media exchange. Once the devices are connected (that is, they are exchanging a media stream directly between each other), the SIP service is no longer involved. However, SIP services provide value beyond just connecting two agents. For example, while setting up or tearing down a connection, SIP services can also implement call blocking or forwarding, as well as interface with gaming and back office systems.
| |
The SIP Modeling Toolkit for IBM® Rational® Software Architect (see Resources) adds SIP-specific extensions to the UML modeling and development platform provided by Rational Software Architect. These extensions include domain-specific profiles, reference models, transforms, and other utilities for modeling and model-driven development (MDD) of next-generation communications services. The toolkit also provides code generation extensions to the existing UML-to-Java™ transforms within Rational Software Architect that update the SIP-specific artifacts of a service implementation.
Therefore, this toolkit makes it easier to create design-level models that target code generation for SIP servlets. It does this by providing domain relevant reference models, as well as stereotyped elements and properties, that capture SIP-specific information (such as P-Header information and so on) in the servlet models. The toolkit then uses those models, elements, and properties to generate code transformations.
Using the SIP Modeling Toolkit, SIP and converged SIP-HTTP services can be created and deployed on the IBM® WebSphere® Application Server product as SIP servlets. It is also possible to customize the toolkit for deployment on other SIP application server platforms. The implementation of SIP services by Java™ Servlets is specified by the Java™ Community Process JSR 116. WebSphere Application Server Version 6.1 and later provides native support for JSR 116.
This article introduces the toolkit and outlines its key features.
Toolkit functionality
The SIP Modeling Toolkit addresses three key areas of SIP service modeling:
-
Call flow modeling: Rapid modeling of SIP call flows using enhanced sequence diagrams
-
Servlet modeling: Using tools and dialogs to design SIP servlets in the context of your applications
-
Transformations and transformation extensions: Generating SIP servlet code and deployment descriptor entries
This toolkit does not presuppose any specific methodology for developing SIP-based services. Using call flow modeling or servlet modeling is optional, and whereas they can be used together successfully, there is no dependency between them. On the other hand, model-to-code transformations do depend on servlet models and the correct use of the related extensions.
SIP Design Model template
SIP design models require that the UML model have SIP reference types and a SIP profile. The SIP Modeling Toolkit installs a new reference model and profile that can be applied to any existing UML model. Or to simplify things, the toolkit includes a model template that can be used to create new model files with the reference model and profile already applied. The SIP reference model includes most of the SIP types used in a design model (from JSR116 and WebSphere Application Server extensions), along with pre-built SIP messages for use in call flow diagrams. The SIP profile includes stereotypes for servlets and UML collaborations used for call flow modeling. The SIP Design Model template is available from the list of templates available when you create a new UML model, as shown in Figure 1.
Figure 1. SIP Design Model template
Call flow modeling
One of the most common ways to communicate a specific scenario of activity between user agents and SIP services is with a call flow diagram. These diagrams are, for the most part, UML sequence diagrams, as shown in Figure 2. The SIP User Agent (UA) typically initiates the call flow with an INVITE message to a SIP-aware service. This service usually forwards the messages on to other SIP services, or translates the messages and invokes other types of equipment (like the call control elements in the control plane).
Figure 2. Call flow diagram (partial)
Most of the information exchanged between the participants is in the header content. The SIP Modeling Toolkit provides a specialized user interface (UI) to capture this extra information (see Figure 3). User interface customizations make it easy to copy headers from other messages and reorganize header order. One button will create or update the content length header based on the actual content specified in the message body.
Figure 3. Call flow message details
Call flows represent very specific scenarios; therefore, the simplest call flows do not contain branches or loops. However, because call flow modeling in Rational Software Architect is based on UML sequence diagrams, you can leverage the full features of UML sequence diagramming to diagram elaborate call flows with loops, branches and alternate sections.
Generate servlet or testing code
In the current version of the toolkit, there is no automation to translate these call flow diagrams directly into implementation models or code. Too many design decisions, which are normally locally determined, need to be considered in order to make it feasible in a generic way. However, because call flows are captured in UML models, it is possible to create your own model-to-model or model-to-code transformations that use this call flow information to generate servlet or testing code.
While automation may not be available out of the box, you can easily establish traceability between the implementation of the SIP service and the call flows that it supports. For example, «trace» relationships can be drawn between call flow lifelines (individual participants in a call flow) and the implementing servlet. Figure 4 shows the Call Blocked scenario, a simple call flow for the Call Blocking sample application that is available in Rational Software Architect as a technology sample.
Both the Call Blocked and the Call Connected scenarios only capture the significant messages of each scenario. It is not necessary to model every possible detail: by definition, models only need to capture the important and relevant information.
The remainder of the call flow shown in Figure 4 follows the normal call connection flow, and is therefore not completed in its entirety.
Figure 4. Call flow diagram for call blocking example (blocked call)
Establish traceability
One of the most important uses for modeling is to establish traceability across artifacts and design elements. In the simplest case, this can be accomplished in a simple design model by drawing «trace» relationships between the implementing servlet classes and the call flows that they implement.
In Figure 5, the implementation of the Call Blocking sample is shown with «trace» relationships between the specific participant roles and the implementing classes. Not only is the «siplet» (the main SIP servlet implementing the SIP service) traced to two of the call flows, but other architecturally significant elements, like the access control list, can be traced to participants in the call flows.
Figure 5. Call flow traceability
These trace relationships are important not because of their potential use in automation and patterns, but because they are important links in the chain of traceability between requirements, implementation and test. These links, established in the model, make it easier to analyze and understand the system, without having to rely on naming and coding conventions. You can navigate and study links during impact analysis, when future changes are being suggested for the system.
Servlet modeling
|
Tooling requirements
When you look at the actual effort involved in implementing a SIP service, the majority of the activity takes place when you create the business logic, including accessing enterprise objects, databases, Web services, and other services. Very little of what is addressed by such services actually involves the SIP technology itself.
This implies that when you choose the right development environment to build those services, you need to choose one that can work with all the relevant technologies, in addition to the SIP-specific ones.
|
|
When you implement a SIP service, you usually begin with a set of requirements that may include both high-level text documents and abstract call flow examples. The design process refines these artifacts, in part, by adding more detail to the header content in the call flows (suitable for direct use with testing), and incorporating external APIs and local framework classes to the design model. Some development teams may decide to use UML state machines as a mechanism to combine call flows and increase the design detail of a specific service.
Figure 6 shows a simple state machine that combines the two main scenarios of the Call Blocking example. UML provides many modeling tools for designers to elaborate the behavior of a service (state machines, activities, collaborations, and so on).
Figure 6. Call blocking state machine
The runtime components of a SIP service (implemented according to the JSR116 specification) require only a Java class to extend the SipServlet framework class, and to include a few elements in the sip.xml and web.xml deployment descriptors of a Web project. Create servlets from scratch in the model by using the tool palette item for Siplet (SIP servlet) or ConvergedServlet, and by creating a new stereotyped class in the model. Table 1 lists the class stereotypes. The palette includes tools for each of the three main stereotypes in the SIP profile.
A stereotype for a UML model element enables you to associate additional semantics to the given model element. It also allows you to define extra properties that can be captured in the model and used during automated transformations.
Table 1. Class stereotypes in the SIP Modeling Toolkit
| Stereotype | Description |
|---|
 Siplet | Applied to classes that respond to SIP messages. Classes stereotyped Siplet (SIP servlet) result in the generation of a Java class that extends SipServlet. |
 HttpServlet | Applied to classes that respond to standard HTTP messages. Classes stereotyped HTTPServlet will result in the generation of Java servlet classes (that is, they extend HttpServlet). |
 ConvergedServlet | Applied to classes that respond to both SIP and HTTP messages. These services extend the WebSphere-supplied class com.ibm.wsspi.sip.converge.ConvergedServlet. |
When you use the palette to create a new Siplet or servlet, it will also ensure that the new class extends the proper superclass from the SIP reference model (see Figure 7). If you do not use the palette, you can still apply the stereotype to a class, and you have the opportunity to extend a different framework class or interface.
Figure 7. New servlets in the design model
A realization of the service, as described by a set of call flow diagrams, begins in the design model with a single stereotyped class that extends the right framework class. Its methods receive requests by SIP clients and are responsible for communicating with a proxy to establish a session with one or more other devices.
The Siplet exists in a larger design, one that includes a number of other classes and library APIs that are used in the implementation of the service. For all but trivial SIP services, the implementation exists in a larger application and will communicate with back end processes, databases, enterprise beans, and other services as shown in Figure 8.
Figure 8. Structural portions of a SIP service design model
The main reason behind the use of the stereotypes is to identify particular classes as being the primary implementations for the SIP service behavior. It is these classes that require additional meta information to "register" them with the Web application server. This additional information is associated with the stereotype and presented to the developer in the form of a special view (shown in Figure 9). This view is available as a new tab in the standard Properties view section.
In the case of a Siplet, this information includes the pattern or filter criteria that defines the conditions under which this Siplet should be activated by the container. The pattern is a simple tree structure that translates into an XML fragment and is used directly in the sip.xml deployment descriptor (as specified by JSR116).
Figure 9. Siplet property view
The rest of the view provides a convenient way to add method overrides for common SIP servlet methods. The Load On Startup property is a standard web.xml deployment descriptor field. It indicates a relative measure of importance that this servlet should be activated during server startup. Create common method overrides by selecting the checkboxes in the view.
When the design model is near completion, it is time to transform the design into Java code and deployment descriptors. The SIP Modeling Toolkit includes a transformation extension to the existing UML-to-Java transformations (both Java 1.4 and Java5). Therefore, the same transformation that you would use to generate generic Java code is used in exactly the same manner to generate SIP and HTTP Servlet code and extensions. You don't have to do anything different has to generate the required SIP content.
Extracting existing SIP deployment information
For existing SIP applications, it is possible to transform existing sip.xml and web.xml deployment descriptor information into the SIP Design Model. You can do this by creating a new transformation configuration, similar to how one is created for the UML-to-Java process. This new type of transformation configuration, provided by the SIP Modeling Toolkit, is called the SIP to UML Transformation, as shown in Figure 10.
Figure 10. Creating a new reverse transformation
The only parameters to this transformation are the Web project and the target model. Invoking this transformation will update the model by creating the SIP servlet, HTTP servlet, or Converged servlet classes, and by updating their SIP-specific properties from the deployment descriptors. This transformation only updates the deployment descriptor content. It does not update the class’ attributes, operations, or associations. Along with the rest of the Java content, you can accomplish these activities by using the existing Java-to-UML transformation that is supplied out-of-the-box with Rational Software Architect.
Design activity overview
The overall design work flow begins with input from the analysts, usually in the form of call flow diagrams, which can be captured as sequence diagrams. Some designers may want to combine these into a UML state machine or a UML activity as a way to consolidate the emergent behavior of all the scenarios. The state machine or activity would then represent a single behavioral component that, when implemented as a SIP service, would support all the call flows. This is also a good analysis mechanism to identify ambiguities and conflicts in expected scenarios.
The service solution design begins with the creation of a «Siplet» stereotyped class in the UML model. This class will map directly to the main SipServlet implementation class. The designer sets SIP domain-specific information through the custom Properties views, and continues the design by adding additional classes, connections to Web services, databases, enterprise beans, and so on. As mentioned previously, most of the work of designing and implementing a SIP service in actual development takes place when you create the business logic with these other classes and technologies.
Resources Learn
Get products and technologies
Discuss
About the author | 
| | Jim Conallen is a software engineer in IBM Software Group's Rational Model-Driven Development Strategy team, where he is actively involved in applying the Object Management Group's (OMG) Model-Driven Architecture (MDA) initiative to IBM's Rational model tooling. Jim is a frequent conference speaker and article writer. His areas of expertise include Web application development, where he developed the Web Application Extension for UML (WAE), an extension to the UML that lets developers model web-centric architectures with UML at appropriate levels of abstraction and detail. This work served as the basis for IBM Rational Rose and IBM Rational XDE Web Modeling functionality. |
Rate this page
| |
