Download Soap Events - Extreme! Computing

SOAP Events
An Extensible and Interoperable
Event System Using SOAP
(xEvents Reference Implementation)
Aleksander Slominski
IU Extreme! Lab
Outline
Scope and Requirements
 Whirlwind survey of existing standards
 Event System Design
 SOAP Events

Core (Base Event Type, Event Listener)
 Advanced (Passing Remote References,
Leasing Event Channels)


Implementation: xEvents


on top of SoapRMI 1.1 Java / C++
Further work
Scope
Application and Component Level
Events
 Not real time or multimedia
 Focus on events that glue disparate
components and allows for easy
application integration (as painless as
possible…)
 Optimal solution: simple (good for
majority of cases) but extensible (for
the rest) and easy to deploy
(leveraging existing standards)

What is Event?
time stamped message
 delivered from source
 to subscribed listeners
 that contains typed data
 may contain sequence number to
prevent duplication and time-to-live

Requirements

Simple


Extensible


Make typical cases simple
Make other cases possible
Easily Deployable
Uses standards
 Language and Platform Independent
 Internet Friendly (firewalls…)

Requirements - details

Naming


Types - Extensible Data Format




Today it means XML and XML schemas…
Internet Enabled


How to find event publishers (LDAP, …)
Works with HTTP (firewalls, NAT, …)
Can survive and recover from failures …
Simple OO Extensible Interfaces (IDL, …)
Security – Leveraging Existing Standards

TLS/SSL, X.509 certificates, digital signatures, …
Tour of Existing Standards
Corba Events
 Jini Events
 Over 100 other event systems (or
more)



http://www.cs.caltech.edu/~adam/isen/event-systems.html
Ad hoc solutions – application specific
mechanism using proprietary format

write to file, socket, and other magic …
Corba Events






Naming Service to locate listeners
Push/Pull models and good performance
Available solutions to enable Internet
computing through firewalls (but not
designed for) and can have load balancing
and failure recovering mechanisms
Use of IDL to describe interfaces
Available extensions for security
High Performance and Multiple Languages but
Complex and Steep Learning Curve …
Jini Events







Naming with Jini Lookup Service (some
limitations but can use optionally JNDI)
Event is Java Object (good extensibility)
Listener interface - flexible publisher model
Leasing - very good for self healing
Uses RMI (available solutions for firewalls)
Leverages Java for security
Easy to use but limited to Java (generally)
Ad Hoc Solutions

It works! (for given application)




but: it does not works with others (on Grid) …
Can be very well optimized and probably is
well contained (no need to change it!)
Existing applications are typically hard to
modify therefore simple interoperable event
mechanism is crucial (in FORTRAN/C just
function call to library etc.)
Typically limited to the application and hard
to connect to other event systems
Conclusions
Any proposed event mechanism must
work with existing event standards
 No one solution is good for everything
…
 Therefore it is important to have
simple and extensible event system
that can easily be added to existing
applications
 It must allow for easy naming, object
types, security and leverage Internet
standards

Event System Design

Choices made for this event system
Design objectives
Events are signals (small size) and
actual data transfers should use more
high performance messaging protocols
 Platform and language independent
 Pervasive and simple format - XML


Easy to receive, use (parse) and store
Works and adapts to Internet using
most widespread global protocol – HTTP
 Naming (LDAP) and Security
(SSL/X.509)

SOAP 1.1
Standard supported by both IBM and
Microsoft (foundation of .NET strategy)
 Elegant and simple
 Builds on top of XML and XML Schemas
 XML it is verbose but good to create
common data format and easy to
transform
 XML Schemas to describe what we
actually send and expect to receive
(object types)

Naming
Leverage existing and working standard
 Minimum: support LDAP
 Allow to work with emerging standards
such as UDDI to describe event services
 SOAP can be easily extended to allow to
store remote references in naming
services

Types
Extensible but simple system to
describe event types
 Not centralized and platform
independent
 Easy to store, process and query
 XML and XML schemas fits the bill

Internet Enabled

SOAP RPC = HTTP + XML
Simple but extensible RPC model
 Defines HTTP bindings for SOAP

Robust and easy to implement
 Good to send signals and also to
provide tle lowest common denominator
protocol



ex. to negotiate compression, encryption,
QoS or type of faster binary protocol used
Firewall friendly (leverages HTTP
infrastructure)
WAN & distributed computing
Everything can fail just any time ..
 Therefore it is important to incorporate
