1

Middleware as a solution

In Business scenarios…

Extreme complexity to deal with

Innumerable variety of entities and situations

Need of a support capable of granting basic and

advanced functions to all different usage and users

Middleware capable of enabling, putting together,

offering to users

best services, most usable components, appropriate

applications, the right system and configurations,

Also the possibility of choosing among different options

The middleware is the enabling entity capable of

organizing all interesting opportunities to users so to

make easy provisioning and to be really available

2

MIDDLEWARE

The layer of software that sits in the middle, between

application levels and lowers layers, net components,

operating systems, heterogeneous hardware,

management platforms, …to grant correct operativity

It is

a decoupling layer

between systems

levels to enable and

make possible a

simplified and

continuous design

of the application

components to

overcome problems

(mainly

heterogeneity)

3

Middleware vs. ad-hoc solutions

Traditional solutions: ad-hoc problem solving

but done once for any situation

Middleware solutions: designed solution

and one solution for-all-cases

4

Typical components of a software business platform

ERP: Enterprise resource planning

CRM: Customer Relationship Management

Financial applications: all financial issues

Supplier / Customer workflow: the whole production

chain, workflowing up and down

Web infrastructure: all applications available via Web,

also to expose the whole of internal processes

Vertical Applications: Important enterprise resources

Horizontal Applications: typical internal components

DBMS and data managements: information systems

and the whole data warehousing

Legacy systems: Old enterprise applications and

typical invaluable resources

Low level functions: Operating systems and

communications functions

5

Several MIDDLEWARE as systems to provide and give a scenario for business services

Middleware as a support to all operation phases in a company, also in terms of legacy systems

Enterprise Application Integration (EAI)

The need of integrating the whole of the company IT resources is the very core goal

That objective must be provided, while preserving Enterprise values

Service Oriented Architecture (SOA)

All interactions among programs and component are analyzed in terms of services

Any service should have a very precise interface

SUPPORT to ENTERPRISE

6

Enterprise Application Integration (EAI)

The idea is to have systems that produce a unified integrated scenario where all typical Business applications programs and components can be synergically provided

There are both:

• Legacy components to be reused

• New components to be designed and fast integrated

The easy and complete integration among all business tools has also another important side effect

The possible control and monitor of the current performance of any part of the whole business

• to have fresh data about performance

• to rapidly change policies and to decide fast (re-)actions

Enterprise Application Integration

7

Modern Enterprise strategies require both existing and new applications to fast change with a critical impact on company assets

ENTERPRISE Information Technology

8

Service-Oriented Architecture

The basic interaction is via services defined as

platform- and network-independent operations that

must be cleanly available and clear in properties

Service-Oriented Architecture (SOA) is the enabling

abstract architecture

A service must have an interface to be called and give

back some specific results

The format must be known to all users and available to

the support infrastructure

There are many ways to provide a SOA framework

SOA must offer basic capabilities for description,

discovery, and communication of services

But it is not tied to any specified technical support

9

SOA is simply a model and it imposes some

methodologies to obtain its goal of a fast and easy to

discover service ecosystem Services are described by an interface that specifies the

interaction abstract properties

The Interface should not change and must be clearly

expressed before any usage

Servers should register as the implementers of the

Interface

Client should request the proper operations by knowing

the interface

Interaction is independent of any implementation detail,

neither platform-, nor communication-, nor network-

dependent

Service-Oriented Architecture SOA

10

Service-Oriented Architecture SOA proposes a precise

enabling architecture with three actors

SOA actors

Providers are in charge

of furnishing services

Requestors are

interested in obtaining

services

Discovery agencies are

responsible to give

service information

and full description of

services

11

One service is an abstraction of any business process,

resource, or application, that can be described by a

standard interface and that can be published and become

widely known (discovery)

Services are:

- reusable, in the sense that they can be applied in

several contexts (no limitation, in general anyone)

- formal, they are not ambiguous in defining the contract

specifications (clear and clean interface)

- loosely coupled, they are not based on any

assumptions on the context where they could be used

- black box, they are neither specifying the internal

business logic nor tied to any implementation details of

a specific solution

Service Conceptualization

12

A service must be available by all platforms that are publishing it to all the ones in need of it, only if the requestor asks for the interface in the right way Interfaces should be widely spread and published in some discovery agencies Services must be:

- autonomous, they must not depend on any context and should be capable of self managing

- stateless, the internal need of state should be minimized (eventually stateless); the invocations must not rely on previous ones (no dependency on one another)

- discovery-available, all service must be found via opportune naming agents and must easy to retrieve and to use

- composable, existing services can be put together to produce a component to be invoked independently as a novel service (composition to create new services)

SOA Design Principles

13

Traditional Business Architectures

14

SOA-oriented ARCHITECTURES

15

SOA enthusiasm

16

Web Services are a proposal for SOA based on the WEB as enabling technology

There is a big difference between Services over the Web and Web Services

In the first, mainly users get services via Web protocols, – users get (static, dynamic) pages via Web, C2B

In the last, Web services are a new precise and different specification to obtain business operation by exploiting the Web technology as if it allowed a new level of programming language typically B2B

(business2business vs. customer2business)

WS inherit the whole HTML-world (operations, protocols, …) by assuming a new Web extension: XML (eXtensible Markup Language) in an open perspective

Web Services (W3C standard organization)

17

MIDDLEWARE and their roles in providing services to a very large and not constrained

distributed systems, with scalability

Middleware as frameworks or infrastructure support to

integrate and compose services

Middlewares tend to be proprietary and barriers are not

so easy to overcome

MIDDLEWARE in integrating systems

Both requirements of

easy overcoming

boundaries

(openness) and

maintaining the

correct security

roles (closeness)

18

Many widespread middlewares

