Arcademis a framework for middleware development
Download
1 / 38

Arcademis: a Framework for Middleware Development - PowerPoint PPT Presentation


  • 163 Views
  • Uploaded on

Arcademis: a Framework for Middleware Development. Fernando Magno Quintão Pereira 1 Marco Túlio de Oliveira Valente 2 Roberto da Silva Bigonha 1 Mariza Andrade da Silva Bigonha 1. 1 – Universidade Federal de Minas Gerais 2 – Pontíficia Universidade Católica de Minas Gerais.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Arcademis: a Framework for Middleware Development' - solstice


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Arcademis a framework for middleware development

Arcademis: a Framework forMiddleware Development

Fernando Magno Quintão Pereira1

Marco Túlio de Oliveira Valente2

Roberto da Silva Bigonha1

Mariza Andrade da Silva Bigonha1

1 – Universidade Federal de Minas Gerais

2 – Pontíficia Universidade Católica de Minas Gerais


Middleware systems
Middleware Systems

  • In the last ten years, developers of distributed systems have often relied on middleware platforms to increase their productivity.

  • A middleware system is a software layer that resides between the operating system and the distributed application layer.

  • Middleware systems hide from application developers details inherent to distributed programming: communication primitives, data marshaling and unmarshaling, failure handling, service lookup and synchronization.

  • Examples of middleware systems: CORBA, Java RMI, COM/DCOM, Lime, MPI.


Frameworks
Frameworks

  • Arcademis is a Java-based framework for middleware development. It consists of a set of classes and interfaces that define the architecture of object-oriented middleware systems.

  • A framework is a technique of reuse. It allows to reuse code and project.

  • A framework is constituted by a set of components, concrete and abstract, that collaborate to describe the skeleton of an application[jonhson97].

  • A framework is different from a library.


Motivations
Motivations

  • The generality of traditional middleware platforms compromises their flexibility.

    • General platforms are often complex systems, whose use demands a lot of computational resources.

  • Traditional middleware systems are monolithic:

    • CORBA implementations, such as ORBIX ou VisiBroker occupy several megabytes of memory; Therefore, they cannot be used in resource constrained devices.

  • Traditional middleware systems present few customization options.

    • Ex.: remote method invocation semantics in Java RMI.


Objectives of the arcademis project
Objectives of the Arcademis Project

  • To allow the development of non-monolithic and easily configurable middleware systems.

    • “What you need is what you get”.

  • To describe the architecture of object-oriented middleware systems.

  • To outline configurable aspects of object-oriented middleware systems.

  • To develop a remote invocation service for the CLDC configuration of Java 2 Micro Edition.


Object oriented middleware
Object-Oriented Middleware

  • Provides to the application developer the illusion that remote objects are locally available.

  • Communication between objects is based on remote method invocation.

Client

Object

Remote

Object

Distributed Application

Layer

Middleware Layer

Stub

Skeleton

Client Address Space

Server Address Space


A component based architecture

Request

Receiver

Request

Sender

Response

Sender

Response

Receiver

A Component-Based Architecture

Client

Application

Lookup

Service

Remote

Object

Distributed Application Layer

Middleware Layer

Remote

Object

Representation

Stub

Activator

Skeleton

Scheduler

Middleware

Protocol

Serialization

Protocol

Chain of

Dispatchers

Chain of

Invokers

Transport

Protocol

Connector

Acceptor


Configuration parameters
Configuration Parameters

  • Arcademis specifies 11 configurable aspects of object-oriented middleware platforms.

    1 – Transport protocol.

    2 – Connection set up.

    3 – Middleware protocol.

    4 – Serialization policy.

    5 – Reliability level of remote

    operations.

    6 – Remote object

    representation.

  • 7 – Service lookup.

  • 8 – Remote object activation.

  • 9 – Invocation policy.

  • 10 – Dispatching policy.

  • 11 – Priority policy.


1 th parameter transport protocol

Channel

<< interface >>

ConnectionServer

Epid epid

+connect(Epid epid):void

+send(byte[] a): void

+recv(): byte[]

+close(): void

+getLocalEpid(): Epid

+setTimeout(int t): void

+getTimeout(): int

+ConnectionServer(Epid epid)

+abstract accept():void

+abstract getChannel():Channel

+abstract setTimeout(int t):void

+abstract getTimeout():int

