The marketing information on JAIN claims the initiative brings service portability, convergence and secure network access to telecoms networks. To address each in turn, we have already exposed the flaw in IN services, that of non-portable applications. JAIN overcomes the service portability barrier through the Java write-once, run-anywhere philosophy that Java
INTERNET-BASED SERVICES 160
1
Some might say hosting services are already a reality, the author is not sure if this is really true or just more hyperbole, whilst the web hosting business is significant the application hosting business is still in its infancy. Small to Medium Enterprises (SMEs) will clearly benefit from outsourcing their applications support to reduce IT spend and using the services of an xSP has significant benefit for a distributed company.
realises through its use of an interim code level called byte code, which runs in a Java byte code interpreter and by providing a ‘standard’ common API framework. JAIN delivers convergence through the imple- mentation of multiple protocol stacks (TCAP, ISUP, MAP, INAP, MGCP, SIP, SIP sevlets, MEGACO/H.248 and H.323), allowing through the JAIN framework the implementation of softswitch functionality on any plat- form that has the Java runtime engine installed. The Java sandbox is used as a security mechanism for controlling rogue programs. By constraining applications to a set of functions they can perform and provide secure remote method invocation procedures, JAIN provides a secure environ- ment for network applications.
The JAIN work is split into two sets of APIs: application APIs and proto- col APIs. We’ve already covered the protocols, the application APIs are: JAIN call control (JCC), JAIN Co-ordinations and Transactions (JCAT), a JAIN SLEE (cf. the IN SLEE), a JAIN service provider API for trust and security management (SPA), a SPA mobility API, a SPA presence and avail- ability API for presence and IM, and a JAIN service creation environment. Some of these APIs are at the time of writing still under development. Figure 12.2 gives an overview of the relationship of these components.
JAIN really builds on the tried and trusted (A)IN model for external service construction and control, but with the already extensive Java API library to call on, to be able to extend and create integrated applications in an ‘open’ SCP. JAIN is not the only incentive. The third-generation (3G) mobile world has been working on an Open Service Access (OSA) frame- work definition which allows third-party applications to be ‘plugged’ into the Universal Mobile Telecommunications Service (UMTS) mobile networks. Both the JAIN work and the OSA work have been influenced by the Parlay specifications. In fact the JAIN service provider APIs are a Java implementation of the Parlay APIs.
The Parlay group is an industry consortium formed in 1998 by BT, Microsoft, Nortel Networks, Siemens, and Ulticom (formerly DGM&S Telecom). The aim of the group was to create an open framework of APIs to support the development of communications applications. Since the inception of the group, a number of other companies such as Cisco, AT&T, Microsoft and IBM joined.
The aim of the Parlay APIs is to provide a network independent appli- cation development environment by the specification of programming language independent APIs, so you can see why JAIN and OSA have looked to them for inspiration.
The Parlay specifications cover the following areas:
† call processing
† connectivity management
† framework, this covers aspects of security and management
† messaging
† mobility
The call processing APIs specify a generic call control service, which provides a third-party call control model. That in theory could provide a framework for developing a call control programming library for the major protocols present in the current and next-generation networks (INAP, ISUP, H.323, SIP, etc.). There are some camps that argue this approach is flawed because no single specification can cover all the speci- fic strengths of a particular protocol and SIP CGI presents an alternate approach that tries to address this concern (see Section 12.3).
INTERNET-BASED SERVICES 162
Java 2 Enterprise Edition (J2EE)
J2EE does for web servers what JAIN does for SCPs. It is a collection of APIs bundled into a framework that sits behind a web server and allows more feature-rich enterprise applications to be built on the web model. J2EE provides tools and APIs for both server side and client side devel- opment. The J2EE model defines a set of tiers, a client tier, a middle tier and an enterprise information system tier (see Figure 12.3). Each tier contains a set of Java capabilities either frameworks such as the enterprise Java beans (EJB) container, sevlets and the web container or programming capabilities such as Java server pages connected to web pages via Hyper- text Markup Language (HTML) tags or as embedded code for presenta- tion of the information from the back office systems.
Servlets are web server extensions to a web server that allow Java programs (implementing the servlet API) to be loaded dynamically into a Java runtime environment of a web server, replacing Common Gateway Interface (CGI) scripts.
Integration to back office systems is via the Java Database Connectivity (JDBC) APIs for connecting to relational databases and the new specified Java connector architecture for connecting to Enterprise Information Systems (EIS). EIS are as Figure 12.3 shows, systems such as enterprise resource planning systems, customer relationship management systems, business support systems, etc.
J2EE also provides programming libraries for access name services such as Domain Name System (DNS) and Lightweight Directory Access Protocol (LDAP) directories (see Chapter 9), and access to email systems via the JavaMail program library.
J2EE also provides APIs for transaction management, Remote Method Invocation (RMI) and message services. The transaction management API provides Java classes to help in the construction of applications that need to co-ordinate a number of distributed events that result in an atomic action being taken, maybe writing a customer record to a database. The
12.3 APPLICATION FRAMEWORKS
Figure 12.3 J2EE framework tiers
RMI API allows synchronous communication between distributed appli- cations to be programmed with very little knowledge of distributed appli- cations. It is an enabler for buildingn-tiered distributed applications. The message service APIs provide similar service to the RMI libraries, except message-based services are asynchronous. A message can be posted to a queue and forgotten about. The application posting the message can do other things.
J2EE is a complete application framework for the development of multi- tiered enterprise applications.
This is a very short description of the kind of services J2EE provides. However, this brevity belittles the real power of J2EE and its significance for the development of hosted services in next-generation networks. Java’s strength of write-once, run-anywhere creates a fantastic opportu- nity for third parties to develop applications that will run on a variety of vendors’ platforms, increasing the opportunity for diversity and richness of new services.
.NET
Microsoft’s .NET is an idea designed and built around XML. Application communication is provided via Simple Object Access Protocol (SOAP). The SOAP specification whilst originated in Microsoft is now a World Wide Web consortium (W3C) standard and is defined as an XML docu- ment specification. The W3C specification means that .NET applications are not restricted to Microsoft only platforms, for example a SOAP server implementation already exists for Linux. Microsoft is concentrating its efforts around their BizTalke server and their HailStorm concept of
web services. This is likely to be a major factor in the distribution and aggregation of new services.
The .NET framework is clearly Microsoft’s answer to J2EE, as the .NET framework also comes with its equivalent of the Java runtime called the Common Language Runtime (CLR). Code is compiled into Microsoft Intermediate Language (MSIL) to run in this environment.
At the time of writing .NET was just getting started and looks to promise an alternative to the J2EE model for development and will provide a stepping-stone for Microsoft application developers to move into distributed web-centric applications. For those who are interested in finding out more about .NET then I suggest you look at Microsoft’s website.