Technology evaluation
From GEANT2-JRA1 Wiki
Contents |
JINI
General info
- Maciej, Roman (from Study of Technics JRA1 Draft):
Very attractive implementation of distributed service-oriented system is JINI. It is a set of Java APIs and runtime conventions that facilitate the building and deploying of distributed systems. It consists of a programming model and a runtime infrastructure.
Applications using JINI are treated as a set of cooperating distributed services. There is one specialized service called Lookup Service where other services can register and client applications can fetch information about required services. The number of Lookup Services in a distributed environment is not limited; moreover, if a couple of services have knowledge about each others they can communicate without any Lookup Service.
When started, each service registers in the Lookup Service. But before the registration happens, the service has to find the Lookup Service. This process is called Discovery. There are three possible ways of Discovery. The first is called “multicast request protocol”. When started, a service sends its presence announcement and the Lookup Service replies to it. The second is called “multicast announcement protocol”, when the Lookup Service broadcasts the information about itself onto a well-known multicast port. In the last one, “the unicast discovery protocol”, the service connects directly to the Lookup Service it knows.
When Discovery process is finished, the service may register in the Lookup Service. This process is called Join. Each service has its unique ID number and offers an interface it implements. It also provides a service proxy object which enables a client to communicate with a remote service. This proxy object is stored in the Lookup Service and a client can get it during the Lookup process. Service proxy enables the client to connect to the remote service and invoke specific behaviours (methods).
JINI is an effective distributed software architecture that enables the developer to design and implement complex application of the distributed functionality. It masks many details which should be implemented using other technologies. JINI is fully implemented in Java and uses its integral mechanisms such as RMI.
JINI is just one of a number of distributed systems architectures, including industry-pervasive systems such as Web Services, CORBA, DCOM or Enterprise Java Beans (EJB).
- Roman:
I've read several docs about Jini (the one sent by Loukik is very useful; Thanks!), run available examples and I must admit that it looks great. At the beginning I was sceptical (only Java, no open standards, complexity) but now I see that it's fine to use.
In general, Jini architecture is composed of services where one of the most important is the lookup service. Sun provides full API to implement them and even the implementation of the lookup service (called reggie). Simple scenario of action in Jini is: - service sends its service proxy (stub) with descriptive information to the lookup service - the client requests the lookup service for a service access (tries to find a service with certain descriptive attributes) - the lookup service provides relevant service proxy to the client - client connects directly with a service using service proxy Simple. This is something what we expect from the lookup entity (discovery of it is done by multicast but if the address is known then the service or client may connect using unicast without searching).
The default communication between services is done in RMI (shortly, java RPC) offering remote procedure calls but also any other protocol offering message passing is allowed (one can choose UDP or TCP on transport level and any protocol on application level).
For the prototype we could use reggie (I think it is sufficient for the work beyond the prototype as well) as a lookup service. Registerring could be done using RMI (reggie implements only this kind of communication) and the communication between other services could be done in SOAP or totally new defined protocol.
Jini also has the security mechanism but only for RMI as it is default communication solution.
In my opinion Jini would be a good choice to implement our system. Now I see that it's rather simple to use (well defined API, available sources). One problem I see is the selection of a communication protocol (except registering part). But no matter what API we take (Jini or something else) we will face this problem. I'm thinking about SOAP but it needs discussion.
Notes
- Discovery of a lookup service in Jini depends on existing of multicast. No multicast -> no discovery, then the address(es) of lookup service(s) is (are) needed as well-known. (Roman)
- In summary, between 25 and 30 NRENs have deployed multicast. 10 of them (most of the time the smallest like Malta) don't have it deployed. (Nicolas)
- The document that Nicolas has mentionned contains misleading information on DFN. Therefore, we should be careful to base important decisions by relying on this document. (Andreas)
- Each service should have ability to discover LS. In Jini this means that each service should have access to multicast. I know that this is a big problem! I propose to forget about multicast in discovery process in any technology (Jini, WS, Zeroconf, ect. ). A service should know at least one well-known LS. This one LS could be the nearest node in P2P network of LSs. (Roman)
Links
Web Services
General info
- Maciej, Roman (from Study of Technics JRA1 Draft)
Web Services are the collection of protocols and standards used for exchanging data between applications. This technology is used to build web-based enterprise applications or distributed entities which utilize open, XML-based standards and transport protocols to exchange data with requesting clients. These clients may be either other applications or web services.
To keep information about available services the Universal Description, Discovery and Integration Service (UDDI) may be deployed. Each Web Service can register in the UDDI and put there its details (name, address, functionality, business category, available API). All clients that need information about Web Service with specific functionality can contact UDDI and find the needed service.
Very important part of Web Services technology is the Simple Object Access Protocol (SOAP). It is an open protocol for exchanging data and messages which are encoded in XML. SOAP defines also standards for remote procedure calls (RPC) over HTTP.
Web Services is the newest proposal in the distributed computing scope. The popularity of it is growing and currently there are several implementations for various OS platforms. Some of them are Apache Axis (Java/C++), Sun JWSDP (Java) and Microsoft .NET (languages supports .NET platform).
Apache Axis
- Loukik:
Apache Axis is a popular SOAP implementation which helps in easy setup of Web Services. It also provides applications such as SOAPMonitor to view and debug SOAP communications coming in and going out of deployed Web Services. It (the Java version) sits on top of Tomcat application server providing web based interfaces for viewing and managing services.
It offers a range of styles (Document/RPC/Message) and also options for having Literal or encoded types (conformance to W3C recommendations). Deploying services can be done in many ways with all of them requiring the use of deployment descriptiors (WSDD). It can work with or without server side stubs and can also create WSDLs at run time. Its also possible to have clients without stubs thus making it easier to have dynamic invocations.
axis.jar provides more functionality such as WSDL2Java (to create stubs) and AdminClient to deploy/undeploy services using WSDDs.
Axis also has a c++ version which sits on top of Apache Web Server and needs Xerces c++ to parse SOAP.
Also of interest could be WSIF (Web Services Invocation Framework) and WSIL (Web Service Inspection Language).
- Thanassis:
- Axis is written in Java and C++. C++ development may not be as mature as Java.
- Axis is a servlet that could be run in a Servlet container, such as Apache Tomcat
- In the Axis case, a client connects to the web (application) server and feeds a SOAP message, which conforms to the service WSDL definition. Axis converts the SOAP message to proper method calls of the classes that implement the service (business logic). Axis is therefore called a “SOAP proxy”.
- Axis uses the WS-Addressing specification to define WS endpoints, in order to be able to access different Web services contained in a Tomcat server. (?)
Deployment in GEANT2:
- GN2-SA3 has already started using Axis and JRA3 is considering using Axis as the development platform.
- Plans for hierachical UDDI registry in GN2. jUDDI is already installed for testing. UDDI will also be used by GT4 (?)
Links
- Tutorial - Comprehensive tutorial on Apache Axis 1.0.
Globus Toolkit 4 (GT4)
- Thanassis:
- The Globus Toolkit 4.0 intends to implement a stable reference implementation of the Web Services Resource Framework (WSRF, refactoring of the Open Grid Services Infrastructure specification, OGSI) in the Java, C and Python programming languages. There are implementations of the Grid Resource Allocation Manager (WS-GRAM), Replica Location Service, Monitoring and Discovery Service (MDS), etc
- GT4 incorporated some of the Axis code but its unknown to which extent.
- WSRF will allow, in the future, for GRID integration
Globus Toolkit 4 vs. Axis
- Thanassis:
- Axis has basic functionality. GT4 uses Axis beneath.
- GT4 has extra functionality in alpha/beta (?) quality for Stateful Management.
- GT4 implements WSRF (a framework for exposing resource states which should be managed). In Axis, similar functionality could be implemented by the user via a service that queries the resources to expose their state.
- GT4 implements WSRF, which has good models for managing storage or computing elements via GRAM. Modeling support for network elements in GT4 is unknown. GRAM may need to be changed. (In EGEE–gLite, which is a superset of GT3, controlling network resources is problematic). Also note that network elements, e.g. links, are more complex than CPUs or disks.
- In GT4, service management is performed only via middleware. In the network case, problem with synchronisation may arise if resource state is changed manually from the network administrator or other reason.
- Using Axis is straightforward, while GT4 is recent so there is not enough experience.
UDDI
UDDI - Universal Description, Discovery and Integration Service
- Loukik:
I managed to setup a UDDI server on one of our machines (using jUDDI) and was able to connect to this server to publish and also retrieve information using uddi4j APIs. The current configuration involves using mysql database for storing data store and also a default database schema. I have attached a html of this default schema.
My experience:
Setting up UDDI has been made quite simple (by apache as in all cases :-) ). With my beginner level of expertise in doing so, it appears as if it has a good set of features. However, from the Lookup Service point of view, I wanted to see keep-Alives, etc. but couldn't find out more within the short time that I devoted towards doing so. Peer 2 Peer Lookup Servers is also a question that needs to be answered. UDDI4j is very easy to use but don't expect a heap of documentation. Deeper investigation is necessary to get info about all required features but from this update, UDDI can be considered as a good option subject to the above observations.
Web Services Resource Framework (WS-RF)
- Martin:
Here are some notes on the WS Resource Framework and its applicability to our requirements.
WSRF facilitates referencing of stateful resources in the WS world, which is inherently stateless. "Stateful resources" could include state about services that a given Web Service endpoint provides, state about the host on which the Web Service (measurement point) resides, or state about ongoing measurements.
The framework consists of a document that describe how WS Resources express their properties (WS-ResourceProperties), a mechanism for managing the lifetime of a resource (WS-ResourceLifetime), a schema for expressing faults (WS-BaseFault) and a means for a group of WS-Resources to be grouped together to cooperatively provide some service.
Another thing that WSRF provides is a unified naming scheme that uses what are referred to as Endpoint References or EPRs. These refer to state elements in a uniform way.
A closely-related standard is the WS-Notification work, which uses compatible mechanisms to support a publication/subscription service.
So how could these pieces fit? Roughly, "Resource Properties" amounts to expressing things about logical system elements as XML documents. That includes everything from the measurement host and network topology to the measurement modules that are installed and their policies and current use (in e.g. recurring measurements.) The key is expressing all that in some model and rendering that in XML. We essentially face that task regardless.
"Resource Lifetime" basically facilitates what networking folks refer to as "fate sharing." Any state consumed in a distributed system needs to be actively maintained by an end user so that if the user goes home, the network state can time out gracefully. The is also referred to as "soft state" and is considered part of the "End to End" family of design principles. This component has a role in terms of managing ongoing measurement and storage resources.
"Base Fault" is pretty obvious even though nothing can possibly go wrong. :)
The ServiceGroup abstraction is valuable in a number of ways as well. Examples could include fungible measurement or storage points. If you just want a measurement from site A to site B, then you can utilize a service group and allow internal mechanisms to choose between the various possibilities. This also provides a mechanism for high availability in that a given interaction can be performed with a group rather than a specific host, so if one instance goes away another can take its place.
Some WS-RF documentation is available here:
- Globus Web Services Resource Framework
- OASIS Web Services Resource Framework
- IBM Web Services Resource Framework
Java2 Platform, Enterprise Edition (J2EE)
- Thanassis:
- Application server with full implementation and integration of Web Services, Servlet, Enterprise JavaBeans (EJB), JDBC, Corba and so on
- Implementation of Web Services, Servlets, Enterprise Java Beans, JDBC, Corba
- Needed Web Service development Tookit
- Rewrite J2EE code to Axis is considered simple.
- Tomcat is also container for J2EE
- J2EE should not be considered in JRA1 as lacks functionality compared to Axis / GT4
JXTA
- Andreas and David:
David and I have read the information on the JXTA homepage and have searched for reports on JXTA. As a result, we would like to provide the following information as basis for the discussion.
JXTA information
JXTA is an open source initiative promoted by Sun Microsystems for a P2P-architecture. Its homepage is located at jxta.org
It defines some basic concepts:
- peers,
- peer groups,
- services,
- end points,
- pipes
- advertisements.
A single entity in the network is called a peer. Peers take part in peer groups to form logical partitions of the network e.g. for security, scoping or monitoring purposes.
The membership of a peer to peer groups is not limited to a single group. A peer or a peer group can offer services which provide some functionality for other peers in the same peer group. JXTA distinguishes between three kinds of peers:
- The edge peer has no special responsibilities with respect to the operation of the whole P2P network.
- The rendezvous peers form a special network of super peers caching advertised peer information for a rapid look-up of network resources.
- The relay peer allows for communication between peers otherwise isolated either by physical network barriers or limitations (e.g. firewalls).
To find or to announce resources (peers, peer groups, services, pipes) in a peer group different types of advertisements can be sent or received by the Peer Discovery Protocol (PDP). Advertisements are language-neutral meta data structures represented as XML documents to describe the resources. To manage the membership in a group and to propagate messages in a peer group the Rendezvous Protocol (RVP) is defined.
In addition, a simple management information protocol, the Peer Information Protocol (PIP), for retrieving management information of other peers, such as state, uptime, traffic load, capabilities, is available. PDP and PIP are based on the Peer Resolver Protocol (PRP), a generic query/response protocol, which can also be extended for other types of queries. PRP enables a peer to make generic queries to one or multiple peers and to get one or multiple responses to the query. At this, the query is matched against a value specified by the requestor.
Endpoint Routing Protocol (ERP) allows for generic exchange of routing information. A peer can use it to find a route (sequence of hops) to use for sending a message to another peer. It is designed to be robust against frequent changes of the topology.
Pipe Binding Protocol (PBP) allows peers to advertise, resolve information regarding to and manage so-called pipes. Pipes are virtual communication channels across the network between one or more peers for the communication between these peers.
A variety of different types of low-level message transport protocols, such as HTTP, TCP/IP, and TLS can be used in the current reference implementation of JXTA. By using the ERP also peers connected to different low-level network types can be allowed to participate together with JXTA.
There is a reference implementation of the architecture in Java, but other implementations in C, Ruby, Phyton, or Perl are also available. Like in other P2P architectures peers can be added/dropped at any time. To allow for a service provisioning change using other resources, no physical network addresses are used, but a JXTA addressing scheme is used.
Evaluation and Applicability
For the realization of the GFD JXTA seems to be a promising candidate, even though only few independent information about the framework has been found on the web. The description above is mainly from the JXTA homepage as other descriptions do not provide a critical review. Therefore, we might encounter unforeseen difficulties when applying JXTA (should not be the problem with Web Services, we suppose). They claim to have a community of 14,000 people, but we guess there could be support problems.
In general, as the GFD proposes a service-oriented, non-centric approach (in contrast to the so-called domain manager approach), a peer-to-peer architecture like JXTA might be suitable, because it can cope with highly dynamic, de-centralised network environments.
JXTA has designed his group membership concept with the possibility for authentication and authorisation, although this is not handled by JXTA framework itself. So AA issues of GFD can be realized by JXTA group concept. The Lookup Service of GFD could be realized in JXTA using advertisements and the Peer Discovery Protocol. All measurement queries could be based on the generic Peer Resolver Protocol.
It should be discussed whether such a peer-to-peer solution needs to be combined with another framework like JINI/Web Services as some communication in the GFD cannot be regarded as p2p (e.g. retrieval of information from measurement points).