1th Parameter – Transport Protocol

  • There are several different implementations of transport protocols: TCP, UDP, HTTP, etc.

  • Arcademis defines the transport protocol by means of two components:

    • the Channelinterface;

    • the ConnectionServer abstract class;


Channel decorators
Channel Decorators

  • Decorator : a design pattern that allows the aggregation of extra functions to a component by means of interceptor objects [Gamma 94].

Channel

<<interface>>

ChannelDecorator

<< decorator >>

TcpChannel

<<arcademis.concrete>>

ZipChannel

<< decorator >>

BufferedChannel

<< decorator >>


2 nd parameter connection set up
2nd parameter – Connection Set Up

  • In Arcademis, connections are established by means of the acceptor-connector design pattern firstly proposed for the TAO platform [Schmidt 94].

  • This pattern distinguishes the elements responsible for the connection establishment (AcceptorandConnector) from the elements in charge of the channel use (ServiceHandler’s).

  • Configuration options:

    • synchronous or asynchronous connection set up;

    • channel reuse or creation of a new channel per connection;

    • reception of connections by a dedicated thread or by the thread of the current application.


The acceptor connector design pattern
The Acceptor-ConnectorDesign Pattern

ConnectionServer

+accept():

+getChannel():Ch

Acceptor +accept():

Connector

+connect(epid):

<<creates>>

<<creates>>

Channel

+send(byte[]): +recv():byte[]

+connect(Epid):

<<creates>>

<<creates>>

<<uses>>

<<uses>>

ServiceHandler

+open(channel):

XxxxxHandler

YyyyyHandler


3 rd parameter serialization policy
3rd Parameter – Serialization Policy

  • In order to send an object across the network it is necessary to transform it into a byte sequence (marshaling), so its contents can be recovered later (unmarshaling). This process is called serialization.

  • According to the Arcademis specification, data serialization is responsibility of the application developer.

    • Marshalable objects must implement the Marshalable interface, which defines the marshal and unmarshal methods.

  • The serialization protocol is defined by an implementation of the arcademis.Stream interface.


Example of marshable object
Example of Marshable Object

import arcademis.*;

public class Example

implements Marshalable {

int argument = 0;

public Example (int argument) {

this.argument = argument;

}

public void marshal(Stream b) {

b.write(argument);

}

public void unmarshal(Stream b) {

this.argument = b.readInt();

}

}

<<interface>>

Marshalable

(from arcademis)

+marshal(Stream b);

+unmarshal(Stream b);

<<interface>>

Stream

(from arcademis)

+write(byte b):

+write(char c):

...

+write(Object o):

+readByte():byte

+readChar():char

...

+readObject():Object


4 th parameter reliability level of remote operations
4th parameter – Reliability Level of Remote Operations

  • Determines the level of reliability provided by the implementation of remote calls.

  • Different implementations can provide the same semantics with different levels of reliability.

  • Example:

    • one-way: the client sends the call to the server and does not wait for any result;

    • best-effort: the client attempts to contact the server once. In the case of errors, a new attempt is not performed;

    • at-most-once: the client performs a number of invocations. Each of them is marked with an identifier, so that the same operation is not executed more than once;

    • at-least-once: the client performs successive remote invocations until a valid result is obtained;


The request response solution
The Request-Response Solution

  • The communication between stubs and skeletons is intermediated by four components: request-sender, request-receiver, response-senderandresponse-receiver.

  • Different implementations of these components determine different reliability levels of remote invocations.

Client

Object

Remote

Object

Request

Sender

Request

Receiver

Skeleton

Stub

Response

Receiver

Response

Sender

Host S

Host T


5 th parameter the middleware communication protocol
5th parameter – The Middleware Communication Protocol

  • The middleware protocol is defined by a set of messages and by a state machine that defines the order in which messages are transmitted.

  • Messages are implementations of the Message interface from Arcademis, and are marshalable objects: arcademis.Message extends Marshalable.

  • The implementation of the marshal and unmarshal operations defines the message contents.

  • Messages are defined according to the Command design pattern [Gamma94]; therefore, the message implementation defines the actions to be executed after it is received.


6 th parameter remote object representation

RemoteReference

RemoteObject

<<abstract>>

+RemoteReference(Epid,Id):

+equals(Object):boolean

+toString():String

+hashCode():int

+getEpid():Epid

+getId():Identifier

+activate():

+deactivate():

+getRef():RemoteReference

+getStub():Stub

+getSkeleton():Skeleton

+equals(Object):boolean

