1 middleware infrastructures for application integration prof. roberto baldoni dr. roberto beraldi...

Middleware Infrastructures for Application Integration

Prof. Roberto Baldoni Dr. Roberto Beraldi

Dr Giorgia LodiDr Leonardo Querzoni

Dr Sirio Scipioni

Università di Roma “La Sapienza”

Content

Service Oriented Architectures Web Services J2EE (Java 2 Enterprise Edition) EJB (Enterprise Java Beans)

Event Driven Architectures Publish/Subscribe Paradigm and

implementations DDS (Data Distribution Service)

SOA and Web Services

Positioning SOA (cont)

Architectural model

Data Oriented

Distributedapplication

Computation Oriented

CommunicationOriented

•Pub/sub•Tuple space•...

•Procedures •Objects •Services

•Message Oriented Middleware•JMS•...

Data Oriented

Positioning SOA

Coupled Not coupled

Coupled

Not coupled

Reference

Computation Oriented

Communication Oriented

Tuple space

Pub/Sub

· RPC· RMI· RSI

RPC = Remote Procedure CallRMI = Remote Method InvocationRSI = Remote Service Invocation

SOA Model

Directory

Service provider

Service consumer

Invoke services

Look up

publish

Computation oriented paradigms

Procedures RPC (Remote Procedure Call)

Objects RMI (Remote Method Invocation)

Services RSI (Remote Service Invocation)

Remote Procedure Call

Client

Calling procedure

Server

Called procedure

Skeleton

Network

parametersresult

Request message Reply message

parameters result

Remote Method Invocation

Client OID

Proxy (OID interface

known at comp time,Marsh/unmarsh)

Network

OID.method(args)

Request message Reply message

Invoke (Dynamic

Invocation Interface,at run time)

Invoke(OID.method(args))

Operating System

Skeleton (compile time)

(Dynamic Skeleton Interface,

run time)

Operating System

Server OID

Ob ject OIDdatai

methods

Remote Service Invocation

Client

Calling Service

Web Server

Called Service

Skeleton

Network

parametersresult

Request message (XML, SOAP,HTTP) Reply message

parameters result

generate

publication

WSDL = Web Service Definition Language

Interoperabilty

DC C:X D:X

Java WSDL C#

Interoperability (example)

Common standards Different implementations, same behaviour

Introduction to Web Services (1/4)

Distributed applications are largely built around the client/sever paradigm

CLIENT SERVER

Request

Server

Client

invocation

result

Serverinvocation

result

Process:Key:

Computer:

Client (web browser), Server (web server) HTTP implements a simple request/reply

protocol GET

Request: url; reply: data POST

Request:url+data, reply: status... ...

HTTP methods are fixed in number They represent the interface through which

clients interact with the server..

CLIENT SERVER

request

Interface

Key ideas

Web services allow for a client to invoke methods (service)

...Client is a program (not interacting with a human)

....Methods (interface) is not fixed Standard technology to allow interoperability

Definition (W3C) ‘Web services provide a standard means of

interoperating between different software applications, running on a variety of platforms and/or frameworks.’

WS Architecture

ServiceProvider

ServiceRequester

Registry(UDDI)

WSDL (publication)WSDL (discover)

SOAP: Simple Object Access ProtocolWSDL: Web Service Definition LanguageUDDI: Universal Discovery, Description, Integration

Technologies of WS

Messages

Extensions(transaction, Reliability..)

Descriptions(WSDL)

ProcessesDiscovery,Choreography,..

Communications(HTTP,SMTP,FTP,JMS,IIOP,...)

XML Derived from SGML (Standard Generalized

Markup Language) Markup

HTML: how to represent a data ... i = italic

XML: information about the type + structure of the data

An example

Elements <name> Smith</name>

Closing tag Data Open tag

Attributes

<name> Smith</name>

</person>

Well Formed Document

1. A rooted tree2. Any open tag has a matching closing tag

<name> Smith </name>

3. Attributes are quoted <person id = “123”> <person/>

4. Empty tags <temperature value = “25”/>

5. Elements are properly nested<x> ... <y>..</y> ... </x>

Example

<?xml version="1.0" encoding="ISO-8859-1"?> <note> <to>Tove</to>

<from>Jani</from> <heading>Reminder</heading>

<body>Don't forget me this weekend!</body> </note>

Name Space

Identified by a URI Declared by means of a reserved attribute

xmlns[:<prefix>]=<URI> Associated to the <prefix> Used to refer to a scheme

An example

<xsd:schema xmlns:xsd = URL of XML schema definitions><xsd:element name= "person" type ="personType" />

<xsd:complexType name="personType"><xsd:sequence>

<xsd:element name = "name" type="xs:string"/> <xsd:element name = "place" type="xs:string"/> <xsd:element name = "year"

type="xs:positiveInteger"/> </xsd:sequence><xsd:attribute name= "id" type = "xs:positiveInteger"/>

</xsd:complexType></xsd:schema>

Valid docuements A valid document is a Well Formed

Document that satisfies a scheme

Document

Scheme

Example

<pers:name> </pers:name>

<pers:place> </pers:place>

<pers:year> </pers:year>

</person>

envelope

header

header element

body element

header element

body element

SOAP message

m:exchange

env:envelope xmlns:env =namespace URI for SOAP envelopes

m:arg1

env:body

xmlns:m = namespace URI of the service description

Hellom:arg2

Reply message

env:envelope xmlns:env = namespace URI for SOAP envelope

m:res1

env:body

xmlns:m = namespace URI for the service description

m:res2World

m:exchangeResponse

HTTP / SOAP

endpoint address

action

POST /examples/stringerHost: ….

Content-Type: application/soap+xmlAction: http://....

<env:envelope xmlns:env= namespace URI for SOAP envelope><env:header> </env:header><env:body> </env:body></env:Envelope>

abstract concrete

how where

definitions

target namespace

interface bindings servicesmessage

document stylerequest-reply style

Message exchange patterns

In-Out

In-Only

Robust In-Only

Out-In

Out-Only

Robust Out-Only

Client Server Delivery Fault message

Request Reply may replace Reply

Request no fault message

Request guaranteedmay be sent

Reply Request may replace Reply

Request no fault message

Request guaranteedmay send fault

Messages sent by

WS Combination (choreography)

hotel bookinga

Travel Agent

flight booking

hire car bookingaService

Client

flight bookingb

hotel bookingbhire car bookingb

From Coulouris, Dollimore and Kindberg, “Distributed Systems: Concepts and Design”

Exercise We are given an electronic shared whiteboard,

where graphical objects can be shared among clients

Design the interface of the whiteboard as a remote object and as a service; outline the differences among the two

Witheboard

Graphical Object

WS implementation in J2EE

Client tier

J2EE Server

Data tier

Legacysystem

Web tier

Business tier

Framework model

Components

CONTAINER

Web service as a Servlet

Browser

Client HTTP

Container Servlet

(i.e., Tomcat)

Servlet

Server Web

Business tier

HTTP request

reply HTTP

2 Web server container3 Container Servlet5 Web server client

4 Servlet generates the reply

Web services API JAX-RPC (old)

SOAP,HTTP1.1,WSDL JAX-WS (new)

Annotation mechanism

