The following article is written by Ron Dearing, Senior Software Engineer of Cysive, Inc. Ron has worked in the software industry for six years, and is a software engineer at Cysive, Inc. where he works in Product Development on the Cymbio Interaction Server. Ron has a BS in Computer Science from North Carolina A&T. Ron may be reached at email@example.com.
Service-oriented architecture using Jini
by Ron Dearing
Currently, service-oriented architectures are becoming an integral aspect of the IT strategy. Service-oriented architectures offer the ability to register, discover, and use services, where the architecture is dynamic in nature. Web services promises to deliver functionality that can be registered, discovered, and executed. However, the technologies that provide the implementation of these features are by its very core, statically based.
Jini's architecture promotes the concept of dynamic registration, discovery, and execution. The architecture addresses the problems of creating service-oriented architectures that are intended to be adaptive, self-healing, self-administered, and distributed.
In this article, Jini will be used as the implementation of a service-oriented architecture. The reader will be able to understand why Jini is needed, how to use Jini services, and solving "real-world" problems with Jini. The evolution from a statically based architecture to a dynamic service-oriented, architecture will describe a mechanism of how your current services may evolve.
What is a service-oriented architecture?
A service-oriented architecture (SOA) is defined as :
"SOA takes the existing software components residing on the network and allows them to be published, invoked and discovered by each other. SOA allows a software programmer to model programming problems in terms of services offered by components to anyone, anywhere over the network."
Web services can be viewed as an implementation of a SOA. The SOA promotes the ability to use of Web services from anywhere on the network. SOA is a natural evolution from the world of procedural and object-oriented programming. In order to realize the full benefit of the SOA, we should not use our traditional systems to implement a solution that requires a dynamic, adaptable infrastructure.
The participants in the Web services architecture are:
- Service provider
- Service registry
- Service requestor
- Service Provider
- The service provider is responsible for publishing a description of the service to the service registry. Normally, the service provider hosts the web service.
- Service Registry
- The service registry is a repository that provides the capability of discovering services by the service requestors.
- Service Requestor
- A software application that is responsible for discovering and invoking the service. The service requestor binds to the service obtained from the service registry.
What is the problem with my static solution when it comes to Web services?
Web services promises the user community a vision where business partners can conduct business by interacting with systems seamlessly on a scale never dreamed of before. A business can register the contact information in a directory, publish a service, find the service, and invoke the service, all dynamically. From the previous statement, looks very simple. However, behind the scenes, some code must provide a means to implement the service. IT has taken their existing technology and used this static technology to implement a dynamic model. We have promised a beautiful, delicious, red apple with a rotten core.
Our answer to Web services, we have implemented a system where we assume the network is reliable, the network does not change, the administrator will perform the majority of maintenance functions, and it is acceptable to reboot the server. Imagine a consumer of a Web service, relying on your infrastructure to send a mission-critical message. Based on our statically based system, if the network goes down while my Enterprise JavaBean is making a call to backend system, our software will more than likely log an exception and the call will fail. The assumption that the network is reliable has proven to be false. The problem is exacerbated when applying the static solution in a world that uses Web services as a global platform.
There are certain application servers that expect the administrator to restart the server if a deployment to a cluster fails. Is it possible for the software to automatically handle this type of task? Unfortunately, the statically, based technology that is normally used does not account for this type of functionality.
What is Jini and how will it solve the problem?
From the official Jini architecture specification , Jini is defined as:
"A Jini system is a distributed system based on the idea federating groups of users and the resources required by those users. The focus of the system is to make the network a more dynamic entity that better reflects the dynamic nature of the workgroup by enabling the ability to add and delete services flexibly."
A Jini system uses the network as a foundation to enable service discovery and service execution. Traditional systems attempt to mask the appearance of the network; in contrast, Jini uses the dynamic, flexible nature of the network to form communities, register services, discover services, and invoke services. Jini attempts to address the problem of the assumptions is reliable, the network does not change, and the administrator will perform the majority of maintenance functions.
To address the assumption that the network is reliable, Jini systems are self-healing. Jini services will repair themselves by using the concept of leasing. Jini ensures that services are removed from the community automatically given time by using a concept called leasing, without the need for an administrator to perform the maintenance. The network can change but Jini will continue to work without the need to update a URL in the software, properties file, or an administrative interface. Jini services are able to respond to such changes automatically. Communicating with a Jini service occurs through service proxies that are downloaded to the client machine without the need to have an administrator to install the code, a practice that is normal in traditional architectures.
Jini's architecture is based on the principle that the system is dynamic, and is closely related to a SOA, in contrast, other technologies such as J2EE, .NET, and Corba have their foundation in a static world. These technologies use a static approach to installing the software with its appropriate stubs and skeletons. One of Jini's strongest points is downloadable, service-proxies that communicate with the Jini service. Jini has the same concept of a service registry, a service provider, and service requestor. The technologies previous mentioned are forcing the SOA model within their static architecture that was not designed for this purpose.
The Jini architecture is comprised of:
- Lookup Service
- Jini Service
- Jini Client
You may notice the diagram of the Jini architecture closely resembles the architecture of Web services. This is another reason why the Jini architecture has a foundation that is rooted in the dynamic principles of a SOA.
- Lookup Service
- The lookup service keeps track of the Jini services and provides the proxies to communicate with the service. In addition, the lookup service is a Jini Service as well. The Sun reference implementation of the Lookup Service is reggie.
- Jini Service
- Jini Service are registered with the lookup service and are capable of being invoked through their public interface which is defined via a Java remote interface. The underlying system that allows Jini services to communicate is RMI.
- Jini Client
- The Jini client is software that requests the proxy from the lookup service in order to invoke the Jini Service.
The Core Jini Services
Jini has a number of built-in services, which enable services to support the dynamic notion of a Jini system.
- Lookup Discovery Service
- The lookup discovery service notifies the Jini client of changes within the Jini community. Services may join and leave the community at anytime.
- Lease Renewal Service
- Resource leasing implies that nothing within a Jini community is held permanently without renewing the lease. The concept of leasing enables the community to support self-healing and failover. Service must renew their lease with the lookup service, in the event, a lease is not renewed; the service is a candidate for removal from the community. Administrators' responsibility in this area is largely minimized due to the systems ability to self-heal.
- Transaction Service
- The transaction service offers the ability to use transactions within a distributed system. Normally, IT enterprise use databases to provide the capability to create transactional systems. Jini's transaction service raises the transactional features of a database to the network, object layer. Services may participate in transactions to ensure the ACID properties, which are associated with transactions.
- Event Mailbox Service
- Changes in the Jini community are propagated through the system using distributed events. The event mailbox service supports the feature of notifying services with events even if the service is currently not active.
Using the Lookup Service
The fundamental service in the Jini community is the lookup service. Clients and services must use the lookup service to facilitate the communication between them.
public class HelloWorldService extends
Setting up Jini
There are three services that are needed for the Jini System:
- Web Server – to download code, which is needed through RMI. Jini comes with a simple Web server that performs the transmission of the downloadable proxies. You may use any Web server for this purpose.
- RMI activation daemon - the activation daemon can start processes that are inactive. Every host that runs a lookup service needs a RMI activation daemon
- Lookup Service – keeps tracks of the services in the Jini system. The lookup service acts as a registry of services.
You may download the Jini starter kit 1.2.1 at http://www.jini.org. The download instructions for Windows are self-explanatory. Winzip may be used to extract the Jini starter kit to a specified directory.
As recommended in the Core Jini, it is best to do your development in an environment that closely mimics your actual production environment. Here we use the command-line to start the required services. Please replace the C:\jini1_2_1 with your home directory where Jini is installed.
You should start the services in the order described below:
- Start the Web Server
java –jar C:\jini1_2_1\lib\tools.jar –port 8080 –dir
- Start the RMI Activation Daemon
- Start the Lookup Service
java –jar c:\jini1_2_1\lib\reggie.jar
Copyright 2002. Reprinted with permission. Cysive, Inc. builds mission-critical business systems for Global 2000 firms to help orchestrate interactions with customers, partners and employees across multiple channels such as web, wireless, voice and Web services.
For more information:
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.
- Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
- Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.