Distributed & Parallel Programming in JEE

Distributed App - Java Enterprise Edition

JNDI – Java Naming Directory Interface

RMI – Remote Method Invocation

CORBA – Agents Oriented Programming

Web Services – WSDL+SOAP

JMS – Java Messages Service – Java Web Server Queues and Topics

EJB – Enterprise Java Beans Components

SOA/Rules Engines/BMP-BPEL – ITC Secure System Design lectures

P2P – Peer To Peer – JXTA / Jini Java Space

Cloud-Virtualization – VMWare VCenter-VSphere/Google–Apache Hadoop

Security:
Policies for RMI/CORBA/EJB
XML Security + WS-Security + JAAS for JBOSS
JCA – Java Crypto Architecture Programming in distributed applications

Secure Distributed Application Development

Section 4

Part I – JRMI – Java Remote Method Invocation

• RMI Overview
• Java RMI allows the programmers to invoke/call
procedures/methods from a class inside in a remote virtual
machine exactly as it is in the local virtual machine.
Local Machine (Client) Remote Machine (Server)

SampleServerInterface
remoteObject;
int s;
…

s = remoteObject.sum(1,2); 1,2
public int sum(int a,int b) {
return a + b;
}

System.out.println(s);
3
Section 4

Part I – JRMI – Java Remote Method Invocation

RMI Architecture
• RMI Server must register its name and
address in the RMI Registry program –
bind

• RMI Client is looking for the address and

the name of the RMI server object in the
RMI Registry program – lookup

• RMI Stub serializes and transmits the

parameters of the call in sequence –
“marshalling” to the RMI Skeleton. RMI
Skeleton de-serializes and extracts the
parameters from the received call –
“unmarshalling”. In the end, the RMI
Skeleton calls the method inside the
server object and send back the
response to the RMI Stub through
“marshalling” the return’s parameter.
Section 4

Part I – JRMI – Java Remote Method Invocation

JRMI Stub & Skeleton

call

skeleton
Stub
RMI Client RMI Server
return
• The client invokes a remote method after obtaining the reference to the
server object through JRMI registry program from the server. The client
delegates the involved method invocation sockets and protocol to the JRMI
Stub class/instance-object.

• JRMI Stub is responsible for calling the method, using the parameter
marshalling technique in order to transfer them to the JRMI Skeleton
class/instance-object. The JRMI Skeleton class/instance-object from the
server side sends the returned response to the JRMI Stub, so the stub must
un-marshalling the result and must pass it to the client object.
• Technically, the JRMI Stub opens socket to the server, “marshaling” the
serializable objects parameters to the server and receive the result from the
JRMI Skeleton.
• JRMI Skeleton has a method that executes the remote calls from the stubs
and it use “un-marshaling” technique in order to extract the parameters of
the call and in order to instruct the JRMI server object to run the invoked
method with the received parameters
Section 4
Part I – JRMI – Java Remote Method Invocation
*in readme.txt:
Developing RMI System
DEVELOPMENT of the RMI SERVER:
1. Defining the remote interface
2. Developing the Java class for instantiation of the JRMI server
object – implementing the interface from the step 1.
3. Developing the Java main server program
4. Compiling the Java server classes source code and generating
the JRMI Skeleton & JRMI Stub classes using rmic utility
program
DEVELOPMENT of the RMI CLIENT:
5. Developing the Java client program
6. Copying the Java compiled byte-code files for JRMI Stub and
for the remote interface – from the server side to the client
side
7. Compiling the client Java source code file together with the
files from step 6.
RUNNING RMI SERVER:
8. Start the JRMI registry program.
9. Start the server program.
RUNNING RMI CLIENT:
10.Start the client program
Section 4

Part I – JRMI – Java Remote Method Invocation

Step 1: Defining the remote interface

• Remote interface between the client and

server objects.

/* SampleServerInterface.java */
import java.rmi.*;

public interface SampleServerInterface extends Remote

{
public int sum(int a,int b) throws RemoteException;
}
Section 4

Part I – JRMI – Java Remote Method Invocation

Step 2: Development of the remote object implementing

the remote interface

• JRMI server object is “unicast remote server” => inheriting the

class java.rmi.server.UnicastRemoteObject.
• JRMI server object implements the interface from the step 1.

/* SampleServerImpl.java */
import java.rmi.*;
import java.rmi.server.*;
import java.rmi.registry.*;
public class SampleServerImpl extends UnicastRemoteObject
implements SampleServerInterface {
SampleServerImpl() throws RemoteException
{ super(); }
Section 4

Part I – JRMI – Java Remote Method Invocation

Step 2: Development of the remote object implementing the

remote interface

/* SampleServerImpl.java */
public int sum(int a,int b) throws RemoteException
{
return a + b;
}
}
Section 4

Part I – JRMI – Java Remote Method Invocation

Step 3: Development of the main server program

The main JRMI server program, activate the RMISecurityManager in

order to protect its own resources in the network and to expose only
the items specified in the security policies from the java.policy file.

The main server program creates the JRMI server object from the
class created in step 2 and implements the interface from the step 1.

The JRMI server must register the object in JRMI registry utility
program – bind() or rebind().
Section 4

Part I – JRMI – Java Remote Method Invocation

Step 3: Development of the main server program

