Inhalt

Software Evolution

Some service oriented technologies

Jini (Apache river)

OSGi

UPNP

Component vs. Service

Enterprise Application Integration

Asynchronous messaging

Neutral message format

Message broker

Message-oriented middleware (MOM)

Integration broker

Software services

Service oriented architecture (SOA)

Application Service Providers (ASP)

Web Services

Simple Object Access Protocol (SOAP)

Web Service Description Language (WSDL)

SAWSDL

Universal Description, Discovery and Integration (UDDI)

WS-Addressing

WS-Policy

WS-MetaDataExchange

QoS-Specifications

WS- Choreography-Description-Language (WS-CDL)

Composition

What is a business process?

Orchestration vs. Choreography

BPEL

Service selection

Concrete vs. abstract process

Integration

Representational State Transfer (REST)

JAX-RS

Description of RESTful web services

Mashups

REST service composition

WS-Interoperability

Enterprise Service Bus (ESB)

Cloud Computing

Humans as a Service

Incentives and rewards

Incorporating humans into a programming paradigm

Elasticity

Vienna elastic computing model

Elasticity in smart environments

Services and non functional properties

Quality of Service

Quality of Experience (QoE)

Service Level Agreements (SLAs)

SLA aggregation

WSLA

WS-Agreement

Software Evolution

Evolution is intrinsic to software which is the crucial reason why it is not possible to gather and “freeze” and completely control all software requirements upfront.

Open-world assumption

In an open world, loosely coupled services become key actors since resources are made available as services on a network (SaaS) and accessible on demand. Such services might be owned by other people who are not under your jurisdiction. This assumption is important for emerging domains like context aware applications.

Implications of the Infrastructure/Processes/Software/Teamwork evolutions:

  • Dependencies between system parts are no longer fixed
  • Applications need to be aware of context changes and unanticipated events
  • Internet of things – need for support of active objects

Mastering the complexity of the future internet:

  • Top-down approach

Process-driven, for enterprise scale, build once – use many times by many service users

  • Bottom-up approach

User-driven, for small scale, build once – use once

Some service oriented technologies

Jini (Apache river)

Java framework for developingSOAs; uses Java RMI and Serialization; provides discovery of Jini services

OSGi

A framework for developing (remotely) deployed services; makes use of portable byte code; security is built into the language; excellent model that supports all variations of devices

UPNP

A device may offer multiple sevices; device registers itself and can then provide the services

Component vs. Service

Component / Service
Rather tightly coupled
  • client needs library
/ Loosely coupled
-Message exchange
-Policy
Fast / Some overhead
Rather fine grained / Rather coarse grained
Client/Server / Peer-to-Peer
Extendable / Composable
Stateless / Context independent

Enterprise Application Integration

EAI is an early solution for the old problem in IT to integrate different (potentially heterogeneous) applications with each other.

The trivial approach is to create an application bridge which receives messages from the source applications, transforms the messages into the format of the target application and finally invokes the target application with the message.

Problems with this trivial approach arise when we encounter heterogeneity, distributed systems and quality of service concerns.

Asynchronous messaging

Therefore, a better solution is one that uses asynchronous messaging and a message queuing middleware. The former application bridge is split in a source adapter and a target adapter where the source adapter puts messages from the source application into the queue and where the target adapter takes messages out of the queue, transforms them into the message format of the target application and invokes the target application.

Neutral message format

With this approach we still have problems for a high number of applications since the number of required adapters is n * n for n different applications. The first improvement in this regard is to introduce a neutral message format, so every adapter transforms to/from the unique neutral message format which reduces the number of adapters to n+n.

Message broker

A further improvement is to use a message broker middleware that sits on top of the message queuing. The broker identifies messages, performs the necessary transformations and routes the message to the target application. It generally simplifies adapter creation and has additional benefits like publish/subscribe support for dynamic environments or the possibility to reflect corporate policies in message transformations.

