ATLAS Tier 2 Plans

Document Sample
ATLAS Tier 2 Plans Powered By Docstoc
					Middleware - from the perspective of SE


Hao Ding
NTNU/IDI
Review of Brataas, Emmerich’s paper

SEPTEMBER 23, 2002




                                      Middleware1
Outline
   What is Middleware?
   Why use Middleware?
   Middleware Requirements
   Middleware Classification
   State-of-the-art research in Middleware
   Middleware and SE Research




                                              Middleware 2
What is Middleware?(Con’d)
   Definition:
         a software layer that provides a programming abstraction as
    well as masking the heterogeneity of the underlying networks,
    hardware, operating system and programming languages.



                                   Applications, services

                                         Middleware

                                     Operating system                       Platform

                             Computer and network hardware

                  Fig 1. Software and hardware service layers in distributed systems




                                                                                       Middleware 3
What is Middleware? (Con’d)
   Technical aspects of Middleware:
        Acts as an additional layer between application and the OS
        Provides useful services to the application
        Abstracts out common functionality required by distributed
         applications
        Applications use the middleware API to invoke services
        By doing so, a middleware system:
            Simplifies the design of the applications/ clients by reducing the number
             of interfaces,
            Provides transparent access to the underlying systems,
            Acts as the platform for inter-system functionality and high level
             application logic, and
            Takes care of locating resources, accessing them, and gathering results.




                                                                             Middleware 4
Why use Middleware?
 Various commercial trends have led to an increasing
demand for DS.
        Mergers between companies
           eg., integration of different division
        Time for providing new services are decreasing
           eg., New company have incompatible requirements for their hardware, or OS platforms.
        Difficult to estimate the scalability requirements
           Internet compatible requirements for their hardware, or OS platforms.

   But contructing a DS is more difficult than building a
    centralized or c/s system.
        Multiple points of failure
        Complicated communications among components open doors for
         security attacks.

        Middleware conceals these difficulties as much as possible!

                                                                                      Middleware 5
Why use Middleware?(Con’d)
        Component1      …   Componentn                                             Component1      …    Componentn

                  Middleware                                                                  Middleware
             Network Operating system                                                   Network Operating system
                    Hardware                                                                   Hardware
Component1    …   Componentn                                               Component1     …   Componentn
                                   Host2                                                                       Hostn-1
       Middleware                                                                   Middleware
  Network Operating system                        Network                     Network Operating system

             Hardware                                                                   Hardware
                         Host1                                                                         Hostn


                                 Fig 2. Middleware in Distributed System Construction



Think…
 Using Middleware to build DS is comparable to that of using
  DBMS when building IS.

                                                                                                          Middleware 6
Middleware Requirements
   Network Communication
   Coordination
   Reliability
   Scalability
   Heterogeneity




                            Middleware 7
Middleware Requirements(Con’d)
    Network Communication
                                                 Eg. Marshalling&Unmarshalling
                        Message
         Layers
DS’
         Application

         Presentation
                                                                       Internetwork
         Session                                                       protocols
                                  Messages (UDP) or Streams (TCP)
DS
         Transport
                                  UDP or TCP packets
         Network
                                  IP datagrams
         Data Link                                                    Underlying
                                  Network-specific frames             network
                                                                      protocols
         Physical

                                                                       Middleware 8
Middleware Requirements (Con’d)
   Coordination
       Next generation systems will be inherently distributed
       Activities between components lead to Inconsistency
       Main problem:
          Synchronous vs. Asynchronous
          Activation: activated vs. deactivated
          Threading policies




                                                                 Middleware 9
Middleware Requirements (Con’d)
   Reliability
       Practical protocols do not guarantee the reliable
        transmition
       Reliability has to be paid for the decreases in
        performance
       Main problem:
          Support distributed transaction
          Support replicating components




                                                        Middleware 10
Middleware Requirements (Con’d)
   Scalability
       Main problem in building scalable DS:
            Access transparency
            Location transparency
            Migration transparency
            Replication tranparency




                                                Middleware 11
Middleware Requirements (Con’d)
   Heterogeneity
       It comes in different dimensions:
            Hardware
            OS platforms
            Programming languages
            Middleware itself
       Main problem:
          Middleware will have to be interoperable with other
             implementations of the same middleware or even different
             types of middleware in order to facilitate DS construction




                                                                 Middleware 12