leasing concept
 However if necessary allow for
unleased operations (when leasing can
not work with existing applications or
components)

Simple OO Interfaces
Event interfaces should not hide but
expose objects
 Easy to understand and to extend
 WSDL or IDL to describe what is event
listener and how to subscribe with
publisher
 Promote interoperability


Must be language and platform
independent
Security
Rarely can be added later
 SOAP already can use HTTP level
security (TLS/SSL)
 Proposed extension to SOAP to support
digital signatures
 Event system should allow to operate in
unsafe mode (for testing, debugging,
…)

SOAP Events Core

Translating requirements into event
system architecture …
Event Design
Builds on top of SOAP 1.1 encoding
 eventType and source can be used for
filtering and message dispatching
 seqNum prevents against delivering
duplicated events
 message contains descriptive
information
 timestamp – time in milliseconds since
UNIX epoch

SOAP Event

Event is a base class and it contains following
fields:








eventNamespace – URI of namespace
eventType – dot hierarchical event type name
source – string describing source (depends on
eventType)
timestamp – in milliseconds since UNIX epoch
seqNo – sequence number
message – human readable description of the
event
handback – described later with subscription
Event type is defined by XML schema: (next
slide)
<schema targetNamespace =
“http://www.extreme.indiana.edu/soap/events/” >
<element name="Event">
<complexType><sequence>
<element name="eventNamespace"
type="string"/>
<element name="eventType" type="string"/>
<element name="source" type="string"/>
<element name="timestamp" type="long"/>
<element name="seqNo" type="long"/>
<element name="message" type="string"/>
<element name="handback" type="string"/>
</sequence></complexType>
</element>
Example: Resource Event
<MachineUtilizationEvent>
<eventNamespace>http://www.extreme.indiana.ed
u/soap/events/resdat#MachineUtilizationEvent
</eventNamespace>
<eventType>resdata.machine.utilization</ev…>
<source>rainier.extreme.indiana.edu</source>
<timestamp>982862312897<timestamp>
<cpuUtilization>0.88< cpuUtilization >
<memoryUsed>123988</memoryUsed>
</MachineUtilizationEvent >
<schema
targetNamespace=“http://www.extreme.indiana.edu/so
ap/events/resdat/”
xmlns:m=“http://www.extreme.indiana.edu/soap/even
ts/” >
<import
namespace="http://www.extreme.indiana.edu/soap/ev
ents/"
schemaLocation="event.xsd"/>
<element name="MachineUtilizationEvent"
base="m:Event" derivedBy="extension">
<complexType><sequence>
<element name="cpuUtilization" type="double"/>
<element name="memoryUsed" type="long"/>
</sequence></complexType>
</element>
</schema>
Event Listener




Very simple interface
Only one method that accepts Event
Can throw SOAP 1.1 Fault in case of
exceptions
In Java pseudo code (WSDL etc. in future):
interface EventListener {
void handleEvent(Event ev) throws Exception;
}
SOAP Events and others

Interoperability


Any SOAP compliant implementation may
publish and listen for events and use Event
Channel
Mobility

To generate events there is no need to
have full fledged SOAP – it is enough to
write pre-formatted strings into socket.
Do We Need More?
Actually core SOAP Events has all that
is necessary to publish and listen for
events!
 However it would be nice to have more:

Using and storing simple remote references
(in file or in Naming Service)
 Lease and leasing event publishers
 Event channels to decouple event publisher
and listeners

SOAP Events
Channels



Decoupling producers from consumers
(Event Channels)
Supporting leased subscription (and
simple XML Remote Reference) to deal
with inherent distributed system failures
Using Naming Service for higher
reliability: mobile event listeners and
channels supports dynamic failure
recovery (lease renew + lookup)
Simple Remote Reference
Location of remote endpoint (web
service)
 What is the type of endpoint (uniquely
identified by URI to its IDL)
 That is it!
 However sometimes it is necessary to
have:

URI namespace of of the endpoint
(required by Apache SOAP)
 SOAPAction

Example of Remote Reference
<Port>
<endpoint>
<location>http://192.168.1.7:4566/urn:soaprmiv11:leasing-filtered-event-channel</location>
<binding><name>urn:soaprmi-v11:leasingfiltered-event-channel</name> </binding>
</endpoint>
<portType>
<uri>urn:soaprmi-v11:temp-java-port-type</uri>
<name>soaprmi.events.LeasingFilteredEventChann
el</name>
</portType></Port>
Port = Remote Reference