Message-oriented middleware (MOM)

MOM involves passing of data between applications over a common communication channel.
Messages are sent asynchronously.
The middleware manages the connection points between clients as well as multiple communication channels between connection points.

Other features:

  • Event-driven processing, i.e. publish/subscriber model
  • Reliability and serialization of messages
  • Subject-based message names to abstract from physical addresses etc.
  • Multiple communication protocols (like store & forward, request/reply)

Integration broker

An application-to-application middleware service that supports one-to-many, many-to-one and many-to-many message distribution.

EAI usually uses a fast and robust communications backbone with MOM and integration broker technology.

Software services

Software services should be analogous to real world services.

A web service is a self contained software entity that is published, discovered and invoked on the internet. It uses XML-based languages and allows loose coupling of systems.

Services must define well-defined interfaces (WSDL).

The service interface defines the service functionality and the ways to access this functionality to the external world. The interface contains:

  • Operations
  • Parameters
  • Data-typing
  • Access protocols

The service implementation implements a service interface while hiding the implementation from the user.

Web services advantages

  • Allow virtualization of resources and utilization of internet infrastructure.
  • Allow Agile development of systems through service composition
  • Can be provided and used from everywhere

Types of web services:

  • Informational services

Simple request/response sequences (e.g. weather info)

  • Complex services

Assembly & invocation of many diverse existing services to form yield multi-step business interactions

Messaging styles for webservices:

  • Synchronous or RPC style – queries are method calls with a set of arguments
  • Asynchronous or message style – client sends entire documents (messages)

Service oriented architecture (SOA)

SOA is an architectural style of software design and it guides all aspects of creating and using services. Its main paradigms are:

  • Loose coupling
  • Dynamic binding
  • High interoperability
  • Elasticity

Roles:

  • Service provider: provides the service implementation, description and technical/business support
  • Service client: the end-user organizations that use a service
  • Service registry: a searchable directory where service descriptions can be published and searched

Technical benefits:

  • Efficient development (easy to divide and assign)
  • More reuse
  • Simplified maintenance (interface stays the same)
  • Incremental adoption (SOA can be implemented step by step)

Business benefits:

  • Increased business agility
  • Better business alignment
  • Customer satisfaction
  • Reduced integration costs
  • Reduced dependency

Challenges:

  • Training costs
  • Maintain discipline – services should be developed for long-term use
  • Need to modify some legacy applications

Possible solution is a step-by-step migration to SOA.

Application Service Providers (ASP)

ASP is the origin of Software as a Service. An ASP rents software to a subscriber. The software components are bound together by the ASP to provide a working solution (i.e. the ASP hosts the software).

Limitations of ASP:

  • No highly interactive applications
  • No application integration
  • No applications that are completely customizable for the subscriber

Web Services

Web services are on possible technology to implement SOA. They are especially well suited since they are based on web standards like XML and HTTP and they are standardized (W3C, OASIS).

The core standard consists of UDDI, SOAP and WSDL but there are extended specifications like WS-Addressing, WS-reliable messaging that allow for advanced features.

Simple Object Access Protocol (SOAP)

SOAP is an XML based messaging protocol that defines

  • A simple enveloping mechanism
  • A processing model for messages
  • Binding mechanism
  • Attachment of non-XML content

Web Service Description Language (WSDL)

XML vocabulary for describing web services.

A WS-description has two parts:

  • Abstract: operations (what?)
  • Concrete: binding, service (how?, where?)

Usage scenarios:

  • Service description for clients (abstract + concrete part)
  • Description of standard service for implementers (abstract only)

Parts of a WSDL description:

  • Types – data type definitions
  • Messages – contains multiple parts, each part references a type
  • Operation – set of messages, defines message exchange pattern
  • Request-Response
  • Solicit-Response
  • One-way
  • Notification
  • Port type – named set of operations
  • Binding – defines message format and protocol for a port type
  • Operation – binding information for corresponding operation in port type
  • A service is a collection of ports (single ports represent alternatives in terms of protocol, distance etc.)