/* SampleServerProgMain.java */
public static void main(String args[])
{
try
{
System.setSecurityManager(new RMISecurityManager());
//set the security manager

//create a local instance of the JRMI server object

SampleServerImpl Server = new SampleServerImpl();

//put the local instance in the registry

Naming.rebind("rmi://localhost:1099/SAMPLE-SERVER" , Server);
...
Section 4

Part I – JRMI – Java Remote Method Invocation

Step 4: Development of the client program

• The JRMI client program activates the RMISecurityManager in order to
expose to the JRMI server only the parts specified in the java.policy file.

• The client program should obtain the reference to the remote object in
order to invoke a remote method from the server object. The JRMI clients
receive the reference to the remote server object after interrogation of
the JRMI registry application – using the lookup() method from
java.rmi.Naming
• The JRMI server object name is like an URL:
rmi://server_registry_host:port/server_rmi_name
rmi://127.0.0.1:1099/SAMPLE-SERVER
• The default port used by the JRMI registry application is 1099.
• The name specified in URL, “server_rmi_name”, must be the same as the
one used by the JRMI server when registered – bind() into JRMI registry
application. For instance, here, the name is “SAMPLE-SERVER”

• The call of the remote object is, from the syntax point of view, the same
as calling a local method but using the a client object with the remote
interface as data type (SampleServerInterface remoteObject).
 Step 5: The client program development
import java.rmi.*;
import java.rmi.server.*;
public class SampleClient
{
public static void main(String[] args)
{
// set the security manager for the client
System.setSecurityManager(new RMISecurityManager());
//get the remote object from the registry
try
{
System.out.println("Security Manager loaded");
String url = “rmi://localhost:1099/SAMPLE-SERVER";
SampleServerInterface remoteObject =
(SampleServer)Naming.lookup(url);
System.out.println("Got remote object");
System.out.println(" 1 + 2 = " + remoteObject.sum(1,2) );
}
catch (RemoteException exc) {
...
 Java Security Policy File – java.policy
Section 4
Part I – JRMI – Java Remote Method Invocation
• In Java, an application actions take into account the privileges
required by Java Virtual Machine - JVM - java.exe to the OS-Operating
System. The JVM is instructed by a Java Policy file. Usually is in
%JAVA_HOME%/jre/lib/security folder or can be passed as parameter
to the JVM through -Dpolicy.file=… option:

grant {
permission java.security.AllPermission;
};

• A modified sample for Java Policy file permission:

grant {
permission java.io.filePermission “d:/tmp”, “read”, “write”;
permission java.net.SocketPermission
“somehost.somedomain.com:999”,”connect”;
permission java.net.SocketPermission “*:1024-
65535”,”connect,request”;
permission java.net.SocketPermission “*:80”,”connect”;
};
Section 4

Part I – JRMI – Java Remote Method Invocation

Comments over the Java Policy file – the second file

1. It permits the Java class to read and write files from the
“d:/tmp” folder and subfolders.

2. It permits the Java class to establish network connections

with “somehost.somedomain.com” in the 999 port.

3. It permits the Java class to accept the network connections

from any computer as long as the requests are coming for the
network ports greater than 1024

4. It permits the Java class to establish the network connections

to any computer from the network as long as the requests are
for port 80 from the server side, in common way for HTTP
protocol.
Section 4

Part I – JRMI – Java Remote Method Invocation

Necessary items for running JRMI

1. The firewall should be configured both on the server and

on the client side

2. The security policy files fisier java.policy should be

configured both on the server and on the client side

3. The programs run taking into account the security policies

described in the java.policy file and JVM heap resize –
option -Xms1000000000
Section 4

Part II – CORBA

OMG created CORBA. CORBA loves JAVA.

1. CORBA Basic Architecture
2. CORBA Basic Flow
3. ORB – Object Request Broker
4. GIOP vs IIOP, IOR
5. IDL is CORBA “language independency”
6. CORBA Services
7. Products – SUN Java IDL
Section 4

Part II – CORBA – Basic Architecture

Client Host Machine Server Host Machine

Client Remote
Object Object

Stub Skeleton

ORB IIOP ORB

Section 4

Part II – CORBA – Basic Architecture

Stubs and Skeletons

• Stub
– lives on client
– pretends to be remote object
• Skeleton
– lives on server
– receives requests from stub
– talks to true remote object
– delivers response to stub

Similar with RMI 1.1 in concepts

Section 4

Part II – CORBA – Basic Architecture

Client Server

request response

ORB ORB
“Object Bus”
Section 4

Part II – CORBA Basic Flow without ORB is like RMI

Client Virtual Machine Server Virtual Machine

Client Remote
Object

Skeleton
Stub Server

“Gigel”
Copyright © 1997 Alex Chaffee
Name Server Virtual Machine
Section 4

Part II – CORBA Basic Flow without ORB is like RMI

1. Server Creates Remote Object

Client Virtual Machine Server Virtual Machine
2. Server Registers Remote Object
Client Remote
Object
1

Skeleton
Stub Server

“Gigel”
Copyright © 1997 Alex Chaffee
Name Server Virtual Machine
Section 4

Part II – CORBA Basic Flow without ORB is like RMI

Client Virtual Machine Server Virtual Machine

Client 3. Client requests object fromRemote
Name Server
4. Name Server returns remote reference
Object
(and stub gets created)

Skeleton
Stub Server
3 4

“Gigel”
Copyright © 1997 Alex Chaffee
Name Server Virtual Machine
Section 4

Part II – CORBA Basic Flow without ORB is like RMI

Client Virtual Machine Server Virtual Machine

Client Remote
Object
5 7

6
Skeleton
Stub Server

5. Client invokes stub method

6. Stub talks to skeleton
7. Skeleton invokes remote object
method “Gigel”
Copyright © 1997 Alex Chaffee
Name Server Virtual Machine
Section 4

Part II – CORBA – ORB Conceptual

• OMG does not specify exactly where the

ORB is in CORBA.

• Depending on which CORBA

implementation (product) is used, the
ORB may be:
– A set of run-time libraries
– A server machine/process
– Part of the operating system (Spring)
– Part of a web browser (Netscape)
Section 4

Part II – CORBA – ORB in Practice

FEATURES:
Object Request Broker - “Object Bus”
Handles all communication among objects
Each host (machine) has its own ORB
ORBs know how to talk to each other
ORB also provides basic services to client

RESPONSABILITIES:
Find the object implementation for the request
Prepare the object implementation to receive the request
Communicate the data making up the request
Retrieve results of request

Note:
There’s an ORB on the server too, and ORB receives request
ORB is good if Stub and Skeleton are written in different programming
language
Section 4

Part II – CORBA – ORB Features

• Method invocations
– Static and Dynamic
– Remote objects or CORBA services
• High-level language bindings
– Use your favorite language; ORB
translates
• Self-describing
– Provides metadata for all objects and
services
Section 4

Part II – CORBA – ORB Features

• Local or remote
– Same API wherever target object lives
• Preserves context
– Distributed security and transactions
• Coexistence with legacy code
– Just provide a wrapper object
Section 4

Part II – CORBA – ORB in Practice

What is an ORB really?

• Not a separate process

• Library code that executes in-process
• Listens to TCP ports for connections
– One port per local object
• Opens TCP sockets to other objects
– N ports per remote machine
Section 4

Part II – CORBA – GIOP and IIOP

• The OMG agreed protocol for ORB

interoperability is called the General Inter-
ORB Protocol (GIOP).
• GIOP defines the logical data
representation and message formats for
communication.
• The OMG defines a realization of GIOP
that uses TCP/IP as the transport layer.
This specialization is called the Internet
Inter-ORB Protocol (IIOP).
Section 4

Part II – CORBA – GIOP and IIOP

Section 4

Part II – CORBA – GIOP and IIOP

GIOP Messages:

• Request message contains a complete marshaled

invocation request (object reference, name of the
method, input parameters)
– Each request has request ID

• Reply message contains a marshaled return values

and output parameters
– Reply message has a corresponding request ID of the
request message
Section 4

Part II – CORBA – ORB

• An IOR (Interoperable Object Reference)

is managed internally by the
interoperating ORBs.
• An IOR may include:
– ORB's internal object reference
– Internet host address
– Port number
• It is not necessary for an application
programmer to know the structure of an
IOR.
Section 4

Part II – CORBA – ORB

IOR:000000000000001049444c3a466f7274756e653a312e300
000000001000000000000005e00010000000000186d617966
6c792e73642e6d6f6e6173682e6564752e617500070a00000
00000363a5c6d6179666c792e73642e6d6f6e6173682e6564
752e61753a666f7274756e653a466f7274756e65313a3a495
23a466f7274756e65
Section 4

Part II – CORBA – ORB

Pseudo-objects
• The ORB is a pseudo-object
• It works just like a remote object, only it’s local

The Basic Object Adapter (BOA)

• Another pseudo-object
• Helps register objects with the ORB
• Functions
– Maintain Implementation Repository
– Generate and interpret object references
– Activate and deactivate implementation objects
– Invoke methods via skeletons
Section 4

Part II – CORBA – ORB

Why do you need both an ORB and a BOA?

• Allows vendors to optimize or enhance

functionality
– register many objects en masse
– cache object state elsewhere
• E.g. Object database
Section 4

Part II – CORBA – ORB

Using the BOA

• Slightly different procedure for initializing

objects
• Hides name service from you
– Ask the BOA to register the object
– Ask the Helper object to bind the object
• Once the object is created, interface is
identical
– Just call methods using normal Java syntax
Section 4

Part II – CORBA – POA/ORB

Object Adapters
Portable Object Adapter – POA

The POA:
• Allows the ORB and Objects to communicate
• Provides many services:
– Dispatches client calls to server objects
– Handles incoming client calls
– Handles registration of servers
– Instantiatiates objects at runtime and creates
and manages object references
• POA is a BOA – Basic Object Adapter
Section 4

Part II – CORBA – ORB

Invocation
ORB

POA Manager

POA
POA
Architecture

• A typical example of the relationship

between POA and servants
Section 4

Part II – CORBA – ORB

Section 4

Part II –
CORBA – ORB
Section 4

Part II – CORBA use IDL for independency

• Interface Definition Language

• Defines protocol to access objects
• Like a contract
• Well-specified
• Language-independent
Section 4

Part II – CORBA use IDL for independency

Section 4

Part II – CORBA use IDL for independency

//IDL Sample:
module Calc {
interface Adder {
long add(in long x, in long y);
}
}
• Defines an class called Adder which
generates objects with a method
called “add”
Section 4

Part II – CORBA use IDL for independency

IDL vs. Java vs. C++ concepts

IDL Java C++
module package namespace
interface interface abstract
class
operation method member
function
attribute pair of pair of
methods functions
Section 4

Part II – CORBA use IDL for independency

IDL Modules

• Map to Java packages

• Unfortunately, it has the root level name of
the module
• Clutters up your package hierarchy
IDL Interfaces

• Map to Java interfaces

IDL Operations

• Map to Java methods

Section 4

Part II – CORBA use IDL for independency

IDL Attributes
• Map to pair of functions – like C# do
• IDL
– string name;
• Java
– public void name(String val);
– public String name();
Section 4

Part II – CORBA Services

CORBA Services

• APIs for low-level, common tasks

• Life Cycle Service
– creating, copying, moving, removing
objects
• Naming Service
– Register objects with a name
– Look up objects by name
Section 4

Part II – CORBA Services

• Concurrency Control Service

– Obtain and release exclusive locks
• Transaction Service
– Two-phase commit coordination
– Supports nested transactions
• Persistence Service
– Storing objects in a variety of databases
– RDBMS, OODBMS, file systems
• Security Service
– Authentication, ACLs, encryption, etc.
• Event Service
– Uncoupled notifications
Section 4

Part II – CORBA Services

• Relationship
• Externalization
• Query
• Licensing
• Properties
• Time
• Trader
• Collection
• … and so on…
• See what means about CORBA will
be never being implemented?
Section 4

Part II – CORBA Products

Remember!
• CORBA is a standard by OMG, not an implementation.

• There are many implementations in Java and C/C++:

– SUN JDK – Java 2 ORB
– VisiBroker for Java or for C++
– Orbacus
– Orbix
– Visigenic(freely available),

• Depending on the particular CORBA implementation, non-

standardized aspects may be different.
Section 4

Part II – SUN Java IDL

• Should be named “Java CORBA”

– More than just IDL
– Full (?) implementation of CORBA in 100% Java
• SUN Java IDL has 3 Parts:
– ORB
– Naming Service – COS – CORBA Object
Service: tnameserv.exe (Non-persistent) &
orbd.exe (Persistent)
– idltojava & javatoidl compiler – now: idlj.exe
• Ships starting with JDK 1.2
Section 4

Part II – SUN Java IDL

The Java ORB

• 100% Java
• Generic
• Allows Java IDL applications to run
either as stand-alone Java
applications, or as applets within
Java-enabled browsers
• Uses IIOP
Section 4

Part II – SUN Java IDL

The compiler: Transparent API

• JavaIDL turns IDL into direct method calls
• Easy to program
• Clients have no knowledge of implementation
• Highly portable
Section 4

Part II – SUN Java IDL

The compiler idlj: IDL to Java

Mapping
• Defined by OMG and implemented here by
SUN
• Translates IDL concepts into Java
language constructs
• Everything is accessible by writing normal-
looking Java code
Section 4

Part II – SUN Java IDL

The compiler idlj: IDL to Java Type Mapping

IDL Type Java Type
boolean boolean
char / wchar char
octet byte
short / unsigned short short
long / unsigned long int
long long / unsigned long long
long float
float double
double String
string / wstring
Section 4

Part II – SUN Java IDL

The compiler: idlj or idltojava

• Development tool provided by SUN

• Automatically generates Java
stubs, skeletons, helpers, holders,
... from IDL
• Generates stubs for specific remote
interfaces
Section 4

Part II – SUN Java IDL

Stubs – Client Side

• Java objects call stub methods

• Stubs communicate with CORBA objects
– and vice versa
• Transparent integration

Skeletons – Server Side

• ORB passes request to skeleton (like a stub)

• Skeleton calls local implementation
Section 4

Part II – SUN Java IDL

DEMO – CORBA Server & Client

Remote Interfaces and Stubs
IDL Interface

implements implements
extends
Remote Object
Client Stub Skeleton
(Server)
Section 4

Part II – CORBA vs. RPC/RMI

• Proxy is equivalent to client stub in RPC/RMI; it provides the same

object interface as the server object
• Proxy marshalls method invocations into messages and unmarshall
the reply messages
• Skeleton is like a server stub in RPC/RMI
Section 4

Part II – CORBA Advanced Architecture

Object Model
• ORB provides few services through ORB interface
• Operations to marshall and unmarshall object references
• Getting object reference to an object implementing a specific CORBA service
Section 4

Part III – Web Services

1. Web Service Overview

2. XML-RPC
3. Web Service WSDL
4. Web Service SOAP Req & Resp
5. Java Web Service Server – Bottom-Up
6. Java Web Service Server – Top-Down
7. Java Web Service Client – ADB - Top-
Down
Section 4

Part III – Web Services Overview

"a software system designed to support interoperable Machine to

Machine interaction over a network.“ (W3C)
Remote Procedure Call over HTTP
Section 4

Part III – Web Services – XML-RPC

Section 4

Part III – Web Services – XML-RPC

remote procedure calls using HTTP for transport and XML as encoding

XML-RPC message is an HTTP-POST request

very simple XML - doesn't use XML namespaces or attributes

works only with HTTP

Section 4

Part III – Web Services – Products & WSDL

Web Services Products:

Apache AXIS2 for Java – course

SUN Java-WS – integrated in NetBeans 6.0.1 – seminar

WSDL Concept:

WSDL – Web Service Definition Language

WSDL = XML document that describes a web service

WSDL – Specifies the location of the service and the operations (or
methods) it exposes
Section 4

Part III – Web Services – WSDL

A WSDL describes a web service using the

following elements:

<binding> contains communication

protocols used by the web service
<portType> defines the operations that can
be performed by a web service, and the
messages that are involved
<message> defines the in/out messages
that are used by the operations methods
<types> defines data types used by the
messages

A WSDL document can also contain

extension elements and a <service> element
that makes it possible to group together the
definitions of several web services .
Section 4

Part III – Web Services – SOAP

SOAP – Simple Object Access Protocol

simple XML based protocol to let applications exchange

information over HTTP

defines a format for sending messages

allows you to get around firewalls (firewalls and proxy servers

normally block RPC traffic)

platform and language independent

transport Protocols: TCP, HTTP, SMTP, and MQ – Message

Queues
Section 4

Part III – Web Services – SOAP

A SOAP message is an ordinary XML

containing the following elements:

<Envelope> which identifies that the XML

document is a SOAP message

<Header> which contains application

specific information about the SOAP
message (such as authentication, payment,
etc) .

<Body> contains the actual SOAP

message

<Fault> contains eventual error messages

Section 4

Part III – Web Services – SOAP with Attachments

The SOAP messaging protocol allows you to send MIME

attachments via SOAP messages. WSDL provides a description of
these attachments.

SOAP with Attachments API for Java (SAAJ) allows you to do

XML messaging from the Java platform

The SAAJ API conforms to the Simple Object Access Protocol

(SOAP) 1.1 and 1.2 specifications and the SOAP with
Attachments specification.
Section 4

Part III – Web Services – SOAP with Attachments

The SAAJ API provides the

SOAPMessage class to represent
a SOAP message.

SAAJ API also provides the

SOAPPart class that is the
container for the SOAP-specific
portion of a SOAPMessage
object. All messages are required
to have a SOAPPart.

A SOAPPart object is a MIME part

and has the MIME headers SOAP with no attachments
Content-Id, Content-Location,
and Content-Type
Section 4

Part III – Web Services – SOAP with Attachments

A SOAP message may include one

or more attachment parts in addition
to the SOAP part.

The SAAJ API provides the

AttachmentPart class to represent an
attachment part of a SOAP message.

An attachment part can contain

any kind of content.

SOAP with two attachments

Section 4

Part III – Web Services - UDDI

an XML-based registry for businesses worldwide to list themselves on the

Internet.

used in a similar manner to JNDI – to register and locate web services

is a directory for storing information about web services

is a directory of web service interfaces described by WSDL

Section 4

Part III – Web Services – A Java vs. Microsoft Architecture

Section 4

Part III – Creating Web Services - BOTTOM-UP - Server

1. set JAVA_HOME, AXIS2_HOME and CATALINA_HOME and all \bin to Path

2. compile java file: javac -cp . package/ServiceName.java
3. create wsdl file: %AXIS2_HOME%/bin/java2wsdl -cp . -cn
package.ServiceName -of ServiceName.wsdl
4. the structure of this service directory will be as follows:
- ServiceName
- META-INF
- services.xml
- ServiceName.wsdl
- lib
- webserv
- ServiceName.class
Section 4

Part III – Creating Web Services - BOTTOM-UP - Server

5. Create service.xml file (set description for service and parameter

name)
6. Copy ServiceName directory or ServiceName.aar to: axis2.war/WEB-
INF/services directory in your Servlet engine
7. start the web server
8. Obtain description of the service:
http://localhost:8080/axis2/services/ServiceName?wsdl
http://localhost:8080/axis2/services/ServiceName?xsd
Section 4

Part III – Creating Web Services – TOP-DOWN - Server

1. set JAVA_HOME, AXIS2_HOME and CATALINA_HOME and all \bin to Path

2. create WSDL file for service&create the skeleton for the web service using
the command: %AXIS2_HOME%/bin/WSDL2Java -uri META-
INF/ServiceName.wsdl -p webserv -d adb -s -ss -sd -ssi -o output_directory
3. the following structure of files is generated:
- resources
- services.xml
- ServiceName.wsdl
- src
- webserv
- java files
- build.xml
Section 4

Part III – Creating Web Services – TOP-DOWN - Server

4. modify ServiceNameSkeleton.java by adding code to the methods

5. set AXIS2_CASS_PATH and compile java files:
javac -cp .;%AXIS2_CLASSPATH% package/*.java
set up the directory structure:
ServiceName
- META-INF
- services.xml
- ServiceName.wsdl
- lib
- package
- class files
- build.xml
Section 4

Part III – Web Services

7. copy ServiceName directory or ServiceName.aar to: axis2.war/WEB-

INF/services directory in your servlet engine and start the server
8. Test the service:
http://localhost:8080/axis2/services/ServiceName?wsdl
http://localhost:8080/axis2/services/ServiceName?xsd
Section 4

Part III – Create Web Services – TOP-DOWN Client

CLIENT types in AXIS 2:

Axis2 Databinding Framework (ADB): ADB is probably the simplest method of
generating an Axis2 client. In most cases, all of the pertinent classes are
created as inner classes of a main stub class. It is not meant to be a full
schema binding application, and has difficulty with structures such as XML
Schema element extensions and restrictions.
XMLBeans: Unlike ADB, XMLBeans is a fully functional schema compiler, so it
doesn't carry the same limitations as ADB. It is, however, a bit more
complicated to use than ADB. It generates a huge number of files, and the
programming model, while being certainly usable, is not as straightforward
as ADB.
Section 4

Part III – Create Web Services – TOP-DOWN Client

CLIENT types in AXIS 2:

JiBX: JiBX is a complete databinding framework that actually provides not only
WSDL-to-Java conversion, but also Java-to-XML conversion. In some ways,
JiBX provides the best of both worlds. JiBX is extremely flexible, enabling you
to choose the classes that represent your entities, but it can be complicated
to set up. On the other hand, once it is set up, actually using the generated
code is as easy as using ADB.
Section 4

Part III – Create Web Services – TOP-DOWN Client

1. Generate client ADB from web service wsdl file using th command:
%AXIS2_HOME%/bin/WSDL2Java -uri ServiceName.wsdl -p clientpackage -d
adb –s
2. compile the stub
javac -cp .;%AXIS2_CLASSPATH% clientpackage/ClientStub.java
3. Compile and run the client
javac -cp .;%AXIS2_CLASSPATH% clientpackage/Client.java
java -cp .;%AXIS2_CLASSPATH% clientpackage/Client.java
Section 4

Part IV – JMS API

Section 4

Part IV – JMS Point2Popint vs. Topic

Section 4

Part IV – JMS Synchronous vs. Asynchronous

Sun Message Consumption Types:

“Messaging products are inherently asynchronous in that no fundamental timing
dependency exists between the production and the consumption of a message.
However, the JMS Specification uses this term in a more precise sense.
Messages can be consumed in either of two ways:

* Synchronously. A subscriber or a receiver explicitly fetches the message

from the destination by calling the receive method. The receive method can
block until a message arrives or can time out if a message does not arrive within
a specified time limit.
* Asynchronously. A client can register a message listener with a consumer. A
message listener is similar to an event listener. Whenever a message arrives at
the destination, the JMS provider delivers the message by calling the listener's
onMessage method, which acts on the contents of the message.”
Section 4

Part IV – JMS API Programming Model

Section 4

Part IV – JMS Non-Durable vs. Durable Topic Subscription

Section 4

Part V – EJB Overview and Products

The Enterprise JavaBeans (EJB) 1.x, 2.x and 3.x specifications define
an architecture for the development and deployment of
transactional, distributed object applications-based, server-side
software components.
Java Web Servers with EJB Containers:
JBoss – RedHat Linux Division – Portlet + BPM/BPEL – Rules Engine
BEA Web Logic – purchased by Oracle
GlassFish – Sun Microsystems – purchased by Oracle / IBM lost - Portlet
Oracle 9iAS – Oracle
Apache GERONIMO – the only openSource compliant with JEE 5.0
IBM Web Sphere - Portlet
Section 4

Part V – EJB Container

The Enterprise JavaBeans

specification defines an
architecture for a
transactional, distributed
object system based on
components.
The specification mandates a
programming model; that is,
conventions or protocols
and a set of classes and
interfaces which make up
the EJB API.
Section 4

Part V – EJB Container

Enterprise beans are software components that run in a special

environment called an EJB container.

The EJB container hosts and manages an enterprise bean in the same
manner that the Java Web Server hosts a servlet or an HTML browser
hosts a Java applet. An enterprise bean cannot function outside of an
EJB container.

The EJB container manages every aspect of an enterprise bean at

runtimes including remote access to the bean, security, persistence,
transactions, concurrency, and access to and pooling of resources.
Section 4
Part V – EJB Interaction with EJB Container
An enterprise bean depends on the container for everything it needs. If an
enterprise bean needs to access a JDBC connection or another enterprise
bean, it does so through the container; if an enterprise bean needs to access
the identity of its caller, obtain a reference to itself, or access properties it
does so through the container.

The enterprise bean interacts with its container through 1 of 3

mechanisms (from JNDI are triggered Callback methods or
EJBContext):
JNDI – Java Naming and Directory Interface – ENC – Environment Naming
Context like: rmiregistry 4 RMI, COS 4 CORBA, UDDI 4 WS
Callback Methods
EJBContext
Section 4

Part V – EJB Interaction with EJB Container

JNDI ENC

JNDI – Java Naming and Directory Interface is a standard extension to the

Java platform for accessing naming systems like LDAP, NetWare, file
systems, etc. Every bean automatically has access to a special
naming system called the ENC – Environment Naming Context. The
ENC is managed by the container and accessed by beans using JNDI.
The JNDI ENC allows a bean to access resources like JDBC
connections, other enterprise beans, and properties specific to that
bean.
Section 4

Part V – EJB Interaction with EJB Container

Callback Methods

Every bean implements a subtype of the EnterpriseBean interface which

defines several methods, called callback methods. Each callback
method alerts the bean TO a different event in its lifecycle and the
container will invoke these methods to notify the bean when it's about
to activate the bean, persist its state to the database, end a
transaction, remove the bean from memory, etc. The callback methods
give the bean a chance to do some housework immediately before or
after some event.
Section 4

Part V – EJB Interaction with EJB Container

EJBContext

Every bean obtains an EJBContext object, which is a reference directly to

the container. The EJBContext interface provides methods for
interacting with the container so that that bean can request
information about its environment like the identity of its client, the
status of a transaction, or to obtain remote references to itself.

The EJBContext could be EntityContext or SessionContext;

Section 4

Part V – EJB 2.x DEMO

JBOSS EJB 2.x and JMS DEMO

JMS Test
Session Bean
Stateful vs Stateless
Entity Bean
CMP vs BMP
Message Driven Bean
Section 4

Part V – Software Conceptual View of EJB 1.x

Section 4

Part V – Software Conceptual View of EJB 1.x

The home interface represents the

life-cycle methods of the component
(create, destroy, find)
while the remote interface represents
the business method of the bean.

The remote interface extends the

javax.ejb.EJBObject.

The home interface extends

javax.ejb.EJBHome interface.

These EJB interface types define a

standard set of utility methods and
provide common base types for all
remote and home interfaces.
Section 4

Part V – EJB as Distributed Objects – RMI/IIOP

Section 4

Part V – EJB as Distributed Objects – RMI/IIOP

The remote and home interfaces are types of Java RMI Remote
interfaces. The java.rmi.Remote interface is used by distributed
objects to represent the bean in a different address space (process
or machine). An enterprise bean is a distributed object.

That means that the bean class is instantiated and lives in the
container but it can be accessed by applications that live in other
address spaces – in other JVMs and other computer machines.
Section 4

Part V – EJB as Distributed Objects – RMI procedure

To make an object instance in one address space available in another requires a

little trick involving network sockets. To make the trick work, wrap the instance
in a special object called a skeleton that has a network connection to another
special object called a stub. The stub implements the remote interface so it
looks like a business object. But the stub doesn't contain business logic; it
holds a network socket connection to the skeleton. Every time a business
method is invoked on the stub's remote interface, the stub sends a network
message to the skeleton telling it which method was invoked. When the
skeleton receives a network message from the stub, it identifies the method
invoked and the arguments, and then invokes the corresponding method on
the actual instance. The instance executes the business method and returns
the result to the skeleton, which sends it to the stub.
Section 4

Part V – EJB Types in EJB 1.1 and 2.1

EJB Types:
1. Entity EJBs
1.1 CMP – Content Managed Persistence
1.2 BMP – Bean Managed Persistence
2. Session EJBs
2.1 Stateless
2.2 Stateful
3. Message Driven Beans – see JMS and JTA
Section 4

Part V – EJB Types in EJB 3.0

EJB Types:
1. Session EJBs
1.1 Stateless
1.2 Stateful
2. Message Driven Beans – see JMS and JTA

Entity EJBs => are included within Java Persistence API

CMP – Content Managed Persistence
BMP – Bean Managed Persistence
Section 4

Part V – EJB 2.1 Life-cycle of a Entity Bean

Section 4

Part V – EJB 2.1 Life-cycle of a Stateful Session Bean

Section 4

Part V – EJB 2.1 Life-cycle of a Stateless Session Bean

Section 4

Part V – EJB 2.1 Life-cycle of a Message Driven Bean

Section 4

Part V – JMS API Local Transaction vs. EJB distributed Transaction

Sun: “Distributed transactions can be either of two kinds:

* Container-managed transactions. The EJB container controls the integrity of your
transactions without your having to call commit or rollback. Container-managed
transactions are recommended for J2EE applications that use the JMS API. You can
specify appropriate transaction attributes for your enterprise bean methods. Use the
Required transaction attribute to ensure that a method is always part of a transaction. If a
transaction is in progress when the method is called, the method will be part of that
transaction; if not, a new transaction will be started before the method is called and will be
committed when the method returns.
* Bean-managed transactions. You can use these in conjunction with the
javax.transaction.UserTransaction interface, which provides its own commit and rollback
methods that you can use to delimit transaction boundaries.”
Section 4

Part V – EJB 2.x Life-cycle of a Message Driven Bean

Sun: “Like a stateless session bean, a message-driven bean can have many
interchangeable instances running at the same time. The container can pool
these instances to allow streams of messages to be processed concurrently.
Concurrency can affect the order in which messages are delivered, so you
should write your application to handle messages that arrive out of sequence.”
Section 4

Part V – EJB 2.x Combined Sample – Session + Message Driven

Section 4

Part V – Entity vs. Session EJB 1.x

The remote interface defines business
methods.

The business methods could be:

• accessor and mutator methods
(get/set) to read and update
information about a business
concept – like in Customer interface
=> entity bean.

• tasks that a bean performs - tasks

are more typical of a type of bean
called a session bean. Session
beans do not represent data like
entity beans. They represent
business processes or agents that
perform a service, like making a
reservation at a hotel – like in
HotelClerk interface => session
bean.
Section 4

Part V – Entity vs. Session EJB 1.x

Section 4

Part V – Entity EJB 1.x

1. Entity EJBs
CustomerHome.java – Home
interface – EJB life-cycle methods.

Customer.java – Remote
Interface – business methods
– here get/set.
Section 4

Part V – Entity EJB 1.x

1. Entity EJBs

CustomerBean.java – EJB entity class

Section 4

Part V – Entity EJB 1.x and 2.x

1. Entity EJBs – The entity bean is used to represent data in the database. It
provides an object-oriented interface to data that would normally be
accessed by the JDBC or some other back-end API.
1.1 CMP – Container Managed Persistence – the container manages the
persistence of the entity bean. Vendor tools are used to map the entity
fields to the database and absolutely no database access code is written
in the bean class.
1.2 BMP – Bean Managed Persistence – the entity bean contains
database access code (usually JDBC) and is responsible for reading
and writing its own state to the database. BMP entities have a lot of help
with this since the container will alert the bean as to when it's necessary
to make an update or read its state from the database.
Section 4

Part V – EJB Types 1.x and 2.x

2. Session EJBs – Session beans are used to manage the interactions of

entity and other session beans, access resources, and generally perform
tasks on behalf of the client. Session beans are not persistent business
objects as are entity beans. They do not represent data in the database.
2.1 Stateless – session beans are made up of business methods that
behave like procedures; they operate only on the arguments passed to
them when they are invoked. Stateless beans are called "stateless"
because they are transient; they do not maintain business state between
method invocations.
2.2 Stateful – Stateful session beans encapsulate business logic and
state specific to a client. Stateful beans are called "stateful" because
they do maintain business state between method invocations, held in
memory and not persistent.
Section 4

Part V – Session EJB 1.x

2. Session EJBs

HotelClerkHome.java – Home
interface – EJB life-cycle methods.
HotelClerk.java – Remote
Interface – business methods
– here TASKS.
Section 4

Part V – Session Stateless EJB 1.x

2. Session EJBs - Stateless

HotelClerkBean.java – Stateless Session EJB.

Section 4

Part V – Session Stateless EJB 1.x

2. Session EJBs - Stateless

HotelClerkBean.java – Stateless Session EJB.

Section 4

Part V – Session Stateful EJB 1.x

2. Session EJBs - Stateful

HotelClerkBean.java – Stateful Session EJB.

Section 4

Part V – Session Stateful EJB 1.x

2. Session EJBs - Stateful

HotelClerkBean.java – Stateful Session EJB.

Section 4

Part V – Deploy EJB 1.x and 2.x

In EJB JAR file for Entity – within META-INF/ejb-jar.xml.
Section 4

Part V – Deploy EJB 1.x and 2.x

Part V – Deploy EJB 1.x and 2.x
Section 4

Part V – EJB 1.x, 2.x vs. EJB 3.x

Section 4

Part V – EJB 1.x, 2.x vs. EJB 3.x

Section 4

Part V – EJB 1.x, 2.x vs. EJB 3.x

Section 4

Part V – JAAS Security

In JEE:
Annotations-Reflection + (Taglibs + Generics + Servlet/JSP)
MVC + EJB + JMS + Rules Engine/BPM-BPEL = LOVE

JBOSS JAAS & WS-Security

Portlets + BPM + BPEL + Rules
Engine =>
JBOSS ESB/SOA vs. P2P JXTA
Section 4

Part VI – Distributed & Parallel Computing Systems – NOT in EXAM

What is a distributed system?
There are a lot of definitions within the technical literature.

A distributed system is a collection of the nodes such as:

computers;
micro-processors;
autonomous processes

Clustering App Servers, Cloud/Virtualization – VMWare

or CentOS, Apache Hadoop or JXTA P2P development
Are the same with the distributed and parallel
computing? Are the solutions implementations for that?
Section 4

Part VI – Distributed & Parallel Computing Systems

What is a distributed system?

In Tanenbaum the definition is more restrictive – a
system is distributed only if:

The autonomous nodes existence is transparent for

the end-user.

The entire architecture is an computing entity, and the

entire distribution responsibility is in the OSs kernels
from the nodes. The end-user is not aware about the
existence of more processors. The one perceives that
is working with only one virtual processor.
Section 4

Part VI – Distributed & Parallel Computing Systems

Distributed Systems Classification

Strong coupled systems, many microprocessors share

the same internal memory and have the same clock –
mainframes, industrial servers, transputers.

Loose coupled systems, each noe-system has its own

internal memory and its own internal clock.

The loose coupled systems are considered

distributed systems.
Section 4

Part VI – Distributed & Parallel Computing Systems

What is a Distributed System?

So, a distributed system is a collection of programs and

processes that run over a network of electronic devices
which cooperates for solving algorithms/problems sets:

- each node from the network has local autonomy in

terms of internal memory and clock,

- and the nodes are transparent for the end-user in

terms of solving the task/problem/algorithm.
Section 4

Part VI – Distributed & Parallel Computing Systems

Actions overview in a distributed & parallel computing system

The most important feature is the migration

phenomenon. The migration phenomenon has three
directions:
data migration;
calculus migration;
processes migration.

The main goal of the distributed & parallel

programming is to solve complex problems
through data and calculus migration.
Section 4

Distributed System? => Clustering Servers vs. Load Balancing

Section 4

Distributed System? => Clustering Servers vs. Load Balancing

Section 4

Distributed System? => Clustering Servers vs. Load Balancing

Most remote services provided by the

JBoss application server, including
JNDI, EJB, RMI and JBoss Remoting,
require the client to obtain (e.g., to look
up and download) a stub (or proxy)
object. The stub object is generated by
the server and it implements the business
interface of the service. The client then
makes local method calls against the stub
object. The call is automatically routed
across the network and invoked against
service objects managed in the server. In
a clustering environment, the server-
generated stub object is also an
interceptor that understand how to route
calls to nodes in the cluster. The stub
object figures out how to find the
appropriate server node, marshal call
parameters, un-marshall call results,
return the results to the caller client.
Section 4

Distributed System? => Clustering Servers vs. Load Balancing

Other JBoss services, in particular the

HTTP web services, do not require the
client to download anything. The client
(e.g., a web browser) sends in requests
and receives responses directly over
the wire according to certain
communication protocols (e.g., the
HTTP protocol). In this case, a load
balancer is required to process all
requests and dispatch them to server
nodes in the cluster. The load
balancer is typically part of the cluster. It
understands the cluster configuration as
well as failover policies. The client only
needs to know about the load balancer.
A potential problem with the load
balancer solution is that the load
balancer itself is a single point of
failure. It needs to be monitored closely
to ensure high availability of the entire
cluster services.
Section 4

Distributed System? => Clustering Servers vs. Load Balancing

Both the JBoss client-side interceptor (stub) and load balancer use load
balancing policies to determine which server node to send a new request to.
In this section, let's go over the load balancing policies available in JBoss AS.
Section 4

Distributed System? => Cloud / Virtualization

Section 4

Distributed System? => Cloud / Virtualization

Section 4

Distributed System? => Cloud / Virtualization

Section 4

Distributed System? => Cloud / Virtualization

Section 4

Distributed System? => Cloud / Virtualization

Section 4

Distributed System? => Cloud / Virtualization

Section 4

Distributed System? => Cloud / Virtualization

Section 4

Distributed System? => Cloud / Virtualization

Section 4

Distributed System? => Cloud / Virtualization

Beyond these enhancements, VMware is also working closely with both Intel and AMD
to ensure that new processor technology features are exploited by virtual infrastructure
to the fullest extent. In particular, the new virtualization hardware assist enhancements
(Intel’s “VT” and AMD’s “Pacifica”) will enable robust virtualization of the CPU
functionality. Such hardware virtualization support does not replace virtual infrastructure,
but allows it to run more efficiently.
Section 4

Distributed System? => Cloud / Virtualization

Section 4

Distributed System? => Cloud / Virtualization

Section 4

Distributed System? => Cloud / Virtualization - Amazon.com EC2

Amazon Elastic Compute Cloud (Amazon EC2) is a web service that

provides resizable compute capacity in the cloud. It is designed to make
web-scale computing easier for developers.

Amazon EC2’s simple web service interface allows you to obtain and
configure capacity with minimal friction. It provides you with complete
control of your computing resources and lets you run on Amazon’s
proven computing environment. Amazon EC2 reduces the time required
to obtain and boot new server instances to minutes, allowing you to
quickly scale capacity, both up and down, as your computing
requirements change.
Section 4

Distributed System? => Cloud / Virtualization - Amazon.com EC2

Section 4

Distributed System? => Cloud / Virtualization - Amazon.com EC2

Amazon EC2 Functionality

Amazon EC2 presents a true virtual computing environment, allowing you to use web service
interfaces to launch instances with a variety of operating systems, load them with your custom
application environment, manage your network’s access permissions, and run your image using as
many or few systems as you desire.

To use Amazon EC2, you simply:

Select a pre-configured, templated image to get up and running immediately. Or create an
Amazon Machine Image (AMI) containing your applications, libraries, data, and associated
configuration settings.
Configure security and network access on your Amazon EC2 instance.
Choose which instance type(s) and operating system you want, then start, terminate, and
monitor as many instances of your AMI as needed, using the web service APIs or the variety of
management tools provided.
Determine whether you want to run in multiple locations, utilize static IP endpoints, or attach
persistent block storage to your instances.
Pay only for the resources that you actually consume, like instance-hours or data transfer.
Section 4

Distributed System? => Cloud / Virtualization - Amazon.com EC2

Instance Types - 2011

Standard Instances

Instances of this family are well suited for most applications.

Small Instance (Default) 1.7 GB of memory, 1 EC2 Compute Unit (1 virtual core
with 1 EC2 Compute Unit), 160 GB of local instance storage, 32-bit platform

Large Instance 7.5 GB of memory, 4 EC2 Compute Units (2 virtual cores with 2
EC2 Compute Units each), 850 GB of local instance storage, 64-bit platform

Extra Large Instance 15 GB of memory, 8 EC2 Compute Units (4 virtual cores

with 2 EC2 Compute Units each), 1690 GB of local instance storage, 64-bit
platform
Section 4

Distributed System? => Cloud / Virtualization - Amazon.com EC2

Section 4

Distributed System? => Cloud / Virtualization - Amazon.com EC2

Section 4

Distributed System? => Cloud / Virtualization - Google.com

Section 4

Distributed System? => Cloud / Virtualization - Google.com

Section 4

CLOUD – Distributed System? – Google.com vs Amazon.com – WiKi:

Danielson, Krissi: Cloud computing is a natural
evolution of the widespread adoption of
virtualization, service-oriented architecture,
autonomic and utility computing. Details are
abstracted from end-users, who no longer have
need for expertise in, or control over, the
technology infrastructure "in the cloud" that
supports them.

The National Institute of Standards and Technology (NIST – nist.org) provides a somewhat
more objective and specific definition: "Cloud computing is a model for enabling
convenient, on-demand network access to a shared pool of configurable computing
resources (e.g., networks, servers, storage, applications, and services) that can be rapidly
provisioned and released with minimal management effort or service provider interaction."
Section 4

Distributed & Parallel Computing System

Advantages:
Schimbul de informaţii. Creşterea masivă a cantităţii de informaţie şi
necesitatea de a schimba rapid informaţii între diferitele puncte aflate în locuri
geografic depărtate fac necesară conectarea între calculatoare autonome.
Partajarea resurselor. O organizaţie preferă să cumpere mai multe
calculatoare mai ieftine şi de puteri rezonabile decât să cumpere unul singur,
mult mai puternic dar mult mai scump. În acest mod devine necesară
interconectarea acestor calculatoare mai mici între ele, eventual cu un număr
redus de calculatoare mai puternice ale căror resurse (memorie, putere a
procesorului, periferice de capacităţi mari) să fie partajate între acestea.
Siguranţă mărită în funcţionare. Dacă un sistem de calcul este format dintr-un
singur calculator, defectarea acestuia face imposibilă utilizarea întregului
sistem, pe cand intr-un sistem distribuit, căderea unui nod nu perturbă
funcţionarea celorlalte, ci acestea preiau sarcinile celui căzut.
Section 4

Distributed & Parallel Computing System

Avantages:

Performanţe mărite. Prezenţa mai multor procesoare într-un sistem distribuit

face posibilă reducerea timpului de realizare a unui calcul masiv. Acest fapt
este posibil prin împărţirea sarcinilor între diferite procesoare, colectarea
ulterioară a rezultatelor parţiale şi determinarea rezultatului final. Acest
procedeu este cunoscut sub numele de paralelizare a calculului.

Specializarea nodurilor. Proiectarea unui sistem de calcul autonom cu mai

multe funcţionalităţi poate să fie foarte dificilă şi din motive practice. Această
proiectare poate să fie simplificată prin împărţirea sistemului în module,
fiecare modul implementând o parte din funcţionalităţi şi comunicând cu alte
module.
Section 4

Distributed & Parallel Computing System

Features:
• suport pentru partajarea resurselor = aceleasi resurse sunt folosite de mai multi utilizatori;

• deschiderea = sistemul poate fi interfaat pe diferite căi;

• concurenta = mai mulţi utilizatori folosesc aceeaşi resursă în acelaşi timp;

• paralelism = un proces pentru a-şi soluţiona problema foloseşte în acelaşi timp diferite
resurse;

• scalabilitate = sistemul acţionează efectiv şi eficient pe diferite scale (datorită

eterogenitatiii resurselor);

• toleranta la erori = când apar accidente sistemul le rezolvă bazându-se pe redundanţa

hardware si software;

• transparenta = gradul de independenţă între componentele sistemului (resurse, utilizatori,

etc) la funcţionare.
Section 4

Distributed & Parallel Computing System

Transparency:
• transparenţa accesului = obiectele (informaţia) locale sau la distanţă vor fi
accesate utilizând operaţii identice;
• transparenţa localizării = obiectele vor fi accesate fără a se cunoaşte poziţia lor
în reţea;
• transparenţa concurenţei = mai multe procese pot opera concurenţial (în acelaşi
timp), utilizând obiecte partajate, fără să interfereze între ele şi fără ca utilizatorul
să remarce acest lucru;
• transparenţa replicării = multiple copii ale obiectelor pot fi utilizate pentru
creşterea performanţei, fără ca utilizatorii sau programele de aplicaţie să
cunoască replicările (copiile pe diferite noduri din reţea);
• transparenţa accidentelor = ascunderea erorilor;
• transparenţa migrării = mutarea obiectelor în sistem (informaţii, date, calcule,
procese) nu trebuie să afecteze operaţiile utilizatorilor sau programelor de
aplicaţie;
• transparenţa performanţelor = sistemul va fi reconfigurat automat la diferite
încărcări pentru creşterea performanţelor.
Section 4

Distributed & Parallel Algorithms Problems:

Lipsa cunoştinţelor despre starea globală. În fluxul de control al unui
algoritm centralizat deciziile se pot lua în funcţie de starea întregului
sistem.

Lipsa unui timp global. Evenimentele care constitue executarea unui

algoritm centralizat formează o mulţime total ordonată, relaţia de ordine
fiind cea naturală, conform cu apariţia temporală a acestor evenimente.

Pseudo-Nedeterminismul. Comportamentul unui program centralizat

poate fi descris în funcţie de datele de intrare. Pentru acelaşi set de
date de intrare, comportamentul unei aplicaţii este identic la rulări
diferite (exceptând cazurile în care se rulează programe ce tratează
subiecte din inteligenţa artificială). La distribuit poate varia
“nedeterminist” viteza de prelucrare, ordinea de tratare a clientilor data
de intarzierile de transmisie, etc.
Section 4

JXTA vs. Client-Server Traditional Model

Sample Applications: Web Radio, IP TV, VoIP/VioIP

Solutions/Conferences, File Download vs. Sharing
Section 4

JXTA vs. Client-Server Traditional Model

Sample Applications: Web Radio, IP TV, VoIP/VioIP

Solutions/Conferences, File Download vs. Sharing
Section 4

JXTA vs. Client-Server Traditional Model

Sample Applications: Web Radio, IP TV, VoIP/VioIP

Solutions/Conferences, File Download vs. Sharing
 Background to JXTA

Section 4

JXTA
Conceived by Sun Microsystems by Bill Joy (the creator of ‘vi’):

+ designed by a small number of experts from academic institutions and industry

• team identified a number of shortcomings in many existing peer-to-peer systems and set up
project JXTA in order to address these.
• their 3 main objectives of were to achieve interoperability, platform independence and ubiquity

The term JXTA is short for juxtapose, as in side by side

• a recognition that P2P is juxtaposed to client-server or Web-based computing,
which is today’s traditional distributed computing model.
Section 4

JXTA

JXTA: a Generic Framework for P2P Computing

• Open platform for P2P programming

• Common functionalities
• Language, OS, network agnostic
• Set of interoperable protocols (XML)
• Open source project:
– http://www.jxta.org
– http://download.java.net/jxta/
Section 4

JXTA

MyJXTA JXTA Interoperability:

(J2SE on Windows) Any Platform, Any Network

JXTA Chat
(MIDP)

JXTA Virtual Network

JXTA-C Shell
(C on Solaris)
Section 4

JXTA – Design Constraints

Interoperability
• software vendors tend to create specific code for their services e.g. file sharing,
instant messaging etc
• incompatible systems
• duplicate effort
• JXTA attempts give peers a common language to talk to each other

Platform independence
JXTA technology is designed to be independent of:
• programming languages e.g. C or Java
• system platforms e.g. Microsoft Windows and UNIX
• networking platforms (such as TCP/IP or Bluetooth)

Ubiquity
• implementable on every device with a digital heartbeat e.g. PDAs, phones,
sensors, consumer electronics appliances, network routers, desktop computers,
data-center servers, storage systems
• avoid specific binding to platforms (Wintel…)
• future proof e.g. such technologies should be extended to new platforms e.g.
mobile phones etc e.g. using JME, Google Android, Java BlackBerry, etc.
Section 4

JXTA - Implementations

JXTA Platform Current Implementations

• Java 2 Platform Standard Edition (J2SE)—the reference implementation

• Java 2 Platform Micro Edition (J2ME)—for MIDP-1.0 compliant devices such as
cell phones, PDAs, and controllers
• PersonalJava technology—for devices such as PDAs and webpads
• C/C++
• PERL
• Python
• Ruby
• Mon (C#)
• Arm-Linux & WinCE
• Smalltalk
JXTA Transport Current Implementations
• TCP
• HTTP
• BEEP
• Reliable Multicast
Section 4

Peer
JXTA Terms

Peer: A JXTA node.

Peer
Peer Peer

JXTA Group: a Peer

A Rendezvous group is a set of
Peer: a meeting JXTA nodes who Peer
Peer
share a common
place e.g. gateway
interest
for JXTA groups
Peer

Peer Peer

Peer Peer Peer Peer

Peer Peer
Section 4

JXTA Virtual Network

Project JXTA
Virtual Network
Peer Peer
Peer Peer
Peer

Peer Peer
Peer

Virtual Mapping
TCP/IP

Physical
Network
HTTP NAT
Firewall Physical Network
Section 4

JXTA Virtual Network

JXTA Virtual Network
PeerIDs are virtual
JVNet Network addresses
Pipe Connections
PeerID3 PeerID4
PeerID1 PeerID5
PeerID6
PeerID2 PeerID3

Tcp/Ip
Tcp/Ip

Tcp/Ip
http http
NAT Firewall

JXTA core Rendezvous-relay Real Network

Software inside
Section 4

JXTA Peer Architecture

Section 4

JXTA Peer Architecture

SUN
JXTA
JXTA Community Applications JXTA
Applications
Applications
JXTA
Shell
SUN • Indexing Peer
JXTA JXTA Community JXTA • Searching
Services Services Commands
Services • File Sharing

Peer Groups Peer Pipes Peer Monitoring

JXTA
Core
Security (authentication, authorization and on the wire)

Any Peer on the extended Web

Section 4

What is JXTA? – Classes & Network Protocols

6 protocols:

• Peer Discovery Protocol

• Peer Resolver Protocol
• Peer Information Protocol
• Pipe Binding Protocol
JXTA is a set of open, generalized P2P protocols that • Endpoint Routing Protocol
allow any connected device on the network to • Rendezvous Protocol
communicate and collaborate

JXTA is middleware – designed as a set of building

blocks to allow developers to rapidly develop P2P
applications

JXTA is designed to have a peer-to-peer, decentralized

model (although JXTA supports traditional
client/centralized server and brokered)

As in Gnutella, every JXTA peer can be both a client and

a server
Section 4

JXTA Overview

Project JXTA defines a set of six protocols , which allow peers to:

• Discover each other

• Self-organize into peer groups
• Advertise and discover network services
• Communicate with each other
• Monitor each other

…and the protocols do not require the use of any particular:

• programming language
• operating system
• network transport
• Topology
• authentication
• Security
• encryption model.

The JXTA protocols therefore allow heterogeneous devices with completely different
software stacks to interoperate.
Section 4

JXTA Architecture
Platform Layer (JXTA Core)
– minimal and essential primitives that are common to P2P networking.
– building blocks to enable key mechanisms for P2P applications,
• including discovery,
• transport (including firewall handling),
• the creation of peers and peer groups,
• and associated security primitives.

Services Layer
– network services that may not be absolutely necessary for a P2P network to operate, but are
common or desirable in the P2P environment.
– Examples of network services include:
• searching and indexing,
• directory,
• storage systems,
• file sharing,
• distributed file systems,
• resource aggregation and renting,
• protocol translation,
• authentication,
• and PKI (Public Key Infrastructure) services.

Applications Layer, implementation of integrated applications, such as:

– P2P instant messaging,
– document and resource sharing,
– entertainment content management and delivery,
– P2P Email systems,
– distributed auction systems, and many others.
Section 4

JXTA Components

• The JXTA network consists of a series of interconnected nodes, or peers

• Peers can self-organize into peer groups, which provide a common set of
services.

• Examples of services that could be provided by a peer group include:

– document sharing or
– chat applications.

• JXTA peers advertise their services in XML documents called

advertisements.
• Advertisements enable other peers on the network to learn how to connect
to, and interact with, a peer’s services.

• JXTA peers use pipes to send messages to one another. Pipes are an
asynchronous and unidirectional message transfer mechanism used for
service communication. Messages are simple XML documents whose
envelope contains:
– routing,
– digest,
– and credential information.

• Pipes are bound to specific endpoints, such as a TCP port and associated
IP address.
Section 4

JXTA Core Protocols

JXTA Core Protocols

• Membership
– Peer Membership
Protocol
• Discovery
– Peer Discovery Protocol
– Peer Resolver Protocol
• Pipe
– Pipe Binding Protocol
– Peer Endpoint Protocol
• Monitoring
– Peer Information
Protocol
Section 4

JXTA
Section 4

JXTA Terms & Concepts

Peer: any networked device that implements one or more of the JXTA protocols

Advertisements: XML structured document that names, describes, and

publishes the existence of a resource e.g. peer, peer group, pipe, or
service.

Messages: sent between peers can be XML or binary

Pipes: messages are send through virtual pipes – see next section …

Identifiers: each JXTA entity e.g. peer, advert etc has a UUID identifier

Rendezvous Nodes: a caching nodes for advertisements – similar to the super/

reflector nodes

Relay Nodes: JXTA routers – help to route messages via firewalls, NAT systems
etc – i.e. they relay the message on
Section 4

JXTA Peers

• A peer
– Unique identifier (UUID)
– Addressable independently of its location
(firewalls, NAT)
– Multiple Peer “endpoint” address (TCP, HTTP, etc.)
• Peer types
– Minimal edge : send/receive
– Full edge : + cache
– Rendezvous : + fwd requests
– Relay : +routing cache +firewall support
Section 4

JXTA Peer Groups

• Why Peer Groups?

– Provide a “group” identity (common interest)
– Create secure & protected domains
– Scope peer operations (discovery, search,
communications)
– Enable monitoring
NetPeerGroup
PeerGroupA
Peer Peer Peer
ID ID Peer
Peer ID ID
ID
Peer Peer
ID ID Peer
ID
PeerGroupB
Section 4
PeerGroup Advertisement:
JXTA Advertisements
<?xml version="1.0"?>
<!DOCTYPE jxta:PGA>
• Every resource is <jxta:PGA>
represented by an <GID>
urn:jxta: uuid-
advertisement BCBCDEABDBBBABEABBBABA000000
</GID>
– Peer <MSID>
urn:jxta:uuid-
– Peer group BFEFDEDFBABAFRUDBACE00000001
</MSID>
– Pipe <Name>
My Group
– Service </Name>
– Content <Desc>
This group is to be used for my own
– Peer status testing
</Desc>
</jxta:PGA>

Pipe Advertisement:

<?xml version="1.0"?>
<!DOCTYPE jxta:PipeAdvertisement>
<jxta:PipeAdvertisement xml:space="preserve" xmlns:jxta="http://jxta.org">
<Id>urn:jxta:uuid-
59616261646162614E5047205032503301E704BC6C144BB28016FDF28A4580EF0
4</Id>
<Type>JxtaPropagate</Type>
<Name>mypipe</Name>
</jxta:PipeAdvertisement>
Section 4
JXTA Pipes
Output Pipe Input Pipe
• Virtual Communication Channels
Peer A JXTA Pipe Peer • Switchable e.g. TCP/IP, HTTP,
1 2 Bluetooth
• NOT point to point
Actual Route

Peer Peer • Pipe endpoints -> input pipe (the

3 4 receiving end) and the output pipe (the
sending end).

• Asynchronous and unidirectional

Firewall
• Messages flow from the output pipe
Pee into the input pipes.
r
• Support the transfer of any object,
including binary code, data strings, and
Pee Pee Pee Pee Java technology-based objects
r r r r

• Two Types:
Pee • (End) Point to (End) Point
r • Propagate - multicast
Point to Point Propagate
Section 4

JXTA Pipes

Note that some peers sit behind a

firewall. HTTP proxy connections are
used to connect to a peer outside the
firewall (a TCP/IP Socks connection Pipes may send messages in different ways, each
could also have been used). Peer C of which may provide a different quality of service.
and Peer A can act as router peers Some examples of this include:
for peers behind firewalls. • Unidirectional, asynchronous: The pipe endpoint
sends a message, and no guarantee of delivery is
A pipe connection may involve made.
multiple peer endpoint transport • Synchronous request/response (RPC): The pipe
connections (multi-hops). The pipe endpoint sends a message and receives a
connection between Peer B and Peer correlated answer.
E involves an HTTP connection • Publish/subscribe: A pipe endpoint subscribes to
between Peer B and Peer C, an HTTP messages sent from a publisher endpoint.
connection between Peer C and Peer • Bulk data transfer: The pipe provides reliable data
D, and a TCP/IP connection between transfer of binary data.
Peer D and Peer E. On the other • Streaming: The pipe provides efficient data
hand, if a pipe connection is transfer over a flow-controlled channel.
established between Peer A and Peer
C, a single peer endpoint connection The default service provided by a JXTA pipe is
will implement the pipe, as Peer A unidirectional, asynchronous communication. All
and Peer C have a direct TCP/IP other pipe services can be implemented by the
connection. developer either directly on top of the peer
endpoints or over the default pipe abstraction.
Section 4

JXTA Pipes & Messages Payload tag:

<?xml version="1.0">
<ShellDoc>
<Item>
<Data>Hello, world!</Data>
</Item>
</ShellDoc>
 2

JXTA Scenario 1
3

1.
RV
2. 4

3.
New
4.
Node .
5
5. 7
.
6

1. Rendezvous node (RV) accepts connection for nodes 1-7 and stores
advertisements locally
2. New node contacts Rendezvous using a discovery mechanism e.g.
Unicast/multicast (PDP)
3. RV authenticates New Node and adds the New Node to the group (RVP)
4. New Nodes performs a file search query by contacting the RV find a match
locally or propagates this query to all other members in the group. The file is
found on node 6 (PDP)
5. New Node and node 6 communicate directly through a JXTA pipe. This
connection is virtual and may actually traverse (route) through the RV node
and node 7.
 JXTA Protocol Stack
Peer Discovery Peer Discovery
Via Peer Resolver Protocol
Protocol Protocol
Peer Information Peer Information
Via Peer Resolver Protocol
Protocol Protocol
Pipe Binding Pipe Binding
Via Peer Resolver Protocol
Protocol Protocol

Peer Resolver Via Enpoint Routing Protocol Peer Resolver

Protocol Protocol

Rendezvous Via Enpoint Routing Protocol Rendezvous

Protocol Protocol

Peer Endpoint Via installed Network Transports Peer Endpoint

Protocol Protocol

Network Transport Via Installed Network Transports Network Transport

 Peer Discovery

Peer Discovery
Protocol • A peer uses the PDP to discover a JXTA resource

Peer Information • resources are described by advertisements e.g. can be

Protocol services, pipes, peers, peer groups, or any other advertisements

Pipe Binding •Note, that the first word, peer, is the subject and not necessarily
Protocol the object

•Using this protocol, peers can advertise their own resources, and
discover the resources from other peers

• Peer resources are published using XML-based advertisements

Two levels of discovery:

1. Joining a JXTA network
1. Multicast
2. Unicast
2. discovering JXTA resource within a JXTA network.
Section 4

JXTA Protocols

Finding Information about Peers

• allows peers to learn about the capabilities and status of other

Peer Discovery peers e.g. uptime, traffic load, capabilities, state etc
Protocol
• e.g. one can send a ping message to see if a peer is alive.
Peer Information
Protocol • also query a peer’s properties where each property as a name
and a value string
Pipe Binding
Protocol •useful for implementing monitoring
 Binding Pipes

• allows a peer to establish a virtual communication channel (i.e. a

pipe) between peers
Peer Discovery
Protocol
• allows the binding of the two or more ends of the pipe endpoints
Peer Information forming the connection
Protocol
•a peer binds a pipe advertisement to a pipe endpoint thus
Pipe Binding indicating here messages actually go over the pipe
Protocol
• Bind occurs during the open operation, whereas unbind occurs
during the close operation.

Output Pipe Input Pipe

Peer A JXTA Pipe Peer

1 2

Actual Route

Peer Peer
3 4

Firewall
Section 4

JXTA Protocols
‘The’ Resolver

• enables a peer to implement high-level search

capabilities

Peer Resolver • allows a peer to send and receive generic

Protocol queries to find or search for peers, peer groups,
pipes, and other information
Rendezvous
Protocol

Peer Endpoint
Protocol
Section 4

JXTA Protocols

Rendezvous

• allows a Peer to send messages to all the listeners

of the service
Peer Resolver
Protocol •The rendezvous protocol defines how a peer can
subscribe or be a subscriber to a propagation
service allowing larger communities to form
Rendezvous
Protocol • A rendezvous nodes’ scope is a peer group

• e.g. the rendezvous protocol is used by the peer

resolver protocol and by the pipe binding protocol in
Peer Endpoint
order to propagate messages.
Protocol
Section 4

JXTA Protocols

Routing Those Messages

Peer Resolver
Protocol • allows a peer to find information about the
available routes for sending a message to
destination peer
Rendezvous
Protocol • i.e. pipes are often not directly connected to
each other

• allows the implementation of routing

Peer Endpoint
algorithms into JXTA
Protocol
• Peers implementing the endpoint routing
protocol respond to queries with available
route information giving a list of gateways
along the route.
Section 4

JXTA Core Services

• Discovery Service
• PeerInfo Service
• Pipe Service
• Resolver Service

• Membership Service
• Access Service
Section 4
JXTA SHELL & MyJXTA DEMO
Section 4
JXTA SHELL & MyJXTA DEMO
Section 4

JXTA Summary

• Features
– This system uses the pure P2P architecture rather than
else. It enables us to share information and
communicate with others, regardless of network
configuration and hierarchy. Finally, it helps us to
collaborate on the Internet.
• Potential applications
– E-education
– Tele-presentation/Conferences on the Internet
– Virtual meeting on the Internet
– Flexible information sharing
– Co-navigation on the Internet, Web Radio/TV, IP TV,
RTP/SIP Streaming and VoIP/VioIP Services
Section 4

JXTA Sample Applications

• Basic group management

• Shared browser
• Group chat
• One-to-one chat
• Pipe across firewalls & NAT via HTTP
Section 4

JXTA Sample Applications

• Short term
– Sharing files (text, image, pdf, mp3) – see MyJXTA
– Improving communication reliability
– Enhancing group management
– Effective memory usage
– Free drawing pad
• Long term
– Voice/video communication based on Java & JMF
– Record additional drawing on text & image file
– Network security
Section 4

Activities in JXTA Core

• Di Distributed Indexing [Note]

• Jxme JXTA for J2ME (CLDC / MIDP )
• jxta-c C language binding for JXTA core
• Jxtaperl A Perl 5 binding.
• Jxtapy JXTA Python binding
• Jxtaruby Ruby implementation
• objc-jxta An objective-c binding
• Platform JXTA platform Java 2 SE
• Pocketjxta Porting the PocketPC
• Security JXTA P2P Security Project [Note]
• Tini TINI binding for JXTA platform
Section 4

Activities in JXTA Services

• caservice Peer service that can validate certificate chains

• cms JXTA Content Management System
• compute-power-market Economics driven P2P Computing Platform and
marketplace!
• edutella RDF-based Metadata Infrastructure for P2P Applications
• gisp Global Information Sharing Protocol [Note]
• ipeers Artifical Intelligence in P2P networks [Note]
• jxrtl XML language allowing Active Networks to be implemented in JXTA
• jxta-rmi RMI API on top of JXTA
• jxta-wire Provide a set of tools to allow many to many JXTA pipes
• jxta-xml-rpc JXTA transport binding implementation for XML-RPC
• jxtaspaces A Distributed Shared Memory Service for JXTA [Note]
• jxtavfs JxtaVFS organizes JXTA network resources as virtual file system. [Note]
• monitoring Monitoring and Metering
• networkservices Integrate Web Services Concepts into JXTA
• p2p-email P2P email group discussions using JXTA Peergroup technology
• payment Implement anonymous and secure financial transactions
• replication Replication/synch engine [Note]
• rrs Service for local and remote administration of rendezvous peers
• rvmanager RendezVous Manager
• search Distributed search service for JXTA and Web content and services [Note]
Section 4

Activities in JXTA Apps

• allhands Event Notification application

• brando Brando P2P Java source code sharing tool
• configurator A GUI configuration tool for the JXTA platform
• dfwbase P2P network with a database at each peer - A knowledge
base
• gnougat Gnougat: Fully decentralised file caching
• halu JXTA media distribution application
• instantp2p JXTA Demonstration GUI
• jnushare A set of application of GISP (fileshare, messageboard)
• juxtaprose a web / discussion content sharing application
• jxauction Develop a auction software using jxta
• myjxta myJXTA - JXTA Demonstration Application (aka InstantP2P)
• parlor App framework for creating collaborative P2P spaces
• radiojxta delivering audio content over JXTA networks
• rosettachat Localized JXTA Peer Text Messaging
• shareddiary Shared Diary for a Small workgroup
• shell JXTA Command Line Shell for interactive access
• vop2p voice over P2P network
Questions & Conclusions

Contact:

Cristian Valeriu TOMA

E-mail: [email protected]

E-mail for all the problems

regarding ISM – IT&C Security
Master:
[email protected]
[email protected]