Middleware: Challenges and Evolution from Procedural to Service - - PowerPoint PPT Presentation

▶
middleware challenges and evolution from procedural to
SMART_READER_LITE
LIVE PREVIEW

Middleware: Challenges and Evolution from Procedural to Service - - PowerPoint PPT Presentation

Feb 23, 2024 257 likes •1.04k views

Middleware: Challenges and Evolution from Procedural to Service Orientation Bruno Traverson (bruno.traverson@edf.fr) IWAISE2008 APRIL 2008 1-1 Middleware Contraction of middle and software . Dfinition Core

slide-1
SLIDE 1

IWAISE’2008 APRIL 2008 1-1

Middleware: Challenges and Evolution from Procedural to Service Orientation

Bruno Traverson (bruno.traverson@edf.fr)

slide-2
SLIDE 2

IWAISE’2008 APRIL 2008 1-2

Middleware

  • Contraction of « middle »

and « software ».

  • Définition

– Core software independent of any application domain and generally covering four categories of functionalities:

  • Communication,
  • Coordination,
  • Conversion,
  • Facilitation.

[Mehta, Medvidovic, Phadke, Towards a taxonomy of software connectors. Software Engineering, 2000] [Meeting in the Middle, Ruth Palmer]

slide-3
SLIDE 3

IWAISE’2008 APRIL 2008 1-3

Software Architecture

  • Four main approaches in middleware
  • Procedural,
  • Object-oriented,
  • Component-based,
  • Service-oriented.
  • Definition

– Structure of a system and its components, their relationships and the mainlines that guide their design and their evolution during time.

[Constantine, Farid Benyaa]

slide-4
SLIDE 4

IWAISE’2008 APRIL 2008 1-4

Contents

  • Basic principles
  • Procedural approach
  • Object-oriented approach
  • Component-based approach
  • Service-oriented approach
  • Conclusion
slide-5
SLIDE 5

IWAISE’2008 APRIL 2008 1-5

Contents

  • Basic principles
  • Procedural approach
  • Object-oriented approach
  • Component-based approach
  • Service-oriented approach
  • Conclusion
slide-6
SLIDE 6

IWAISE’2008 APRIL 2008 1-6

Communication

  • Communication functions insure exchanges

among the various elements of a distributed application.

  • Classification based on the kind of the flow
  • Information flow (data or code),
  • Control flow (signal or call).
  • And on the kind of binding between elements
  • Direct binding (elements know each other),
  • Indirect binding (elements communicate via a tier).
slide-7
SLIDE 7

IWAISE’2008 APRIL 2008 1-7

Client/Server

  • One entity playing the « client » role calls an
  • peration offered by another entity playing the

« server » role.

  • Characteristics

– Control flow with direct binding – Simultaneous presence of client and server entities, – Blocking call for the client.

client server

slide-8
SLIDE 8

IWAISE’2008 APRIL 2008 1-8

Producer/Consumer

  • Entities playing the « producer » role emit events to
  • ther entities playing the « consumer » role.
  • Event producers and

consumers communicate through a tier called « event channel » (anonymous communication).

  • Characteristics
  • Information flow with indirect binding,
  • Muti-peer communication,
  • Push or Pull model.

push push event channel producer consumer event propagation

slide-9
SLIDE 9

IWAISE’2008 APRIL 2008 1-9

Coordination

  • Coordination

functions

  • rganize

the global execution of the various elements of a distributed application.

  • Classification based on the coordination strategy

– Based on concurrency between activities (scheduling functions : serialization and causality orders, transaction) – Based on cooperation among activities (consensus algorithms : distributed termination, workflow).

slide-10
SLIDE 10

IWAISE’2008 APRIL 2008 1-10

Transaction

  • Definition
  • A set of operations that makes the Information

System go from one initial consistent state to another final consistent state.

  • Corollary
  • Intermediate states may be inconsistent.
  • Four ACID properties
  • Atomicity
  • Consistency
  • Isolation
  • Durability
slide-11
SLIDE 11

IWAISE’2008 APRIL 2008 1-11

Workflow

  • Limits of transaction management
  • A transaction cannot commit if one of its operations

fails (atomicity),

  • A transaction cannot cooperate with other

transactions (isolation),

  • A transaction must be short-lived (atomicity and

isolation).

  • Definition

A set of "open-ended" operations (uncertain duration, conditional execution, potential interactions with other activities).

slide-12
SLIDE 12

IWAISE’2008 APRIL 2008 1-12