Middleware Classification
   The basis for classification:
       The primitives that middleware products provide for the
        interaction between distributed components
   Four categories:
       Transactional Middleware
       Message-Oriented Middleware
       Procedural Middleware
       Object and Component Middleware
   Five aspects we will discuss:
       Network communication
       Coordination
       Reliability
       Scalability
       Heterogeneity


                                                                  Middleware 13
Transactional Middleware(TM)
 Protocol: Distributed Transaction Processing(DTP) protocol
(Distributed two-phrase commit)
 Products: IBM’s CICS, BEA’s Tuexdo, Transarc’s Encina
 Transaction Protocol:

       Application server      Resource manager         Transaction manager



                  request(tp_ID,….)
                                               join(tp_ID)


                  More requests….     Lock
                                                commit?(tp_ID)

                                             commit_or_abort(tp_ID)

                               Commit or rollback



                                                                          Middleware 14
Transactional Middleware(Con’d)
   Network communication:
        Client and server components can reside on differents hosts and
         therefore requests are transported via the network.


   Coordination:
        Support various activation polices (active on demand or
         deactivated when idle for some time)


   Reliability:
        ’DTP is widely supported by RDBMS and OODBMS’ means…

Distributed components built on such DBMSs can easily participate in distributed transactions




                                                                               Middleware 15
Transactional Middleware(Con’d)
   Scalability:
        Most transaction monitors support: load balancing and replication of
         server components
        rely on the DBMS
   Heterogeneity:
        Support: in aspects of hardware and OS.
        Different DBMSs also participate in tranactions, but…
        Data heterogeneity is not well-supported by TM
   Several Weakness:
        Undue overhead if there is no need to use Transaction or ACID
         semantics;
        Marshalling and unmarshalling need to be done manually;
         eg., M and unM between data structures a client uses and parameters
         services require
        No standardized approach for defining the services that server
         components offer.

                                                                       Middleware 16
Message-Oriented Middleware(MOM)
   Products: IBM’s MQSeries, Sun’s Java Message Queue,
    BEA’s MeesageQ, Tibco
   Network Communications:
       Asynchronous or synchronous
          Request/reply
          Publish/subscribe
          Peer-to-peer
   Coordination:
       Support asynchronous message delivery very naturally
          Queuing (prioritized, filters)
          Dynamic routing of messages
          Load balancing
       Weakness, at the same time, implementation of synchronous
        requests is cumbersome.
          Synchronization should be done by client manually


                                                               Middleware 17
Message-Oriented Middleware(Con’d)
   Reliability
       Guaranteed delivery of messages
          Levels(persistence in memory or on disk)
          Deliver exactly once in correct order
          Acknowledgement of receipt of messages
   Scalability:
       Do not support access transparency, which disables migration
        and replication transparency.
          Client components use message queues for remote
           commnunication, not the local one.
          Queue need to be set up by admin
          Queues is hard-codied in both client and server components.




                                                                    Middleware 18
Message-Oriented Middleware(Con’d)
   Heterogeneity:
       MOM does not support data heterogeneity.
          Data translation: engineers have to write code for marshalling.
   Security
       SSL, Kerberos
   Efficiency:
       Lightweight systems, distributed event notification and
        publish/subscribe-based architectures.
   Weakness:
       Message could be delivered more than once. (at-least once
        delivery)
       Do not support transaction properties, such as, ACID.
       Limited support for scalability and heterogeneity.

                                                                      Middleware 19
Procedual Middleware(PM)
   Introduction to Remote Procedure Calls(RPC):
       Devised by SUN in early 1980s.
       Part of the Open Network Computing(ONC) platform
       Available on most Unix implementations, also Windows.




                           Fig . Remote Procedure Calls


                                                                Middleware 20
Procedual Middleware(Con’d)
   Network Communication:
       By marshalling and unmarshalling
          Parameters are translated into messages.
       By client and server stubs. (refer to the figure)
   Coordination:
       Support synchronous communication
          RPCs are synchronous distributed program-to-program
           communication
       Not support asynchronous and multicast communication
       PM provides different forms of activating server components:
          Always available
          Be started on demand
              eg., inetd daemon




                                                                 Middleware 21
