Service Oriented Architecture in RESIST project: TAPAS approach

1
Service Oriented Architecture in RESIST project
TAPAS approach  

• Hernan Vanzetto
• Marcos Da Silveira

2
SOA What?
Service Oriented Architecture expresses a
perspective of software architecture that defines
the use of services to support the requirements
of software users. (Wikipedia)
Services Service Providers Service
Consumers Service Registries Messaging
3
How components interacts?
S-Provider

• The Contract describing the service, its inputs
  and outputs, location, and method of invocation
  is placed in the Registry by the Service Provider
• The Service Consumer locates a Service using the
  specifications found in the services contract
  from a Registry
• Service Consumers use Services provided by a
  Service Provider to perform all or part of some
  business function

S-Consumer
4
How components interacts?

• The Contract describing the service, its inputs
  and outputs, location, and method of invocation
  is placed in the Registry by the Service Provider
• The Service Consumer locates a Service using the
  specifications found in the services contract
  from a Registry
• Service Consumers use Services provided by a
  Service Provider to perform all or part of some
  business function

• All the Services in the world are useless unless
  
• We know what they are named
• We know where to find them
• We know what the expected inputs and outputs are
• We trust them to work as specified in their
  contract

5
Governance

• Be sure that multiple services dont provide the
  same functionality
• Identify the responsible for a given service
• Prioritize and control the execution of services
• Verify if services are conform to standards
• Be sure that contracts respect services
  specification
• Ensure that services are registered and can be
  located by consumers

6
SOA Main properties
Loosing Coupling

• Loosing Coupling
• Coarse-grained
• Avoid Proprietary technology and protocols to
  avoid vendor lock-in
• A well-defined contract from the service
  provider spells out the business and technology
  requirements for using the service (the
  interface) and how to invoke the service

is a long-standing IT term meaning that the
internals of an application or business service
must be able to be changed without impacting
client applications
7
SOA Main properties

• Loosing Coupling
• Coarse-grained
• Avoid Proprietary technology and protocols to
  avoid vendor lock-in
• A well-defined contract from the service
  provider spells out the business and technology
  requirements for using the service (the
  interface) and how to invoke the service

Services are more highly coarse-grained than
typical IT objects and components frequently
services map directly to a business function or
activity Coarse-grained interactions are simpler
and require fewer messages to use the service,
and thus, fewer messages cluttering the system
8
Shift To A Service-Oriented Architecture
From
To

• Function oriented
• Build to last
• Prolonged development cycles

• Coordination oriented
• Build to change
• Incrementally built and deployed

• Application silos
• Tightly coupled
• Object oriented
• Known implementation

• Enterprise solutions
• Loosely coupled
• Message oriented
• Abstraction

Comparing SOA with DOA (Séan Baker and Simon
Dobson)
9
Enterprise Service Bus (ESB)

• The ESB is the backbone of SOA, but it is not SOA
  by itself.
• An ESB is a standards-based integration platform
  combining messaging, web services, data
  transformation, and dynamic routing. ESB is a new
  approach to integration

10
Enterprise Service Bus (ESB)

• The ESB is the backbone of SOA, but it is not SOA
  by itself.
• An ESB is a standards-based integration platform
  combining messaging, web services, data
  transformation, and dynamic routing. ESB is a new
  approach to integration
• Some of the major vendors of ESBs include
• BEA Systems AquaLogic
• IBM WebSphere Message Broker
• Microsoft BizTalk Server
• Oracle SOA Suite
• TIBCO Software Business Works
• Fiorano Software SOA 2006 Platform
• Cape Clear Software ESB
• Software AG Enterprise Service Integrator
• Sonic Software SOA Suite
• Etc.

11
Interoperability Efforts

• Healthcare Service Specification Project
• The Object Management Group (OMG) community
• The Health Level Seven (HL7) community
• The Integrating the Healthcare Enterprise (IHE)
  community
• The Eclipse Open Healthcare Framework community

12
RESIST

• Resist is part of SECOM program Security and
  Efficacy of new practices of electronic COMmerce
  in all socio-economics sectors
• General Objectives
• To identify necessary improvements of informatics
  in medical services.
• To specify and implement an e-health platform
  prototype
• To contribute to solve availability problems
• To offer solutions to personalized and/or remote
  treatments

