1 Middleware Infrastructures for Application Integration Prof. Roberto Baldoni Dr. Roberto Beraldi...
-
date post
19-Dec-2015 -
Category
Documents
-
view
228 -
download
2
Transcript of 1 Middleware Infrastructures for Application Integration Prof. Roberto Baldoni Dr. Roberto Beraldi...
1
Middleware Infrastructures for Application Integration
Prof. Roberto Baldoni Dr. Roberto Beraldi
Dr Giorgia LodiDr Leonardo Querzoni
Dr Sirio Scipioni
Università di Roma “La Sapienza”
2
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)
3
SOA and Web Services
4
Positioning SOA (cont)
Architectural model
Data Oriented
Distributedapplication
Computation Oriented
CommunicationOriented
•Pub/sub•Tuple space•...
•Procedures •Objects •Services
•Message Oriented Middleware•JMS•...
5
Data Oriented
Positioning SOA
Coupled Not coupled
Coupled
Not coupled
Time
Reference
Computation Oriented
Communication Oriented
Tuple space
MOM
Pub/Sub
· RPC· RMI· RSI
RPC = Remote Procedure CallRMI = Remote Method InvocationRSI = Remote Service Invocation
6
SOA Model
Directory
Service provider
Service consumer
Invoke services
Look up
publish
7
Computation oriented paradigms
Procedures RPC (Remote Procedure Call)
Objects RMI (Remote Method Invocation)
Services RSI (Remote Service Invocation)
8
Remote Procedure Call
Client
Calling procedure
Stub
Server
Called procedure
Skeleton
Network
parametersresult
Request message Reply message
parameters result
9
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
10
Remote Service Invocation
Client
Calling Service
Stub
Web Server
Called Service
Skeleton
Network
parametersresult
Request message (XML, SOAP,HTTP) Reply message
parameters result
WSDL
generate
publication
WSDL = Web Service Definition Language
11
Interoperabilty
X
A:X
A
B:X
DC C:X D:X
B
12
Java WSDL C#
Interoperability (example)
Common standards Different implementations, same behaviour
13
Introduction to Web Services (1/4)
Distributed applications are largely built around the client/sever paradigm
CLIENT SERVER
Request
Reply
14
Introduction to Web Services (2/4)
Server
Client
Client
invocation
result
Serverinvocation
result
Process:Key:
Computer:
15
Introduction to Web Services (3/4)
Client (web browser), Server (web server) HTTP implements a simple request/reply
protocol GET
Request: url; reply: data POST
Request:url+data, reply: status... ...
16
Introduction to Web Services (4/4)
HTTP methods are fixed in number They represent the interface through which
clients interact with the server..
CLIENT SERVER
request
reply
Interface
17
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
18
Definition (W3C) ‘Web services provide a standard means of
interoperating between different software applications, running on a variety of platforms and/or frameworks.’
19
WS Architecture
ServiceProvider
ServiceRequester
Registry(UDDI)
SOAP
WSDL (publication)WSDL (discover)
SOAP: Simple Object Access ProtocolWSDL: Web Service Definition LanguageUDDI: Universal Discovery, Description, Integration
20
Technologies of WS
Messages
SOAP
Extensions(transaction, Reliability..)
Descriptions(WSDL)
ProcessesDiscovery,Choreography,..
Bas
e T
ech
nol
ogie
s :
XM
L,S
chem
e
Sec
uri
ty
Man
agem
ent
Communications(HTTP,SMTP,FTP,JMS,IIOP,...)
21
XML Derived from SGML (Standard Generalized
Markup Language) Markup
HTML: how to represent a data <i> ... </i> i = italic
XML: information about the type + structure of the data
22
An example
23
Elements <name> Smith</name>
Closing tag Data Open tag
24
Attributes
<person id=“123”>
<name> Smith</name>
</person>
25
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>
26
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>
27
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
28
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>
29
Valid docuements A valid document is a Well Formed
Document that satisfies a scheme
Document
Scheme
30
Example
<person pers:id=“123” xmlns:pers=“http//...”>
<pers:name> </pers:name>
<pers:place> </pers:place>
<pers:year> </pers:year>
</person>
31
SOAP
envelope
header
body
header element
body element
header element
body element
32
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
World
33
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
Hello
34
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>
So
ap
me
ssa
ge
HT
TP
h
ead
er
35
WSDL
abstract concrete
how where
definitions
types
target namespace
interface bindings servicesmessage
document stylerequest-reply style
36
Message exchange patterns
Name
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
37
WS Combination (choreography)
hotel bookinga
Travel Agent
flight booking
a
hire car bookingaService
Client
flight bookingb
hotel bookingbhire car bookingb
From Coulouris, Dollimore and Kindberg, “Distributed Systems: Concepts and Design”
38
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
39
WS implementation in J2EE
Client tier
J2EE Server
Data tier
Legacysystem
EIS
DB
Web tier
Business tier
40
Framework model
Components
CONTAINER
41
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
1 2
345
42
Web services API JAX-RPC (old)
SOAP,HTTP1.1,WSDL JAX-WS (new)
Annotation mechanism
43
Java 2 Enterprise Edition (J2EE)
44
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
45
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
46
Distributed Multi-tiered Applications
Application Client
Browser
DB DB
Client tier
JSP/Servlet
Web tier
Business tier
EIS tier
Enterprise Beans
Enterprise Beans
Client machine
J2EE Server machine
Database Server machine
47
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
48
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
49
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
50
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
51
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
52
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>”);
53
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
54
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
55
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 {
…………}
}
56
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)
57
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
58
JSP Example
<html><head>
<title> My JSP Example </title></head><body>
JSP Hello word<br><br><%! public String writeThisTest() {
String testToWrite=“Hello Guys!!”;return testToWrite;
}%><br><%= writeThisTest() %>
</body></html>
59
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
60
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
61
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)
62
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
63
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 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> …
64
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
65
J2EE middleware services
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
66
J2EE middleware services
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
67
J2EE middleware services
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
68
J2EE middleware services
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)
69
J2EE middleware services
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)
70
J2EE overall architecture
J2SE
BrowserBrowser
…
J2EE Server
DBDB
DBDB ApplicationApplication
ClientClient
Application client
container
JAX-RPC
SAAJ JMX
JNDIJAXR
JMS
Web Srvcs
JDBC
RMIRMI
HTTPHTTP
HTTPSHTTPS
Web ContainerJSPJSPServletServlet
J2SE
……
JCA
JTA
JNDI
Java MAIL
SBSBEBEBEBEB
EJB Container
J2SE
SBSB
MDBMDB
……
JCA
JTA
JNDI
Java MAIL
RMIRMI
71
J2EE application example
customer
HTTP
HTTPS
J2EE Server
Web tier [Servlets/JSPs]
Business tier [EJBs]
browse
select
purchase
DBDB
catalog
Shopping cart
JDBC
Book order
Java Mail
Mail server
secure
72
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 …
73
Enterprise Java Beans (EJBs)
version 2.1
74
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
75
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
76
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)
77
Remote Interface example
import javax.ejb.*;import java.rmi.RemoteException;import java.rmi.Remote;
public interface myFirstRemoteInterface extends EJBObject {
public … businessMethod1() throws RemoteException; … …
}
78
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;…
}
79
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
80
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
}
81
EJB architecture
ClientClientJ2EE J2EE serverserver
EJB EJB ContainerContainer
HomeHomeStubStubHomeHomeStubStub
ClientClientStubStub
ClientClientStubStub
HomeHomeObjectObjectHomeHomeObjectObject
EJBEJBObjectObjectEJBEJB
ObjectObjectBeanBeanClassClassBeanBeanClassClass
Remote Remote InterfaceInterface
Home InterfaceHome Interface
82
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
83
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
84
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(…); …………
85
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
86
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
87
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
88
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
89
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
Remote Remote InterfaceInterface
Bean poolBean pool
90
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
91
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)
92
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)
93
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)
94
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
95
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
96
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
97
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
98
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
99
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!!
100
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…)
101
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
102
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
103
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 …
104
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
105
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
106
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
107
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
108
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
109
Event-Driven Architectures
110
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.
111
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.
112
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.
113
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
Event
114
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.
115
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.
116
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 …
117
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.
118
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.
119
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.
e2
event2:name= Acme REvalue=18$
event1:name= Acme cablesvalue=23$
e1 e1
e1
120
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.
121
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.
122
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=167
x<18 AND x>10
x=30 OR x>200
x=30
x<>30
x<5
x>10
x>40
x=22
123
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=167
x<18 AND x>10
x=30 OR x>200
x=30
x<>30x<5
x>10
x>40
x=22
124
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>30
x=167
x<18 AND x>10
x=30 OR x>200
x=30
x<>30x<5
x>10
x>40
x=22
125
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=30
x<>30
x<18 AND x>10
x=30 OR x>200
x=167
x>30
x=22
x>40
x>10
x<5
6 x>10
8 x<5
9 ANY
3x>=30 OR (x<18 AND
x>10)
7 x>10
5 ANY
3 ANY
ax>=30 OR (x<18 AND
x>10)
5 ANY
1 -
2 -
bx>=30 OR (x<18 AND
x>10)
3 ANY
e ANY
5 x>10 OR x<5
d ANY
9 x>10 OR x<5
f -
126
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=30
x<>30
x<18 AND x>10
x=30 OR x>200
x=167
x>30
x=22
x>40
x>10
x<5
6 x>10
8 x<5
9 ANY
3x>=30 OR (x<18 AND
x>10)
7 x>10
5 ANY
3 ANY
ax>=30 OR (x<18 AND
x>10)
5 ANY
1 -
2 -
bx>=30 OR (x<18 AND
x>10)
3 ANY
e ANY
5 x>10 OR x<5
d ANY
9 x>10 OR x<5
f -
127
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).
128
Rendez-Vous Routing Phase 1: two nodes issue the same subscription S.
SN(S) = {4,a}
129
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.
130
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)
131
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
132
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
133
DCPS Provides a Global Data Space that is
accessible to all interested application Subscriptions are decoupled from Publications Contracts established by means of QoS
134
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
135
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
136
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
137
DCPS Entities DataReader: Object to read data regarding a particular
Topic. Subscriber: Aggregation of DataReader objects.
Responsible for receiving Data Samples
138
DDS and QoS QoS Contract “Request/Offered”
QoS Request/Offered: Ensure that the compatible QoS parameters are set
Offer must be better than Request
139
DDS and QoS QoS Contract “Request/Offered”
QoS Request/Offered: Ensure that the compatible QoS parameters are set
Offer must be better than Request
140
DDS and QoS QoS Contract “Request/Offered”
QoS Request/Offered: Ensure that the compatible QoS parameters are set
Offer must be better than Requestif QoS are
compatible
Communication Established!
141
DDS and QoS QoS Contract “Request/Offered”
QoS Request/Offered: Ensure that the compatible QoS parameters are set
Offer must be better than Requestif QoS aren’t
compatible
Communication NOT Established!
142
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
143
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
144
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
145
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
146
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
147
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
148
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
149
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
150
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
151
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
152
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
153
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
154
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
155
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
156
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
157
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
158
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
159
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
160
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.
161
Test Scenarios National Scenario
1 Publisher, 2 Subscribers Nodes belong to same Nation
European Scenario 1 Publisher, 20 Subscribers Nodes belong to Europe
162
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.
163
Fragmentation Impact Fragmentation also impacts performance for reliable
communication. Large events » more fragments More fragments » strong loss rate Strong loss rate » large latency
164
System size impact The point-to-point communication primitive hampers
scalability with respect to the number of subscribers.
165
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.
166
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.
167
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
168
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
169
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;
};
170
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-sub- scribe 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
171
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);
}
172
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");
shutdown(participant);
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");
shutdown(participant);
exit(-1);
}
173
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");
shutdown(participant);
return -1;
}
printf("create_participant done\n");
174
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");
shutdown(participant);
return -1;
}
175
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");
shutdown(participant);
return -1;
}
printf("create_publisher done\n");
176
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");
shutdown(participant);
return -1;
}
printf("create_datawriter done\n");
177
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");
shutdown(participant);
return -1;
}
printf("DataWriter narrow done\n");
178
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");
shutdown(participant);
return -1;
}
printf("create_subscriber done\n");
179
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");
shutdown(participant);
delete reader_listener;
return -1;
}
printf("create_datareader done\n");
180
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");
shutdown(participant);
return -1;
}
printf("participant enabled\n");
181
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!
182
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
183
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
184
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);
185
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");
shutdown(participant);
return -1;
}
publisher->copy_from_topic_qos(writer_qos, topic_qos);
186
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
187
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;
188
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");
shutdown(participant);
return -1;
}
subscriber->copy_from_topic_qos(reader_qos, topic_qos);
reader_qos.reader_resource_limits.max_samples_per_remote_writer = readerQueue;
189
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
190
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;
191
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(×tamp_snd, NULL);
instance->ts_snd_sec = timestamp_snd.tv_sec;
instance->ts_snd_usec = timestamp_snd.tv_usec;
192
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(×tamp_snd, NULL);
instance->ts_snd_sec = timestamp_snd.tv_sec;
instance->ts_snd_usec = timestamp_snd.tv_usec;
193
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);
}
194
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);
}
195
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);
196
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().
197
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.
198
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*/);
};
199
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);
}
}
200
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");
}
201
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");
shutdown(participant);
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);