and SLEE focus on a component model (see the
box titled “What Is a Component Model?”) over
specific implementations. EJBs (see the box on
“The EJB Component Model”) are an excellent
candidate for such a component model, but it is
certainly possible to use other component mod-
els, such as JiniÔ [7], Jini JavaSpaces [8], JiroÔ
[9] or JES [10]. Most of these container struc-
tures, extended with the right features, are viable
implementation platforms for JAIN.
Figure 5 gives an example of a possible envi-
ronment for an EJB-based JAIN implementa-
tion. In the figure the application server provides
one or more types of containers for different
types of EJBs. The EJBs are the building blocks
for services. An implementation of the JAIN
SLEE can be considered an integrated network
application server.
THE EJB COMPONENT MODEL
The best known *-Beans are JavaBeans and Enterprise JavaBeans (EJBs). In the
management domain MBeans have been around for several years. JavaBeans
was t he first software component model added t o the Java world, and its
primary focus was on reusable components, components that can be visually
manipulated and customized in (GUI) development environments to assem-
ble applications using introspection and a runtime event model to provide
notification and callbacks.
Enterprise JavaBeans are focused on the enterprise problem domain. It
delivers a server side software component modelthat supports the typical require-
ments of a database/transaction environment, such as access control, CORBA
interoperability, object transaction monitors, availability, and load-balancing.
Each EJB does not provide all these facilit ies by itself; it relies on a so-called
container for these services. This is exactly the strength of a *- Bean/contain-
er model: The developer of the *-Bean can focus on expressing t he service
logic without having to worryabout usually complicated system-levelissues (e.g.,
related to high availability and load balancing).
Thus, one of the differences b et ween JavaBeans and EJBs is that Java-
Beans can execute directly on the Java Virtual Machine. EJBs need a contain-
er to live in. In many cases it is attractive, though, to provide a container or
agent for JavaBeans as well (e.g., to handle lifecycle issues or translating Jav-
aBean events into some other event mechanism such as SNMP traps). This is
the case in JMX, and the currently available reference implementation of JMX
(see the box “What Is JMX”).
The component model as defined for the
SLEE also supports distributed implementations
where portions of the SLEE are migrated to the
edge of the network, say, to run on a residential
gateway or even inside a consumer device.
CONCLUSION
The JAIN network topology provides carriers
with the ability to deploy next-generation net-
work services on devices inside or at the edge of
the integrated network, including any Java-
enabled end-user device. Furthermore, support
for all the necessary telephony protocols that are
used between the different network elements in
intelligent networks, advanced intelligent net-
works (AIN), and IP-based (telephony) networks
is mandatory. JAIN has chosen an evolutionary
approach that over time will allow completely
new approaches to be incorporated. Wherever
possible the approach is decoupled and modu-
larized to make this easier. A concrete example
is the adoption of the JTAPI core/extension
package structure which does not make all call
models depend on a single state machine.
JAIN-compliant components do not reside on
a single server; rather, functionality is imple-
mented as a multitier, distributed application on
all signaling network elements. Such an approach
provides significant advantages for scalability,
performance, reliability, manageability, reusabili-
ty, and flexibility. The JAIN architecture lever-
ages the p latform inde pend ence of Ja va.
However, it is also designed to be distributed
and independent of any specific protocol or mid-
dleware infrastructure.
[3] S. Beddu s, G. Bru ce, and S. Davis, “Open ing Up Net-
w o rks w it h JAIN Parlay,” t o ap pear, IEEE Comm u n.
Mag., Apr. 2000.
[4] Call Control Interoperability Working Group, Enterprise
Computer Telephony Forum: http://www.ectf.org/ectf/
tech/ccwg.htm
[5] Ja va Man a gem ent Exte nsio n s: ht t p://ja va.su n.co m /
products/JavaManagement
index.html
ADDITIONAL READING
[1] JTAPI: http://java.sun.com/products/jtapi
BIOGRAPHIES
JOHN DE KEIJZER (joh n.dekeijzer@h ollan d.sun .com) is th e
Integrated Networks strategist and JAIN program manager
for Su n Microsystems. Wo rking a t Vicorp, Tandem, an d
now Sun Microsystems, he was the chief architect for intel-
ligent network and enhanced networked service solutions
in Europe, the United States, and Asia/Pacific. At Sun, he is
responsible for implementing a unified strategy for open
systems for next-generation telephone and data networks.
DOUGLAS TAIT (douglas.tait@East.Sun.com) received his B.S.
in computer sciences from Temple University and his M.S.
in computer architecture and network design from the Uni-
versity of Pennsylva nia . His computer exp erience includes
compan ies such as Unisys, Telesciences, General Elect ric,
and Martin Mariett a. He spent severa l years develo pin g
device drivers for SS7 protocol stacks and eventually man-
a ged AIN projects at MCI an d Sprint. One of the origin al
JAIN arch itect s, he is driving t he sta ndardization of Java
interfaces in the communicatio ns ind ustry and provid ing
solutions on Sun platforms.
JAIN technology is changing the communica-
tions market from many proprietary closed sys-
tems to a single network architecture where
services can rapidly be created and deployed.
For more information, including availability
of completed portions of the specificat ions,
com/products/jain.
ROB GOEDMAN joined the Dutch su bsidiary of Sun in 1986
and transferred to the United States in 1990. He worked at
Sun’s FirstPerson o n the blendin g of grap hical user inter-
faces a nd digital video for TV based on the Oak lang uage
(Oak later b eca me Ja va ). He was resp onsible in th e Sun
Thomson Alliance for a team tha t investigated incorporat-
ing Java into set-t op boxes. He subsequ en tly led several
engin eering team s, on e of which delivered Sun ’s imp le-
mentation of a proxy cache appliance with high scalability
and failover. Since mid-1998 he has been a member of the
JAIN team, initially responsible for bringing the JAIN initia-
tive in line with Sun’s Java Community Process.
REFERENCES
[1] R. R. Bh at an d R. Gu p ta , “JAIN Pro t oco l APIs,” IEEE
Commun. Mag., this issue.
[2] R. Jain , F. M. Anjum , P. Missier, an d S. Shastry, “Java
Ca ll Co n tro l, Coo rd in at ion, and Transa ct ion s,” IEEE
Commun. Mag., this issue.
IEEE Communications Magazine • January 2000
99