+toString():String

+hashCode():int

6th Parameter - Remote Object Representation

Marshalable

<<Interface>>

Epid

<<Interface>>

Identifier

<<Interface>>


7 th parameter service lookup
7th Parameter – Service Lookup

  • Arcademis is a service oriented architecture [Champion02]:

    • service provider (remote objects);

    • service requesters (clients);

    • discovery agencies (lookup service).

Lookup

service

Service

identifier

publish()

find()

Service

Requester

Service

Provider


8 th parameter invocation policy

Invoker

<<interface>>

Stub

RequestSender

+invoke(RemoteCall,

RemoteReference):Stream

8th Parameter – Invocation Policy

  • Stubs use instances of arcademis.Invoker to issue remote calls.

  • Clients can specify non-functional characteristics of remote invocations: log generation, use of caches and buffers, timing, etc.

InvokerDecorator

+invoke(RemoteCall,

RemoteReference):Stream


Invoker decorators
Invoker Decorators

  • In order to add further functionalities to invokers, Arcademis allows the use of invoker decorators. Examples of decorators include:

    • caches: record the result of remote calls that do not cause side effects, do not throw exceptions and always return the same valued when given the same parameters;

    • buffers: group several messages in the same package aiming to improve network utilization;

    • timers: after a certain period of time, if the invoker does not received the call’s result, the operation can be aborted;

    • load balancing: when the stub has access to more than one service provider, the invoker can distribute remote calls among the available servers;

    • log generators;


9 th parameter dispatching policy
9th Parameter – Dispatching Policy

  • The server architecture is defined by the implementation of the arcademis.Dispatcher component.

  • Dispatcher decorators allow to aggregate extra functionalities to dispatchers:

    • log generation;

    • report of server load rate to clients;

    • redirection of calls to other servers;

    • creation of threads to process specific calls;

    • Implementation of security policies.


Example of server architecture
Example of Server Architecture

DispatcherDecorator

RequestReceiver

Dispatcher

Scheduler

Skeleton

ResponseSender

RemoteObject


10 th parameter priority policy
10th Parameter – Priority Policy

  • Arcademis allows the assignment of different priorities to remote methods.

  • Remote calls are scheduled by the arcademis.server.Scheduler component.

  • Different priority policies can be adopted:

    • first in, first out;

    • the priority of each method is defined by the stub implementation;

    • service providers assign clients different priorities;


11 th parameter remote object activation
11th Parameter – Remote Object Activation

  • A remote object needs to be activated before being able to receive remote invocations.

  • What happens during the remote object activation:

    • instantiation and initialization of skeleton, dispatcher, scheduler and acceptor;

    • creation of threads to handle incoming remote calls;

    • bind of the remote object to a network address;

    • creation of a unique identifier to the remote object.

  • The remote object activation policy is implemented by the arcademis.server.Activator component.


Remote object activation
Remote Object Activation

(from arcademis.server)

Active

<<Interface>>

+activate():

+deactivate():

from arcademis.server)

RemoteObject

<<abstract>>

from arcademis.server)

Activator

<<abstract>>

+getRef():RemoteReference

+getStub():Stub

+getSkeleton():Skeleton

+equals(Object):boolean

+toString():String

+hashCode():int


The orb class
The ORB Class

  • The Arcademis components are instantiated according to the abstract factorydesign pattern [Gamma 94].

    • Make it easier to configure instances of Arcademis.

  • Every factory is associated to a singleton component: the ORB (arcademis.ORB).

  • To configure an instance of Arcademis means to determine the implementation of the factories bound to the ORB.

  • The ORB functions can be accessed by means of a façade (arcademis.OrbAccessor).


The orb class1
The ORB Class

Distributed Applications

ORB

16 factories

Invoker

factory

Dispatcher

factory

Channel

factory

Activator

factory

Connector

factory

Message

Factory

Epid

factory

Notifier

factory

Acceptor

factory

Stream

factory

Scheduler

factory

Identifier

factory

Buffer

factory

ServiceHandler

factory

Protocol

factory

ConnectionServer

factory

Operating System


Case study rme remote method invocation for java 2 micro edition
Case Study – RME – Remote Method Invocation for Java 2 Micro Edition

  • RME is a middleware platform derived from Arcademis that targets the CLDC (Connected Limited Device Configuration) configuration of J2ME.

  • Java RMI cannot be deployed in the CLDC configuration because this environment does not support J2SE computational reflection and, consequently, object serialization.

  • RME provides the same programming syntax than Java RMI.