Changes in WSDL 2.0:

  • there is no message construct any more
  • root element “description” instead of “definition”
  • interfaces replace port types
  • endpoints replace ports

SAWSDL

WSDL extension for describing semantic web services. It is possible to add links from structures in WSDL to concepts in an ontology.

  • Lift type – transform from XML to ontology representation
  • Lower type – transform from ontology representation to XML

Universal Description, Discovery and Integration (UDDI)

Registry service for web services. Originally, it was intended to be a public directory but this is not (yet) fully realized.

The UDDI API is specified in WSDL with SOAP bindings.

UDDI contains information about services for

  • developers
  • other services (runtime binding)

UDDI assumes a separation of content into pages (phone book analogy):

  • White pages – organization listing, contact information, provided services
  • Yellow pages – Classifications of companies and web services
  • Green pages – technical service information, pointers to service description documents (at provider’s site)

UDDI data structures:

  • businessEntity – service provider description (e.g. some company)
  • businessService – description of a group of related web services
  • bindingTemplate – technical web service description
  • tModel – generic container for any type of specification, unstructured (meant to be read by humans), reference to actual document

Since the tModel (unstructured) is hard to use for dynamic binding the standard approach was to publish a standard interface as a tModel. The developer uses this interface to develop the client application. At runtime, the application looks up the UDDI for the known tModel key and binds to some service that implements this standard interface ( not really dynamic).

UDDI user classes:

  • Service providers
  • Service requestors
  • Other registries (registry synching in- and outbound)

One of the main problems of UDDI was the poor quality and maintenance of the content. Most of the listed services were actually not available. Current alternatives are:

  • Service portals - Registry Websites for humans
  • Service search engines - Crawls for webservices
  • P2P Registries - Distributed(no single point of failure, no powerful central entity, scalable)
  • VRESCo(Vienna Runtime Environment for SoC) - Extended/Enriched UDDI
  • Direct service information Exchange - WS-MetadataExchange

WS-Addressing

SOAP does not specify how addressing should be done. The simple solution is to use HTTP but this has the drawback that no complex message exchange patterns and no long running, stateful interactions are supported.

WS-Addressing is a more complex addressing mechanism. It supports endpoint references and uses the SOAP header for storing addressing information.

Interoperable, transport-independent way of identifying receiver and sender.

WS-Policy

Allows description of conditions, constraints, service-level requirements and assurances.

WS-Policy is actually a collection of two specifications:

  • WS-Attachment (e.g. this enables the attachment of a WS-Policy to a web service; how to associate a policy with a subject)
  • WS-Policy (grammar, merging, intersection)

While e.g. WSDL describes functional properties, WS-Policy describes non-functional properties of a web service.

The general approach of WS-Policy that both server and client provide policies. These two policies are merged (Policy Merging – yields the “sum” of the policies) or intersected (Policy Intersection – yields the compatibility between client and server).

A policy consists of assertions that are built with “ExcatlyOne”, “All” and “optional” tags/attributes.

WS-Policy DNF (Disjunctive Normal Form) is used for merging policies. The policies are algorithmically translated to DNF.

Policy Validation does some kind of compatibility checks/intersection (structural approach). However, assertion-specific knowledge is needed to ascertain compatibility between policies in general.

WS-MetaDataExchange

Allows the dynamic exchange of meta data like WS-Policy between endpoints without the need for a registry.

Client and service already know each other and the client directly ask the service for the details – e.g. exchange WSDL, WS-Addressing, WS-Policy.

WS-MetaDataExchange operations:

  • Get – returns all metadata
  • Get WSDL – returns location of WSDL
  • Get Metadata – returns location of any other metadata
  • Put / Delete Metadata – modify the service metadata

