1. Service Oriented Architectures in Heterogeneous Environments
Yarema Mazuryk
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

2. Context – Connected HomeG G
Currently at home we have lots of software intensive devices. The trend is such, that eventually all these devices will become connected to the network, and we, certainly would like to benefit from it by, say, having applications in which several devices are collaborating. The challenge is that the devices may use different types of physical media, thus making the development of the mentioned applications extremely difficult. So, primarily, we would like to answer the question if there is a model (abstraction level) in which all devices look the same, disregarding their HW and SW platforms, types of network connection. This model has to take into account the nature of the home network, which can be described by following:
Wireless LAN
Firewire (IEEE1394)
Bluetooth
Ethernet
Powerline
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

3. Connected Home Client Mobility Heterogeneous Network Ad Hoc Network
First of all, the heterogenity of the home network – different devices might use different physical media.
Second of all, mobility of the clients – the clients may roam all over the environment, they can join and leave te network frequently, and that cannot be predicted, which leads us to the third property – the home networks are typicall ad hoc networks, which are not persistant in time, but are formed by the devices that are in environment and are able to communicate between each other
Ad Hoc Network
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

4. Key Aspects Transparent control Advanced interaction
Self organizing networks
Minimal (zero)
configuration
The PROGRESS workshop on domestic appliances defined a set of the research directions, which are interested to the industry as well:
Self organizing networks –
Privacy –
Embedded intelligence –
Transparent control –
Open communication protocols –
Minimal configuration of the systems –
Advanced interaction issues – (input and output part)
We think that the service oriented architectures is a framework, which can help addressing these issues. So what is the service orientation, and where do we see it’s place in the embedded Internet?
Privacy
Open protocols
Embedded intelligence
Transparent control
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

5. Service Oriented Architecture - Place
Client1
Service1
Application
Client
API
Service
API
Client
API
Service
API
Middleware
Service Oriented
Platform
Service Oriented
Platform
Transport
Transport
Open protocol
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

6. Service Oriented Architecture – Addressed Issues
Reusability
Maintainability
Scalability
Functional
Incrementalism
Agility
Interoperability
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

7. Service Oriented Architecture – Conceptual Model
+name
Service
Description
Service Advertisement
Service
Implementation
Service
Advertisement
provides
+address
+address
uses
retrieves
Service
Discovery
Service
User
Eventing,
Control
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

8. Service Description Example (UPnP)
<actionList>
<action> <!-- are we playing now? -->
<name>GetPlayMode</name>
<argumentList>
<argument>
<name>Mode</name>
<relatedStateVariable>PlayMode</relatedStateVariable>
<direction>out</direction>
<retval />
</argument>
</argumentList>
</action>
</actionList>
<serviceStateTable>
<stateVariable sendEvents="yes">
<name>PlayMode</name>
<dataType>string</dataType>
<allowedValueList>
<allowedValue>PLAY</allowedValue>
<allowedValue>PAUSE</allowedValue>
<allowedValue>STOP</allowedValue>
</allowedValueList>
</serviceStateTable>
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

9. SOA – “Publish-Find-Bind-Execute” Model1
Publish
Network
Provider
Find 2
Consumer
Contract 3
Bind 4
Execute
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

10. SOA vs Component Based Development
Central -
Networking environment
Message
based
API
based
Communication model
Coarse-
grained
Fine-
grained
Interfaces
Single &
active As
needed
Instantiation
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

11. Addressing & Naming Uniform addressing scheme
Independent from physical network addressing
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

12. Discovery - GOALS Locate the service provider
Retrieve provider’s access interface
Acquire additional information
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

13. Discovery - METHODS 16-Apr-17 Service Discovery Pre-configured
Non- configured
Location aware
Mediated
Immediate
Non-transparent
Transparent
Active
Passive
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

14. Advertisement Publish information about the service implementation
Provider’s location
Service Description
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

15. Eventing & Control Provider Event B execute action A,
subscribe to event B
Consumer
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

16. Existing Approaches Can we base on one of these
UPnP - IP-bound, has scalability problems
JXTA - Network independent, existing implementation has
performance problems
Pastry Focuses on efficient request routing
Web services - IP-bound
Can we base on one of these
or do we need something new?
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

17. What is JXTA? 16-Apr-17 *borrowed from www.jxta.org
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

18. JXTA Vision promote communication (not isolation) among applications
keep the core small and elegant
support multiple platforms and languages, micro devices to servers
address security from the beginning
JXTA is an open source project
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

19. JXTA Architecture 16-Apr-17 Y. Mazuryk, y.mazuryk@tue.nl
TU/e Informatica, System Architecture and Networking

20. JXTA – Set of XML-based Protocols
Peer Discovery Protocol—Enables peers to discover peer services on the network
Peer Resolver Protocol—Allows peers to send and process generic
requests
Rendezvous Protocol—Handles the details of propagating messages between peers
Peer Information Protocol—Provides peers with a way to obtain status information from other peers on the network
Pipe Binding Protocol—Provides a mechanism to bind a virtual communication channel to a peer endpoint
Endpoint Routing Protocol—Provides a set of messages used to
enable message routing from a source peer to a destination peer
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

21. JXTA – Key Concepts Peer Peer Peer Rdv Peer Peer Relay Peer Peer Group
Pipe
Peer
Peer
Rdv
Peer
Peer
Relay
Peer
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

22. Performance (discovery latency, memory usage, ...)
Case Study
Distributed Data Storage in Service-Oriented Fashion
JXTA
UPnP
...
ANALYZE & COMPARE:
Performance (discovery latency, memory usage, ...)
Scalability
Ad hoc networking
Client mobility
...
PROPOSE: Service Oriented Framework
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

23. Future Work Accommodate real-time requirements in SOA
Investigate security aspects
Interaction with the user
Interaction between services
Group services
Mobile services
...
16-Apr-17
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

24. 16-Apr-17 Y. Mazuryk, y.mazuryk@tue.nl
TU/e Informatica, System Architecture and Networking