Conversion

  • Conversion functions mask the disparities

among the various elements of a distributed application.

  • Classification based on the level of conversion
  • Interface adaptation,
  • Communication protocol,
  • General model.
  • And the responsibility of the conversion
  • Application responsibility (gateway),
  • Middleware responsibility (bridge),
  • Shared responsibility (context-awareness, pervasive systems).
slide-13
SLIDE 13

IWAISE’2008 APRIL 2008 1-13

Basic Conversion Techniques

client server Interface X Interface Y Interface X gateway Interface Y : middleware : application client server Protocol A Protocol B Protocol A bridge Protocol B

slide-14
SLIDE 14

IWAISE’2008 APRIL 2008 1-14

Adaptable Middleware

  • Modification of all the system or of one of its

parts in a transparent way with regards to its

  • perational state in order to satisfy a particular

concern (error correction, performance

  • ptimization).
  • Characteristics

– Manual adaptation

  • Adaptation strategy handled by a human administrator,
  • Event propagation when evolution is detected.

– Automatic adaptation

  • Self-adaptation following registered adaptation strategies,
  • Reflection mechanism allowing self-observation and self-

modification.

slide-15
SLIDE 15

IWAISE’2008 APRIL 2008 1-15

Facilitation

  • Facilitation functions optimize interactions

among the various elements of a distributed application.

  • The main goal is to enhance performance and

reliability characteristics of the application or, more generally, to manage the quality of service (QoS).

– Fault tolerance, – Load balancing.

slide-16
SLIDE 16

IWAISE’2008 APRIL 2008 1-16

QoS Contracts

  • Definition

– Interval of tolerance between QoS requests and

  • ffers (in case of environment failure, offer a

service of lower quality but still acceptable by the user).

  • Characteristics
  • Composition,
  • Observation,
  • Guarantee,
  • Negotiation.
slide-17
SLIDE 17

IWAISE’2008 APRIL 2008 1-17

Contents

  • Basic principles
  • Procedural approach
  • Object-oriented approach
  • Component-based approach
  • Service-oriented approach
  • Conclusion
slide-18
SLIDE 18

IWAISE’2008 APRIL 2008 1-18

Procedural Approach

  • The system is splitted into functional modules.

When the modules are running on remote machines, middleware supports distribution.

  • Main standards
  • DCE : Distributed Computing Environment,
  • DTP : Distributed Transaction Processing.
  • Main realizations
  • Distributed Operating Systems,
  • Distributed Transaction Processing Monitors.
slide-19
SLIDE 19

IWAISE’2008 APRIL 2008 1-19

Communication Paradigms

  • Asynchronous Processing
  • Entities communicate through a tier,
  • Exchange flow is one-way.
  • Conversational
  • Entities communicate as peers,
  • Information is exchanged inside a session with respect to

control rules defined by peers.

  • Request/Response
  • One entity calls the other,
  • Exchange flow is two-way.
slide-20
SLIDE 20

IWAISE’2008 APRIL 2008 1-20

  • Using a Programmatic Interface

svcA(tpsvcinfo); {... tpreturn()} CLIENTS tpenqueue() ... tpdequeue() TMQUEUE enqueue dequeue FIFO CHANNEL MANAGERS TMS_QM SERVERS TMQFORWARD dequeue tpcall() enqueue svcA client_replyA FAILURE_Q

Asynchronous Processing

slide-21
SLIDE 21

IWAISE’2008 APRIL 2008 1-21

  • Using a Programmatic Interface

svcA(tpsvcinfo); {... tprecv(tpsvcinfo->cd, ..., &revent); tpsend(tpsvcinfo-> cd, ..., TPRECVONLY); tprecv(tpsvcinfo-> cd, ..., &revent); tpreturn(TPSUCCESS, ...)} Client { cd=tpconnect("svcA ", ..., TPSENDONLY); tpsend(cd, ..., TPRECVONLY); tprecv(cd, ..., &revent); tpsend(cd, ..., TPRECVONLY); tprecv(cd, ..., &revent); } Server

Conversational

slide-22
SLIDE 22

IWAISE’2008 APRIL 2008 1-22

  • Using a Programmatic Interface

Client { ... tpcall("svcA", ...); ... } Serveur svcA(tpsvcinfo); {... tpreturn( TPSUCCESS, ...); }

Request/Response (1)

slide-23
SLIDE 23

IWAISE’2008 APRIL 2008 1-23

Request/Response (2)

  • Using a Language Extension
  • The interface offering remote operations is defined using a