Port has Endpoint(s)
Endpoint has Location (URL)
Endpoint may have optionally Binding
Binding may contain endpoint dependent
parameters (in example it is name that
describes SOAP URI)
Port type is uniquely identified by pair (uri,
name) and it may point simply to WSDL
(ex. http://host/myService.wsdl#Listener)
This is just XML and can be stored in
Directory Service
Leased Event Subscription


Subscribe passing remote ref and asking for
lease (EventListener is Port)
When subscribing an event lease is returned
(simple object that contain duration of lease
granted)
interface LeasingFilteredEventPublisher {
EventLease subscribeLease(
EventListener listener,
Event filter, long leaseDuration,
String handback) throws Exception;
}
Yet another XML schema …
<schema targetNamespace =
“http://www.extreme.indiana.edu/soap/event
s/” >
<element name="EventLease">
<complexType>
<sequence>
<element name=“duration“ type="long"/>
</sequence>
</complexType>
</element>
Example Subscribe Request

It is using SOAP-RPC
HTTP header
 SOAP envelope and body and XML element
with function name (subscribeLease) and
namespace identifying endpoint (from
binding)
 Parameters

• First parameter is remote reference (it is Port)
• The rest of parameters

End of SOAP envelope
HTTP Headers
POST /leasing-filtered-event-channel HTTP/1.0
Host: localhost
Content-Type: text/xml
Content-Length: 1475
SOAPAction: "http://localhost:4566/leasingfiltered-event-channel#subscribeLease"
Connection: Close
…
SOAP Envelope and Call
<SOAP-ENV:Envelope
xmlns:SOAPENV='http://schemas.xmlsoap.org/soap/envelope/'
xmlns:SOAPENC='http://schemas.xmlsoap.org/soap/encoding/‘
xmlns:xsi='http://www.w3.org/1999/XMLSchema/insta
nce/'
xmlns:xsd='http://www.w3.org/1999/XMLSchema/'
SOAPENV:encodingStyle='http://schemas.xmlsoap.org/so
ap/encoding/'>
<SOAP-ENV:Body>
<subscribeLease>
…
First param with remote-ref
<p1 id='id1' xsi:type='ns1:soaprmi.port.Port' xmlns:ns1='urn:soaprmiv11:temp-java-xml-type'>
<endpoint id='id2' xsi:type='ns2:soaprmi.port.Endpoint'
xmlns:ns2='urn:soaprmi-v11:temp-java-xml-type'>
<binding id='id3' xsi:type='ns3:soaprmi.port.Binding'
xmlns:ns3='urn:soaprmi-v11:temp-java-xml-type'>
<name xsi:type='xsd:string'>urn:soaprmi-v11:simple-listener</name>
</binding>
<location xsi:type='xsd:string'>http://192.168.1.7:4561/urn:soaprmiv11:simple-listener</location>
</endpoint>
<name xsi:type='xsd:string'>urn:soaprmi-v11:simple-listener</name>
<portType id='id4' xsi:type='ns2:soaprmi.port.PortType'
xmlns:ns2='urn:soaprmi-v11:temp-java-xml-type'>
<name xsi:type='xsd:string'>soaprmi.events.EventListener</name>
<uri xsi:type='xsd:string'>urn:soaprmi-v11:temp-java-port-type</uri>
</portType>
<userName xsi:type='xsd:string'></userName>
</p1>
Rest of parameters and
closing of SOAP envelope
…
<p2 xsi:type='xsd:long'>240000</p2>
<p3 xsi:type='ns1:soaprmi.events.Event'
xmlns:ns1='urn:soaprmi-v11:temp-java-xml
-type' xsi:null='1'/>
<p4 xsi:type='ns1:string'
xmlns:ns1='http://www.w3.org/1999/XMLSc
hema/' xsi:null
='1'/>
</subscribeLease>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Event Channels
 Event
Channel = combination of
Even Listener with Event Publisher:
public interface EventChannel extends
EventListener, EventPublisher {
}
public interface
LeasingFilteredEventChannel extends
EventChannel,
LeasingFilteredEventPublisher {
}
Implementation:
xEvents
xEvents is implemented in SoapRMI
C++ and Java (also can be used from
Jython)
 This is proof-of-concept implementation
 To check that SOAP Events design will
work with any SOAP 1.1 compliant
implementation.

SoapRMI Design Motivation
RMI model
 Web services
 Distributed Events

Typical RMI Scenario
Registry
[Java/C++/…]
Client
[Java/C++/…]
Internet space
2.
1.
3.
<Port>
<location>
http://host:8888/server
</location>
<binding>…
</Port>
Server
[Java/C++/…]
SOAP on the wire
Stages in RMI scenario
1. Server publishes remote reference:
Server serverImpl = new ServerImpl();
Naming.bind(“helloService”, serverImpl);
2. Client lookups server remote reference:
Server serverRef =
(Server) Naming.lookup(“helloService”);
3. Client execute call on server:
serverRef.sayHello(“World”);
Web Services
Client
[Java/C++/…]
HelloClient.java
SOAP on wire
Server
[Java/C++/…]
HelloServlet.java
Load service
description
Publish service
description
(SOAP/Files/WebDAV)
(SOAP/Files/WebDAV)
<Port>
<location>
http://host:8888/ser
ver
</location>
<binding>…
</Port>
Service Directory
<Port>
<location>
http://host:8888/ser
ver
</location>
<binding>…
</Port>
Distributed Events
Publisher
[Java/C++/…]
SOAP on wire
Listener
[Java/C++/…]
Publish service
description
Load service
description
(SOAP/Files/WebDAV)
(SOAP/Files/WebDAV)
<Port>
<location>
http://host:8888/se
rver
</location>
<binding>…
</Port>
Subscription
<Port>
<location>
http://host:8888/ser
ver
</location>
<binding>…
</Port>
SOAP Events
Events
Publisher
SOAP handleEvent
SOAP handleEventResponse
Events
Listener
Implemented as:
Implemented as:
•Java application
•Java application
•C/C++ application
SOAP 1.1
•Servlet
•Python script
•Python script
•Others: Perl, VB, …
•Others: Perl, VB, …
SOAP and SoapRMI
RMI system on top of SOAP (simple
API)
 Supports Web Services

SoapRMI remote object can be put into
servlet
 To contact specify URL and interfaces


Naming services
Standard RMI registry (Naming.bind, …)
 JNDI for Java (and access OpenLDAP)
 SoapRMI Registry-to-JNDI bridge for C++

Implementation Details
Compliant with SOAP 1.1
 Sample code available to show how to
write event publishers and listeners in
SoapRMI Java and C++
 Extensibility

Events are objects and can be extended
 XML Schema can be used to describe event
format and we have support for mapping
schema types into objects

xEvents

Publisher


Open socket, write string, close socket (or
keep open for keep-alive)
Listener

Accept socket, parse simple XML, do stuff
Event channel with filtering (and
persistence)
 Easily pluggable: Event Listener or
Event Channel can work standalone or
in Servlet

EventListener

Very simple interface (throws
RemoteException that maps to SOAP
Fault):
interface EventListener {
void handleEvent(Event ev) throws
soaprmi.RemoteException;
}
EventPublisher
Each event publisher may have its
own API
 EventPublisher is just simple
marker interface

interface EventPublisher {
}
LeasingFilteredEventPublisher

We provide one simple push subscribe
with lease:
public interface LeasingFilteredEventPublisher
extends EventPublisher {
EventLease subscribeLease(EventListener
myReference,
long leaseDuration,
Event filter,
String handback
) throws RemoteException;
}
EventChannel

Event channel decouples event
publishers and listeners and it is both
publisher and listener:
public interface EventChannel extends
EventListener, EventPublisher {
}
public interface LeasingFilteredEventChannel
extends LeasingEventChannel,
LeasingFilteredEventPublisher {
}
Implementation
Most of xEvents are interfaces and few
basic classes such as Event
 However in package
soaprmi.events.util is simple
implementation of

Listener (standalone and as servlet)
 Publisher (produces machine utilization
events)
 Leasing Filtered Event Channel

Performance

On the order of 100 round-trip events/sec




though raw XML parsing speed of 5000/sec
Can be fine tuned for particular event types
or implemented in C++
To receive events parsing can be done by
hand if received event types are limited or
using simple and small XML Pull Parser both
for C++ and Java
Persistent event channel uses JDBC and
MySQL for backend
XML Parsing

Available strategies






DOM: put parsed tree in memory and allow
to manipulate it
SAX: pick what you need from input stream
XPP (XML Pull Parser): parse incoming
stream
Mixed: progressive DOM – combining SAX
with creating DOM on demand
Layers: XPP -> SAX -> DOM
For events: low CPU and memory
overhead
XML Pull Parser
Designed to unmarshal complex data
structures from XML (such as SOAP)
 Can be easily embedded in any
application
 Minimized memory allocation during
parsing and parser can be reused
 Tokenizing done in fast automata
 It is small (20KB for Java JAR file)
 Used both in SoapRMI Java and C++

Example: Resource Monitoring

Publisher: Sensor collects data packs it into
string and writes into socket connected to EC


Event Channel (EC) receives event parses it
and delivers to subscribers


Small specialized C program without XML parser!
SoapRMI Java service: standalone or embedded in
servlet
Listener: subscribes to EC to receive
resource utilization events

Java application or servlet that uses SoapRMI
Setting up Publisher - Listener


Simple things should be easy to do, such as:
connecting producers to consumers:



run listener 2001
run publisher http://localhost:2001
Listener and Publisher can be in SoapRMI
(C++ or Java) or event hand written.
Event
Source
Event
Instance
Format
SOAP Envelope
From Template
SOAP Event Publisher
SOAP RPC CALL
handleEvent
HTTP over TCP
SOAP Events
Listener
Producers
Publishers/Sensors
Java
Simple Publisher
Consumers
Listeners
Channels
TC: Java
Test Channel
SL: Java
Simple Listener
test.*
C++
Resdat Sensor
Java
Resdat Sensor1
Java
Resdat Sensor2
FC: Java
Filtering Channel
resdat.*
CSL: C++
Simple Listener
test.*
RC: Java
Resdat Channel
SL1: Java
Simple Listener1
SL2: Java
Simple Listener2
Example Setup: Listeners

Setup event channels




Setup event listeners




run channel –rebind FC
run unfiltered –rebind TC –subscribe FC
run unfiltered –rebind RC [NOTE: no –subscribe FC]
run listener –rebind SL –subscribe TC
run listener –rebind SL1 –subscribe RC
run listener –rebind SL2 [NOTE: no –subscribe RC]
Setup dynamic connections:


run connect –publisher FC –listener RC
run connect –publisher RC –listener SL2
Example Setup:Publishers

Publishers – start pumping events
run publisher TC
 run sensor FC
 run sensor RC


C++ publisher


./sensor FC
C++ listener

./listener –bind FC
Fault Tolerance




taking down any part of interconnected event
network will not bring down system
event listeners (including event channels) are
location independent – they rebind their
reference on startup and during subscription
renewal listeners get updated remote
references
migration of listeners to another host is
supported – publishers will lookup in
directory new reference and use it
Example: kill FC or SL1 and move to another
host
How it works?
public static void main(String[] args) {
parseArgs(args);
EventListener listener =
Util.getListenerRef(optListener, optCtxUrl);
Util.startSubscription(optPublisher,
listener, optCtxUrl, 4 * 60 * 1000, …);
}
How it works (2)?
public static LeasingEventChannel getLECRef(String loc,
String ctx)
throws soaprmi.RemoteException
{
Remote ref = soaprmi.util.Util.lookupRemote(
loc, null, ctx, LeasingEventChannel.class);
if(! (ref instanceof LeasingEventChannel)) {
throw new RemoteException("remote object is not"
+" LeasingEventChannel at location "+loc
+" (context "+ctx+")");
}
return (LeasingEventChannel) ref;
}
How it works (3)?
public static Remote lookupRemote(String loc, Remote ref,
String ctx, Class iface ) throws RemoteException
{
if(loc.startsWith("http://") || loc.startsWith("https://")) {
return soaprmi.soaprpc.SoapServices.getDefault()
.createStartpoint(loc, new Class[]{iface});
}
// do RMI registry lookup
String rmi = makeRMIRef(loc, ctx);
if(rmi != null) {
return Naming.lookup(rmi);
}
...
DirContext dirCtx = getInitialDirContext(ctx);
return (Remote) dirCtx.lookup(loc);
}
Further Work





Exploring C++ and Java performance of
xEvents
Interfacing with other SOAP implementation
(currently works with Apache SOAP and
preliminary with .NET)
Using TLS/SSL transport and leveraging
SOAP Digital Signature Extension (SOAP
DSig Spec)
Integrating xEvents into CCAT and Active
Notebook (already working with previous
incarnation)
Adding Persistent Event Channel