Some of rme characteristics
Some of RME Characteristics Micro Edition

  • RME uses 13 of the 16 factories of Arcademis.

  • Transport protocol: TCP/IP.

  • Synchronous connection set up, with channel reuse.

  • Middleware Protocol: seven different types of messages.

  • Reliability of remote calls: best-effort or at-most-once.

  • Name service: the same interface as in Java RMI.

  • Dispatcher sends remote calls directly to the skeleton.

  • Priority policy: first-in, first-out.


Contributions of the arcademis project
Contributions Micro Edition of the Arcademis Project

  • Methodological contributions:

    • description of the architecture of object-oriented middleware;

    • enumeration of several configuration parameters of middleware systems;

    • descriptions of new solutions for middleware implementation. Ex.: request-response.

  • Practical contributions:

    • Arcademis implementation;

    • RME implementation.


Final remarks
Final Remarks Micro Edition

  • Flexible system.

    • Arcademis could be used in an environment where Java RMI could not.

    • Project based on design patterns: abstract factory, singleton, acceptor-connector, etc.

    • Abstract factories facilitate middleware configuration.

    • Tests show that Arcademis’ flexibility does not substantially compromise its overall performance.

  • Arcademis does not provides dynamic reconfiguration, although some of its components can be changed during execution time. Ex.: invoker decorators in RME.


Download
Download Micro Edition

http://www.dcc.ufmg.br/llp/arcademis/


Application example phone book
Application Example: Phone Book Micro Edition

import rme.*; import arcademis.*;

public interface PhoneCatalogue extends Remote {

public PhoneAddress getPhoneAddress(String name)

throws ArcademisException;

}

import java.io.*; import java.util.*;

public class PhoneBook extends rme.server.RmeRemoteObject

implements PhoneCatalogue

{

Hashtable h = null;

public PhoneAddress getPhoneAddress(String name) {

return (PhoneAddress)h.get(name);

}

private void insert(String name, String number, String address)

{ ... }

}


Phoneaddress implementation
PhoneAddress Micro EditionImplementation

import arcademis.*;

public class PhoneAddress implements Marshalable {

private String name, phoneNumber, address;

public PhoneAddress(String n, String p, String a){

name = n; phoneNumber = p; address = a;

}

public void marshal(Stream b) {

b.write(phoneNumber);

b.write(name);

b.write(address);

}

public void unmarshal(Stream b) {

this.phoneNumber = (String)b.readObject();

this.name = (String)b.readObject();

this.address = (String)b.readObject();

}

// other method’s implementations: get’s and set’s

}


Server application
Server Application Micro Edition

public class Server {

public static void main(String args[]) {

try {

rme.RmeConfigurator c = new rme.RmeConfigurator();

c.configure();

PhoneBook o = new PhoneBook();

rme.naming.RmeNaming.bind("obj", o);

o.activate();

o.readFile(args[0]); // fills the phone book

}

catch (arcademis.ArcademisException e){}

catch (arcademis.concreteComponents.MalformedURLException e){}

catch (rme.naming.AlreadyBoundException e){}

catch (java.io.IOException e){}

}

}


Client application j2se
Client Application (J2SE) Micro Edition

import arcademis.*;

import rme.*;

public class Client {

public static void main(String a[]) {

try {

RmeConfigurator c = new RmeConfigurator();

c.configure();

PhoneCatalogue phoneBook = (PhoneCatalogue)

RmeNaming.lookup("algol.dcc.ufmg.br/obj");

PhoneAddress a =

phoneBook.getPhoneAddress(“Machado de Assis”);

System.out.println(a.toString());

} catch (Exception e) {}

}

}


Orb configuration
ORB Configuration Micro Edition

package rme;

import rme.server.*; import arcademis.*;

public final class RmeConfigurator implements Configurator {

public void configure() throws ReconfigurationException {

if(ORB.isOpenForReconfiguration()) {

// Define the channel factory

ChannelFc cnFc = new RmeChannelFc();

ORB.setChannelFactory(cnFc);

// Define the connection server factory

ConnectionServerFc csFc = new RmeConServerFc();

ORB.setConnectionServerFactory(csFc);

// Define the other 7 factories ...

// close the ORB for furter reconfigurations

ORB.closeForReconfiguration();

}

else throw new ReconfigurationException();

}

}