Java integrated development tools

2.7. Service creation and delivery 19

2.7.7. Java integrated development tools

When the development is based on Java environments, it benefits from the integration of the ser-vice creation and execution environments. The following figure illustrates the development chain in Parlay and Parlay X when a specific SDK is introduced (note the SDK can be itself integrated within an existing IDE).

.1. OSA/Parlay innovative services in different environments

OSA/Parlay provides a range of network-agnostic APIs, making the standard not only applicable to fixed and mobile networks, but also to existing (and future) next generation network architectures.

These APIs offer rich functionalities, enabling the creation of a wide range of services in a variety of technologies, with detailed access to the capabilities available in various network types. In addition, the Parlay X APIs provide a much simpler abstraction of communication capabilities targeted at Web Service Application development.

This rich feature set combined with Parlay’s ability to provide convergent applications between fixed, mobile and IT networks creates a vast market of opportunities where the only limit seems to be our imagination. Before going deeper in the detail of the APIs, this section provides a quick overview of the type of innovative services that can be designed with Parlay APIs.

3.1.1. mobile applications

Reverse Charge Calling

Prepaid subscribers with no credit can use an OSA application to make reverse charge calls towards other users on the same network. The tariff of such calls will typically include a premium. Presence-sensitive Click-to-Conference MS Outlook based plug-ins for telecommunications services can be provided with presence information by OSA applications using Parlay-X capabilities. For example, if an attempt is made to conference a range of numbers into a call from the desktop, then pop-up windows can display information on which mobile users are currently active.

Virtual Mobile PBX

Many mobile operators have successfully launched Virtual Mobile PBX systems in order to replace their PBXs with a set of mobile handsets. Calls to the company number can be routed to a mobile handset for the receptionist and simultaneously, pop ups and click events on the desktop can allow the receptionist to transfer the call to employees as they would with a traditional PBX.

Inbound Call Management

There are now a range of OSA applications that allow mobile users to effectively manage incoming calls. For example, during meetings, business users can be pushed a GPRS or USSD menu with a set of options instead having of the handset ringing. These options may allow the user to automati-cally send a message or play an announcement to the caller requesting that they call back later.

Mobile Call Completion to Busy Subscriber

In the fixed line world, Call Completion to Busy Subscriber (CCBS) allows users to “camp on” a busy line until it becomes available. OSA applications provide similar functionality in mobile networks such that a call can be automatically created when a subscriber becomes available again in order to generate more minutes in the network.

3. THe osa MoDel DeTaIleD

Location-Based Services

There are a wide range of Location-Based Services available today. Several of these use the OSA standards to access location information in the network since the same OSA interface can be used to manage call control, messaging features, etc. OSA Location-Based Services are particularly compelling as the mobility functionality can be associated with several other network capabilities.

3.1.2. fixed applications

Internet Call Waiting

Internet Call Waiting is well-understood functionality that was designed in the pre-ADSL low-rate Internet ages, when a choice had to be made between picking up the call and leaving the network, or staying connected and missing the call. Users connected to the Internet could be notified of an incoming call by their ISP, through a screen pop-up that provided options to deal with the call. Sev-eral OSA implementations of this application are commercially deployed today that use the network independence of the technology in order to terminate incoming calls either on alternative mobile numbers or on a PC-based application in voice over IP.

Wholesale Voice

Deregulation in many markets has seen former monopoly fixed-line operators open up their net-works to Carrier select and pre-select competition. Rather than competitive service providers pur-chasing their own switch and a regulated interconnect agreement, wholesale voice OSA applica-tions allow them to lease switching capacity as a commercial managed service.

Network Call Center

Call centers are a highly competitive market segment with many service providers that are new entrants to the market targeting these customers. OSA fixed-line applications are available that provide management screens for call center organisations to configure inbound call load distribu-tion across multiple sites. Typical PBX and CTI soludistribu-tions can also achieve this, but there are costs associated with forwarding calls in this manner. A network-centric solution allows operators to gain more market share in the call center segment by significantly reducing the operational costs associ-ated with load management between sites.

3.1.3. convergent applications

Video Color Ring Back Tone

There are now a large number of commercially successful Color Ring Back Tones applications that allow music to be played to callers instead of ring back tone. An OSA-based approach allows the technology to be seamlessly migrated to take advantage of more advanced capabilities as they become available. For example, IMS architectures in mobile networks can provide streamed video to callers instead of music.