Standard Object-Based: CORBA, standard proposal

Proprietary: DCOM and .NET – Microsoft

Business MW: IBM, Siebel, Bea, …

Database: Oracle, …

Many other tendencies

…

Any middleware integrates different solutions

MIDDLEWARE and their diffusion

19

For security sake, firewalls tend to be very closed and to block

any attempt of entering any organization boundary

firewalls specify constraints on the opened functions and gates

and tend to be very suspicious toward outside potential

malicious operations

Services over the WEB are typically open for business sake

The Web gate

is always

open for

business

MIDDLEWARE and SECURITY

20

WEB SERVICES as a standard MIDDLEWARE for SOA over the Web, for provisioning of services in an environment with all Web-compatible technologies

Requestors and

Providers in

the C/S roles

and

Brokers as

the agency

for name

discovery

Web Services as a middleware

21

Web Services protocols: SOAP, WSDL; UDDI

The three basic protocols

are respectively

specialized:

SOAP to interact and to request providers available services

WSDL to fully describe any interesting service

UDDI to maintain all available and published services

These protocols can only describe the above simple interaction, but leaves many open issues: security and protection, authorization, reliability, quality of service, service coordination, transactions, …

22

Web Services Architecture

Basic WS protocols have been largely applied and also pursued

in many successful prototypes and large experiments, but an

effective support middleware is still to come, to answer all

requirements of integrations and service relationships

Expressive limitation and rigidity of these protocols

Basic protocols

alone

SOAP

WSDL

UDDI

are not so expressive

23

New Web Services architecture

W3C has

proposed a new

architecture

based on many

other satellite

protocols so to

enhance the WS

capacity of

modeling and of

obviated to strict

limitations

24

Web Services WS-* approach

Web Services has introduced several additional protocols, collectively called WS-* to address more urgent issues

WS-Transaction

WS-Coordination

WS-Reliable

Messaging

…

Business Process

Execution Language

for Web Services

(BPEL4WS)

25

Simple services and …

Even in general the problem of service provisioning is not completely addressed and solved…

Once you have a SOA scenario, you can provide services, ask for services, and so on…

But services are typically something you can put together, for instance by feeding one service output to another service input (e.g., in a pipeline) or in a flow, even producing some more complex composite service

26

Service Composition & Workflow

Workflow as a composition of different services to

orchestrate a new service available for use

Each composed service belongs to its offering

environment but can be properly put together for the

general result

Any composition is based on connectivity

(correctness in passing data from one service to

another) how to grant it? Automatically?

Any composition requires non functional properties

such as timeliness, security, dependability,

atomicity, etc. how to grant it? Automatically?

Web services basic protocols define no answer, left

to the extensions Web-* protocols

27

Web Services new protocols

Service Composition as in Business Process Execution

Language for Web Services (BPEL4WS)

A new proposal of a script language based on WSDL that

allows to define how a new service can be derived from old

ones, by simply putting together existing services, with a few

flow concepts

Workflow Management standard activities based on:

• sequence: one activity after another (output -> input)

• parallel (AND split): all activities go in parallel

• alternative (OR split): several activities in an alternate

choice (differentiated activations);

• join (AND & OR): joint termination of related activities

(wait all, wait only the first one to complete)

28

Business level support to integration and

orchestration

design by using graphical composition tools

ORCHESTRATION

Portals

ERP Packaged Apps

Home-grown

Content Mgmt

Mainframes Data

Terminal Apps Unix

Orchestration

Web

Service

Web

Service Web

Service Web

Service

Web

Service Web

Service

Web

Service

Integration

Publishing

Integration

Transforming

& mapping

Communication

Process Modeling

29

Integration of WS-* and business requirements

Toward an enterprise integration

Web Services Container

Industry Registry

SOAP /

HTTP(S)

WSDL WSDL UDDI

Web

Services

Client

Web

Services

Runtime

discovery

description

firewall

Enterprise

Internet

execution

Web Services Business Functionality

Business

Composition

30

SOA expectations

ROI

Return

Of

Investment

31

Evaluation and Evolution in Technologies

V

isib

ilit

y

Maturity

Technology Trigger

Peak of Inflated Expectation

Trough of

Disillusion

Slope of Enlightenment

Plateau of Productivity

Web

Services

CORBA

Any technology has its own life cycle

Also some hypes connected

32

Trough of Disillusionment

33

Cloud: big expectations

34

WS-* protocols are heavy and expensive in terms of support

so can be used profitably in the case of coarse-grained

services, but they are not the only way of implementing

concretely SOA

Lighter Representational State Transfer (REST) Protocol

to work WEB-compatibly for fine-grained services and

limited costs

Some simple strategies to support a light and easy and

less constrained interaction based on web Resources

- Usage of HTTP methods (POST, GET, PUT, DELETE)

- Stateless Protocol based on URL in directories

- XML or other lighter description languages

Alternate solutions to WS e WS-*

35

REST ????

36

Web protocols are also constraining because they are

typically synchronous and not so flexible: any minimal change

on the Web page has be reported back to the client and the client

has to ask for it (when?)

Web 2.0 - AJAX

Asynchronous protocols are used invisibly to the user

They are working transparently to user operations and are

capable of getting the fresh information needed in an

asynchronous way

Asynchronous Javascript And XML (AJAX)

Ajax is the new support capable of using Web services in a

technical sense

The term Web2.0 is also related to a more participatory and

peer to peer interaction, social networks deriving from that

WEB 2.0

37

Asynchronicity vs. Synchronous operations

With a normal Web

synchronous operation

any change must be

requested and asked for,

by waiting for it

Ajax operation allows the

user to go on doing

things and not to wait

while

the browser is in charge

of getting the new

information and check

for variation of old ones

38

AJAX Internal Organization

39

SOA and Cloud