13
RESISTs Tasks

• Definition of the elements that compose the
  system
• Requirements, market study, etc.
• Definition of the platforms architecture
• Experimental Validation prototype

14
RESIST Platform
Family Doctor
Patient

• Prescription
• Transfer
• Monitoring
• Results

• Consent
• Measure Instruments
• Monitoring Instruments
• Information

Communication Data/information stock Computer
Decision Support Deployment Fault Detection
Identification Services management Capacities
management Security Permissions
management Credential management Policies
management

• Unique patient
• identification
• Master Patient Index

• Prescription
• Transfer
• Monitoring
• Results

Platform
Social Security
Hospital/Specialist
Basic idea
15
Informal Users Services

• Authenticate
• Personal Information Consultation
• Document Transfer
• Consents modifications

Services
Patient
16
Healthcare relationships Services
H-Center
Patients
H-Professional
Patient Administration Clinical Care
Systems Laboratory Systems Imaging
Systems Pharmacies Healthcare Management Facilitie
s Management Attendance Outcomes Test Results
Engagement Assignments Schedules Test Requests
Results Administration Permissions Care Records
Appointments Admissions Discharges Consents Patien
t Journeys
H-Center
Standards of care Funding Performance Audit
Government
17
RESIST Requirements

• Easy exploitation and integration.
• Userfriendly interfaces.
• Service composition.
• Operate in a heterogeneous communication
  environment.
• Using Wire, WiFi, GRPS.
• Unix, Windows or Mac OS
• Manage devices mobility.
• Diverse points of access (hospital, home,
  office).
• Changing of devices interface (Desktop, PDA,
  etc.).
• Monitoring devices and people.
• Resilience
• Manage resources and power limitation.
• Time limitation.
• Data quantity limitation.
• Energy limitation.

18
RESIST Requirements

• Satisfactory reliability and scalability.
• Incorporate services.
• Orchestrate services (sequence, concurrence,
  cooperation, competition, etc.).
• Incorporate and control devices.
• Fault tolerance
• Composed of loose coupling components.
• Independency of Service Execution.
• Well defined contract with a clear description of
  required information and offered service.
• Have a service registration component
• Following factory patterns, the services
  implementation (contract, capabilities, etc.) are
  registered. The status is dynamically
  verified/updated.
• The set of services offered respect pre-defined
  standards (name, reference, QoS, feedback, etc.).
• Have a publication service system where the
  interface is presented.
• The list of services can be public or private.
• The same service can be associated with different
  implementations.
• Each service implementation is unique and
  identified by one (or a set of) property(s).
• The status of the service can be accessed by
  authorized customers.
• Filters can be used to facilitate the search.

19
RESIST Requirements

• Operate synchronously or asynchronously.
• Service can be executed immediately or scheduled
• Results can be accessed in real-time or in
  batches.
• Use standards to implement messages exchange.
• Communication between components/services uses
  messages.
• Have a reasoning engine to connect intelligently
  the services requesters and the service
  providers.
• If the provider is not explicit in the request,
  the system must to have a reasoning engine to
  decide which provider will be chosen. In respect
  to the legacies.
• Manage Security and Safety.
• Identification mechanism (users access)
• Authorization mechanism (register, publish,
  access)
• Manage Legacies and Polices.
• Legal criteria to implement authorization
• Legal criteria to allow/cancel registration
• Legal criteria to connect customers with
  providers.
• Priorities.

20
(No Transcript)
21
TAPAS Telematics Architecture for Play-Based
Adaptable Systems

• Its a project running at the Department of
  Telematics, NTNU (Norwegian University of Science
  and Technology) since 1998
• SOA components in TAPAS

Service System
Service Component
Service Component
Service Component
Service Component
executed as
Software Component
Software Component
Software Component
Node 3
Node 1
Node 2
22
TAPAS as a SOA

• Coordination oriented
• Build to change
• Incrementally built and deployed

• Loosely coupled
• Message oriented
• Abstraction

23
TAPAS adaptability

• TAPAS its an architecture for network-based
  service systems, focused on adaptability
• Adaptable service systems adapts dynamically to
  changes in both time and position related to
  users, resources and service requirements
• Adaptability is modelled as a 3-classes property
• rearrangement flexibility
• failure robustness and survivability
• Quality of Service (QoS) awareness and resource
  control.