Java 2 Enterprise Edition (J2EE)

Java 2 Enterprise Edition

J2EE technology provides a component-based approach to the design, development, assembly and deployment of enterprise applications

J2EE offers a multi-tiered distributed application model The ability to reuse components Integrated eXtensible Markup Language (XML)-

based data interchange A unified security model Flexible transaction control

Distributed Multi-tiered Applications

J2EE application logic is divided into components according to function Application components

can be installed on different machines depending on the tier in the multi-tiered J2EE environment

Four tiers Client-tier Web-tier Business tier Enterprise information system (EIS)-tier

Distributed Multi-tiered Applications

Application Client

Browser

Client tier

JSP/Servlet

Web tier

Business tier

EIS tier

Enterprise Beans

Client machine

J2EE Server machine

Database Server machine

J2EE containers

Runtime environments They host application components

Application components use their protocols and methods for interacting with other

components and platform services never interact directly with other J2EE components

Provide the required middleware services to the application components they host A federated view of the underlying J2EE APIs

Types of containers

Different containers depending on the kind of application component they host Application client container Applet container

manages the execution of applets. Consists of a Web browser and Java Plug-in running on the client together

Web container manages the execution of JSP page and servlet components

for J2EE applications Enterprise JavaBeans (EJB) container

manages the execution of enterprise beans for J2EE applications

J2EE components

A J2EE component is a functional software unit Five types of components:

Application clients Web clients Java Servlet JavaServer Pages (JSP) Enterprise Java Beans (EJBs)

J2EE components written in Java and compiled in the same way as any program in Java

J2EE components are assembled into a J2EE application and deployed to production

Application clients

Run on a client machine Exhibit a graphical user interface (GUI)

Swing or Abstract Window Toolkit (AWT) APIs command-line interface

They may directly access enterprise beans running on the business tier

They may communication with a servlet running on the Web tier by opening a HTTP connection

Web Clients and Applets

Web pages (HTML,XML…) generated by Web Components

Web browser it renders the pages received from the server

Sometimes called thin clients Applets Small client applications written in Java

execute in the JVM installed in the Web browser Necessary

Java Plug-in and security policy file in order to successfully execute the applet in Web browsers

Web Components: Servlets

Java objects that dynamically process requests and construct responses Serve as a HTTP-aware middle layer that resides on

the server side They know how to communicate with both the clients, in

HTTP, and EJBs with Remote Method Invocation (RMI) Typically take a HTTP request as input, parse its data,

perform some logic, and then construct a response to the client

They are not scripts; the HTML part is embedded inside the Java code

response.write(“<html> <body> Hello Guys!! </body></html>”);

Web Components: Servlets

The javax.servlet and the javax.servlet.http provide interfaces and classes for writing servlets

When implementing a generic service use the GenericServlet class provided with

the Java Servlet API When handling HTTP-specific services

use the HttpServlet class provides methods such as doGet and doPost

Servlet life cycle

Controlled by the Web container When a request is mapped to a servlet, the

container performs the following steps If an instance of the servlet does not exist

Loads the servlet class Instantiates an instance of the servlet class Initializes the servlet instance by calling the init method

Invokes the service method, passing a request and response object

Service method can be the service method of the GenericServlet or a doMethod (e.g., doGet, doPost) of the HTTPServlet

Servlet Example