language called IDL (Interface Definition Language).

  • Communication between client and server involves adaptators

to network based on the interface definition.

Client Communication Kernel Procedure Server IDL Interface Client Stub Server Stub

slide-24
SLIDE 24

IWAISE’2008 APRIL 2008 1-24

System Management Communication Management Transaction Management Service Management Security Workstation Presentation Workstation Remote Site

  • • •
  • • •

Routing Load Management

Illustration: TP Monitors

Remote Site

slide-25
SLIDE 25

IWAISE’2008 APRIL 2008 1-25

Main Functions (1)

  • Security
  • The TP monitor must check that the service request from a

user owns the right to be processed (authentication, access right lists, integrity and privacy management).

  • Routing
  • Scheduling mechanism similar to that used in an operating

system

  • Lookup for local availability then for remote availability,
  • Lookup for a local server instance,
  • If no instance, launching of a new server instance or queuing.
  • Load management
  • Used if more than one server may satisfy the service request.
  • Two strategies
  • Minimize response times (load balancing),
  • Maximize system throughput (load sharing).
slide-26
SLIDE 26

IWAISE’2008 APRIL 2008 1-26

Main Functions (2)

  • Transaction management

– Used for commitment and recovery, – Atomic commitment, logging, recovery procedures.

  • Service management

– Ensures transactional execution of the service requests, – Transaction context management, service association to a server.

  • Communication management

– Ensures transactional communication, – Transaction context propagation, communication paradigm support (request/response, conversational, asynchronous processing).

slide-27
SLIDE 27

IWAISE’2008 APRIL 2008 1-27

Conclusion on Procedures

  • Assets
  • Interface Definition Language (IDL),
  • Application Programmatic Interface (API).
  • Advantages
  • “Natural” distribution of processing,
  • Transactional execution.
  • Limits
  • Tightly-coupled systems,
  • Interoperability between domains still difficult.
slide-28
SLIDE 28

IWAISE’2008 APRIL 2008 1-28

Bibliography on Procedures

  • DCE: Remote Procedure Call.

X/Open CAE Specification. C309. X/Open Company Limited, 1994.

  • DTP : Distributed Transaction

Processing Reference Model, Version 3. G307. X/Open Company Limited, 1996.

slide-29
SLIDE 29

IWAISE’2008 APRIL 2008 1-29

Contents

  • Basic principles
  • Procedural approach
  • Object-oriented approach
  • Component-based approach
  • Service-oriented approach
  • Conclusion
slide-30
SLIDE 30

IWAISE’2008 APRIL 2008 1-30

Object-oriented Approach

  • The system is viewed as interacting objects.

When the objects are running on remote machines, middleware supports distribution.

  • Main standards
  • CORBA : Common Object Request Broker Architecture,
  • COM : Common Object Model.
  • Main realizations
  • Object Brokers.
slide-31
SLIDE 31

IWAISE’2008 APRIL 2008 1-31

Object

  • Definition
  • Entity containing as well data (attributes) as

processing (methods) accessible through an interface.

  • Used in a lot of domains
  • Modeling methodologies,
  • Programming languages,
  • Databases,
  • Distributed environments.
slide-32
SLIDE 32

IWAISE’2008 APRIL 2008 1-32

Basic Principles

  • Wrapping
  • Object description is separated from its

realization.

  • Composition
  • Multiple objects may be combined to form one
  • bject.
  • Inheritance
  • Relationship between objects that permits to

define new objects by using characteristics of existing objects.

slide-33
SLIDE 33

IWAISE’2008 APRIL 2008 1-33

Assets

  • Evolution support
  • Replacement or modification of a component with

no impact on its environment (wrapping).

  • Legacy integration
  • Mixing of existing and new applications (wrapping

and composition).

  • Extension support
  • New components may be built from existing objects

(composition and inheritance).

slide-34
SLIDE 34

IWAISE’2008 APRIL 2008 1-34

Illustration : CORBA

  • OMG: Object Management Group

– International consortium composed of hardware manufacturers, software editors and users. – Produce specifications for the design of distributed object-oriented software applications.

  • OMG specifications

– CORBA (Common Object Request Broker Architecture) – OMA (Object Management Architecture)

slide-35
SLIDE 35

IWAISE’2008 APRIL 2008 1-35

CORBA Architecture (1)

  • ORB: Object Request Broker
  • Vehicle for requests between objects.

Client ORB Object

slide-36
SLIDE 36