QoS-Specifications

  • WS-Security
  • WS-ReliableMessaging (e.g. in-order-delivery, at-least-once-delivery)
  • WS-Coordination (for multi-party, multi-message web service tasks)
  • WS-Transaction (WS-AtomicTransaction, WS-BusinessActivity)

WS-Choreography-Description-Language (WS-CDL)

  • Describes how services work together.

Business Process Execution Language (BPEL) for web services

  • Describes the orchestration of web services.
  • Describe and execute business processes.
  • Recursive creation of larger web services from smaller ones

Composition

Composition means to combine existing services (atomic or composed) to create new applications/processes.

Service composition is a SOA development task and requires functional requirements. It is based on QoS parameters.

Composition types:

  • Static – composed services are defined at design time
  • Dynamic – composed services are defined at runtime
  • Deployment – composed services are determined at deployment time, i.e. different installations can have different service compositions

Requirements for composition:

  • Flexible integration, i.e. it should be possible to express business scenarios, adaptable to change
  • Recursive composition
  • Separation of concerns, i.e. independent of QoS requirements, messaging protocols etc.
  • Recoverability

Challenges:

  • Representation of an abstract process
  • Discovery and interoperability of services
  • Efficiency of web process execution
  • Process execution – find techniques to execute the composed process
  • Process monitoring – find technique to monitor web process execution

Composition approaches:

  • Process driven – compositions are treated as workflows
  • Requirement driven – compositions are generated from detailed requirement specifications
  • AI based – compositions are defined by reasoning engines

Composition protocols:

  • Orchestration (BPEL) – centralized cooperation
  • Choreography (WS-CDL) – decentralized federation
  • Event-based federation (WS-Eventing) – decentralized event-based approach

General concerns:

  • Agility & Scalability – required for real-time integration
  • Life cycle management – monitoring of enterprise resources, rapid response to changes
  • Robustness/Resilience – high availability, fast and effective recovering
  • Security – appropriate security practices in IT solutions

What is a business process?

A business process is an activity consisting of tasks that are executed in a predefined sequence and according to business rules yielding some outcome.

A process model describes a real world process while a workflow model describes the technology interactions that implement the real world process.

Orchestration vs. Choreography

Web service orchestration means to compose services business processes.

  • Define composite services
  • Reuse of existing web services
  • Composition in the “part-of” sense
  • Private business process

Web service choreography means to compose services for business collaboration.

  • Define how multiple parties collaborate
  • Peer-to-peer model
  • Composition in the “sequencing” sense
  • Observable public message exchange

BPEL

BPEL is a block-structured, process-oriented composition language and is intended for orchestration. It allows the definition of concrete and abstract processes. BPEL relies on WSDL, i.e. BPEL processes are exposed as WSDL services and BPEL processes interact with other services through their WSDL.

The basic component in BPEL is an activity of which there are 2 kinds:

  • Primitive activity
  • Structured activity – defines the order in which a set of activities is executed

A BPEL process definition consists of:

  • Activities
  • Containers (For data handling)
  • Partners (offer services to and use service offered by the BPEL process)
  • Data
  • Messages
  • Scopes
  • Fault handling (on fault handler per scope; default handler re-throws the fault)
  • Activities are linked by control links
  • Compensation handlers (at most one per scope; can only be used when the scope is finished since it compensates the entire scope; default handler executes inner compensation handlers in reverse order)

BPEL variables are necessary to maintain the process state. Their types can be:

  • Messages
  • Simplex XML type
  • Complex XML type

The BPEL life cycle is responsible for mapping messages to instances (= correlation). A correlation set can be used to define parts of a message to be used for correlation (i.e. same first name and last name  same instance)

Service selection

Relations between partners are specified by partner links which are instances of partner link types. A partner link type defines a pair of roles (implement WSDL port types), i.e. it defines the relation between a pair of abstract web services = choreography.

The partner link actually identifiesthe services that are invoked during process execution.

An endpoint identifies a specific partner link instance, it is statically or dynamically bound.