3.

Scheduled Conference Calls

Network operators typically charge premium rates for conference calls. OSA applications are avail-able that provide plug-ins to enterprise systems (such as MS Outlook) and use Parlay-X interfaces in the network to provide a much more user-friendly mechanism to arrange conference calls. This encourages greater use of such services based on the convenience of having the network create the call compared with traditional systems that require users to navigate announcement menus and remember passwords. There is an added benefit of exposing the network operator’s brand on many desktops in the market.

Mass Market VPN

Traditional IN systems are good at offering large-scale VPN systems towards the corporate segment but these products are typically not suitable for the mass market. OSA-based VPN systems can be aimed at a family or a community and provide a number of features such as on-net SMS broadcast, cheaper on-net calls, call barring options for the VPN owner, etc. These systems can be charged on a subscription basis and allow prepaid users to be included.

Call-Related Data

OSA applications can generate data traffic, based on specific call events. For example, a call missed by a corporate user can result in a MMS push to the caller with the company logo and a link to the corporate address book. Alternatively, a wireless Yellow Pages solution can be provided so that when a service company is called (for example, pizza delivery, hairdresser, etc.) an advertisement can be pushed to the caller.

Multi-Channel Televoting

Televoting systems are well-understood products. There are OSA-based solutions that provide multi-channel support, based on the broad horizontal scope of the OSA interface. Consequently, a single consistent OSA application can count votes made by IVR, SMS, USSD, WAP, etc. The vot-ing mechanism can also be location-sensitive with results available to media organisations in real time.

Message Broadcast

Many mobile handsets can currently be programmed to generate SMS broadcast events but this is not a user-friendly process. Available OSA applications allow users to access Web-based provision-ing screens to create broadcast lists. The broad functional scope of the OSA standards then allows a single message to be delivered to multiple recipients that may have a range of different messaging capabilities on their handsets.

Virtual Contact Numbers

In many markets, there is a range of publications in which people can insert personal messages or advertise items for sale. Typically, this requires a telephone number to be included, which can lead

to nuisance phone calls. As part of a broad set of OSA applications that target niche markets, there are products available that allow a number range to be associated with a specific publication or other media outlets. Web-based management screens then allow these publications to assign a vir-tual contact number from their number range to personal advertisers, before recycling this number for later use once the advertisement has expired.

.. Architecture

Open Service Access (OSA) enables applications implementing services to make use of network functionalities, defined in terms of a set of Service Capability Features (SCFs). These SCFs provide network capabilities accessible to applications through the standardized OSA interface for service development. They have been described by the 3GPP using UML and come in three realizations (OMG Interface Description Language^TM, Java J2SE^TM and Java J2EE^TM). They are open and acces-sible to application developers, who can design services in any programming language, while the underlying core network functions use their specific protocols. Popular examples of SCFs include Call Control and User Location.

Generally, the OSA architecture is composed of:

• Applications such as VPN, conferencing, location based services, etc…

• A Framework enabling applications to use the SCFs, through the Authentification, Registration and Discovery methods defined in the OSA interface

• Service Capability Servers providing the applications with SCFs, which are abstractions from underlying network functionality.

framework Service capability server(s)

Open Service Access

OSA

OSA API

Application server Application

Interface class

E.g. Location server MExE server SAT server Discovery

User Location Call control

HSS CSE S-CSCF Servers

Figure 15: The OSA/Parlay Overall Architecture

3.

.. Description of the OSA/Parlay Framework

The Framework API contains interfaces between the Application Server and the Framework, be-tween the Network Service Capability Server (SCS) and the Framework, and bebe-tween the Enterprise Operator and the Framework (these interfaces are represented by the yellow circles in the diagram below). The description of the Framework in the present document separates the interfaces into these three distinct sets: Framework to Application interfaces, Framework to Enterprise Operator interfaces and Framework to Service interfaces.

Enterprise Operator

Client Application

Framework

_Control^Call

Registered Services

Mobility UI

Figure 16: The OSA/Parlay Framework Relationships

Some of the mechanisms are applied only once (e.g. establishment of service agreement), others are applied each time a user subscription is made to an application (e.g. enabling the call attempt event for a new user).

Basic mechanisms between Application and Framework are:

• Authentication: This is done by using a peer-to-peer model but not necessarily mutual. Once an off-line service agreement exists, the application can access the authentication interface in order to use any OSA interface

• Authorization: Authorization is distinguished from authentication in that authorization is the action of determining what a previously authenticated application is allowed to do. Authen- tication must precede authorization. Once authenticated, an application is authorized to access certain service capability features

• Discovery of Framework and network service capability features: After successful authentication, applications can obtain available Framework interfaces and use the discovery interface to obtain information on authorized network service capability features. The Discovery

interface can be used at any time after successful authentication

• Establishment of service agreement: Before any application can interact with a network service capability feature, a service agreement must be established. It may consist of an off-line (e.g. by physically exchanging documents) and an on-line part. The application has to sign the service agreement on-line part before it is allowed to access any network service capability feature

• Access to network service capability features: The Framework must provide access control functions to authorize the access to service capability features or service data for any API method from an application, with the specified security level, context, or domain.

The basic mechanism between Framework and Service Capability Server is:

• Registering of network service capability features.SCFs offered by a Service Capa- bility Server can be registered at the Framework. In this way the Framework can in- form the Applications upon request about available service capability features (Discovery).

For example, this mechanism is applied when installing or upgrading a Service Capability Server.

The basic mechanism between Framework and Enterprise Operator is:

• Service Subscription function. This function represents a contractual agreement between the Enterprise Operator and the Framework. In this subscription business model, the enterprise operators act in the role of subscriber/customer of services and the client applications act in the role of users or service consumers. The Framework itself acts as service retailer.

3.3.1. framework access Session aPi

• Initial Access:

Before being authorized to use the OSA SCFs, the client must first of all authenticate itself with the Framework. For this purpose, the client needs a reference to the Initial Contact interfaces for the Framework. It may be obtained through an URL, a Naming or Trading Service or an equivalent service, a stringified object reference, etc. To initiate the authentication process, the initiateAuthen-ticationWithVersion is used (and only supported). Once the client has been authenticated by the Framework, it can gain access to other Framework interfaces and SCFs. This is done by invoking the requestAccess method, by which the client requests a certain type of access SCF. Indepen-dently, the client could decide to authenticate the Framework, before deciding to continue using the interfaces provided by the Framework. Steps are:

1. Initiate Authentication. The client invokes initiateAuthenticationWithVersion on the Fra- mework’s «public» (initial contact) interface to initiate the authentication process

2. Select Authentication Mechanism. The client invokes selectAuthenticationMechanism on the Framework’s API Level Authentication interface, identifying the authentication algorithm it supports for use with CHAP (OSA authentication is based on CHAP)

3.

3. The client authenticates the Framework, issuing a challenge in the challenge() method 4. The client provides an indication if authentication succeeded

5. The Framework authenticates the client. It can authenticate the client before the client authenticates the Framework, or afterwards, or the two authentication processes could be interleaved. However, the client shall respond immediately to any challenge issued by the Framework, as the Framework might not respond to any challenge issued by the client until the Framework has successfully authenticated the client

6. The Framework provides an indication if authentication succeeded

7. Request Access. Upon successful authentication of the client by the Framework, the client is permitted to invoke requestAccess on the Framework’s API Level Authentication interface, providing in turn a reference to its own access interface

8. The client and Framework negotiate the signing algorithm to be used for any signed exchanges

9. The client invokes obtainInterface on the Framework’s Access interface to obtain a reference to its service discovery interface.

: Ipinitial : IpAPLevelAuthentication

Client : IpAccess

: IpClientAPILevelAuthentication Framework

1: initiateAuthenticationithVersion (clientDomain, auth Type, frameworkVersion)

2: selectAuthenticationMechanism()

3: challenge()

4: authenticationSucceeded()

7: requestAccess

8: sselectSigningAlgorithm() 5: challenge()

6: authenticationSucceeded()

9: obtaininterface()

Figure 17: Initial access in OSA/Parlay Framework

• Framework Terminates Access:

1. Following successful authentication and service discovery, the client initiates the service agreement signing process and the application starts to use the new service manager interface

2. The Framework decides to terminate the application’s access session, and to terminate all its service agreements. This is an unusual and drastic step, but could be due for example to violation or expiry of the application’s service agreements, or some problem within the