IWAISE’2008 APRIL 2008 1-36

ORB Main Components

  • IDL : Interface Definition Language
  • Language used to describe object interfaces.
  • Related to portability support.
  • IIOP : Internet Inter-ORB Protocol
  • Request/response communication paradigm.
  • Related to interoperability support.
slide-37
SLIDE 37

IWAISE’2008 APRIL 2008 1-37

CORBA Architecture (2)

  • Static invocation
  • Client and server interfaces that ensure marshalling/unmarshalling

functions related to object interactions.

  • Object adapter
  • Routing function in the server side,
  • i.e. Establish the link between CORBA object references and

implementation object references (servants).

Client ORB Object

  • bject adapter

static invocation interface static skeleton interface

slide-38
SLIDE 38

IWAISE’2008 APRIL 2008 1-38

CORBA Architecture (3)

  • Dynamic invocation
  • Permits to send and to receive requests
  • n objects unknown at compile time.
  • Interface repository
  • Contains IDL definitions.

Client ORB dynamic skeleton interface Object

  • bject adapter

interface repository dynamic skeleton interface

slide-39
SLIDE 39

IWAISE’2008 APRIL 2008 1-39

CORBA Architecture (4)

Client ORB ORB interface Object

  • ORB interface
  • Services for object reference management and

initialization.

  • Implementation repository
  • Contains object implementations.

implementation repository

slide-40
SLIDE 40

IWAISE’2008 APRIL 2008 1-40

CORBA Architecture (5)

Client ORB dynamic invocation interface ORB interface Object

  • bject adapter

static invocation interface static skeleton interface dynamic skeleton interface

  • A global view ...

interface repository implementation repository

slide-41
SLIDE 41

IWAISE’2008 APRIL 2008 1-41

OMA Architecture

General service interfaces

Non-standardized application-specific interfaces Vertical domain-specific interfaces Horizontal facility interfaces

Application Objects Domain Objects CORBAfacilities CORBAservices

Object Request Broker

slide-42
SLIDE 42

IWAISE’2008 APRIL 2008 1-42

Conclusion on Objects

  • Assets
  • Unification of information and control flow.
  • Advantages
  • Evolutivity and extensibility,
  • Standardization of horizontal functions (services)

and vertical functions (facilities, domain objects).

  • Limits
  • Tightly-coupled systems,
  • Programmation and management still complex.
slide-43
SLIDE 43

IWAISE’2008 APRIL 2008 1-43

Bibliography on Objects

  • OMG, The Common Object Request

Broker: Architecture and

  • Specification. Version 3.0, July 2002.
  • M. Henning, S. Vinoski, Advanced

CORBA Programming with C++, Addison-Wesley, 1999.

slide-44
SLIDE 44

IWAISE’2008 APRIL 2008 1-44

Contents

  • Basic principles
  • Procedural approach
  • Object-oriented approach
  • Component-based approach
  • Service-oriented approach
  • Conclusion
slide-45
SLIDE 45

IWAISE’2008 APRIL 2008 1-45

Component-based Approach

  • The system is the result of the assembly of its
  • components. When the components are

running on remote machines, middleware supports distribution.

  • Main standards
  • CCM : CORBA Component Model,
  • EJB : Enterprise JavaBeans,
  • COM+ : Common Object Model.
  • Main realizations
  • Application Servers.
slide-46
SLIDE 46

IWAISE’2008 APRIL 2008 1-46

Component (1)

  • Software development may vary between

two options

– Specific software programming

+ Satisfaction of user requirements,

  • Expensive realization and maintenance,
  • Long time-to-market.

– Generic software tuning

+ Cost and risk decrease,

  • Adaptation to user requirements harder,
  • Loss of local control.
  • Software

component approach is a compromise between these two options.

slide-47
SLIDE 47

IWAISE’2008 APRIL 2008 1-47

Component (2)

100 % c

  • s

t r e d u c t i

  • n

0 % flexibility

« Make-All » and « Buy-All » spectrum

  • Characteristics

– Configuration, – Reuse, – Assembly.

% bought

Source : Component Software, Clemens Szyperski, Addison-Wesley

slide-48
SLIDE 48

IWAISE’2008 APRIL 2008 1-48

Configuration

  • A component is designed and

developed independently

  • f

applications that will use it.

  • Adaptation of a component to its

usage environment is called tuning

  • r configuration
  • Application tuning,
  • System tuning.
slide-49
SLIDE 49

IWAISE’2008 APRIL 2008 1-49