public class MyServlet extends HTTPServlet {………public void init(ServletConfig config)

throws ServletException {super.init(config);System.out.println(“Servlet initialized”)

}public void destroy() {

super.destroy();System.out.println(“Servlet destroyed”);

}public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {

…………}

Web Components: Java Server Pages (JSP)

Text-based documents allow developers to create Web contents with both static

and dynamic components static content expressed in any text-based format (HTML, XML …) dynamic content constructed by JSP elements

Provide a more natural approach to creating static contents

HTML pages with special embedded JSP tags tags can contain Java code

NO Java classes files with .jsp extension (they are not compiled like

common Java programs)

Java Server Pages (JSP)

A JSP engine parses the .jsp and creates a Java servlet source file (translation) The source file is then compiled into a class file (compilation)

Both the translation and compilation phases can yield errors If an error occurs while the page is being translated (e.g., if

the translator encounters a malformed JSP element) The server returns a ParseException and the servlet class source

file is empty or incomplete If an error occurs while the JSP page is being compiled (e.g.,

due to a syntax error in a scriptlet tag) The server returns a JasperException

JSP Example

<title> My JSP Example </title></head><body>

JSP Hello word <%! public String writeThisTest() {

String testToWrite=“Hello Guys!!”;return testToWrite;

}%> <%= writeThisTest() %>

</body></html>

Business Components

The Enterprise Java Beans (EJBs) of the J2EE specifications

Handle the business code i.e. the logic that meets the needs of a business domain

Retrieve data from J2EE clients, process it and send it to the EIS tier (and vice versa)

Three kinds of EJBs Session Beans: transient conversation with a client Entity Beans: persistent data stored in one row of a

database table Message Driven Beans: combine feature of a session bean

and a Java Message listener

J2EE applications

J2EE applications packaged in Enterprise Archive (EAR) files EAR files are standard Java Archive (JAR) files

with .ear extension The EAR file contains J2EE modules

J2EE modules (four types) one or more J2EE components for same container type a component Deployment Descriptor (DD) for that type

J2EE modules

EJB module contains .class files for EJBs and an EJB DD EJB module packaged as JAR file (.jar extension)

Web module contains JSP files, .class files for servlet, HTML files and a Web DD Web module packaged as JAR file with .war extension

Resource adapter module contains Java interfaces, classes and libraries and the resource

adapter DD Resource adapter module packaged as JAR file (.rar extension)

Application client module contains .class files and an application client DD Application client module packaged as JAR file (.jar extension)

Deployment Descriptors (DDs)

A XML document describes a component’s deployment settings (e.g.

transactional information, database mapping, security roles)

Used to inform the container about how to manage the bean and its life cycle

Can be changed without modifying the bean source code it contains declarative information at run time the J2EE server reads the DD and acts

upon the component accordingly Different DDs depending on the J2EE modules

DD example

<?xml version=“1.0” encoding=“UTF-8”?><ejb-jar> <description>Entity Bean Example </description> <display-name>Entity Beans</display-name> <enterprise-beans>  <entity> <display-name>Container Managed Persistence Player</display-name> <ejb-name>CMPPlayer</ejb-name> <home>entity.ejb.PlayerHome</home> <remote>entity.ejb.Player</remote> <ejb-class>entity.ejb.CMPPlayerBean</ejb-class> <prim-key-class>java.lang.String</prim-key-class> <primkey-field>playerId</primkey-field> <cmp-field><field-name>name</field-name></cmp-field> … </entity> …

J2EE middleware services

Robust suite of middleware services the services rely on the Java 2 Standard Edition (J2SE)

Technologies included in J2EE Enterprise Java Beans (EJBs)

Defines how server-side components are written Java Servlets and Java Server Pages (JSPs)

Defines and manages servlets and JSPs Java Remote Method Invocation (RMI) and RMI-

IIOP RMI allows for inter-process communication RMI-IIOP is a portable extension of RMI that uses the

Internet-Inter-ORB Protocol (IIOP) for CORBA integration

HTTP HTTP client-side API defined in the package java.net HTTP server-side API defined by servlets and JSPs interfaces HTTPs: HTTP over SSL

Java DataBase Connectivity (JDBC) It is a relational database bridge that allows developers to invoke SQL

commands from Java methods Generally used by EJBs but even servlet or JSP page can use it to access the

database directly Composed by two parts: an application-level interface used by applications for

accessing database and a service provider interface to attach JDBC drivers to the J2EE platform

Java Message Service (JMS) It allows application components to create, send, receive and read messages It enables distributed communication that is loosely coupled, reliable, and

asynchronous

Java Naming and Directory Interface (JNDI) provides methods for associating attributes with objects,

searching for objects using attributes independent of any specific implementations

JNDI used to access multiple naming and directory services (e.g. LDAP, DNS, NIS…)

Java Transaction API (JTA) provides methods for managing transactions (e.g.

begins, rollbacks, commits) JavaMail

Used to send e-mail notifications

Java API for XML Processing (JAXP) supports the processing of XML documents using

either Document Object Model (DOM) or Simple API for XML Parsing (SAX)

enables applications to parse and transform XML documents

Java Authentication and Authorization Service (JAAS) provides a way for J2EE application to authenticate

and authorize a specific user or group of users to run it

Web Service management provides support for both web service clients and web service

endpoints includes

Java API for XML-RPC (JAX-RPC): supports for web services calls using the SOAP/HTTP protocol

SOAP with Attachments API for Java (SAAJ): provides support for manipulating low-level SOAP messages

Web Services defines the deployment of web services clients and web service endpoints Defines the implementation of web service endpoints using enterprise

beans Java API for XML Registries (JAXR): provides client access XML

registry servers (UDDI)

J2EE Connector Architecture (JCA) used by tools vendors and system integrators to create

resource adapters resource adapters are software components that allow J2EE

components to access and interact with enterprise information systems, plugged into any J2EE product

resource adapters are useful to manage details of middleware integration to existing systems

Java IDL sun Microsystem’s Java-based implementation of CORBA allows for integration with other languages (J2EE fully

compatible with CORBA)

J2EE overall architecture

BrowserBrowser

J2EE Server

DBDB ApplicationApplication

ClientClient

Application client

container

JAX-RPC

SAAJ JMX

JNDIJAXR

Web Srvcs

RMIRMI

HTTPHTTP

HTTPSHTTPS

Web ContainerJSPJSPServletServlet

……

Java MAIL

SBSBEBEBEBEB

EJB Container

MDBMDB

……

Java MAIL

RMIRMI

J2EE application example

customer

J2EE Server

Web tier [Servlets/JSPs]

Business tier [EJBs]

browse

select

purchase

catalog

Shopping cart

Book order

Java Mail

Mail server

secure

J2EE Application Servers

Middleware platforms that implement the J2EE specifications

Open Source Application Servers JBoss (JBoss Group) JOnAS (ObjectWeb consortium) Geronimo (Apache Software Foundation) …

Commercial Application Servers BEA Web Logic IBM WebSphere Sun ONE Application Server …

Enterprise Java Beans (EJBs)

version 2.1

EJBs: What are they?

They are NOT JavaBeans They are business components of the

J2EE specifications There are different types of EJBs

Session Beans Entity Beans Message Driven Beans

JavaBeans vs EJBs

Reusable software components written in the Java programming language that can be visually manipulated in builder tools (Sun) encapsulates functionalities provide services based on a specification can be assembled easily to create applications Java classes that follow a software component

specification example: buttons, scrollbars, rowset, etc…

In order to implement JavaBeans there are specific conventions (design patterns) to follow

EJB Interfaces

Remote Interface Defines the business methods It is the interface for the outside world (i.e., actual

interface for the component’s services) Implemented by the EJB object

Home Interface Defines the beans creation methods Defines the finder methods Implemented by the Home Object

Local Interface and Home Local Interface (EJB 2.0)

Remote Interface example

import javax.ejb.*;import java.rmi.RemoteException;import java.rmi.Remote;

public interface myFirstRemoteInterface extends EJBObject {

public … businessMethod1() throws RemoteException; … …

Home Interface Example

import javax.ejb.*;import java.rmi.RemoteException;

public interface myFirstHomeInterface extends EJBHome {

myFirstRemoteInterface create() throws RemoteException, CreateException;public myFirstRemoteInterface findByPrimaryKey(String key) throws FinderException, RemoteException;…

EJB class

Implements the business methods (e.g., defined by the programmer)

Implements the life-cycle methods (e.g., ejbCreate(), ejbPostCreate(), ejbPassivate(), ejbActivate(), ejbRemove())

Implements the finder methods (e.g., find…()) Clients never interacts with the class

They use methods of the Remote and Home Interfaces, interacting with automatically generated stubs

EJB class example

import javax.ejb.*;import java.rmi.RemoteException;import javax.naming.*;

public class myFirstBeanEJB implements … (where … indicate the type of bean to implement, e.g., SessionBean, EntityBean) {

// implementation of EJB-required methods // implementation of EJB-business logic methods

EJB architecture

ClientClientJ2EE J2EE serverserver

EJB EJB ContainerContainer

HomeHomeStubStubHomeHomeStubStub

ClientClientStubStub

HomeHomeObjectObjectHomeHomeObjectObject

EJBEJBObjectObjectEJBEJB

ObjectObjectBeanBeanClassClassBeanBeanClassClass

Remote Remote InterfaceInterface

Home InterfaceHome Interface

Naming

Java Naming and Directory Interface (JNDI) EJBs mandate the use of JNDI as a lookup API on

Java clients It is a kind of wrapper around the underlying

naming service The naming service actually used is up to the EJB server

vendor

JNDI used for accessing EJB Home Interface

How to invoke an EJB

JNDI J2EE J2EE ServerServer

EJB EJB ContainerContainerClientClient HomeHome

ObjectObjectHomeHomeObjectObject

1. Ask forfor HomeHome ObjObj

2. Return Home Object Reference

3. Ask forfor EJB ObjEJB Obj

EJBEJBObjectObjectEJBEJB

ObjectObject

4.Create EJB Object

5. Return EJB 5. Return EJB Object Object ReferenceReference6. Invoke 6. Invoke

a methoda method BeanBeanClassClassBeanBeanClassClass

7. Delegate the call to the Bean

Invoking an EJB: example

…/* Get system properties for JNDI initialization */Properties props = System.getProperties();Context ctx = new InitialContext(props); /* Get the reference to the home object * (the factory for the EJB objects) */homeInterfaceType nameHome = (homeInterfaceType) ctx.lookup(“JNDInameOfHomeInterface”);/* Use the factory to create the EJB Object */remoteInterfaceType nameRemote = nameHome.create(…);/* Call the business methods defined in the remote* interface*/nameRemote.businessMethod(…); …………

Types of EJBs

Session Beans Associated to a client Represent business interactions

Entity Beans Persistent Represent business objects

Message Driven Beans Act as an entry points for asynchronous messages No interfaces defined, only bean class

Session Beans

Useful for describing interactions with clients They do not represent shared data in the

database but they can access shared data There are two types of Session Beans:

Stateless Session Beans They do not maintain state across method invocations Examples: credit card verifier

Stateful Session Beans Dedicated to one client for the life of the bean instance Act as client agents: retain state on behalf of the client Example: checking account balance

When to use Session Beans

Only one client has access to the bean instance

Non persistent and existing only for a short period of time For Stateful Session Beans, the beans need

to hold information about the client across method invocations

Mediate between the client and other application components

Entity Beans

Represent business objects in a persistent storage e.g., accounts, orders, customers

They they model data object oriented view of a database

Have a primary key Each entity bean may be retrieved in much the same

manner you search records with a primary key in a database

Can be shared by multiple clients As they are persistent and reachable by any client

they suffer from all the same types of problems associated with concurrent access of a shared resource

When to use Entity Beans

When you need to represent business entities When you provide a safe and consistent interface

to a set of shared data

Client 1“Giorgia”

Client 2“Andrea”

EJB Object 1“Giorgia’s bank

Account”

EJB Object 2“Andrea’s bank

Account”

EJB EJB ContainerContainer

Entity Bean

Instances

Remote Remote InterfaceInterface

Bean poolBean pool

Message Driven Beans (MDBs)

Have only a bean class no remote or home interfaces

Can consume and process messages designed to consume messages from topics or queues

Act as a JMS message listener they implement only one method onMessage()

Process only JMS messages (EJB 2.0)

When to use them To receive messages asynchronously When consuming JMS messages

impossible to write session or entity beans that respond to JMS messages

Message Driven Beans (MDBs)

A MDB instance retains no data or conversational state for a specific client (Sun)

All instances of a message-driven bean are equivalent the EJB container can assign a message to any

message-driven bean instance the container can pool these instances to allow streams

of messages to be processed concurrently (Sun) A single message-driven bean can process

messages from multiple clients (Sun)

Persistence

No persistence for Stateless Session Beans and Message Driven Beans

Stateful Session Beans can be passivated the state is defined by Java Serialization

Entity Beans are persistent: two types of persistence Bean Managed Persistence (BMP) Container Managed Persistence (CMP)

Bean-Managed Persistence

Component developer write code to translate in-memory fields into an underlying data store (e.g., relational database)

Business methods can access the database (i.e. business methods implement SQL queries)

Container-Managed Persistence

Entity Beans CMP are the simplest to develop The container performs every function of the

component’s data access on behalf of the programmer The bean’s code must not contain database access calls

The state is represented by persistent fields Abstract setters and getters EJB required methods implemented by the EJB container DB mapping specified in the DD

When the bean CMP is created, the EJB container instantiate the primary key

All the fields in the bean must be declared as public The container can set the fields when it performs operations on

behalf of the bean

EJBQL Query Language

The Enterprise JavaBeans™ Query Language (EJB™ QL) defines the queries for the finder and select methods of an entity bean with CMP

You define EJB QL queries in the deployment descriptor of the entity bean

An EJB QL query has three clauses: SELECT, FROM, and WHERE

EJBQL Query Language

FINDER METHODS Finder methods get either a single or a collection of

entity bean instances from the persistence store Defined in the home interface of an entity bean, i.e., they are

exposed to the client

SELECT METHODS A select method is an abstract method, defined in an

entity bean class, and implemented by an EJB QL query in the bean's deployment descriptor

Container-Managed Relationship (CMR) Represented by the cmr fields in the DD Support

One-to-one One-to-many Many-to-many

The entity bean uses a Java Collection to represent the "many" side of a relationship

The single side is represented by the local bean object CMR requires both entity beans to reside in a single

JVM Entity beans must have local interfaces

Transactions

Container Managed Transactions (CMT) Managed automatically by the EJB Container No use of API In DD the beans and the methods involved in the

transaction are specified Supported by all bean types The container

maps the transactions to DB transactions begins a transaction immediately before an EJB’s method

starts commits the transactions just before the method exits

Each method is associated with a single transaction. Nested or multiple transactions are not allowed within a method

Transactions

Bean Managed Transactions (BMT) Managed by the bean developer Supported by the Session Beans and the

Message Driven Beans only Developers must decide whether to use

JDBC or JTA transactions

N.B: Use them only when necessary!!

Summary of EJB container responsibilities

Design of EJBs as single-threaded components (no worry about thread synchronization with concurrent client accesses)

EJB container instantiates multiple instances of components to serve concurrent client requests

Advantages: no need to worry about deadlock inside application code EJB container uses management methods to alert beans when

middleware events take place

Client codeEJB EJB ContainerContainer

Enterprise Bean

invokinvokee

delegadelegatetePoint of interception. Point of interception.

The container gives The container gives beans implicit beans implicit services (e.g. life-services (e.g. life-cycle, transaction, cycle, transaction, security, security, persistence…)persistence…)

EJB 3.0 specification

Makes the container do more work and the developers do less work

Decreases the number of programming artifacts for developers to provide

Eliminates the requirement to implement ejb<method> callback methods

Reduces the complexity of the entity bean programming model

EJB 3.0: advantages

Fewer number of classes and interfaces No home interface No component interface to implement

POJO/POJI-based components Abstract bean classes replaced with Plain Old

Java Objects (POJOs) Component and Home interfaces replaced with

Plain Old Java Interfaces (POJIs) Interfaces are optional

EJB 3.0: advantages

Deployment descriptors are optional Use of Java metadata annotations

It is necessary JDK 5.0 to develop EJB 3.0

Semplification of APIs for accessing bean’s environment JNDI lookups are no longer necessary

New persistence APIs …

No home interface

Use only a business interface that does not extend EJBObject Plain Old Java Interface (POJI)

public interface MyBusinessInterface { … } It contains all business methods

Business interface can be remote, local or both Methods in it can throw arbitrary application exceptions

They are not allowed to throw java.rmi.RemoteException No business interface for Message Driven Beans It can be optional

No component interface

javax.ejb.SessionBean …. The way through which the container notified the bean

instance of life cycle events ejbCreate(), ejbDestroy()…

No need of component interface in EJB 3.0 Bean class will be a Plain Old Java Object (POJO) that

implements a business interface If bean interested in getting notification from container

Bean provides a separate class with the callback notification methods (bean’s callback listener class)

Bean class implements callback notification methods Both approaches require the use of java annotations

Annotations

Metadata Additional definition that can be attached to an element

within the code in order to further characterize it Can be applied to methods, variables, constructors,

package declarations, and so on Begin with @ sign followed by the annotation name

Annotation name may be followed by annotation data EJB 3.0 has defined annotations for use in EJB

development The specification has also defined metadata to annotate

deployment information within the code

Deployment Descriptor: optional Deployment descriptors are redundant as

developers can use annotations in lieu of them Deployment metadata can be included in the

EJB code At deployment time, the metadata can used to provide

the appropriate behaviour to the bean Remember: they are optional

The bean developer can Put all the deployment information in deployment descriptors Distribute deployment information across the bean class and

the deployment descriptor Use only annotations Deployment descriptors override annotations

Simplifying APIs access

Client applications for EJB 2.1 obtain a reference to entity and session bean objects using the JNDI name

EJB 3.0 clients obtain them using annotations

Event-Driven Architectures

The Pub/Sub Paradigm Publishers: produce data in form of events. Subscribers: declare interests on published data with subscriptions Each subscription is a filter on the set of published events. An Event Notification Service (ENS) notifies to each subscriber every

published event that matches at least one of its subscriptions.

The Pub/Sub Paradigm Publish/subscribe was thought as a comprehensive solution for those

problems: Many-to-many communication model - Interactions take place in an

environment where various information producers and consumers can communicate, all at the same time. Each piece of information can be delivered at the same time to various consumers. Each consumer receives information from various producers.

Space decoupling - Interacting parties do not need to know each other. Message addressing is based on their content.

Time decoupling - Interacting parties do not need to be actively participating in the interaction at the same time. Information delivery is mediated through a third party.

Synchronization decoupling - Information flow from producers to consumers is also mediated, thus synchronization among interacting parties is not needed.

Push/Pull interactions - both methods are allowed. These characteristics make pub/sub perfectly suited for distributed

applications relying on document-centric communication.

Event Events represent information structured following an event

schema.

The event schema is fixed, defined a-priori, and known to all the participants.

It defines a set of fields or attributes, each constituted by a name and a type. The types allowed depend on the specific implementation, but basic types (like integers, floats, booleans, strings) are usually available.

Given an event schema, an event is a collection of values, one for each attribute defined in the schema.

Event Example: suppose we are dealing with an application

whose purpose is to distribute updates about computer-related blogs.

name type allowed values

blog_name string ANY

address URL ANY

genre enumeration

[hardware, software, peripherals, development]

author string ANY

abstract string ANY

rating integer [1-5]

update_date date >1-1-1970 00:00

name value

blog_name Prad.de

address http://www.prad.de/en/index.html

genre peripherals

author Mark Hansen

abstract“The review of the new TFT panel...”

rating 4

update_date 26-4-2006 17:58

Event Schema

Subscription Subscribers express their interests in specific events issuing

subscriptions.

A subscription is, generally speaking, a constraint expressed on the event schema.

The Event Notification Service will notify an event e to a subscriber x only if the values that define the event satisfy the constraint defined by one of the subscriptions s issued by x. In this case we say that e matches s.

Subscriptions can take various forms, depending on the subscription language and model employed by each specific implementation.

Example: a subscription can be a conjunction of constraints each expressed on a single attribute. Each constraint in this case can be as simple as a >=< operator applied on an integer attribute, or complex as a regular expression applied to a string.

Event Space From an abstract point of view the event schema defines an n-

dimensional event space (where n is the number of attributes). In this space each event e represents a point. Each subscription s identifies a subspace. An event e matches the subscription s if, and only if, the

corresponding point is included in the portion of the event space delimited by s.

A taxonomy Depending on the subscription model used we distinguish

various flavors of publish/subscribe: Topic-based Hierarchy-based Content-based Type-based Concept-based XML-based …

Topic-based Selection Data published in the system is mostly unstructured, but each event is

“tagged” with the identifier of a topic it is published in. Subscribers issue subscriptions containing the topics they are interested in.

A topic can be thus represented as a “virtual channel” connecting producers to consumers. For this reason the problem of data distribution in topic-based publish/subscribe systems is considered quite close to group communications.

Hierarchy-based Selection Even in this case each event is “tagged” with the topic it is published

in, and Subscribers issue subscriptions containing the topics they are interested in.

Contrarily to the previous model, here topics are organized in a hierarchical structure which express a notion of containment between topics. When a subscriber subscribe a topic, it will receive all the events published in that topic and in all the topics present in the corresponding sub-tree.

Content-based Selection All the data published in the system is mostly structured. Each

subscription can be expressed as a conjunction of constrains expressed on attributes. The Event Notification Service filters out useless events before notifying a subscriber.

event2:name= Acme REvalue=18$

event1:name= Acme cablesvalue=23$

Event Notification Service The Event Notification Service is usually implemented as a:

Centralized service: the ENS is implemented on a single server. Distributed service: the ENS is constituted by a set of nodes, event

brokers, which cooperate to implement the service.

The latter is usually preferred for large settings where scalability is a fundamental issue.

Event Notification Service Modern ENSs are implemented through a set of processes, called

event brokers, forming an overlay network. Each client (publisher or subscriber) accesses the service through a

broker that masks the system complexity. An event routing mechanism routes each event inside the ENS from

the broker where it is published to the broker(s) where it must be notified.

Event Flooding Each event is broadcast from the publisher in the whole system. The implementation is straightforward but very expensive. This solution has the highest message overhead with no memory

overhead.x>30

x<18 AND x>10

x=30 OR x>200

Subscription Flooding Each subscription is copied on every broker, in order to build locally complete

subscription tables. These tables are then used to locally match events and directly notify interested subscribers. This approach suffers from a large memory overhead, but event diffusion is optimal. It is impractical in applications where subscriptions change frequently.

x>30 IP x

x<>30 IP y

x<5 IP z

x>40 IP w

x>10 IP xyzx>30

x<18 AND x>10

x=30 OR x>200

x<>30x<5

Filter-based Routing Subscriptions are partially diffused in the system and used to build

routing tables. These tables, are then exploited during event diffusion to dynamically build a multicast tree that (hopefully) connects the publisher to all, and only, the interested subscribers.

x<18 AND x>10

x=30 OR x>200

x<>30x<5

x<18 AND x>10

x=30 OR x>200

6 x>10

3x>=30 OR (x<18 AND

7 x>10

ax>=30 OR (x<18 AND

bx>=30 OR (x<18 AND

5 x>10 OR x<5

9 x>10 OR x<5

x<18 AND x>10

x=30 OR x>200

6 x>10

3x>=30 OR (x<18 AND

7 x>10

ax>=30 OR (x<18 AND

bx>=30 OR (x<18 AND

5 x>10 OR x<5

9 x>10 OR x<5

Rendez-Vous Routing It is based on two functions, namely SN and EN, used to associate

respectively subscriptions and events to brokers in the system.

Given a subscription s, SN(s) returns a set of nodes which are responsible for storing s and forwarding received events matching s to all those subscribers that subscribed it.

Given an event e, EN(e) returns a set of nodes which must receive e to match it against the subscriptions they store.

Event routing is a two-phases process: first an event e is sent to all brokers returned by EN(e), then those brokers match it against the subscriptions they store and notify the corresponding subscribers.

This approach works only if for each subscription s and event e, such that e matches s, the intersection between EN(e) and SN(s) is not empty (mapping intersection rule).

Rendez-Vous Routing Phase 1: two nodes issue the same subscription S.

SN(S) = {4,a}

Rendez-Vous Routing Phase 1I: an event e matching S is routed toward the rendez-vous node where it

is matched against S.

EN(e) = {5,6,a} Broker a is the rendez-vous point between event e and subscription S.

A Generic Architecture of a Pub/Sub Systems

From “Distributed Event Routing in Publish/Subscribe Communication Systems: a survey” R.Baldoni,

L. Querzoni, S. Takoma, A. Virgillito midlab tech.rep. 2007, to appear (springer)

Introduction to DDS DDS

is based on a topic-based Publish-Subscribe Paradigm

provides a QoS enabled dissemination

Traditional applications domains are: Industrial Process control Air Traffic Control Systems Naval Combat Management Systems

DDS Components DCPS = Data Centric Publish_Subscribe

Purpose: distribute the Data DLRL = Data Local Reconstruction Layer

Purpose: provide an object-based model to access data “as if” it was local

DLRLDLRLDLRLDLRL

DCPSDCPSDCPSDCPS

DCPS Provides a Global Data Space that is

accessible to all interested application Subscriptions are decoupled from Publications Contracts established by means of QoS

DCPS Based on a data-oriented approach

Publishers and subscribers exchange data samples Global Data Space can contain several topics It allows the definition of several QoS policies that allow

the middleware to control QoS properties that affect predictability, overhead and resource utilization

Benefit of DDS/DCPS Predictable and/or reliable data distribution

No single point of failure QoS Parameters used to set up communication

determinism/reliability Naturally suitable to environments

characterized by intermittent connectivity Plug & Play

Dynamic, automatic discovery

DCPS Entities DomainParticipant: it represents participation of the

application in communication collective DataWriter: Object to write data on a particular Topic Publisher: Aggregation of DataWriter objects. Responsible

for disseminating Data Samples

DCPS Entities DataReader: Object to read data regarding a particular

Topic. Subscriber: Aggregation of DataReader objects.

Responsible for receiving Data Samples

DDS and QoS QoS Contract “Request/Offered”

QoS Request/Offered: Ensure that the compatible QoS parameters are set

Offer must be better than Request

Offer must be better than Requestif QoS are

compatible

Communication Established!

Offer must be better than Requestif QoS aren’t

compatible

Communication NOT Established!

DDS, Topics and Keys Multiple instance of the same Topic

Do not need a separate Topic for each data-object instance Used to identify specific instances Topic Key can be any data-type within the Topic

QoS Policies: Data Delivery Reliability: indicates the level of reliability

requested/offered by the service Reliable Best-Effort

Ownership: specifies whether more than one DataWriter can update the same instance of a Data Object

Shared: all DataWriters can update the same data instance Exclusive: only highest-strength DataWriter can update the data

instance Liveliness: used to define mechanism used to determine

status of Entity Automatic: Infrastructure-Managed Manual: Application-Managed

QoS Policies: Data Delivery Destination Order: controls logical order among changes

by_reception_timestamp: order is determined by DataReader timestamps

by_source_timestamp: order is determined by DataWriter timestamps

QoS Policies: Data Availability Durability: determines is/how instances of a topic are

saved Volatile: no instance history saved Transient: history saved in local memory Persistent: history saved in permanent storage

History: specifies the behaviour when the value of a sample changes before it can be successfully communicated to one or more subscribers

Keep_last: keep “depth” samples at any one time Keep_all: keep each sample

Resource Limits: specifies the resources that the service can consume in order to meet the requested QoS

QoS Policies: Timeliness Deadline: a DataReader expects a new update at least

once every deadline period

Time-based Filter: Filter that allows a DataReader to specify that it is interested only in a subset of he values of the data. DataReader does not want to receive more than one value each minimum_separation period

Latency Budget: specifies the maximum acceptable delay from the time the data is written until the data is inserted in the receiver’s application cache and the receiver application is notified of the fact

DCPS Discovery Automatic Discovery Service:

Necessary in order to find new participants to distributed system Pluggable Discovery:

Discovery Protocols can be implemented using plugin-like modules

Currently there is only a module: Simple Discovery Procotol (SDP) Periodically Polling of a pre-configured list of locators Preconfigured-list can be automatically extended with new locators from newly discovered

Participants

RTI DDS Real-Time Innovations, Inc. provides RTI DDS a COTS

implementation of DDS, consulting and Training Services.

RTI DDS implements full RTPS and full DCPS, partially the DLRL layer.

Embedded threads to handle communication, reliability, QoS etc

RTI DDS Testing We implemented test applications using RTI DDS that can

compute RTT (min, max, avg, std dev) compute Loss Rate compute Throughput

The analysis is realized leveraging the PlanetLab testing facility.

Network of machines dedicated to distributed protocol testing and early deployment.

Worldwide deployment » real WAN setting.

Test Scenarios National Scenario

1 Publisher, 2 Subscribers Nodes belong to same Nation

European Scenario 1 Publisher, 20 Subscribers Nodes belong to Europe

Fragmentation Impact In a heterogeneous setting event routing is demanded to a

simple point-to-point UDP- based communication primitive. Large events are fragmented. Fragmentation adversely impacts performance.

Fragmentation Impact Fragmentation also impacts performance for reliable

communication. Large events » more fragments More fragments » strong loss rate Strong loss rate » large latency

System size impact The point-to-point communication primitive hampers

scalability with respect to the number of subscribers.

Impact of heterogeneous nodes Subscribers with different available resources

(computational and network) are treated in the same way by the middleware.

Heterogeneity has a negative impact on performance with reliable event dissemination.

Rules of thumb for system designers Limit total event size:

Event fragmentation at the transport level leads to loss of events (best-effort) and large latency (reliable).

With small events the middleware shows a stable and predictable behaviour.

Limit the number of subscribers: Latency grows almost linearly with the number of subscribers.

Use nodes with homogeneous resources: Global system performance are limited by the slowest node.

Monitor continuously system performance: The heterogeneous and dynamic setting can vary its characteristics

over time. System configuration must be periodically adapted to the new

environmental conditions.

DLRL Provides “Local Object Caches” built from the Global Data

Space. Objects manipulated with a “natural” language binding

Inheritance, Object Graphs, supported as language objects Actions on local objects cause updates to DCPS Global Data QoS contracts still available via underlying DCPS

Programming RTI DDS We want to create Publisher and Subscriber of a RTI DDS

application

We have to Define the Data Structures Generate a basic code Create an istance of DDSDomainParticipantFactory Configure DDSDomainParticipantFactory Default QoS Create a DDSDomainParticipant Register Data Type (IDL) Create Topic_Send and Topic_Reply Create a Publisher and a Subscriber Create a DataWriter and a DataReader

Data Structures Create a file called dds_testing.idl

struct test_packet {

string<128> updated_by;

long sequence_number;

long subscriber_id;

long ts_snd_sec;

long ts_snd_usec;

sequence<octet, MAX_DATA_LENGTH> data;

Generate the Code Invoke rtiddsgen

rtiddsgen –language C++ –example <arch> dds_testing.idl

rtiddsgen generates all the code you need to run a basic distributed publish-subscribe application using the dds_testing data type.

dds_testing.cxx, dds_testing.h dds_testing_publisher.cxx dds_testing_subscriber.cxx dds_testingPlugin.cxx, dds_testingPlugin.h dds_testingSupport.cxx, dds_testingSupport.h

rtiddsgen also creates a makefile, or a workspace and project files, depending on your architecture

Implementing DDS Entities Creating an istance of DDSDomainParticipantFactory

DDSDomainParticipant *participant = NULL;

DDSDomainParticipantFactory* factory = NULL;

DDS_DomainParticipantFactoryQos factory_qos;

DDS_DomainParticipantQos participant_qos;

DDS_ReturnCode_t retcode;

// DomainParticipantFactory

factory = DDSDomainParticipantFactory::get_instance();

if (factory == NULL) {

printf("***Error: failed to get the domain participant factory\n");

shutdown(participant);

exit(-1);

Implementing DDS Entities Configuring Factory Default QoS

if (factory->get_qos(factory_qos) != DDS_RETCODE_OK) {

printf("***Error: failed to get domain participant factory qos\n");

exit(-1);

factory_qos.entity_factory.autoenable_created_entities = DDS_BOOLEAN_FALSE;

if (factory->set_qos(factory_qos) != DDS_RETCODE_OK) {

printf("***Error: failed to set domain participant factory qos\n");

exit(-1);

Implementing DDS Entities Creating a DDSDomainParticipant

retcode = factory->get_default_participant_qos(participant_qos);

participant = factory->create_participant(domainId, participant_qos, NULL, DDS_STATUS_MASK_NONE);

if (participant == NULL) {

printf("***Error: create participant failed\n");

return -1;

printf("create_participant done\n");

Implementing DDS Entities Topics have to be created before DataReaders and DataWriters.

DDSTopic *topic = NULL;

type_name = test_packetTypeSupport::get_type_name();

retcode = test_packetTypeSupport::register_type(participant, type_name);

participant->get_default_topic_qos(topic_qos);

char* temp = (char*)calloc(128, sizeof(char));

sprintf(temp,"%s %s",”Topic",topicSon);

topic = participant->create_topic(temp, type_name, topic_qos, NULL, DDS_STATUS_MASK_NONE);

if (topic == NULL) {

printf("***Error: create send topic failed\n");

return -1;

Implementing DDS Entities Creating a Publisher(in dds_testing_publisher.cxx)

DDSPublisher *publisher = NULL;

publisher = participant->create_publisher(

DDS_PUBLISHER_QOS_DEFAULT, NULL, DDS_STATUS_MASK_NONE);

if (publisher == NULL) {

printf("***Error: create_publisher failed\n");

return -1;

printf("create_publisher done\n");

Implementing DDS Entities Creating a DataWriter

DDSDataWriter *writer = NULL;

retcode = publisher->get_default_datawriter_qos(writer_qos);

writer = publisher->create_datawriter(

topic_send, writer_qos, NULL, DDS_STATUS_MASK_NONE);

if (writer == NULL) {

printf("***Error: create_datawriter failed\n");

return -1;

printf("create_datawriter done\n");

Implementing DDS Entities Casting a generic DDSDataWriter pointer to a

FooDataWriter pointer

test_packet_writer = test_packetDataWriter::narrow(writer);

if (test_packet_writer == NULL) {

printf("***Error: DataWriter narrow failed\n");

return -1;

printf("DataWriter narrow done\n");

Implementing DDS Entities Creating a Subscriber(in dds_testing_subscriber.cxx)

DDSSubscriber *subscriber = NULL;

subscriber = participant->create_subscriber(

DDS_SUBSCRIBER_QOS_DEFAULT, NULL, DDS_STATUS_MASK_NONE);

if (subscriber == NULL) {

printf("***Error: create_subscriber failed\n");

return -1;

printf("create_subscriber done\n");

Implementing DDS Entities Creating a DataReader

DDSDataReader *reader = NULL;

retcode = subscriber->get_default_datareader_qos(reader_qos);

reader = subscriber->create_datareader(topic_reply, reader_qos, reader_listener, DDS_STATUS_MASK_ALL);

if (reader == NULL) {

printf("***Error: create_datareader failed\n");

delete reader_listener;

return -1;

printf("create_datareader done\n");

Implementing DDS Entities Finally we enable the Participant(in both files)

retcode = participant->enable();

if(retcode != DDS_RETCODE_OK){

printf("***Error: failed in enabling participant\n");

return -1;

printf("participant enabled\n");

Configuring DDS QoS Policies QoS policies can be configured in several DDS Entities(some of

them can be RTI proprietary extensions of OMG DDS Standard)

DDSParticipant TRANSPORT_BUILTIN

Topic RELIABILITY, OWNERSHIP, RESOURCE_LIMITS, etc…

Publisher and Subscriber ASYNCHRONOUS_PUBBLISHER, etc…

DataWriter and DataReader RELIABILITY, OWNERSHIP, RESOURCE_LIMITS, etc…

Pay Attention! QoS policies have to defined before creating the corresponding

object Incompatible QoS couldn’t be notified by RTI DDS!

QoS Policies: Data Delivery Reliability: indicates the level of reliability

requested/offered by the service Reliable Best-Effort

Ownership: specifies whether more than one DataWriter can update the same instance of a Data Object

Shared: all DataWriters can update the same data instance Exclusive: only highest-strength DataWriter can update the data

instance Liveliness: used to define mechanism used to determine

status of Entity Automatic: Infrastructure-Managed Manual: Application-Managed

QoS Policies: Data Delivery Destination Order: controls logical order among changes

by_reception_timestamp: order is determined by DataReader timestamps

by_source_timestamp: order is determined by DataWriter timestamps

QoS Policies: Data Delivery We define a Topic reliable

DDS_TopicQos topic_qos;

participant->get_default_topic_qos(topic_qos);

topic_qos.reliability.kind = DDS_RELIABLE_RELIABILITY_QOS;

Now we can create the topic using

topic = participant->create_topic(temp, type_name, topic_qos, NULL, DDS_STATUS_MASK_NONE);

QoS Policies: Data Delivery We can copy QoS policies from a Topic in a

DataWriter(DataReader) object

DDS_DataWriterQos writer_qos;

retcode = publisher->get_default_datawriter_qos(writer_qos);

f(retcode != DDS_RETCODE_OK){

printf("***Error: getting datawriter default QoS failed\n");

return -1;

publisher->copy_from_topic_qos(writer_qos, topic_qos);

QoS Policies: Data Availability Durability: determines is/how instances of a topic are

saved Volatile: no instance history saved Transient: history saved in local memory Persistent: history saved in permanent storage

History: specifies the behaviour when the value of a sample changes before it can be successfully communicated to one or more subscribers

Keep_last: keep “depth” samples at any one time Keep_all: keep each sample

Resource Limits: specifies the resources that the service can consume in order to meet the requested QoS

QoS Policies: Data Availability A selection between Reliability and History policies

if(ReliableSend==0){

//BEST EFFORT TOPIC

topic_qos.reliability.kind = DDS_BEST_EFFORT_RELIABILITY_QOS;

}else{

//RELIABLE TOPIC

topic_qos.reliability.kind = DDS_RELIABLE_RELIABILITY_QOS;

if(StrictReliableSend==1){

//history

topic_qos.history.kind = DDS_KEEP_ALL_HISTORY_QOS;

//Durability Transient Local

topic_qos.durability.kind = DDS_TRANSIENT_LOCAL_DURABILITY_QOS;

QoS Policies: Data Availability Resource Limits policies are tipically defined in

DataWriter/DataReader

DDS_DataReaderQos reader_qos;

retcode = subscriber->get_default_datareader_qos(reader_qos);

if(retcode != DDS_RETCODE_OK){

printf("***Error: getting datareader default QoS failed\n");

return -1;

subscriber->copy_from_topic_qos(reader_qos, topic_qos);

reader_qos.reader_resource_limits.max_samples_per_remote_writer = readerQueue;

QoS Policies: Timeliness Deadline: a DataReader expects a new update at least

once every deadline period

Time-based Filter: Filter that allows a DataReader to specify that it is interested only in a subset of he values of the data. DataReader does not want to receive more than one value each minimum_separation period

Latency Budget: specifies the maximum acceptable delay from the time the data is written until the data is inserted in the receiver’s application cache and the receiver application is notified of the fact

QoS Policies: Timeliness An example of timeliness is deadline

topic_qos.deadline.period = deadline_period;

It can be defined also for DataWriter/DataReader

writer_qos.deadline.period.sec = deadline;

writer_qos.deadline.period.nanosec = 0;

Sending Data Sending Data involves three basic step:

Create an instance of Data Sample

Fill empty data fields in Data Sample

Write the instance

instance = test_packetTypeSupport::create_data();

instance->sequence_number = count;

gettimeofday(&timestamp_snd, NULL);

instance->ts_snd_sec = timestamp_snd.tv_sec;

instance->ts_snd_usec = timestamp_snd.tv_usec;

Sending Data Create an instance of Data Sample

instance = test_packetTypeSupport::create_data();

Fill empty data fields in Data Sample

instance->sequence_number = count;

gettimeofday(&timestamp_snd, NULL);

instance->ts_snd_sec = timestamp_snd.tv_sec;

instance->ts_snd_usec = timestamp_snd.tv_usec;

Sending Data Fill an octet field with an octet size smaller than the

MAX_DATA_LENGTH for the DDS packet, as defined in IDL

if(size<MAX_DATA_LENGTH){

data_buffer = (DDS_Octet *)calloc(MAX_DATA_LENGTH, sizeof(DDS_Octet));

instance->data.maximum(0);

instance->data.loan_contiguous(data_buffer, MAX_DATA_LENGTH, MAX_DATA_LENGTH);

instance->data.ensure_length(size, MAX_DATA_LENGTH);

Sending Data Otherwise…

if(size >= MAX_DATA_LENGTH){

data_buffer = (DDS_Octet *)calloc(MAX_DATA_LENGTH, sizeof(DDS_Octet));

instance->data.maximum(0);

instance->data.loan_contiguous(data_buffer, MAX_DATA_LENGTH, MAX_DATA_LENGTH);

instance->data.ensure_length(MAX_DATA_LENGTH, MAX_DATA_LENGTH);

Sending Data Writing the Data Sample

retcode = test_packet_writer->write(*instance, instance_handle);

Finally we delete Data loaded in the Data Sample

if(data_buffer!=NULL){

free(data_buffer);

instance->data.unloan();

/* Delete data sample */

retcode = test_packetTypeSupport::delete_data(instance);

Retrieving Data There are three ways to receive data

Manually polling for data by explicitly calling a DataReader’s read() or take() method

Asynchronous notification by mean of Listener

RTI Data Distribution Service will invoke the Listener’s callback routine when there is new data. Within the callback routine, user code can access the data by calling read() or take() on the DataReader.

Using Conditions and WaitSet by mean of wait() method

Application’s thread is blocked until the criteria (such as the arrival of samples, or a specific status) set in the Condition becomes true then the application resumes and can access the data with read() or take().

Retrieving Data: Listener Install a Listener on the DataReader or Subscriber

Create a DDSDataReaderListener for the DataReader (or a DDSSubscriberListener for Subscriber)

Creating a DDSDataReaderListener with the on_data_available() callback enabled: on_data_available() will be called when new data arrives for that DataReader.

Creating a DDSSubscriberListener with the on_data_on_readers() callback enabled: on_data_on_readers() will be called when data arrives for any DataReader created by the Subscriber.

Only 1 Listener will be called back when new data arrives for a DataReader. The on_data_on_readers() operation takes precedence over the on_data_available() operation.

In the following we show how it is possible to implement a DDSDataReaderListener with the on_data_available() callback enabled.

Retrieving Data: Listener Create a DDSDataReaderListener deriving a Listener class

from those base classes.

class test_packetListener : public DDSDataReaderListener {

public:

virtual void on_requested_deadline_missed(…) {}

virtual void on_sample_rejected(…) {}

virtual void on_liveliness_changed(…) {}

virtual void on_sample_lost(…) {}

virtual void on_subscription_matched(DDSDataReader*,const DDS_SubscriptionMatchedStatus&);

virtual void on_data_available(DDSDataReader* reader);

virtual void on_requested_incompatible_qos(DDSDataReader* /*reader*/, const DDS_RequestedIncompatibleQosStatus& /*status*/);

Retrieving Data: Listener Now we are implementing virtual procedures

on_data_available

void test_packetListener::on_data_available(DDSDataReader* reader) {

struct DDS_Duration_t retry = {0, 10*1000*1000};

pthread_t t_id;

if(pthread_create(&t_id, NULL, on_data_available_thread, reader) != 0){

printf("***Error: Cannot create a new thread for receiving data\n");

NDDSUtility::sleep(retry);

Retrieving Data: Listener Now we are implementing virtual procedures

on_subscription_matched on_requested_incompatible_qos

void test_packetListener::on_subscription_matched(DDSDataReader* reader, const DDS_SubscriptionMatchedStatus& sub_status){

printf("***subscriber found\n");

if(sem_signal(semaphore_id)==-1){

printf("***Error: failed in calling signal on semaphore of key %d\n", sem_key);

void test_packetListener::on_requested_incompatible_qos(DDSDataReader* reader, const DDS_RequestedIncompatibleQosStatus& sub_status){

printf("***Error: incompatible QoS settings between domain participants... Check the usage of -reliable and -strict options\n");

Retrieving Data: Listener Install the Listener on the DataReader

/* Create data reader listener */

reader_listener = new test_packetListener();

if (reader_listener == NULL) {

printf("***Error: listener instantiation failed\n");

return -1;

/* Create a data reader with the just created listener*/

reader = subscriber->create_datareader(topic_reply, reader_qos, reader_listener, DDS_STATUS_MASK_ALL);

1 middleware infrastructures for application integration prof. roberto baldoni dr. roberto beraldi...

web services slide

interoperability slide

sapienza slide

behaviour slide

service stub web server

x b slide

methods service

server web server http

Documents

dr roberto shimabuku azato

dr. roberto aguiar

curricilum dr. ceravolo roberto

seguridadinformárica snort -...

dr. roberto cacchione radioinmunoterapia€¦ · recuento...

dr. roberto meli piralla

primario desconocido r1mi dr roberto garcia

professor dr. paulo roberto gomes luzzardi

jmédico 116 dr. roberto misici · 2020. 6. 25. · revista...

comandos sistema operativo linux · sistemas operativos...

tiroides en ecografia. dr. alessandri roberto

informe auditoria social hospital dr. roberto …

prof. dr. roberto kochen director técnico

dr. josé roberto martínez abarca

seguridad en redes...

lcbm: statistics-based parallel collaborative …...lcbm:...

dermatite seborreica - dr. carlos roberto antônio

cv dr roberto cassis

dr. roberto tapia conyer - gob.mx

shell scripting en linux -...