Framework itself. The Framework will also destroy each of the service managers the application was using. The application is now no longer authenticated with the Framework, and all Framework and service interfaces it was using are destroyed.

: IpAccess

: IpAppServiceAgreementManagement : IpServiceAgreementManagement

AppLogic : IpClientAccess : IpMultiPartyCallControlManager : IpUserLocationCamel

1: signServiceAgreement()

2: signServiceAgreement() 3: createNotification()

4: triggeredLocationReportingStartReq() 5: terminateAccess()

Figure 18: OSA/Parlay Framework terminates access

• Application Terminates Access:

1. The application terminates its use of the service manager instances in a controlled manner 2. The application decides to terminate its access session and all its service agreements in

one go. The Framework will also destroy each of the service managers the application was using. The application is now no longer authenticated with the Framework, and all Framework and service interfaces it was using are destroyed. The application could have terminated its service agreements one by one which would have been a more controlled shutdown.

: IpClientAccess : IpAccess

AppLogic : IpMultiPartyCallControlManager : IpUserLocationCamel

1: destroyNotification()

2: triggeredLocationReportingStop()

3: terminate Access()

Figure 19: OSA/Parlay application terminates access

• Non-API level authentication:

1. The client calls initiateAuthenticationWithVersion on the OSA Framework Initial interface.

This allows the client to specify the type of authentication process.

2. The client invokes the requestAccess method on the Framework’s Authentication interface 3. If the authentication was successful, the client and the Framework can negotiate, on the

Framework’s Access interface, the signing algorithm to be used for any signed exchanges.

3.

4. The client can now invoke obtainInterface on the Framework’s Access interface to obtain a reference to its service discovery interface.

: IpInitial : IpAccess

Client Framework : IpAuthentication

1: initiateAuthenticationWithVersion (clientDomain, auth Type, frameworkVersion)

2: requestAccess()

3: selectSigningAlgorithm()

4: obtaininterface() Underlying Distribution Technology Mechanism is used for application identification and authentication, or both the client and the Framework recognise each other as trusted parties not requiring API level authentication. There is no requirement as to when authentication should take place using the Underlying Distribution Technology Mechanism:

before initiateAuthenticationWithVersion is invoked, after requestAccess is invoked, or between the two.

Figure 20: OSA/Parlay Non-API level authentication

• API level authentication:

The OSA API supports multiple authentication techniques. The procedure used to select an appropriate technique for a given situation is described below. The authentication mechanisms may be supported by cryptographic processes to provide confidentiality, and by digital signa-tures to ensure integrity. The inclusion of cryptographic processes and digital signasigna-tures in the authentication procedure depends on the type of authentication technique selected. The client must authenticate with the Framework before it is able to use any of the other interfaces sup-ported by the Framework. Invocations on other interfaces will fail until authentication has been successfully completed.

1. The client calls initiateAuthenticationWithVersion on the OSA Framework Initial interface.

This allows the client to specify the type of authentication process. This authentication process may be specific to the provider, or the implementation technology used. OSA defines a generic authentication interface (API Level Authentication), which can be used to perform the authentication process

2. The client invokes the selectAuthenticationMechanism on the Framework’s API Level Authentication interface. This includes the authentication algorithms supported by the

client. The Framework then chooses a mechanism based on the capabilities of the client and the Framework

3. The application and Framework interact to authenticate each other by using the challenge method. Note that at any point during the access session, either side can request re- authentication of the other side.

: IpInitial Client

: IpClientAPILevelAuthentication Framework : IpAPILevelAuthentication

1: initiateAuthentication WithVersion (clientDomain, auth Type, frameworkVersion)

2: selectAuthenticationMachanism()

3: challenge()

5: challenge()

6: authenticationSucceeded()

4: challenge()

7: challenge()

8: authenticationSucceeded()

9: requestAccess() : ipClientAPILevelAuthentication reference is passed to framework andipAPILevelAuthentication reference is returned.

This is an example of the sequence of authentication operations. Different authentication protocols may have different requirements on the order of operations

: IpClientAccess reference is passed to Framework and ipAccess reference is returned

Figure 21: OSA/Parlay API level authentication

3.3.2. framework to application aPi

This API is used for applications to discover and use SCFs. Several methods are used to:

In document Devoteam SDP (Service delivery Platform) white paper (Page 30-129)