Reuse

  • Reuse permits the decrease in costs of

realization and maintenance.

  • Reuse implies strict design rules

(design for and by reuse) and an adequate organization (reusable component repository).

slide-50
SLIDE 50

IWAISE’2008 APRIL 2008 1-50

Assembly

  • Assembly enables effective usage of a

software application in a given execution environment

  • At the level of a component: building constraints

including what is required by the component.

  • At the level of a set of components: combine constraints

including binding descriptions.

slide-51
SLIDE 51

IWAISE’2008 APRIL 2008 1-51

Illustration : Enterprise JavaBean

  • Java component composed of two interfaces:

EJBhome and EJBobject et one class: EnterpriseBean.

– EJBhome corresponds to factory functions, – EJBobject represents the component interface, – EnterpriseBean constitutes the component implementation.

Bean EJB home EJB object Enterprise Bean instance

slide-52
SLIDE 52

IWAISE’2008 APRIL 2008 1-52

Container

  • Set of Java interfaces and

classes related to one category of component and linking the component and its hosting server.

  • The component

requirements in terms of environment are described in an XML deployment descriptor.

Container

Bean 1 Enterprise Bean instance EJB home EJB object Bean 2 Enterprise Bean instance EJB home EJB object

slide-53
SLIDE 53

IWAISE’2008 APRIL 2008 1-53

Server

  • Execution environment fore one or more containers.
  • Access to transaction, security, persistence and notification

services.

  • The server is generic and is not developed by the programmer.

Container Bean Client Transaction Security Persistence Notification Server

: developed and specific : generated and specific : generic runtime

slide-54
SLIDE 54

IWAISE’2008 APRIL 2008 1-54

Component Categories

  • Session : component dedicated to one client

– Without client context management (stateless session bean), – With client context management (stateful session bean).

  • Entity : component shared among multiple clients

– Managing by itself its persistence (bean-managed persistence), – Persistence management is delegated to container (container-managed persistence).

  • Message-driven : component that is triggered by

message receipts.

slide-55
SLIDE 55

IWAISE’2008 APRIL 2008 1-55

Conclusion on Components

  • Assets
  • Standard containers.
  • Advantages
  • Better separation between functional and technical

concerns,

  • Declarative approach (descriptors).
  • Limits
  • Limited choice of supporting functions and of lifecycle

policies,

  • Some architectures are restricted to one programming

language (EJB) or one operating system (COM+).

slide-56
SLIDE 56

IWAISE’2008 APRIL 2008 1-56

Bibliography on Components

  • “ Enterprise JavaBeansTM Specification,

Version 2.1 ”. Sun Microsystems, 2003.

  • Clemens SZYPERSKI, « Component

Software – Beyond Object-Oriented Programming ». Addison-Wesley, 1998.

slide-57
SLIDE 57

IWAISE’2008 APRIL 2008 1-57

Contents

  • Basic principles
  • Procedural approach
  • Object-oriented approach
  • Component-based approach
  • Service-oriented approach
  • Conclusion
slide-58
SLIDE 58

IWAISE’2008 APRIL 2008 1-58

Service-oriented Approach

  • The system is designed as a market of services

with offers and demands that may match. When the services are running on remote machines, middleware supports distribution.

  • Main standards
  • SOA: Service Oriented Architecture,
  • Web Services.
  • Main realizations
  • Enterprise Service Bus.
slide-59
SLIDE 59

IWAISE’2008 APRIL 2008 1-59

Service Oriented Architecture

  • Definition
  • Enables matching of service requests and offers.
  • Characteristics
  • Take benefits of analogy with business services

(easy mapping to organizational decomposition),

  • Externalize coordination functions (orchestration of

services, loosely-coupling),

  • Better handle requester constraints (contract-based

approach).

slide-60
SLIDE 60

IWAISE’2008 APRIL 2008 1-60

Loosely Coupling

  • A service does not invoke directly another

service…

FORBIDDEN

Service A Service B Orchestration

  • …but delegates invocation to an external

processing (orchestration).

Service A Service B

SOA COMPLIANT + Stateless

[Pierre Bonnet, Orchestra Networks]

slide-61
SLIDE 61

IWAISE’2008 APRIL 2008 1-61

Service Contract

  • Collaboration

between service provider and service consumer.

  • Management of several usage contracts,
  • Administration of variants and of versions.

[Pierre Bonnet, Orchestra Networks]

slide-62
SLIDE 62

IWAISE’2008 APRIL 2008 1-62