Procedual Middleware(Con’d)
   Reliability:
       At-most once semantics
          Returns an exception if RPC fails.
       Not support exactly-once semantics or transactions.
   Scalability:
       Rather limited
          No replication mechanisms in Unix or Windows RPCs.
   Heterogeneity:
       Support different programming languages
       Also support different hardware and OS platforms
          The stubs can translate hardware-specific information into the
           standardized form.




                                                                     Middleware 22
Procedual Middleware(Con’d)
   Evaluation:
       PM is weaker than TM and MOM.
          it is not fault tolerant and scalable
       Coordination primitives in PM only support synchronous directly.
       Improved TM and MOM with interface definitions
          Automactically marshal and unmarshal service parameters and
           results
          This interface definition is not reflexive, which can be done by
           object and component middleware.




                                                                       Middleware 23
Object and Component Middleware
   Evolved from RPCs.
   Three Major Standards:
       CORBA
          Common Object Request Broker Architecture
          Industry sponsored standard
       DCOM
          Distributed Component Object Model
                Microsoft
                from COM from OLE
       Java RMI
          Remote Method Invocation
       All can be made to be inter-operable




                                                       Middleware 24
Object and Component Middleware(Con’d)
   CORBA
       Specification of a distributed middleware
       Specs drawn up by Object Management Group (OMG,)
       Goal: Interoperability with distributed applications on various
        platforms
       Industry sponsored standard

        Client
        objects
                                   Server objects
                                                       Object
                                                       adapter

                        Object request broker core
                   Interface
                                          CORBA services
                  repository
                                                                  Middleware 25
Object and Component Middleware(Con’d)
   COM
       The client connects to the object through the COM server,
        transparently.


                      3. Get object interface
                         pointer and return to            Server
                         client
          Client
        Application          4. Call Interface           COM Object
                                Members
             1. Create
                Object
                                   COM
                                                 2. Find
                                                    Implementation




                                                                      Middleware 26
Object and Component Middleware(Con’d)
     Interprocess of COM

                                            COM Object
           Client
         Application



           Proxy                                 Stub



       COM      Library                    COM      Library

         Channel                            Channel



        RPC Runtime                        RPC Runtime


           Transport                        Transport

                          Process border
                                                              Middleware 27
Object and Component Middleware(Con’d)
   Remote Method Invocation (RMI)
       Main Idea: Working with an object on a remote machine is made
        to look like calling a procedure on the remote site, i.e.
          the application/client sends a message to the remote object
          the remote object receives message, does processing and sends back
           message with results - the server side;
          the client receives message and uses/prints result
       RMI Communication
           Client                                                 Server


         doOperation               Request
                                   message                      getRequest
                                                                select object
           (wait)                                                 execute
                                   Reply                          method
                                   message                       sendReply
        (continuation)


                                                                                Middleware 28
Object and Component Middleware(Con’d)
   Network Communication
       Support distributed object requests
       Using IDL.
   Coordination
       Default is synchronization primitives
          Blocking the client object until the server objects has returned the
           response.
       Also support other synchronization primitives
          CORBA 3.0: deferred synchronous and asynchronous object requests.
       Support different activative policies and threading policies.




                                                                       Middleware 29
Object and Component Middleware(Con’d)
   Reliability
       At-most once
       Also support the concept of transactions.
          CORBA: use Object Transaction service to cluster requests from
           several distributed objects into transactions.
          COM: integrated with Microsoft’s Transaction Server
          RMI: Java Transaction Service provides the same capability.
   Scalability:
       Still somewhat limited.
          eg., support for replication is still rather limited.
   Heterogeneity:
       Programming Language:
          CORBA & COM: support multiple programming language bindings
          RMI: Java VM resided in both client and server objects.
       IIOP supports the exchange of request data.

                                                                   Middleware 30
Object and Component Middleware(Con’d)
   Evaluation:
       Very powerful component model
       Integrating most of the capabilities of transactional, message-
        oriented or procedual middleware
       However, scalability is still rather limited, which disables the
        distributed object paradigm on a large-scale.




                                                                  Middleware 31
State-of-the-art research in Middleware
   Weakness of the state-of-the-pratice middleware:
       Inflexible
       Do not scale beyond LAN
       Not dependable and suited in wireless network
   Future research entries:
       More flexible middleware
       Better scalability and fault-tolerance middleware, eg., replication
        techniques.
       Real-time
       Mobile and pervasive computing




                                                                  Middleware 32