24
Capabilities and Status

• The system resources are represented by the
  so-called Capability and Status of the system.
• A capability is an inherent property of a node or
  a user, which defines the ability to do
  something.
• can be classified into Resources, Functions and
  Data
• Status is a measure for the situation in a
  system with respect to the number of active
  entities, the traffic situation, the QoS, etc.

25
Architecture Layers

• TAPAS is separated into two architectures
• System Management Architecture shows the
  structure of services and services components.
  Focus on functionality.
• Computing Architecture is a generic architecture
  for the modeling of any software component.
  Focus on the modeling of functionality with
  respect to implementation.

26
Computing Architecture
27
Play View as a theater metaphor
Play (Service System)
Roles(ServiceComponents)
Director
Role Figure
Free Actor
Role Figure
Role Figure
Actors(SoftwareComponents)
Node 1
Node 2
Node 3
28
Computing Architecture
29
System Management Architecture
30
The System Architecture Modules

• Service Management is responsible for the
  definition of new services, deployment and
  invocation of services and service components.
• Capability and Status Management monitors system
  capabilities and status and access/maintains the
  CS repository.
• Configuration Management Optimization of service
  systems initial configuration and
  re-configuration with respect to the capabilities
  and QoS.
• Mobility Management handles the various mobility
  types.

31
System Management Architecture
32
Message specification modeling
33
Implementation example
node1.cap
cpu.clock.266 memory.ram.160 screen.colors.65000
34
ActorPlugIn request
35
PlugOut request
36
Conclusions

• Easier systems description - theater metaphor
• 2 architectures, that complements each other
• Flexibility and Fault tolerance
• Good mobility management principles
• In development (few things works correctly)
• Loose documentation
•  Hot line 

37
Questions
38
SOA Main properties

• Loose coupling is a long-standing IT term meaning
  that the internals of an application or business
  service must be able to be changed without
  impacting client applications Specifically, a
  service consumer should not be required to know
  any more about a service than what is contained
  in the published contract
• Loose coupling means that message(s) used to
  interact with a service are 100 involved with
  the business function being performed without
  regard to how the function is being performed

39
SOA Main properties

• Services are more highly coarse-grained than
  typical IT objects and components frequently
  services map directly to a business function or
  activity
• Coarse-grained interactions are simpler and
  require fewer messages to use the service, and
  thus, fewer messages cluttering the system
• Designing services and interactions may be
  complex since the different aspects of providers
  and consumers must be reconciled into a simple
  set of course grained communications
• Pass the entire Purchase Order as a
  coarse-grained unit rather than breaking it into
  PO Header and PO Detail Lines as you might have
  done in the past

40
What is Grid Computing?

• A computational grid is a hardware and software
  infrastructure that provides dependable,
  consistent, pervasive, and inexpensive access to
  high-end computational capabilities.
• The Grid Blueprint for a New Computing
  Infrastructure, Kesselman Foster

• Criteria for a Grid
• Coordinates resources that are not subject to
  centralized control.
• Uses standard, open, general-purpose protocols
  and interfaces.
• Delivers nontrivial qualities of service.

Source What is the Grid? A Three Point
Checklist, Ian Foster, Argonne National
Laboratory University of Chicago
41
Grid and Web Services Standards
Grid
GT1
GT2
OGSi
WS-I Compliant Technology Stack
Have been converging
WSRF
BPEL
WS-
WSDL, SOAP
XML
HTTP
Web
Convergence of Core Technology Standards allows
Common base for Business and Technology Services
42
Two Key Grid Computing Groups

• The Globus Alliance (www.globus.org)
• Composed of people from
• Argonne National Labs, University of Chicago,
  University of Southern California Information
  Sciences Institute, University of Edinburgh and
  others.
• OGSA/I standards initially proposed by the Globus
  Group
• Based off papers Anatomy of the Grid
  Physiology of the Grid
• The Global Grid Forum (www.ggf.org)
• History
• First meeting in June of 1999, Based off the IETF
  charter
• Heavy involvement of Academic Groups and Industry
• (e.g. IBM Grid Computing, HP, United Devices,
  Oracle, UK e-Science Programme, US DOE, US NSF,
  Indiana University, and many others)
• Process
• Meets three times annually
• Solicits involvement from industry, research
  groups, and academics