Illustration : Web Services

  • In a first step, WebServices are used as access

solutions to IS through Web techniques.

  • Then, they should enable development of simple

interaction mechanisms between applications through Internet.

  • In the mid-term, scenarios more elaborated among

several WebServices will imply sophisticated cooperation mechanisms.

slide-63
SLIDE 63

IWAISE’2008 APRIL 2008 1-63

Architecture ( 1 )

Server Application Client Application

Description

search use registration

Description Name Service

SOAP

SOAP : Simple Object Access Protocol WSDL : Web Service Description Language XML : eXtended Markup Language UDDI : Universal Description Discovery and Integration

WSDL WSDL

WS Server

WS Client UDDI

slide-64
SLIDE 64

IWAISE’2008 APRIL 2008 1-64

Architecture ( 2 )

  • Interaction models

: WebService Legend Client Client soap soap Web Server WS client

UDDI

WS server WS server presentation presentation WS client

Document model RPC model

slide-65
SLIDE 65

IWAISE’2008 APRIL 2008 1-65

Service Description ( 1 )

  • A WSDL document contains seven sections:
  • Types : data type definitions.
  • Message : exchanged message definitions.
  • Operation : operation definitions.
  • Port Type : set of operations reachable on one or more access

points (endpoints).

slide-66
SLIDE 66

IWAISE’2008 APRIL 2008 1-66

Service Description ( 2 )

  • Binding : communication protocol and data format used on a given

port type.

  • Port : access point defined as a combination of a « binding » and

a network address.

  • Service : set of related access points.
slide-67
SLIDE 67

IWAISE’2008 APRIL 2008 1-67

Web Service Level Agreement

slide-68
SLIDE 68

IWAISE’2008 APRIL 2008 1-68

Conclusion on Services

  • Assets
  • Adaptation to various usage contexts.
  • Advantages
  • Decoupling between usage and realization
  • Possible evolution to cooperative applications
  • Peer-to-peer interactions,
  • Complex multi-peer interactions.
  • Limits
  • Web Services still highly influenced by their technical basis
  • Web techniques,
  • XML techniques.
slide-69
SLIDE 69

IWAISE’2008 APRIL 2008 1-69

Bibliography on Services

  • OASIS, « Reference Model for Service Oriented

Architecture 1.0 ». soa-rm-cs, August 2006.

  • W3C, « Web Services Architecture». wsa, February

2004.

slide-70
SLIDE 70

IWAISE’2008 APRIL 2008 1-70

Contents

  • Basic principles
  • Procedural approach
  • Object-oriented approach
  • Component-based approach
  • Service-oriented approach
  • Conclusion
slide-71
SLIDE 71

IWAISE’2008 APRIL 2008 1-71

Standards and Products ( 1 )

  • Great diversity but four main approaches
  • Procedural
  • Object-oriented
  • Component-based
  • Service-oriented
slide-72
SLIDE 72

IWAISE’2008 APRIL 2008 1-72

Standards and Products ( 2 )

  • Procedural approach
  • TP Monitors,
  • DTP model -> Xa interface,
  • Tuxedo from BEA, CICS from IBM.
  • Object-oriented approach
  • Object brokers,
  • CORBA,
  • Orbix from IONA, Visibroker from Borland.
slide-73
SLIDE 73

IWAISE’2008 APRIL 2008 1-73

Standards and Products ( 3 )

  • Component-based approach
  • Application servers,
  • EJB,
  • WebLogic from BEA, WebSphere from IBM.
  • Service-oriented approach
  • SOA : Service Oriented Architecture,
  • Web Services,
  • .Net from Microsoft.
slide-74
SLIDE 74

IWAISE’2008 APRIL 2008 1-74

Techniques ( 1 )

  • Classification
  • Communication
  • Coordination
  • Conversion
  • Facilitation
slide-75
SLIDE 75

IWAISE’2008 APRIL 2008 1-75

Techniques ( 2 )

  • Communication functions
  • Control flow with direct binding,
  • Information flow with indirect binding.
  • Coordination functions
  • Transaction strategy,
  • Workflow strategy.
slide-76
SLIDE 76

IWAISE’2008 APRIL 2008 1-76

Techniques ( 3 )

  • Conversion functions
  • Generic framework,
  • Platform abstraction

… to « modelware ».

  • Facilitation functions
  • Quality of Service management

… to « autonomic » systems.

slide-77
SLIDE 77

IWAISE’2008 APRIL 2008 1-77

Thanks for your attention !

Any questions?