State-of-the-art research in Middleware(Con’d)
   Flexible Middleware
       It is unreasonable to assume that client components identify he
        component from which they can obtain services.
          Naming services in most of the present middleware.
                MOMs use named messgae queues
                CORBA: naming service
                COM: moniker
                Java/RMI: use RMIRegistry to bind names to components
       Trading instead of naming
          ISO/ODP standard
          Like the yellow pages of the telephone directory.
                Components are located based on service types.
                Trader registers the service type and the particular QoS.
                Clients query the trader, trader returns the result.
          Enable the dynamic connection of clients with server components
           based on the service characteristics rather than the service name.

                                                                             Middleware 33
State-of-the-art research in Middleware(Con’d)
   Flexible Middleware(Con’d)
       Reflection:
          Aim to support meta object protocols
              These protocols are used for inspector and adaptation

          Support queries of middleware’s behaviour upon events
          Support adjusting middleware’s behaviour to any of those events.
       Application-level Transport Protocols:
          Undue overhead while marshalling and unmarshalling
          Research on the combined use of middleware and markup-languages
                OMG: will provide the seamless interoperability between CORBA data
                 structure and XML structured documents.




                                                                           Middleware 34
State-of-the-art research in Middleware(Con’d)
   Scalable Middleware
       Present:
          successfully used in scalable applications on LAN.
          Imposed limitations in the globally distributed systems/environment.
       Solution:
          Supporting replication to the necessary extent to achieve global
           distribution
          One method: through non-transparent replication.




                                                                      Middleware 35
State-of-the-art research in Middleware(Con’d)
   Real-time Middleware
       Present:
          Limit use in real-time and embedded system:
                all requests have the same priority.
                Memory requirements prevent deployment in embedded systems.
       Research status:
          TAO: a real-time CORBA prototype which realized
                Request prioritization
                Definition of scheduling policies
          CORBA 3.0 builds on this research.




                                                                       Middleware 36
State-of-the-art research in Middleware(Con’d)
   Middleware for Mobile computing
       Problems when using current middleware in wireless network
        environment:
          Treat unreachability as exceptional situation and raise errors that
           client or server component programmers have to deal with.
          Translation between different heterogenous data representations
                eg., Bandwidth in wireless network is much less than the wired network
       Solutions:
          Providing coordination primitives
          Use compressed transport representation to save bandwidth




                                                                            Middleware 37
Middleware and SE Research
    Requirements of using Middleware in SE
         Selecting the right middleware
         Employing middleware to meet a set of non-functional
          requirements
         In SE, the use of middleware is not transparent for system
          design
    Two Trends – Impacts of Middleware on SE
         Middleware products are conceived to deliver immediate benefits
          in the construction of DS.
         Middleware vendors have a proven track record to incorporate
          middleware research

    Unless research into SE for DS delivers principles, notations, methods and tools that are
    compatible with the capabilities that current middleware products provide, SE research results
    will only be of limited industrial significance.

                                                                                         Middleware 38
Middleware and SE Research (Con’d)
   Requirements Engineering
       Why need it?
          Non-functional requirements are to be of a useful impact to
           middleware oriented architecting.
                 Challenges of co-ordination, reliability, scalability and heterogeneity in
                  DS are faced with a non-functional nature.
                 Existing requirements engineering methods have a strong focus on
                  functional requirements.
          Expensive and hard to make changes on a particular middleware
           system.
          Requirements tend to be unstable and change over time.
       How to elicit it?
          Identify the current requirements
          Estimate the ranges in which they can evolve during the planned
           life time of the DS.



                                                                                  Middleware 39
Middleware and SE Research (Con’d)
   Software Architecture
       Why need it?
          Methods are needed to help software engineers to impove the
           requirements engineering
          Needs to define artchitecting processed to help engineers to
           mitigate the risk of choosing the wrong middleware or architecture
       How?
          Develop middleware-oriented ADLs for all connectors provided by
           the middleware.




                                                                     Middleware 40
Summary
    We have discussed:
   What is middleware and its classification
   The current state of the art in middleware research
    and…
   Use this knowledge to derive a software engineering
    research agenda that will produce the principles,
    notations, methods and tools that are needed to support
    all activities during the SE process.




                                                    Middleware 41

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:5
posted:5/13/2012
language:
pages:41