1. Service Oriented Architectures in Heterogeneous Environments
Yarema Mazuryk
28-Nov-18
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

2. About Me
1994 – 1999 M.Sc. in Computer Science , National University “Lviv Polytechnics”, Lviv, Ukraine
1998 – 2001 engineer at mobile telecom operator, Lviv, Ukraine
2001 – 2003 trainee at Software Technology (OOTI) program at TU Eindhoven
joined EES.5413 project as a jr. researcher
28-Nov-18
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

3. 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
28-Nov-18
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
28-Nov-18
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
Traditionally the networked system can be described by a layered architecture with following layers: application – providing functionality to the user, middleware (interoperability layer) – providing abstraction from the network transport to the applications, and transport layer, which in fact, enables information exchange between the devices. The place, where we do need service orientation is mostly in the middleware. Having such a platform built on top of the transport layer, we, in the application layer, would be abstracted from the uninteresting details of the networking by two kinds of APIs – Service API, which will allow us to build network services, and Client API, which would facilitate development of applications which will employ available network services. For example, we have Client on one device, and Service on another. The Client is using the Client API to request a service to perform some functionality, the service oriented platform, using a open communication protocol, transparently to the application is routing the request to the service, which is located on another peer in the network. The real challenge in system architecting is in accommodating the non-functional requirements to the software system. What non functional requirements can be addressed by the SOA?
Open protocol
28-Nov-18
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

6. Service Oriented Architecture – Addressed Issues
Reusability
Maintainability
Scalability
Functional
Incrementalism
Last decade the focus of architecting was on scalability, reusability, and, latter, maintainability of the system. System, built on top of the SOA is loosely coupled, which facilitates those three -abilities. However, there is more than that. The one of the main issues addressed by SO approach is interoperability. Interoperability on different levels – interoperability between different software platforms, interoperability between different hardware platforms, and interoperability on the implementation language level. Service Oriented system is an ultimately interoperable system. Besides, we have agility – characterising the system as the one, which is light, and faciitiates ease of movement – the ability to quickly change the systems functionality.
Functional incrementatlism – the ability to add functions to the system in increments. Lets take a closer look at the service oriented framework.
Agility
Interoperability
28-Nov-18
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

7. Service Oriented Architecture – Conceptual Model
Addressing and Naming
+name
Service
Description
Service Advertisement
Service
Implementation
Service
Advertisement
provides
+address
+address
uses
retrieves
So, obviously the model is based on the notion of service, which, in fact, describes some behaviour (functionality), which it’s implementation can provide. The service is described by a service description, which is language independent. For, example, XML-like specification. The service is implemented by a service provider (or implementation), which, in turn is being used by a service user (consumer). As I mentioned before, the system is loosely coupled, that means that there is neither service user knows anything about the service provider in advance, nor service provider has any information about it’s clients. So, the parties have to get acquainted with each other somehow. In order to do that, Service Implementation provides a so-called service Advertisement, which contains the description of the service that is being provided by the specific provider, and the address of the provider itself. The service user retrieves this advertisement, and based on the service description and using the given address is employing the service provider. So, in that model we can highlight following important aspects, that are essential for a service oriented system:
Addressing and naming of the services, service providers and service users – in order to facilitate communications between them.
Service advertisement – how the services make themselves known to the potential clients.
Service discovery – how the service users find out information about the services and where they can be found on the network.
Eventing and control – how the interaction between the service providers and users is going. I will try to look into all of these issues in more details. But first in order to make thiungs more clear, I would like to look at the example service description.
Service
Discovery
Service
User
Eventing,
Control
28-Nov-18
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

8. SOA – “Publish-Find-Bind-Execute” Model1
Publish
Network
Provider
Find 2
Consumer
We have a provider and a consumer in the network. Provider publish information about itself to the network. Consumer finds published information about the relevant provider, and only then the binding between provider and consumer goes – according to the contract (service description + subscription to events). Only after that the consumer requests to perform certain action from the provider. You may say, that it all looks very similar to the component based software development, and will be right. However, not completely.
Contract 3
Bind 4
Execute
28-Nov-18
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

9. Existing Approaches Can we base on one of these
UPnP
JXTA
Web services …
Currently there is a number of approaches that can be identified as compliant to the SOA description, mentioned before. However, all of them have some deficiencies, with respect to the usage model we have in mind – ad hoc networking in the heterogeneous environment. UPnP is a know approach by Sun and Microsoft, which is conquering the industry currently, however, it doesn’t address security explicitly, has some scalability problems and is assuming availability of the IP network. But the conceptual model of UPnP is close to what we have in mind. On the contrary, JXTA specifications looks as it is not really dependent on the underlying network, but the conceptual model is slightly different, and currently available implementation of JXTA suffers from severe performance issues. The question is –if one of the available frameworks is suitable for home networking, and satisfying the requirements we have. What has to be changed, and how.
Can we base on one of these
or do we need something new?
28-Nov-18
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

10. What is JXTA?
JXTA technology is a set of open protocols that allow any connected device on the network ranging from cell phones and wireless PDAs to PCs and servers to communicate and collaborate in a P2P manner.
JXTA peers create a virtual network where any peer can interact with other peers and resources directly even when some of the peers and resources are behind firewalls and NATs or are on different network transports.
JXTA objectives are:
Interoperability - across different peer-to-peer systems and communities
Platform independence - multiple/diverse languages, systems, and networks
Ubiquity - every device with a digital heartbeat
*borrowed from
28-Nov-18
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

11. JXTA Architecture 28-Nov-18
We can roughly break down a typical P2P software stack into three layers. At the bottom is the core layer that deals
with peer establishment, communication management such as routing, and other low-level “plumbing”. In the middle
is a service layer that deals with higher-level concepts, such as indexing, searching, and file sharing. These services,
which make heavy use of the plumbing features provided by the core, are useful by themselves but also are commonly
included as components in an overall P2P system. At the top is the layer of applications, such as ing, auctioning,
and storage systems. Some features, such as security, manifest in all three layers and throughout a P2P system, albeit
in different forms according to the location in the software architecture.
JXTA technology is designed to provide a layer on top of which services and applications are built. We designed this
layer to be thin and small, yet providing interesting and powerful primitives for use by the services and applications.
We envision this layer to stay thin and small as this is the best approach both to maintaining interoperability among
competitive offerings from various P2P contributors and to providing maximum room for innovation (and profit) by
these contributors.
28-Nov-18
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

12. 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
28-Nov-18
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

13. JXTA File Sharing Application – Simple Architecture …
Browse files
Add, remove files
Retrieve files
ShareApplication
JXTA Libraries
Application
Service
Advertisement
DirectoryService
DirectoryServiceAdvertisement
DirectoryServiceImpl
DirectoryServiceAdv
28-Nov-18
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

14. … complicated Implementation…
4 packages
15 classes (11 only for JXTA functionality)
around 1500 LOC
Way too much for such a small application
28-Nov-18
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

15. … And even more
Around 64% of exchanged data is useless w. r. t. functionality (XML tags)
Migrating to new versions of JXTA is challenging (deprecated APIs, lots of bugs)
Memory requirements – around 30MB (without GUI)
High latency in discovery
28-Nov-18
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

16. Future Work Service Oriented Framework for In-Home Networks:
- interoperability between various middleware standards
(JXTA, UPnP, Webservices, …)
- quality attributes of network services included
- services as building blocks for other services
(scripting language for service composition)
- minimize overhead in network protocols
- transparent mobility of services in the network
28-Nov-18
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking

17.
28-Nov-18
Y. Mazuryk,
TU/e Informatica, System Architecture and Networking