Download - Middleware as a solution - unibo.it
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