Middleware Technologies
Franco Zambonelli
January 2004
Universit di Modena e Reggio Emilia
Outline
{
Why Middleware?
z
Problems of open and situated distributed
computing systems
What is Middleware?
z
z
Basic features
Middleware Models
{
{
{
Interaction models
Services to be provided
Implementation models
Overview of Technologies
z
z
z
J2EE
CORBA
.NET
Modern Distributed Systems
{
{
Modern distributed systems (as well as non-distributed ones), need
to be adaptive, that is
Open
z
z
z
New components join the systems, while others may leave
We cannot re-configure and re-design the system any time it changes
(economically and practically unfeasible)
We cannot rely on a priori information about each and every component
that will be part of the system (impossible, new specification may be
known only a posteriori)
In addition, components may be heterogeneous (developed with different
technologies or for different platforms)
Situated and Context-aware
z
z
z
Components of a system may be deployed in partially unknown
environment (computational of physical)
Some info about the actual environment must be dynamically retrieved at
deployment time or at run-time (cannot be a priori coded)
The environment can have its own dynamics, and it is necessary for the
components of a system, and for the system itself, to dynamically adapt to
such dynamics
An Example: a Problem
{
Consider a distributed application
z
z
Made up of a set of components on different
computers
That interact with each via TCP Sockets
Socket s = new Socket(155.185.3.2, 143)
s.write(print me this line please!)
// I must know a priori that such a print server exist
// at a specific IP and at a specific port!!!
// I can do nothing if at some time a better printer
// gets installed in the network
JFrame jf = new JFrame(Hello);
Jf = setBounds(0,0,360,140);
Jf.show();
// I must a priori know that the user display supports such
// a dimension of the frame. But what if the users wants
// to run its application on a 120*120 Nokia phone display?
4
and a Possible Solution
{
Suppose we have a Dr.Know able to discover on
demand:
z
z
Which printer services are available
The characteristics of the PC
Then, Dr.Know would be a middleware
Vector printers = DrKnow.Discover(print_services)
// returns a Vector with all the printers currently
available
For (int i=0; i<Vector.length; i++)
printers[i].getSpeed();
//select fastest printer available and print
s.write(print me this line please!)
Display disp = DrKnow.getContext(Display);
Jf = setBounds(0,0,disp.x,disp.y);
// size according to the dimension of the current display
5
What does Middleware?
{
Enabling Interactions
z
z
z
Supporting Interactions
z
z
z
z
Acting as the uniform glue that collate components in the systems
Facilitate components interactions (e.g., supporting naming and
dynamic discovery of services)
Dealing with heterogeneous components (e.g., components and
services developed using different technologies)
Provide solutions for common problems of interactions (e.g.
inconsistencies and synchronization in accessing shared resources,
persistence)
Provide support for openness (new components getting in the system)
Provide support for problems (fault recovery, replication)
Provide support for system manager (monitoring, and logging)
Promoting Context-Awareness
z
Have components be aware of whats happening (e.g., a new
component has connected, a component changed its state, the room
temperature has changed)
Virtualization of environmental resources into digital resources (e.g., a
thermostat as a software object)
6
Where is Middleware?
{
Middleware act as an middle layer between the osware and the application software
z
z
Applications uses the services of the middleware
The middleware uses the services of the network layer of the
operating system (and of the operating system in general)
To some extent, middleware can be considered as a sort
of
z
z
operating system for distributed systems instead of
operating system for a computer
DNS as a Basic Middleware Service
{
DNS decouples actual IP from symbolic name
z
z
z
z
Enables dynamicity of IP
Enables interactions to be based on names of
resources rather than on IPs
Sometimes, this enables an automatic forwarding to
the best resource
E.g., replicated web services with policies for IP
selection (Google)
But this is definitely not enough
In general, the current Internet and Web
architecture
The names must be known and are fixed
does not provide middleware services, but only
basic mechanisms to enable interactions
Socket s = new Socket(www.printersite.com, 1234);
s.writeln(write this line);
Operating Systems vs. Middleware
{
Operating Systems
z
Provide high-level
abstractions for the
resources of a
computer
Facilitate and
orchestrate access to
resources
Application Software
Operating System
Hardware
Middleware
z
Provide high-level
abstractions for the
resources of a network
Facilitate and
orchestrate access to
distributed resources
Distributed Applications
Middleware
Network of Computers
9
Middleware for Local Services
{
Specific types of software infrastructures
also act as local middleware
z
z
z
An additional layer above the operating
system
To complement it with additional special
purpose service
To add support for openness and
orchestration of local programs
Examples
z
z
z
TomCat and the Servlet Context
Java
Typically as components of a larger
middleware environment (e.g., Java
J2EE)
Application Software
Local Middleware
Services
Operating System
Hardware
10
TomCat as a Middleware for Service
Composition
{
{
TomCat (i.e., J2EE) provides several services that
can be considered as local middleware services
Servlet Context
z
z
Servlet Sessions
z
z
A sort of shared dataspace to enable Web services
to share data and contextual information
A local naming and discovery service, to enable
services to share Java objects (attributes)
A sort of additional contextual information
Enable services to keep track of history, and to
adapt their execution depending on such history
All of this make the Web server adaptive
z
z
New services can be deployed and adapt their
execution to the context
Services can adapt their behavior depending on
history
11
JAVA as a Middleware
{
{
The JAVA environment, per se, can be considered as a
sort of middleware
In fact, it provides a number of additional services over
the operating system
z
z
z
z
z
Supporting dynamic class loading: new classes can enter a
Java program dynamically (openness)
Take care of finding classes autonomously in the file system
Provide a service for freeing memory (garbage collection)
Provide support for heterogeneity: its applications can
execute on any type of computer, thanks to the JVM
Provide support for event and exception handling: a
primitive form of context-awareness (system level and user
level events can be caught)
But Java in its Enterprise Edition is also a truly
middleware for distributed systems
12
Middleware Models
{
RPC and Object-based
z
z
Event-based
z
z
Rooted on shared memory models
Support sorts of stigmergic interactions between components
Most middleware technologies, handles both objects, shared
memories, and events
z
Rooted on interactive computing models
Support a reactive context-aware model
Shared Dataspaces
z
Rooted in the Remote Procedure Call paradigm
Support distributed object applications (e.g., remote method
invocations)
And provides different services for the different types of models
These model, more than interaction models are best known as
coordination models in that they provide
z
z
z
Communication between components
Synchronization of activity between components
In general, orchestration (i.e., coordination) of activities between
components
13
RPC and Object-based Middleware
{
Support
z
z
Basic services to be provided
z
z
Application based on Distributed objects
That invoke each other methods as if they were
local objects
RPC (remote procedure call) or remote method
invocation (RMI)
Publication and Discovery of Objects and Their
Services
Additional services
z
z
z
attribute-based discovery
Heterogeneous Interactions
Transactions, Recovery, Load Balancing, Replication
14
Remote Method Invocation
{
A Service that enable an object to invoke the
services of another non-local object as if it were
local
z
The object that must be invoked remotely must
{
be compiled with special tools provided by the
middleware (e.g., the rmic compiler in Java RMI)
to generate a stub that receive remote method
invocations and transforms them into local ones
The invoking object must receive a special reference
to the objects, that act as proxy copy, and that will
provide to forward invocations to the remote stub
O1
O2
(invoker)
(invoked)
O2 Stub
O2 Proxy
Network
15
Naming and Discovery
{
A special Naming service component (e.g., the
RMIregistry in Java) of the middleware takes care
of connecting the invoker and the invoked
{
{
{
The invoked must communicate its public interface
to the Naming Service and must make known itself
via a public name (binding of name)
The Naming service act as a Yellow Pages service
The invoker asks a reference to an object with a
specific name to the Naming service, which will
provide a proxy to it in return (this operation is
called discovery or lookup)
O1
2) lookup
(invoker)
O2 Proxy
3) proxy
provided
Naming
Service
1) binding
O2
(invoked)
O2 Stub
16
Attribute-based discovery
{
The classical Naming service (as in RMI)
z
z
z
Solution: attributed-based discovery
z
z
z
(printer, laser, *, *) I need a laser printer, no matter if it is color or
slow
(train, timetable, *) I need a service for train timetables
And it obtains in return proxies to all services matching the requested
attributed
z
z
z
An object does not bind itself to a simple name, but to a set of attributes, and
publish these attributes on the Naming service
(printer, laser, color, 8ppm)
(trains, timetable, Italy)
When another object needs specific services, it can ask to the Naming
services for objects with attributes of interest
z
Enables two objects, previously-unknown to each other, to interact
BUT there must be a priori agreement on the name
So, it is not very adaptive
This clearly makes the system more adaptive to dynamic changes and more
suitable to open systems
There is little to know in advance, most information can be obtained on-the-fly
It requires the naming service to do the pattern matching work
Implemented in the so called JINI middleware (now part of J2EE), to
support more dynamic plug&play distributed object applications
17
Heterogeneous Interactions
{
The stub and the proxy
Therefore, one can think at the two objects being different in terms of
Provided that
z
z
z
z
{
{
Decouple the invoker from the invoking objects
They interact with the mediation of these components, provided by the middleware
Programming language, Technologies, Type systems, Interface specification
There is a common interface language to publish interfaces on Naming service
The stub and the skeletons to the necessary translation work
Any two heterogeneous object can interact
The pioneer system in this area is CORBA (IDL, Interface description
language). Now, there are standard way of publishing interfaces and systems
descriptions
z
z
Exploiting XML and according to the SOAP standard
Implemented by most middleware systems
O1 Java
(invoker)
O2 Proxy
2) Lookup
Via common
Language
Interface
Naming
Service
1)
Binding
of common language
interface
O2 C++
(invoked)
O2 Stub
Network
18
Other Services
Transactions
The middleware can make critical operations be part of a transaction, All-or-nothing
semantics
{
{
A set of operation (method invocations) are executed as an atomic unit
If one operation fails the system roll back i.e., recovery to its previous state
E.g., transferring money from a bank to another
Synchronization
z
z
Critical operations/methods on an object or on a set of objects should be performed without
having other objects act concurrently
The middleware can provide at maing specific actions mutually exclusive, this synchronizing
the accesses to shared resources/object
Load Balancing
z
z
Among a set of equivalent services/objects, the middleware can take care of automatically
providing a proxy to the less loaded one
Many popular Web sites (e.g., google) exploit a middleware doing this, to distributed request
among several machines
Replication & Caching
Several intensively accessed services/objects can be automatically replicated by the
middleware in several locations, so as to Improve overall performances and tolerate local
failures
The Web, actually has a caching system
Quality of Service
Ensure that operations are served within a specific time, i.e., with a guaranteed quality
All these additional services may clearly also be present (in sligthly different forms
adapted to the model) for event-based and shared dataspace middleware systems
19
Event-based Models
{
Interactions are based on the key concept of events
Publish-Subscribe Model
z
z
z
z
z
Some that happened
Generated event can be published, i.e., made known to the
audience
Interested components can susbscribe (i.e., declare interest) to
specific types/classes of event
A susbscriber gets notified of relevant published events
And react to it by executing a proper event handling method
Various types of events can be conceived
z
z
z
z
z
System level events (new hardware, clock, system error, etc.)
OS Level events (i.e., file open, file unlocked, device ready, etc.)
Network level events (new node connected, node disconnected,
transmission error)
Application level events (new object created, new message arrived,
data changed, etc.)
User level events (i.e., interactions with the program)
20
10
Publish-Subscribe Interactions
{
A functionality of the middleware to subscribe to events
z
z
A functionality of the middleware to generate events
z
Tells the middleware what events a component is interest in
Associate a reaction function/method to events (event
handler)
Application level components can decide how and what
events to generate
Upon generation of an event
z
z
z
The middleware catch the event
It delivers (notifies) the event to the subscriber
The subscriber react accordingly
1)
Subscribe
To Event A
O1
Event
Dispatcher
2) Publish
Event A
O2
3) Notify
To Event A
4) React
Network
21
Models of Subscriptions
{
By Name
z
z
z
By Type
z
z
z
z
Events can be Typed (i.e., belong to a specific class, as in Java)
Subscriber declare interest in specific types (e.g., as in Java GUI, ActionEvents
or DocumentEvents)
Has the problem that either the types are many or a subscriber receives too
many notifications in which it may not be interested
But if the types are too many, this resembles a naming scheme
By Attribute
z
z
z
Events are published with a name
Subscribers declare interest in specific names
Has the same problems of Naming in RMI (not dynamic, not adaptive)
As in attributed-based naming of services
Enables adaptive subscription with little a priori knowledge
Clearly requires the Event Dispatcher to analyze events and subscription and
make the publish-subscribe work
Events with a Content
z
z
Event can also contain things, i.e., additional descriptions, data, attachments
So, they can be used to pass data from one component to another, as a
message
22
11
Models of Notification
{
Synchronous
z
As soon as an event arrives, the event dispatcher
{
{
{
Asynchronous
z
When an event arrives, the event dispatcher
{
{
{
{
Check the matching subscriptions
Notify the interested components
Stores the event (possibly with a lease time)
Future subscribers can be notified of past events too
From the subscribed viewpoint
z
z
Check the matching subscriptions
Notify the interested components
Forget the event
The subscriber can decide to react immediately to an event
Or it can delay event handling to any later appropriate moment
In most systems
z
z
The subscribers can specify on which events of the past (how far in the past)
they are interested
Events can specify a time-to-live (lease time)
23
Space and Time Decoupling
{
{
{
Event-based models have a very important characteristics to promote
adaptivity (other than providing context-awareness)
When considering the asynchronous notification mode
Space decoupling:
z
z
Time decoupling:
z
z
z
z
z
z
The components do not need to coexist in space (they can be temporarily
on different networks)
The components do not need to share a common name space (if based on
attributed matching)
The components do not need to coexist in time
An event can be generated at time T
The generator can die or go away
The subscriber can arrive/born at time T+T1
Subscribe to the event
And be notified about the past event
On the other hand, in the synchronous mode
z
Event-based interaction can be used to synchronize activities
24
12
Event-based Models vs. RMI
{
Advantages of Event-based Models
z
Context-awareness
Decoupling
{
{
Since event can have a content
And can solicit the execution of a method
Event-based models can mimic RMI ones
Advantages of RMI Models
z
Remote method invocation require the invoking and the invoker to
coexist in space (i.e., in the same network) and time (i.e., must be on
execution simultaneously)
Event-based models enable space and time decoupling, better suited to
a dynamic world
Message-passing
{
Components can be easily made aware of what is happening in the
system
Well-known and used interaction models
Get the best of the two
z
z
Enable RMI interactions and at the same time make components be
able to handle/generate events
Also to discover the arrival/dismissing of objects and services
25
Shared Dataspace Models
{
Components interacts via a sort of shared
memory
z
z
Where they can put data
Where they can get data (extracting or simply
reading it)
Provided by a component acting as a shared
dataspace service
Read A
Shared
DataSpace
O1
Put A
O2
Network
26
13
Data Models
{
Simple variables
z
z
The same as normal programs access the RAM memory
Put(v); Get(v);
Tuples (or Records), i.e., ordered set of typed fields
z
z
(int 5, float 3.14, String Hello);
Put(Tuple); Read(Tuple);
Object
Structured Files
z
z
z
z
XML, RDF, etc.
In that case, accessing the shared memory may implies accessing
portions of the files, or modifying (e.g., via XSL) already stored files
Remember the Servlet Context and the WEB-INF.xml file?
Any File
z
z
E.g., Serialized Java Objects
Mp2, DivX, etc.
Accessing the dataspace means depositing and retrieving complete
files
The DataSpace model provides internal policies to
z
z
Organizes the data internally
Maximize efficiency in retrieving
27
Models for Data Access: By Name
{
By Name
z
z
Data is stored with associated name
z
z
Any piece of data has an associated name
E.g., Var V, Tuple Franco, Object John, File MyData.XML
Put(v, 5)
Put(Tuple, Franco);
Data is retrieved by asking for a specific name
z
z
Int value = Read(v);
Tuple = Read(Franco);
Advantage: Conceptually very simple
Disadvantage: Not Adaptive, require a priori agreement on
names
Sometimes, wild cards can be used to specify names
z
z
Vector Tuple[] = ReadAll(F*);
Better solution, still not enough for open and dynamic systems
28
14
Models for Data Access: By Content
{
By Content, applicable to structured data, similar to attributebased naming
z
z
z
z
{
{
Any piece of data has content (i.e., values for its fields)
(int 5, String Bye Bye, char c, float 4.56);
(Tuple A)
(int 7, String Hello, char c, float 4.76)
(Tuple B)
(int 5, float 3.14, String Hello)
(Tuple C)
Data is stored without having necessarily a name
Data is retrieved by asking for specific characteristics of its
content, as in DBMS access
z
z
Tuple = Read(int 5, String null, char c, float null);
This request match Tuple A (corresponding structure and
corresponding content), not march Tuple B (non corresponding
content) and not Tuple B (non corresponding structure)
Advantage: more dynamic and adaptive, requires only
knowing the structure of data
Disadvantage: more complex to implement
Sometimes, many data items match a request, for which:
z
z
Either one data item is get at random
Or collective operations retrieving all data items can be provided
29
DataSpace Models vs. Event-based
{
Advantages of DataSpace models
z
z
z
Disadvantages
z
z
Space and Time uncoupling, as in event-based models Although
some models may require explicit synchronization to access to data
Nice representation of common context for interactions, which
event-based models miss
Physical contextual information can be stored in the data space, as
a useful virtual reflection of a real-world environment
Components may have to actively interrogate (poll) the
dataspace to understand whats happening
Relevant events or data may be lost
Solution
z
z
z
z
z
DataSpace services can provide for event notification
Whenever some new data enters the dataspace
Whenever some component access the dataspace
In that way. Components can be made aware of whats happening
The DataSpace service becomes also an event service
30
15
Implementation Models
{
All the analyzed middleware services
(discovery service, event dispatcher,
dataspace) can be implemented in
different ways
z
z
z
z
z
Centralized
Locally Distributed
Distributed
Totally Distributed (Peer-to-Peer)
With different types of task partitioning in
case of distributed implementations
Where each solution has advantages and
disadvantages
31
Centralized Implementation
{
A Single component on a single node to
implement the middleware service
z
All components access to it for any requests
{ All RMI names are registered there OR
{ All events are dispatched by it and all
subscriptions managed by it
{ All data is stored and accessed by it
E.g., The DHCP service of the university
MW
Service
32
16
Centralized Implementation: Pros and
Cons
{
Advantages
z
z
Very simple implementation
No problems of consistency, there is a single
version of the world situation
Disadvantages
z
Not scalable to many large-size systems
{
{
{
Do not exploit locality
{
Computational bottleneck
Communication bottleneck
Memory bottleneck
The service may be far away from the component
that needs it
Single point of failure
33
Locally Distributed Implementation
{
The service is still a single one, but it is
implemented on a cluster of local computers
z
z
Each in charge of providing the same service
With a dispatcher component that act as access
point and forward the request to the one of the
nodes in the cluster
Examples: the Google cluster (15.000
Workstations), the Italian Vodafone cluster (for
mobile phone bill accounting)
Dispatcher
34
17
Locally Distributed Implementation:
Mechanisms and Policies
{
Mechanisms
z
z
z
z
Each node is able to autonomously executed the service
Typically, they all can access the same data, i.e., have a
uniform view of the world (i.e., of the objects, events,
data)
The Dispatcher receives request for services and
command one node to provide the service
Then, the commanded node interact directly with the
client
Policies
z
z
z
How the dispatcher select a node? Typically, with the aim
of load balancing
Randomly OR Cyclically: high-probability to have uniform
load distribution if all requests are similar
To Less Loaded node: takes into account how many
services each node is currently serving, and forward the
service to the less loaded node
35
Locally Distributed Implementation:
Pros and Cons
{
Advantages
z
z
z
Very effective for intensively accessed services
high computational load
Very effective for management (all in a single
room)
Very effective to protect data
Disadvantages
z
z
z
The Dispatcher is a Communication bottleneck
The Dispatcher is a Single Point of Failure (but
there are solutions to deal with this)
Do not exploit locality in accesses
36
18
Distributed Implementation
{
A set of services centers
z
z
z
Distributed across different sites
Coordinating with each other
Each capable of servicing requests
E.g. The DNS System, The Usenet News
MW
Service
MW
Service
MW
Service
37
Distributed Implementation: Pros and
Cons
{
Advantages
z
z
z
z
Scalability
Not computation or communication bottleneck
Locality in access to services
No single point of failure
Disadvantages
z
z
More complex to implement
Problems of mechanisms and policies required
to coordinate the distributed service centers
38
19
Distributed Implementation:
Mechanisms and Policies
{
Mechanisms
z
z
The various service centers take care of a
specific portion of the work
They coordinate with each other (exchange
data, information, and synchronize) to ensure
that they share a common vision of the world
They can forward a request to other service
centers, or they can cooperatively fulfill
requests
Policies
z
According to which strategy they can partition
the work?
39
Distributed Implementation: Policies (1)
{
Global replication Local Service
z
z
z
Advantages
z
z
z
All data and info is replicated to all service centers
i.e., all RMI services registers all events, all tuples
You can then request a service to any service center, and
it will be fulfill it autonomously
Requests can be effectively served
Very resilient to faults
Exploit locality in requests very well
Disadvantage
z
z
z
Very high costs for global replication
High communication costs for preserving consistency
among the various distributed replicas
Consider for example when a client changes a variable in
the dataspace.such change on a single replica must
consistently reflect everywhere
40
20
Distributed Implementation: Policies (2)
{
No Replication Global Forwarding of Requests
z
Data is stored on a single copy on a single node
{
{
z
z
e.g., the name of an RMU service or an occurred event
When you do a request to a service center, it is forwarded to all
service centers. The one which has the data necessary to fulfill the
request, will then contact directly the client
Advantages
z
z
z
This is typically the node where such data/event/RMIservice was produced
But there could be other choices, e.g., group relative data/event/services
together on a node based on its characteristics or content (Cfr. Distributed
Hash Tables)
No problems of replication consistency
Low costs for maintaining a single vision of the world
Exploits locality very well : if multiple answer to a request are
possible (e.g., there are several RMI services matching the
requested attributes, the most local one is typically obtained)
Disadvantage
z
z
Requests may take a long time to be fulfilled
There are points of failure, that however affect only a portion of the
requests
41
Distributed Implementation: Policies (3)
{
Mixed Policies
z
z
z
In general
z
z
Do some partial replication of data (not on all service
centers)
Forward requests to a partial sub-set of service centers
Ensuring that any request will be forwarded to at least
one node containing a replica of a specific data
Such a solution tries to get the advantages of both
previous solutions
Minimizing the advantages of both
It is a matter of goals to be reached to decide what
is the best policy to adopt for a specific middleware
service
42
21
Fully Distributed Implementation
{
At the extreme, one can imagine that each component that
wish to exploit middleware services
z
z
z
{
{
Volunteer itself to also act as service center
Taking care of some portion of the data and of some portion of
requests
In coordination with the other service centers
This is Peer-to-Peer
E.g., Kazaa, Gnutella, etc.
43
Fully Distributed Implementation
{
Policies
z
z
Advantages
z
z
Really open and decentralized
No single point of failure
Disadvantages
z
z
Today, typically based on a no replication, full forwarding
of requests policy
But replication indeed is promoted!!
Dramatic communication overload due to requests
Very complex inter-connection network for peers
Requires specific solutions
z
To be analyzed separately
44
22
Overview of Existing Middleware
{
CORBA
J2EE
.NET
45
CORBA
{
One of the first working
middleware
Goal: supporting distributed
and heterogeneous objectbased applications
Based on a Distributed
Object Model
z
z
Object and services
advertise themselvev
Client request CORBA (i.e.,
the so called ORB Object
Request Broker) which
services are available
The ORB receives service
invocations and forwards
them to the interest object
implementations
The ORB is the basic service
of the middleware
46
23
CORBA Components
{
ORB
z
z
z
z
z
z
Is the basic engines
Takes care of services naming (also attribute-based naming) for
objects and their services
Handles proxies and stubs
Receives discovery requests
Forwards service requests to objects and translate requests in case
of heterogeneous objects
In some cases, replication services
IDL: Interface Definition Language
z
z
The standard language with which objects advertise to ORB their
public (invokable) interfaces
Enables heterogeneous interactions
Event channel
IIPO
z
z
z
A component of the ORB that handles events and subscriptions
An ORB is typically executing over a LAN
IIPO is a protocol (over IP) to enable different ORB to interact with
each other and to define Inter-ORB systems, that is, a CORBA system
which works in a distributed implementation
Local replication, global forwarding of requests
47
J2EE
{
Based on Java Technology and Web-based
z
z
z
{
{
All Java features
Web-based middleware features (Servlet, JSP,
Servlet Context)
Enterprise JavaBeans (shared self-contained objects)
Plus a number of distributed middleware features
Goal: supporting distributed Java Web-based
applications
48
24
J2EE Architecture
49
J2EE Components
{
Web-based (JPS, Servlet, JavaBeans)
z
z
z
SOAP Interface Components
z
XML classes
Specific classes to handle and manipulate XML files
Various classes to manipulate Web-based graphical
interfaces
To publish services according to the SOAP standard
(which includes XML descriptions of services, attributes of
services, possible code attachments)
An Emerging standard for Web-based distributed object
applications
Plus:
z
z
z
z
An XML HTTP-based Messaging Service
JavaSpaces as a Shared DataSpace service
JINI, as an attribute-based Service Discovery service
Security services
50
25
Microsoft .NET
{
{
{
Goals similar to that of J2EE
But relying on proprietary product rather than on free
ones
Examples
z
z
z
z
z
z
C# vs. Java
ASP vs. JSP
ActiveX vs. JavaBeans
VisualBasic vs. JavaScript
XML is XML (its a standard!!)
SOAP is SOAP (its a standard!!)
However, if you know what Java Technologies are, you
will not problems at all in getting .NET at hand.
51
Open Issues in Middleware
{
Support for personalized user-aware services
z
z
Support for Pervasive Computing
z
Services that enable to understand what is happening in a
cognitive way
E.g., exploiting in a more intense way XML, RDF, Common
Ontologies
Autonomic Services
z
z
Integrating in an easy and seamless way sensors, location systems,
Tags, etc. (see lecture on pervasive computing technologies)
Semantic Services
z
User profiling
Understanding and adapting to users need and context
Services that can self-configure, self-repair
E.g., exploiting self-inspection and naturally-inspired selforganization
Multiagent Systems Middleware
z
z
Supporting the multiagent systems paradigm
See lecture on multiagent systems
52
26
Readings
{
{
{
{
T. Eugster et. Al, The Many Faces of Publish Subscribe, ACM
Computing Surveys, Vol. 35, No. 2, June 2003
D. Schmidt, R. Schantz, Middleware for Distributed Systems,
chapter in the book Evolving the Common Structure for Network
Centric Applications, Wiley & Sons (2001)
K. Geihs, Middleware Challenges Ahead, IEEE Computer, Vol. 24,
No. 6, June 2001.
J. Waldo et al., A Note on Distributed Computing, Lecture Notes in
Computer Science, No. 1222, June 1999.
See Also
The Various Resources on Middleware at http://dsonline.computer.org
53
27
