Middleware, Service-Oriented Architectures and Grid Computing by rsr13049

VIEWS: 126 PAGES: 140

									        Middleware, Service-Oriented
      Architectures and Grid Computing
CSE
300
                          Prof. Steven A. Demurjian

                Computer Science & Engineering Department
                      The University of Connecticut
                     371 Fairfield Road, Box U-2155
                          Storrs, CT 06269-2155
                         steve@engr.uconn.edu
                   http://www.engr.uconn.edu/~steve
                           (860) 486 - 4818




      † Special Thanks to Prof. Alex Shvartsman, Keith Bessette, Scott Craig
      and Prior CSE333 students for providing portions of this material.
                                                                         MW+SOA-1
            What is a Distributed Application?
         Distributed Computing/Applications are …
CSE         Systems of Systems
300
            Interoperation of New & Existing Applications
            Legacy, Databases, COTS, New Clients, etc.
            Network Centric Environment
         Distributed Computing Applications must …
            Manage, Control, Access, and Modify Data
            Allow Humans to Interact with Data
            Provide High-Availability and Performance
            Evolvable Over Time
         Present & Future Army Systems Exhibit All of
          These Characteristics and More!


                                                        MW+SOA-2
            What is a Distributed Application?

CSE
300        System of Systems                Network Centric Environment
        Heterogeneity          Performance                     High-Availability
         Hardware
         OS, PLs            Legacy              DB Client
                            Client                                 Java
                                       Legacy         Server       Client
                        Database

                                       Server
                        COTS                            Database
                                                                      COTS
                   Java            Legacy        COTS                 Client
  Dynamic          Client

 Environment                                Increase Productivity
                                 New/Innovative
      Transparent Interoperation
                                 Information Use
                                                                               MW+SOA-3
              Another View – Today’s Reality
         Premise: Artifacts - set of
CSE         DB, Legacy, COTS,
300           GOTS, Each w/ API         Database                COTS
         Premise: Users
                                                    Legacy             Legacy
            New and Existing
                                                                       Client
            Utilize Artifact APIs
                                        Java
         Distributed Application, DA   Client
                                                                           GOTS
            Artifacts + Users
                                                    NETWORK
         What are the Issues?
            How Do they Interact?
            Heterogeneity                                             GOTS
                                                                       Client
            Security Concerns
                                        Legacy
            Different Programmatic
                                                                Database
              Models
            Etc. Etc. Etc.
                                         Database      COTS
                                          Client       Client
                                                                       MW+SOA-4
          Why is Distributed Computing Needed?
         Today’s Environments Contain Applications …
CSE         Created with Multiple Prog. Languages
300
            Executing on Heterogeneous Platforms
            Locally and Geographically Distributed
         Distributed Computing Applications Must …
            Allow Seamless and Transparent Interoperation
            Provide Tools for Engineers and Users
         Result: Inter-Operating Environment
            Utilize Information in New/Innovative Ways
            Leveraged to Increase Productivity
            Support Diverse User Activities
            Dynamically Respond to Changes



                                                        MW+SOA-5
      Striving for New Techniques/Technologies
         We Must Diverge from Business as Usual
CSE        C Programming with RPC
300
           Customized Development without Reuse
           Solutions that Aren’t Extensible and Evolvable
           Cobbling Together Solutions w/o Method or
            Reason is Unacceptable and Doomed to Fail!
         We Must Face Today’s Realities
           Legacy Code is Fact of Life
           New Technologies Offer New Challenges
           Adopt to Leverage Their Benefits
           We Must Draw Careful Balance to Opt for
            Mature Technologies While Targeting
            Emerging Technologies with Potential!
                                                        MW+SOA-6
                    Who are the Players?
         Stakeholders
CSE         Software Architects (Requirements)
300
            System Designers (Solutions)
            Application Builders (Implementation)
         Stakeholders Striving to Provide …
            System Interaction and Information Exchange
            Utilization of Existing Applications in New and
             Innovative Ways
         End-Users at Various Skill Levels and with Specific
          and Limited Access Requirements
            Novice vs. Adept vs. Expert
            Who Uses What When and for How Long?



                                                         MW+SOA-7
             Why a Distributed Application?
         Reasons:
CSE
            Data used is Distributed
300
            Computation is Distributed
            Application Users are
             Distributed
         2 Key Issues for Solution:
            Platform-Independent
             Models and Abstraction
             Techniques                               Shared Objects


            Hide Low-Level Details
            Provide a Well-Performing    • Easy to Re-use
                                          • Easy to distribute
             Solution                     • Easy to maintain
            Works Today and
             Tomorrow!
                                                                  MW+SOA-8
                     Distributed Systems
      Fundamental Realities of Distributed Systems
CSE
300

                              Co-located             Distributed

       Communication              Fast                  Slower

                                                      Objects fail
          Failures        Objects fail together   separately, Network
                                                     can partition
                          Only with multiple
      Concurrent Access                                  Yes
                               threads
                                                    Not Inherently
           Secure                 Yes               Often Add-On
                                                     Capability



                                                                     MW+SOA-9
                       Service Oriented Architecture
                       & Grid Computing


       Marc Brooks, The MITRE Corporation

       The author's affiliation with The MITRE Corporation is provided
       for identification purposes only, and is not intended to convey or
       imply MITRE's concurrence with, or support for, the positions,
       opinions or viewpoints expressed by the author.

http://colab.cim3.net/file/work/EmergingTechnology_Conference/2004-06-03_MITRE/Brooks_2004_03_24.ppt
What is Service Oriented Architecture (SOA)?

 An SOA application
  is a composition of
  services                          Service
                                    Registry
 A “service” is the
  atomic unit of an
  SOA                          Find        Register

 Services encapsulate
                        Service       Bind,      Service
  a business process Consumer Execute Provider
 Service Providers
  Register themselves
 Service use involves:
  Find, Bind, Execute
                                                                Service
                                                                Registry

SOA Actors                                               Find        Register

                                                     Service     Bind,     Service
                                                    Consumer    Execute    Provider




   Service Provider
     Provides   a stateless, location transparent business
      service
   Service Registry
     Allows service consumers to locate service providers
      that meet required criteria
   Service Consumer
     Uses service providers to complete business
      processes
                                              Service
                                              Registry

SOA Benefits                           Find        Register

                                   Service     Bind,     Service
                                  Consumer    Execute    Provider


Business Benefits
 Focus on Business Domain solutions
 Leverage Existing Infrastructure
 Agility


Technical Benefits
 Loose Coupling
 Autonomous Service
 Location Transparency
 Late Binding
          What is a Service Oriented Architecture?
          Solutions that Focus on Services that Need to be
CSE        Available to Meet Need of Users (Entities)
300
          Users are Assumed to be Interacting via Client
           Applications (Browser or Standalone)
             Interactions with Services Transparent to Users
               (Integrated into Software)
          Interactions Between Entities Occur via a Message
           Exchange - Conceptual
             Resources are Software Artifact Accessible via
               API Consisting of Services
             Services are Logical Grouping of Methods
               (Functions) that are Available for Use
             Services are Utilized When Messages are Invoked
               Against Them by Outside Users
          Both Web-Based and Middleware Settings
                                                        MW+SOA-14
                 Middleware-Based SOA
         Distributed Object Computing Platforms are Well
CSE       Established in the Field - Historically
300
            DCE (Distributed Computing Environment)
            COM/OLE (Component Object Model/Object
             Linking and Embedding)
         Modern Middleware (JINI, CORBA, .NET):
            CORBA –Standards Committee (OMG) Controls
             Technology – Many Programming Languages
            JINI – Sun-Based Product – The Poor Mans
             CORBA – Java
            .NET – Microsoft’s Forward into the Modern
             Market – C#



                                                     MW+SOA-15
               What Must All SOA Provide?
         Both Middleware & Web-Based SOAs Must Provide
CSE        Middle Layer Infrastructure that Provides Bridge
300
             Between Software Artifacts
               Clients and Resources in Middlware Setting
               Clients (Browsers) and Resources in Web Setting
            Allow Software Artifacts (Resources) to
             Register/Publish their APIs (Services and
             Methods) for use by Clients/Other Resources
         Lookup Service: Middleware for Artifacts (Resources
          and/or Clients and/or Other Resources) to Interact
            Support Dynamic Discovery – Find Services
             Based on Attributes and Values
            Location Transparency to Service Requestors
            Found Service Sets up Binding Between Service
             Consumer and Service Provider
                                                              MW+SOA-16
      SOA Akin to CBD
CSE
300




                        MW+SOA-17
        Supplier /Consumer Model
CSE   SUPPLY
300                                 CONSUME
       Build New
                                     Assemble
       Wrap Existing
                                     Applications
       Buy




                       MANAGE
                        Publish
                        Subscribe
                        Catalog
                        Browse




                                                    MW+SOA-18
                      Objectives of SOA
         Can SOAs Support Highly-Available Distributed
CSE       Applications?
300
         Can Replicated Services be Registered and Available
          for Use by Clients?
         Can SOAs Support a Network-Centric Environment
          with Dynamic Clients and Services?
         Will Clients Continue to Operate Effectively if a
          Replicated Service Fails?
         Can SOAs be Utilized to Maintain Data Consistency
          of Replicas?
         Are SOAs Easy to Learn and Use?
         What is Maturity Level of SOAs Technology?


                                                        MW+SOA-19
                  Overview of Presentation
         Objective is to Explore CORBA, JINI, and .NET
CSE      Various Aspects of Three Technologies
300
            Overall Architecture
            Interoperability Capabilities
            Access and Usage
         Exploration of Web Service-Oriented Architectures
            What are they?
            How do they Work?
            WSOAs + Middleware
         Transition to Grid Computing
            What is the Grid?
            What is its Purpose and Role
            Grid + SOA + Middleware

                                                        MW+SOA-20
                        What is CORBA?
         Common Object Request Broker Architecture
CSE      Architecture to Allow:
300
           Existing COTS, GOTS, Legacy, DB, etc. to
             Interact with One Another
           Integrate These with New Clients/Servers/Etc.
         Consists of Following Major Components
           Object Request Broker (ORB):
               Arbitrate and Interact
               Role of Lookup for Service Discovery
             Interface Definition Language (IDL):
               Common Definitional Format
               Means for Different “Software” written in Different
                Languages to Interact with One Another

                                                                MW+SOA-21
                    What is CORBA?
         CORBA is a          CORBA Language Mappings
CSE
300       Specification for            Ada
          Interoperability          C and C++
         OMG (Object                 COBOL
          Management                Java to IDL
                                       Lisp
          Group) Supplies a       CORBA Scripting
          Set of Flexible            Language
          Abstraction and            Smalltalk
          Concrete Services           Others
                                       Perl
         Vendors Must                Haskell
          Follow Standard             Python
                                       Eiffel
                                    PHP/ORBit
                                                    MW+SOA-22
                      What is CORBA?
         Differs from Typical Programming Languages
CSE      Objects can be …
300
           Located Throughout Network
           Interoperate with Objects on other Platforms
           Written in Ant PLs for which there is mapping
             from IDL to that Language
                     Application
                                                     Domain Interfaces
                     Interfaces




                              Object Request Broker




                                   Object Services


                                                                         MW+SOA-23
                        What is CORBA?
         CORBA Provides a Robust set of Services (COS)
CSE         Services to Support Integration and Interoperation of
300          Distributed Objects
            Services Defined on top of ORB as standard CORBA
             Objects with IDL interfaces
            Vendors Must Implement CORBA Services (COS)



                                                         Object Life
                             Naming             Event    Cycle
             Factory                                     Naming
                             Context           Channel
                                                         Events
                                                         Relationships
                                                         Externalization
                                                         Transactions
                       Object Request Broker             Trader
                                                         Query
                                                         Property



                                                                 MW+SOA-24
                                        What is CORBA?
           Allow Interactions from Client to Server CORBA
CSE        Installed on All Participating Machines
300
                   Client Application                              Server Application




          Static                      ORB                    ORB          Skel
                                                                                 DSI
                      DII           Interface              Interface      eton
          Stub
                                                                                    Object Adapter



                   Client ORB Core              Network            Server ORB Core




                                                Same for all                 There may be multiple
                   IDL - Independent
                                                applications                 object adapters

                                                                                                     MW+SOA-25
               CORBA: Architectural Goals
         Simplicity
CSE      Consistency
300
         Scalability
         Usability for End Users
         Usability for Administrators
         Usability for Implementers
         Flexibility of Security Policy
         Independence of Security Technology
         Application Portability
         Interoperability
         Performance
         Object Orientation


                                                MW+SOA-26
          Role of an Object Request Broker (ORB)
          ORB Provides the Underlying Infrastructure for
CSE        Supporting Interoperating Software Systems
300
           (Applications) Composed of Distributed Objects
             ORB Provides the Basic Request Delivery
             ORB Provides Interface Definitions
          Location is Transparent to the Caller and Object
           Implementation
          Caller and the Object Implementation Can be in the
           Same Process thru Opposite Sides of the World
          ORB Manages Local Location and Optimization
                            OR B
              Clie nt                     Obje ct
           Applica tion              I mple me nta tion




                                                          MW+SOA-27
           Interface Definition Language, IDL
         Key Component of CORBA Is the Interface
CSE       Definition Language, IDL
300
            Mapping is Available in C, C++, Java, Ada, Etc.
            IDL Is Independent of Any Language/Compiler
            Multiple Inheritance
            Public Interface Oriented
            Not for Implementation
         Primary Support for Interoperability Between Static
          and Dynamic Request Mechanisms
         Advantage: Modification of Client Code without
          Impacting of Server Code, and vice-versa
         Disadvantage:
            A complete new language with C++ like Syntax
            Programmers Must Prepare IDL Modules
                                                         MW+SOA-28
          ORB and High Level View of Requests
         The Request Consists of
CSE         Target Object
300
            Operation (Method)
            Parameters
            Request Context (Optional)


             Clie nt                            Obje ct
           Applica tion                     I mple me nta tion

              Obje ct Ca ll                 Me thods a nd D a ta




          I D L Bounda ry         OR B       I D L Bounda ry

           Obje ct re fe re nce   Request   Obje ct dispa tche r



                                                               MW+SOA-29
           CORBA Components and Interfaces
         Client Stub: Client Invokes a Particular Object Op.
CSE      Dynamic Invocation: Run-Time-Construction of
300       Operation Invocations
         Implementation Skeleton: Interface Through Which a
          Method Receives a Request
         Object Adapter: Provides (De)activation, Object
          Creation/Reference Mgmt. for Implementations
         ORB Interface: Common ORB Operations

                     Client                                   Object Implementation


                                                              Implementation      Object
           Dynamic        Client            ORB                 Skeletons
            Invoke        Stubs           Interface                               Adapter

                                         ORB Core

                         One interface                           ORB internal interface
                         One interface per object adaptor
                         One interface per object operation
                                                                                          MW+SOA-30
                                          Interfaces
         Objects are Defined in IDL via Interfaces
CSE      Object Definitions (Interfaces) are Manifested as
300
          Objects in the Interface Repository, as Client Stubs,
          and as Implementation Skeletons
         Descriptions of Object Implementations are
          Maintained as Objects in the Impl. Repository

                          IDL Interface                              Implementation
                           Definitions                                 Installation




             Interface               Client         Implementation        Implementation
            Repository               Stubs            Skeletons             Repository


          Access              Includes           Includes            Describes


                         Client                      Object Implementation        MW+SOA-31
                              CORBA: Repositories
         Interface Repository                               Implementation Repository
CSE          Client access to                                          Location of
300           definitions                                                implementation
             Type checking for                                         Activation information
              signatures                                                Administration control
             Traversal of                                              Security
              inheritance graphs                                        Resource allocation


                              IDL Interface                              Implementation
                               Definitions                                 Installation




                        Interface             Client               Implementation                 Implementation
                       Repository             Stubs                  Skeletons                      Repository

              Access
                                                   Includes   Includes                                      Describes



                                    Client                                          Object Implementation
                                                                                                                    MW+SOA-32
                                 Client Side
         Clients Perform Requests Using Object References
CSE      Clients Issue Requests through Object Interface Stubs
300
          (Static) or DII (Dynamic Invocation Inter.)
         Clients May Access General ORB Services:
            Interface Repository (IR)
            Context Management
            Request Management

                             Client

        Object
      Repository
                                                      Object Implementation



                   Dynamic     Client       ORB
                    Invoke     Stubs      Interface   Implementation          Object
                                                        Skeletons
                                                                              Adapter


                                        ORB Core

                                                                              MW+SOA-33
                      Object Implementation Side
         Implementations Receive Requests Thru Skeletons
CSE      Object Adapter Adapts to Specifics of Object
300
          Implementation Schemes
         Basic Object Adapter (BOA) Provides:
            Management of References
            Method Invocation
            Authentication
            Implementation Registration
            Activation / Deactivation

                                   Object Implementation


                                                                 Implementation
                Client
                                               Implem.             Repository
                                    ORB       Skeletons
            Dynamic      Client   Interface
             Invoke      Stubs                  Object Adapter
                                   ORB Core
                                                                             MW+SOA-34
                                            CORBA
         Basic Object Adapter (BOA)
CSE         Provides Basic Services to Allow Variety Of
300
             CORBA Objects to be Created – Ambiguous
         Portable Object Adapter (POA)
            Allow Developers yo Construct Object
             Implementations that are Portable Between ORBs
            Mediator Between ORB And Server

                                            Server Applications

                                                                  Servants

          Client                      ORB               POA

                   Incoming Request




                                                                             MW+SOA-35
                   CORBA: POA Policies
         Provided to Programmer for Control Over an Object’s
CSE       Identity, State, Storage and Life-cycle
300
         7 Different Policies
            Thread Policy
            Life-Span Policy
            Object ID Uniqueness Policy
            ID Assignment Policy
            Servant Retention Policy
            Request Processing Policy
            Implicit Activation Policy
         We Briefly Review each in Turn



                                                       MW+SOA-36
                   CORBA: POA Policies
         Thread Policy - Depends on Number of Objects the
CSE       Application Will Have
300
            Depends on Operating System
            Expected Load on System
             ORB_CTRL_MODEL/SINGLE_THREAD_MODEL
         Life Span Policy - Transient object cannot live
          beyond the process which created it
            Persistent object can live beyond the process
             which created it
            TRANSIENT / PERSISTENT
         Object ID Uniqueness Policy
            UNIQUE_ID / MULTIPLE_ID




                                                             MW+SOA-37
                   CORBA: POA Policies
         ID Assignment Policy - To specify whether Object ID
CSE       was generated by the application or ORB
300
            USER_ID / SYSTEM_ID
         Servant Retention Policy: States if POA retains active
          servants in object map
            RETAIN / NON_RETAIN
         Request Processing Policy: States how request
          processed by the POA
            USE_ACTIVE_OBJECT_MAP_ONLY /
              USE_DEFAULT_SERVANT /
              USE_SERVANT_MANAGER
         Implicit Activation Policy: Indicates if Implicit
          activation of servants is supported by POA
            IMPLICIT_ACTIVATION /
              NO_IMPLICIT_ACTIVATION
                                                          MW+SOA-38
           Dynamic Invocation Interface (DII)
         DII Allows Clients to Dynamically:
CSE        Discover Objects
           Discover Objects’ Interfaces
300

           Create Requests
           Invoke Requests (-> Methods)
           Receive Responses
         Major DII Features:
           Requests Appear as Objects
           Requests are Reusable
           Invocation May be Synchronous or Asynchronous
           Requests Can be Generated Dynamically,
             Statically or Using Both Approaches


                                                    MW+SOA-39
                    Request Components
         Object Reference -- Identifies the Target Object
CSE      Operation -- Identifies Which Operation to Invoke
300
          (Which Method Will Be Executed)
         Parameters -- Input, Output or Inout Method Arg-s
         Context Object -- the Context Within Which the
          Request Is to Be Performed
         Results -- the Result Value(s) Returned
         Environment -- the Exec-n Env-t and Exception Info.
         Request Handle -- the Id. For This Request Instance




                                                        MW+SOA-40
      Repositories: Interface and Implementation
         Interface Repository
CSE         Dynamic Client Access to Interface Definitions to
300
              Construct a Request
            Dynamic Type Checking of Request Signatures
            Traversal of Inheritance Graphs
         Implementation Repository
            Location of Implementations and Methods
            Activation Information
            Administration Control
            Resource Allocation
            Security




                                                         MW+SOA-41
                       Three Types of ORBs
         Single Process Library Resident
CSE
300

           Client             Object    ORB and implementations
                                        implemented as libraries
                                        (routines) resident in
                                        the client.
                    Request
          ORB

         Client and Implementation Resident


           Client             Object    ORB implemented as
                                        libraries (routines) resident
                                        in the clients and in the
                                        implementations.
                    Request
          ORB




                                                                        MW+SOA-42
                       Three Types of ORBs
         Server or Operating System Based
CSE
300


                                        ORB is implemented as
            Client             Object   a server (separate process)
                                        which brokers requests
                                        between client and
                     Request            implementation processes.
           ORB
                                        ORB is part of the
                                        operating system.




                                                                      MW+SOA-43
             Three Types of Implementations

CSE
300
           Single Process “one shot” Object
      Object Implementation           Implementation is a single
          Single Process              process that is activated
                                      upon the request delivery
                    Single
                    method
                    invocation



           Multi-Threaded “resident” Object
      Object Implementation           Implementation is a permanent
                                      or resident multi-threaded
          Single Process              process

                     Method C
                       Method B
                         Method A




                                                                   MW+SOA-44
               Three Types of Implementations

CSE      Multi-Process Object
300




          Object Implementation          Implementation is a set
            Process 1         Method A   of processes dedicated to
                                         a particular (group of)
            Process 2         Method B   method(s)

            Process 3         Method C   Processes can be distributed




                                                                        MW+SOA-45
            Interface Definition Language, IDL
         Language used to describe the interfaces that client
CSE       objects call and object implementations provide.
300
         Obeys the same lexical rules as C++, but introduces
          some new keywords.
         Supports standard C++ preprocessing features.
         Interfaces can have operations and attributes.
            Operation declaration consists of a return type, an
              identifier, a parameter list, and an optional raises
              expression (exceptions).
            Attribute declaration is logically equivalent to
              declaring a pair of accessor operations. May be
              declared as readonly.
         Interface specifications are placed in a source file
          having the extension “.idl”

                                                             MW+SOA-46
               IDL: Modules and Interfaces
         Module: Used to scope IDL identifiers.
CSE         Mapped to C++ namespace with the same
300
              name. Mapped to a C++ class if the namespace
              construct is not supported.
            Mapped to Java package with the same name.
            IDL declarations not enclosed in any module have
              global scope when mapped.
         Interface: Description of set of operations that a
          client may request of an object.
            Multiple inheritance supported
            Interface body may contain the following kinds of
              declarations: constant, type, attribute, and
              operation.


                                                         MW+SOA-47
                 IDL: Basic Types

CSE   Type             Range
300
      short            -215 .. 215-1 (16-bit)
      unsigned short   0 .. 216-1 (16-bit)
      long             -231 .. 231-1 (32-bit)
      unsigned long    0 .. 216-1 (32-bit)
      float            IEEE single-precision floating point
      double           IEEE double-precision floating point
      char             8-bit quantity
      boolean          TRUE or FALSE
      octet            8-bit (guaranteed during transmission)
      any              values that can express any IDL type

                                                                MW+SOA-48
                   IDL: Complex Types
         Structures:
CSE         struct FixedLengthStruct {
300
                long          field1; // 32-bit
                short         field2; // 16-bit
             };
            struct VariableLengthStruct {
                long          field1; // 32-bit
                string        field2;
             };
         Discriminated Unions: Cross between the C union
          and switch statements.
         Enumerations: Ordered list of identifiers.
            enum quality_t {
                Poor, Fair, Good, Excellent};

                                                     MW+SOA-49
               IDL: Complex Types (cont.)
         Sequences: One-dimensional array with maximum
CSE       size (fixed at compile time) and length (set at run
300
          time).
            Unbounded Sequence:
              typdef sequence<long> longSeq;
            Bounded Sequence:
              sequence<long,10> fieldname;
         Strings: Declared using keyword string. May be
          bounded or unbounded.
            string name<32>; //bounded
         Arrays: Multidimensional, fixed-size arrays of any
          IDL data type.



                                                        MW+SOA-50
                            IDL Example: GUI

CSE   /*                                                interface Dialog1 {
       * File Name:     GUI.idl                            void update(in Dialog1Data_t val);
300    */                                               };

      #ifndef GUI_IDL                                   interface Dialog2 {
      #define GUI_IDL                                      void update(in Dialog2Data_t val);
                                                        };
      module GUI {                                 };

       struct timespec_t {                         #endif       // GUI_IDL
          long tv_sec;
          long tv_nsec;
       };

       struct Dialog1Data_t {
          timespec_t     DataTime;
          float          val;
       };

       struct Dialog2Data_t {
          timespec_t     DataTime;
          long           val;
       };

       interface MainWindow {
          void logEvent(in timespec_t timestamp,
                        in string val);
       };


                                                                                      MW+SOA-51
                        IDL Example: Server

CSE   /*                                void registerDialog1(
       * File Name:   Server.idl            in GUI::Dialog1 val,
300    */                                   in boolean flag)
                                            raises (OperationTimeout);
      #ifndef SERVER_IDL                  void setDialog1Enabled(
      #define SERVER_IDL                    in boolean flag)
                                            raises (OperationTimeout);
      #include "GUI.idl"                  GUI::Dialog1Data_t getDialog1Data()
                                            raises (OperationTimeout,
      interface Server {                            NotAvailable);

       enum reason_t {                    void registerDialog2(
          NotInitialized,                   in GUI::Dialog2 val,
          ErrorDetected                     in boolean flag)
       };                                   raises (OperationTimeout);
       exception NotAvailable {           void setDialog2Enabled(
          reason_t reason;                  in boolean flag)
       };                                   raises (OperationTimeout);
                                          GUI::Dialog2Data_t getDialog2Data()
       exception OperationTimeout {};       raises (OperationTimeout,
                                                    NotAvailable);
       void registerMainWindow(         };
         in GUI::MainWindow val,
         in boolean flag)               #endif   // SERVER_IDL
         raises (OperationTimeout);
       void setMainWindowEnabled(
         in boolean flag)
         raises (OperationTimeout);


                                                                          MW+SOA-52
                         What is JINI?
         An Infrastructure for Network Centric Applications in
CSE       Spontaneous Environment
300
            Clients Enter/Leave Network Unpredictably
            Resources and Services Enter/Leave due to
             Failure, Redundancy, Topology Change
            Both Typify Present/Future Army Systems
         Goals of JINI
            Plug-and-Play of Clients and Services
            Erasing Hardware/Software Distinction:
             Everything is a Service
            Enable Spontaneous Network Applications
            Architecture where Services Define Function
            Strive for Easy to Use/Understand Technology


                                                         MW+SOA-53
                  Sun’s JINI Technology
         JINI is a Sophisticated Java API
CSE      Construct Distributed Applications Using JINI by
300
            Federating Groups of Users
            Resources Provide Services (Database Access,
             Printing, Real-Time Sensor) for Users
         JINI and Stakeholders
            Core of Technologies to Architect, Design,
             Implement, and Test Distributed Applications
            Construct Software “Resistant” to Failure
         JINI and Users
            High Availability Through Redundancy
            Dynamic Responses to User Requests
             Regardless of Network & Resource Changes

                                                    MW+SOA-54
      Java Computing Architecture and JINI

CSE
300




                                         MW+SOA-55
      JINI Components and Dependencies

CSE
300

               Infrastructure   Programming    Services
                                Model
      Base     Java VM          Java APIs      JNDI
      Java
               RMI              JavaBeans      Enterprise Beans
               Java Security                   JTS
                                               JMS
      Java +   Discovery/Join   Leasing        Transaction
      JINI                                     Manager
               Distributed      Transactions   JavaSpaces
               Security
               Lookup           Events         Lookup service



                                                             MW+SOA-56
                   How Does JINI Work?
         Distributed Application Constructed Using One or
CSE       More Lookup Services
300
         Lookup Service Support Interactions by
            Resources: “Advertise” Services
             Discover, Register Services, Renew Lease
            Client: “Locate/Utilize” Services
             Discover, Search for Services, Invocation
         Multiple Lookup Services
            Resources Responsible for Registering All
            Clients Interact with Multiple Lookups
            Stakeholders Must Write “Apropos” Code
         Discovery Initiates Process for Client or Resource

                                                          MW+SOA-57
          Discovery by Resource & Client

CSE
300

                     JINI      JINI
                    Lookup    Lookup
                    Service   Service



        Discovery to               Discovery to
      Locate Services              Register Services


                                        Resource
               Client                   Service Object
                                        Service Attributes




                                                             MW+SOA-58
                     Basic JINI Concepts
         JINI Lookup Service Maintains Registry for
CSE       Available Services of Distributed Application
300
         Resources Provide Services that Register and Join
          with JINI Lookup Service
         Clients Discover and Utilize Services Based on
          Interface of Services
            Ask Lookup for RegisterForCourse(CSE900)
            Return Proxy for Execution of Service
            Location of Service Transparent to Client
         Locations of Clients, Services, Lookup Service, etc.,
          can Change over Time
         Conceptually, JINI Similar to Distributed OS with
          Dynamically Definable/Changeable Resources

                                                           MW+SOA-59
                      Basic JINI Concepts
         A Resource Provides a Set of Services for Use by
CSE       Clients (Users) and Other Resources (Services)
300
         A Service is Similar to a Public Method
           Exportable - Analogous to API
           Any Entity Utilized by Person or Program
           Samples Include:
               Computation, Persistent Store, Printer, Sensor
               Software Filter, Real-Time Data Source
               Anything that is Relevant for Your Domain!
            Services: Concrete Interfaces of Components
         Services Register with Lookup Service
            Clearinghouse for Resources to Register Services
             and Clients to Locate Services

                                                                 MW+SOA-60
               JINI Resources & Services

CSE
300
                         Register
                         Services
            JINI                      Printer Resource
           Lookup
                                       Service Object
           Service                     Service Attributes

         Sun’s Initial Perspective                    PrinterActions Class
            JINI for Hardware         Class and          enqueuePrintJob
                                       Methods            dequeuePrintJob
            Printers, Digital
                                                          getPrinterStatus
              Cameras, etc.            Define             getPrinterType
            Plug-and-Play on          Services           installPrinter
              Network                  to be              removePrinter
                                                          startJob
         PrinterActions Class Defines Registered         cancelJob
          the “Component” that is
          Registered with JINI
                                                                      MW+SOA-61
               Objectives and Utility of JINI
         For Users, JINI Offers
CSE         Sharing of Resources (Services) over Network
300
            Location Transparency of Users and Services
            Both Critical for “Moving” Personnel
         For Stakeholders, JINI Provides
            Infrastructure for Federating Services in
             Distributed Setting
            Programming Model to Register & Discover
             Services
            Availability of Services Throughout Distributed
             Setting
          Leading to Ease in Constructing, Maintaining, and
          Evolving Network Centric Applications

                                                         MW+SOA-62
                   How Does JINI Work?
         Resources Discover and Join Lookup Service
CSE      When Resources Leave or Fail to Renew Leases
300
           Lookup Service Must Adjust Registry
           Time Lag Between Departure and Removal of
             Services from Registry
           What Happens When Client Receives Service
             Just Prior to Failure?
           Utilization of Java Exception Handling
           Client Code Written to Dynamically Adapt
         Resource Register
           Services on Class-by-Class Basis
           Service Object (Java API - Method Signatures)
           Optional Descriptive Service Attributes


                                                      MW+SOA-63
                  JINI Concepts and Terms
         Registration of Services via Leasing Mechanism
CSE         Resource Leases Services to Lookup Service
300
            Resources Renew Services Prior to Expiration
            If not, Services Become Unavailable
            Lookup Service Maintains Registry
            Limit Availability of Services Based on Time,
             Workload, User Requirements, etc.
            Services as Available “Components”
         Leasing Supports High-Availability
            Registration and Renewal Process
            Upon Failure, Services Removed from Registry
         Clients, Resources, Lookup Can Occupy Same or
          Different Computing Nodes

                                                        MW+SOA-64
                      Registration & Leasing
         FOREVER or EXPIRATION DATE (millisecs)
CSE      Renewal Must Occur Prior to Expiration
300
         JINI Provides Lease Renewal Manager to Allow
          Resource to Delegate Renewal Responsibility

             JINI        Leasing/Lease Renewal       Printer Resource
            Lookup
                                                      Service Object
            Service                                   Service Attributes

  Lease for 5 minutes (3000000 msec)             Class and    PrinterActions Class
                                                                 enqueuePrintJob
  Must Renew Before 5 Minutes Expire             Methods
                                                 Define          dequeuePrintJob
                                                                 getPrinterStatus
  If Not Renewed, Lookup Removes                 Services
                                                                 getPrinterType
                                                 to be
  If Failure, Lookup May Still Supply            Registered      installPrinter
                                                                 removePrinter
    Service Until Expiration (5 mins)                            startJob
                                                                 cancelJob
  Client MUST be SMART!
                                                                           MW+SOA-65
      JINI Support for Distributed Computing

CSE
300    Clients                   Redundant
                   JINI Lookup   Lookups
       Using         Service                              Resources
       Services                                           Provide
       Java                                               Services
                                      Database   Legacy
       Client
                                                            COTS
        Java
        Client
                                                            Legacy
        Legacy
        Client
                                                            COTS
        Database
         Client
                                                          Database

        COTS            JINI Lookup
        Client            Service          Legacy    COTS
                                                               MW+SOA-66
              Component Perspective and JINI
         Resources as Components
CSE        Resources Provide Services
300
           What Service Provides: Component Interface
           Clients, Servers, Resources, Use Component
             Interface to Design/Construct Functionality

            Java                                             Legacy
            Client

                                                             COTS
                                    JINI
 Constructed via Services of       Lookup
   Legacy, COTS, Database, etc.    Service
                                                         Database
 Lookup Registered Services
 Functionality via Service Reuse
 Services as Component APIs
                                             Legacy   COTS
                                                                MW+SOA-67
                  Two Example Resources
         University Application
CSE         Students can Register/Drop Courses and Check
300
             the Schedule/Catalog
            Faculty can Alter Course DB and Check the
             Schedule/Catalog
         Military Application - Database of Parts
            Ability to Requisition/Add/Delete Parts
            Different User Authority Based on Rank
         For Both:
            Client to JINI to Discover Services
            Client to Resource for Method Invocation
             (Resembles RMI)


                                                       MW+SOA-68
      What Does an Actual System Look Like?

CSE
300                     Java                   Java
                        GUI                    GUI
                      UDB Client             MDB Client




                                                          MDBServer
                                                          GetParts
                                                          GetRequisition
      UDBServer Service
                                                          GetReqParts
      GetClasses();
                                                          WriteParts
      PreReqCourse();
                                    JINI                  WriteRequisition
      GetVacantClasses();
                                                          DeletePart
      EnrollCourse();              Lookup                 DeleteRequisition
      AddCourse();                 Service                AddParts
      RemoveCourse();
                                                          RemovePart
                                                          AddRequisition
           University DB
          Resource (UDB)
                                                             Military
                                                            Requisition
                                                               DB
                                                             Resource


                                                                     MW+SOA-69
       Join, Lookup, and Service Invocation

CSE
300                         Lookup Service
      Request
                             Registry of Entries
      Service
                                Service Object
      AddCourse(CSE900)
                                Service Attributes


                     Return                          J Register & Lease Services
                     Service                         o   CourseDB Class
                    Proxy to                         i Contains Method
                 AddCourse( )                        n    AddCourse ( )

                                                              Resource
            Client    Service Invocation via Proxy
                       by Transparent RMI Call                Service Object
                                                              Service Attributes

            1. Client Invokes AddCourse(CSE900) on Resource
                  2. Resource Returns Status of Invocation
                                                                            MW+SOA-70
             Services of Military Application
         Query Service:
CSE         GetParts: Queries DB for Parts
300
            GetRequisition: Queries DB for Requisition
            GetReqParts: All Requisition Details for a
             Particular Part
         Update Service:
            WriteParts: Store Part to DB
            WriteRequisition: Requisition Changes to DB
            DeletePart: Deletes Part from DB
            DeleteRequisition: Deletes Requisition from DB
         Other Services/Methods Omitted
         Notice: These are Just Public Methods Organized into
          Logical Groupings
         JINI Allows Searching of Groupings by Service
                                                        MW+SOA-71
      Execution Process of Client using JINI

CSE
                  1 Register_Client(Harris,Security Off., Military)
300
      Military                                                                       Security
      Client                                                                        Registration
                    4 Return Result,Create_Token(Security Off., Token)
                                                                                     Services
                                            2 Verify_UR(Harris, Security Off.)
                                                                                        3 Client OK?

                  5. Discover/Lookup(MilitaryDb,Modification,
                      CreateRequisition) Returns Proxy to Military Client

      6 CreateRequisition(Token, Tank Details, Harris)
                                                                                          USR
                                                                                      Security
                 11 Return Result,CreateRequisition(…)
                                                                Lookup              Authorization
                                                                Service               Services
                    7 IsClient_Registered(Token)
                    9 Check_Privileges(Token, MilitaryDb, Modification,
                                       CreateRequisition, [Tank Details, Harris])
                                                                                      Security
        MilitaryDB                                                                     Policy
         Resource          8 Return Result of IsClient_Registered(…)
                                                                                      Services

                            10 Return Result of Check_Privileges(…)


                                                                                                   MW+SOA-72
      Services Console

CSE
300




                         MW+SOA-73
      Services GUI

CSE
300




                     MW+SOA-74
                        What is .NET?
         .NET is Microsoft’s Solution to Enterprise Computing
CSE       and Interoperability
300
         Aimed to Compete with Java/J2EE
         Interoperability: Old (CORBA, COM) & New (RMI)
         Provides Uniform Programming Environment via
          Extension of C - C#




                                                        MW+SOA-75
                              .NET Architecture and Usage
              Three Level Architecture
CSE           XML and DataSet as Objects of Interaction
300
          Presentation Tier

      Windows Forms
          MyApp.Exe


                              DataSet



                                                   Business Tier                        Data Tier
                                        Internet
      Web Forms                         Intranet
                                                   Data Object (Class)
          IE
                                                                         Data Adapter
                                                            DataSet
                                        XML
                              DataSet
                                                                         Data Adapter




          Business to Business




      (BizTalk, for example)




                                                                                               MW+SOA-76
                What are .Net Components?
         CTS (Common Type System)
CSE        Defines Common Standard for Languages
300
         CLR (Common Language Runtime)
           Manages the Execution of a .Net Application
           Provides Cross Platform Support By Ensuring
              Type Safety, Code Verification, Exception Handling
              Garbage Collection and Memory Management
              Note: Akin to Java Runtime Environment
         ASP.NET
           This Component Provides a Layer of Classes for
            Web Services



                                                             MW+SOA-77
               What are .Net Components?
         Windows Forms
CSE        Provides A Layer Of Classes For The Windows
300
             User Interface
         ADO.NET
           Provides Classes for Data Access Including
             Database and XML
         Base Class Library
           Low Level Classes Capture Core .Net
             Functionality
           Provides Infrastructure for Construction of
             Remaining .net Framework Classes




                                                    MW+SOA-78
                        Remoting in .Net
         Remoting Makes an Object in One Process Available
CSE       to an Application in Another Process (Akin to RMI)
300
         Marshalling Enables a Controlled Data
          Communication Between the 2 Processes
         Marshalling an Object Can Occur in 2 Ways
            Marshall By Value:
               Server Creates a Copy of the Object and Passes the
                Copy to the Client
             Marshall By Reference:
               Server Creates a Reference of the Object and Sends
                this Reference to the Client




                                                               MW+SOA-79
                     Remoting in .NET

CSE
300




      When a client calls an object marshalled by reference
      of the object in the client’s application domain and the
      client uses that proxy to access that original object on
                              the server
                                                          MW+SOA-80
                    Remoting in .NET

CSE
300




      When a client calls an object marshaled by value the
       server creates and exact copy and sends that copy
         to the client. The client then uses the data of the
          object and executes the required functionality
          directly within the client’s own process without
              making any additional calls to the server
                                                        MW+SOA-81
                   Recall Similarity to RMI in Java
          Java Objects in JVMs (on Different Computers)
CSE
300
           Transparently Invoke Each Other's Methods
          RMI Enables Distributed Object Computing
                       Client                      Server              Hello


                  HelloApplet                            HelloImpl

                                                                       rmic HelloImpl.java
            5                     1                         2          3

                Stub            Stub                   Skel           Skel

          Unmarshall       Marshall                 Unmarshall   Marshall

                                       RMI Layer
            NDR             NDR                        NDR           NDR

          Transport       Transport     Start rmiregistery
                                                     Transport   Transport

                                            4
                                                                                      MW+SOA-82
                 Web Services ASP.NET
         Communication Based on Open Protocols
CSE        Data via XML
300
           Schema via XSD
         Other Supported Protocols Inlcude:
           UDDI
           DISCO
           WSDL
           SOAP




                                                  MW+SOA-83
      ADO.NET Architecture

CSE
300




                             MW+SOA-84
                 CORBA vs. JINI vs. .NET
         Important to Differentiate Between
CSE         Standard (CORBA) – Vendors Implement
300
            Technologies (JINI, .NET)
         Many Different Pros and Cons w.r.t. Infrastructure,
          Usage, Environment, Interoperability, Ease of Use,
          Programming Requirements, etc. etc. etc.
         Many Different Perspectives to Compare Capabilities
          and Functionalities of Technologies

         What about Other Approaches?
           Terrific Presentation by D. Schmidt
           Combines Patterns and Middleware
           http://www.cs.wustl.edu/~schmidt/patterns-
            frameworks-middleware.ppt
                                                         MW+SOA-85
                    Brief Comparison…
         Database Connectivity
CSE         Java uses JDBC and .Net uses Ado.net or
300
             ODBC.NET
         Cross platform interoperability
            J2EE and CORBA Easily Supports Interoperation
             .Net Focuses on Windows Platform
         Programming Languages
            .Net and CORBA Support Multiple Languages
             J2EE Focuses on Java (with Links to IDL)
         Cross Vendor Interoperability
            J2EE and CORBA Guaranteed by Specifications
             Microsoft is the only vendor for .Net
         Remoting: Strong Similarities Across All Three

                                                     MW+SOA-86
      Web Service Oriented Architectures (WSOA)
         An SOA is often Cast in a Web-Based Setting
CSE      Possible Services include:
300
            Data Transfer (e.g. FTP) or Storage Service
            Troubleshooting Service
         Service Operations (Messages) are Encapsulated
          Behind a Message-Oriented Service Interface
            Hides Details of Service Implementation/Location
            Assumes an Architecture for Access
            Provides a Logical View that is Message-Oriented
            Available Service/Messages are Descriptively
             Supplied for Purpose of Discovery/Lookup
            Network-Oriented
            Scalable – Add New Services/Extend Existing
             Services for New/Improved Functionality
                                                        MW+SOA-87
                      WSOA in Practice
         From Web Services Architecture, W3C
CSE       A Web service is a software system designed to
300
          support interoperable machine-to-machine
          interaction over a network. It has an interface
          described in a machine processable format
          (specifically WSDL). Other systems interact with the
          Web service in a manner prescribed by its description
          using SOAP messages, typically conveyed using
          HTTP with an XML serialization in conjunction with
          other Web-related standards.




                                                         MW+SOA-88
          Web Services Architecture from W3C
         Complex
CSE       Architecture with
300
          Many Different
          Capabilities and
          Features
            Open Ended
             (Like Web)
            Target Multiple
             Domains/Usages
         Current Web and
          Future (Emerging?)
          Semantic Web



                                           MW+SOA-89
                      Another WSOA Example

CSE
300




      From: http://www.service-architecture.com/
                                                   MW+SOA-90
                      Another WSOA Example

CSE
300




      From: http://www.service-architecture.com/
                                                   MW+SOA-91
Service Oriented Architecture
      Reference Model
            An informal SOA Ontology



http://ontolog.cim3.net/file/resource/workshop/jul-2006/soa2006-07.ppt
         Reference Model
• An abstract framework for
  understanding significant relationships
  among the entities of some
  environment.
• Consists of a minimal set of unifying
  concepts, axioms and relationships
  within a particular problem domain.
• Is independent of specific standards,
  technologies, implementations, or other
Reference Model
Service Oriented Architecture
• Service Oriented Architecture is a
  paradigm for organizing and utilizing
  distributed capabilities that may be
  under the control of different ownership
  domains.
• Goal of this reference model is to define
  the essence of Service Oriented
  Architecture
      Why Service Oriented
         Architecture?
• Drivers:
  • Large scale Enterprise systems
  • Internet scale provisioning of services
  • Reduce the cost of doing business
• Benefits
  • Build scalable, evolvable systems
     • Scalable because minimizes assumptions
  • Manage complex systems
  • Encourage re-use of business function
         Why is it different?
• SOA reflects the reality of ownership
  boundaries
  • CORBA, RMI, COM, DCOM, etc. all try to
    implement transparent distributed systems
  • Ownership is of the essence in SOA
• SOA is task oriented
  • Services are organized by function
     • Getting something done
• SOA is inspired by human organizations
  • It worked for us, it should work for machines
      What is not in the RM
• Service composition
  • Choreography, orchestration
  • Process Oriented Architecture
• Organizational framework
  • Who is doing what to whom
• Specific technologies
  • not even specific architectures
Key concepts
                             Service
• A mechanism to enable access to
  one or more capabilities
   • using a prescribed interface
   • consistent with constraints and
     policies as specified by the service
     description.
                             Visibility
Visibility is the relationship
between service participants that is
satisfied when they are able to
interact with each other



• Awareness
     • Service description
     • Discovery
• Willingness
     • Policy & contract
• Reachability
     • Communication
                             Interaction
 Interacting with a service involves performing actions against the service




The extent to which one system can
effectively interpret information from
another system is governed by the
semantic engagement of the
various systems.
The semantic engagement of a
system is a relationship between the
system and information it may
encounter.
                 Real World Effect
The purpose of using a capability is to realize one or more real world effects.
At its core, an interaction is “an act” as opposed to “an object” and the
result of an interaction is an effect (or a set/series of effects).



                                    The real world effect is couched
                                    in terms of changes to the state shared by
                                    the participants and stakeholders in
                                    a service interaction
About Services
     Conditions and Expectations



• Policy
   • Constraint representing the
     intention of a participant in a
     service
• Contract
   • Constraint representing an
     agreement between two or
     more participants.
                          Description
  The service description
  represents the information
  needed in order to use,
  manage or provide a
  service.




• Service reachability
• Service Functionality
• Service Policies
• Service Interface
             Execution Context
The execution context is the set of infrastructure elements,
process entities, policy assertions and agreements that are
identified as part of an instantiated service interaction,
and thus forms a path between those with needs and those
with capabilities
    Is a Reference Model an
           Ontology?
• Establishing a vocabulary
  • A lot of definitions
     • The RM glossary has 28 entries
• Formality was considered
  • Audience is not formal
  • Mechanical processing of RM not expected
           What about UML
• UML obvious choice for an architecture
  spec
• But,
  • Inheritance (is-a) relationship almost never
    used
  • Extraneous precision
     • E.g. we tried to define Service, not count the
       number of service providers
  • It’s so ugly <duck/>
An early concept map
          Concepts Maps
Concepts maps
were excellent
graphical
indices
to text




                     Concepts, and
                     relationships.
                     All we needed
On the cutting-room floor…
                      Where we are
 • Committee Specification published
 • Reference Architecture effort started




http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
                   Comments on WSOA
         Wealth of Information on WSOA Available on-Line
CSE      Let’s Review Four Other Presentations Briefly
300
            http://download.microsoft.com/download/b/d/b/bd
              b24175-50bc-4e74-8df9-
              835cef6521cb/ConnectedSystems.ppt
            http://www.cs.queensu.ca/home/cords/soa.ppt
            http://www.rgoarchitects.com/Files/SOA.ppt
            http://www.wsmo.org/TR/d17/resources/200605-
              OASIS/SemanticServiceOrientedArchitectureTuto
              rial.ppt
         All Links on Course Web Page
         Last Presentation Transitions from SOA to Semantic
          Web

                                                      MW+SOA-114
             Service Oriented Architecture
             & Grid Computing


Marc Brooks, The MITRE Corporation

The author's affiliation with The MITRE Corporation is provided
for identification purposes only, and is not intended to convey or
imply MITRE's concurrence with, or support for, the positions,
opinions or viewpoints expressed by the author.
   What is Grid Computing?

“A computational grid is a hardware and software infrastructure
  that provides dependable, consistent, pervasive, and
  inexpensive access to high-end computational capabilities.”
   -”The Grid: Blueprint for a New Computing Infrastructure”, Kesselman & Foster


      Criteria for a Grid*:
      1. Coordinates resources that are not subject
         to centralized control.
      2. Uses standard, open, general-purpose
         protocols and interfaces.
      3. Delivers nontrivial qualities of service
Source: “What is the Grid? A Three Point Checklist”, Ian Foster, Argonne National Laboratory & University of Chicago
Grid Computing Benefits

   Exploit Underutilized resources
       CPU Scavenging, Hotspot leveling

 Resource Balancing
 Virtualize resources across an enterprise
       Data Grids, Compute Grids

   Enable collaboration for virtual
    organizations
Two Key Grid Computing Groups
The Globus Alliance (www.globus.org)
 Composed of people from:
     Argonne National Labs, University of Chicago, University of Southern
       California Information Sciences Institute, University of Edinburgh and
       others.
   OGSA/I standards initially proposed by the Globus Group
       Based off papers “Anatomy of the Grid” & “Physiology of the Grid”

The Global Grid Forum (www.ggf.org)
 History
       First meeting in June of 1999, Based off the IETF charter
   Heavy involvement of Academic Groups and Industry
       (e.g. IBM Grid Computing, HP, United Devices, Oracle, UK e-Science
        Programme, US DOE, US NSF, Indiana University, and many others)
   Process
     Meets three times annually
     Solicits involvement from industry, research groups, and academics
Companies involved in Grid Computing
    Avaki                    Jivalti                 Powerllel
    Axceleon                 Mithral                 ProcessTree
    CapCal                   Mind Electric           Sharman Networks Kazza
    Centrata
                              Mojo Nation             Sun Gridware
    DataSynapse
    Distributed Science      NewsToYou.com           Sysnet Solutions
    Elepar                   NICE, Italy             Tsunami Research
    Entropia.com             Noemix, Inc.            Ubero
    Grid Frastructure        Oracle                  United Devices
    GridSystems
                              Parabon                 Veritas
    Groove Networks
    IBM                      Platform Computing      Xcomp
    Intel                    Popular Power




Source: http://www.gridcomputing.com/
Standards involved with SOA & Grid Computing

SOA Standards            Grid Standards
 WSDL                    OGSI
 UDDI                      Extension   to WSDL
 BPEL                    WS-Resource
                            WS-ResourceLifetime
 WS-Profile
                            WS-
 WS-Security                ResourceProperties
 WS-Choreography           WS-
                             RenewableReferences
                            WS-ServiceGroup
And many others…
                            WS-BaseFaults
   Grid and Web Services Standards



 Started far
  apart in                                            WS-I Compliant
applications
                Have been                              Technology
      &         converging                                Stack
technology                                   WSRF




           Convergence of Core Technology Standards allows
          Common base for Business and Technology Services
Service Oriented Architecture
“What is Service-Oriented Architecture?”. Hao He.
   http://webservices.xml.com/lpt/a/ws/2003/09/30/soa.html
“Service-Oriented Architecture: A Primer”. Michael S. Pallos.
   http://www.bijonline.com/PDF/SOAPallos.pdf
“The Benefits of a Service-Oriented Architecture”. Michael Stevens.
   http://www.developer.com/design/article.php/1041191
Web Services Specifications - http://www.w3.org/2002/ws/

Grid Computing
Global Grid Forum (http://www.ggf.org)
The Globus Alliance ( http://www.globus.org)
“The Physiology of the Grid”. Ian Foster, Carl Kesselman, Jeffrey M.
   Nick, Steven Tuecke. http://www.globus.org/research/papers/ogsa.pdf
“The Anatomy of the Grid”. Ian Foster, Carl Kesselman, Steven Tuecke.
   http://www.globus.org/research/papers/anatomy.pdf
Web Services Resource Framework - http://www.globus.org/wsrf/
        What is the Grid?

• The World Wide Web provides seamless access to information that
is stored in many millions of different geographical locations

• In contrast, the Grid is an emerging infrastructure that provides
seamless access to computing power and data storage capacity
distributed over the globe.

From: http://gridcafe.web.cern.ch/gridcafe/demos/Grid-beginners.ppt
       What is the Grid?
• The term Grid was coined by Ian Foster and Carl
Kesselman (Grid bible “The Grid: blueprint for a new
computing infrastructure”).

• The name Grid is chosen by analogy with the
electric power grid: plug-in to computing power
without worrying where it comes from, like a toaster.

• The idea has been around under other names for a
while (distributed computing, metacomputing, …).

•This time, technology is in place to realise the
dream on a global scale.
         How will it work?
• The Grid relies on advanced software, called middleware, which
ensures seamless communication between different computers and
different parts of the world

• The Grid search engine will not only find the
data the scientist needs, but also the data
processing techniques and the computing
power to carry them out

• It will distribute the
computing task to
wherever in the world
there is spare
capacity, and send the
result to the scientist
           How will it work?
The GRID middleware:
• Finds convenient places for the scientists “job” (computing task) to be run
• Optimises use of the widely dispersed resources
• Organises efficient access to scientific data
• Deals with authentication to the different sites that the scientists will be
using
• Interfaces to local site authorisation
and resource allocation policies
• Runs the jobs
• Monitors progress
• Recovers from problems


… and ….
Tells you when the work is complete and transfers the result back!
         What are the challenges?
Must share data between thousands of scientists with multiple
interests

Must link major computer centres, not just PCs

Must ensure all data accessible anywhere, anytime

Must grow rapidly, yet remain reliable for more than a decade

Must cope with different management policies of different centres

Must ensure data security: more is at stake than just money!

Must be up and running by 2007
        Benefits for Science
• More effective and seamless collaboration of dispersed
communities, both scientific and commercial

• Ability to run large-scale applications comprising thousands of
computers, for wide range of applications

• Transparent access to distributed resources from your desktop,
or even your mobile phone

• The term “e-Science” has been coined to express these
benefits
       Grid projects in the world
                                                       •UK e-Science Grid
                                                       •Netherlands – VLAM, PolderGrid
                                                       •Germany – UNICORE, Grid proposal
•NASA Information Power Grid                           •France – Grid funding approved
•DOE Science Grid                                      •Italy – INFN Grid
•NSF National Virtual Observatory                      •Eire – Grid proposals
•NSF GriPhyN                                           •Switzerland - Network/Grid proposal
•DOE Particle Physics Data Grid                        •Hungary – DemoGrid, Grid proposal
•NSF TeraGrid                                          •Norway, Sweden - NorduGrid
•DOE ASCI Grid
                               •DataGrid (CERN, ...)
•DOE Earth Systems Grid
                               •EuroGrid (Unicore)
•DARPA CoABS Grid              •DataTag (CERN,…)
•NEESGrid                      •Astrophysical Virtual Observatory
•DOH BIRN                      •GRIP (Globus/Unicore)
•NSF iVDGL                     •GRIA (Industrial applications)
                               •GridLab (Cactus Toolkit)
                               •CrossGrid (Infrastructure Components)
                               •EGSO (Solar Physics)
          Grid Applications for Science
• Medical/Healthcare (imaging, diagnosis and
treatment )
• Bioinformatics (study of the human genome and
proteome to understand genetic diseases)
• Nanotechnology (design of new materials from the
molecular scale)
• Engineering (design optimization, simulation, failure
analysis and remote Instrument access and
control)
• Natural Resources and the Environment
(weather forecasting, earth observation, modeling
and prediction of complex systems)
         Medical/Healthcare Applications
                                                   “The Grid will enable a
• Digital image archives                           standardized, distributed digital
• Collaborative virtual environments               mammography resource for
                                                   improving diagnostic
• On-line clinical conferences                     confidence"


                                       “The Grid makes it possible to use
                                       large collections of images in new,
                                       dynamic ways, including medical
                                       diagnosis.”


                                 “The ability to visualise 3D
                                 medical images is key to
                                 the diagnosis of
                                 pathologies and pre-
                                 surgical planning”




                                                       Quotes from: http://gridoutreach.org.uk
         Bioinformatics
• Capturing the complex and evolving patterns of genetic
information, determining the development of an embryo
• Understanding the genetic interactions that underlie the processes
of life-form development, disease and evolution.




    “Every time a new genome
    is sequenced the result is
    compared in a variety of
    ways with other genomes.
    Each code is made of 3.5
    billion pairs of chemicals…”
         Nanotechnology
• New and 'better' materials
• Benefits in pharmaceuticals, agrochemicals, food production,
  electronics manufacture from the faster, cheaper discovery of new
  catalysts, metals, polymers, organic and inorganic materials




                      “The Grid has the potential
                      to store and analyze data on
                      a scale that will support
                      faster, cheaper synthesis of
                      a whole range of new
                      materials.”




                                                     Quotes from: http://gridoutreach.org.uk
         Natural Resources/Environment
• Modeling and prediction of earthquakes
• Climate change studies and weather forecast
• Pollution control
• Socio-economic growth planning, financial modeling and
  performance optimization

                       “Federations of
                       heterogeneous databases
                       can be exploited through
                       the Grid to solve complex
                       questions about global
                       issues such as
                       biodiversity.”




                                                   Quotes from: http://gridoutreach.org.uk
        Precursors of the Grid
• SETI@home: sharing of spare PC processing power to analyze
radio signals

• Napster: sharing of data (music) between computers

• Entropia DCGrid: commercial solution for sharing workstations
within a company


The difference:
The Grid CERN is developing will combine resources at major
computer centers, and require dedicated equipment and
sophisticated middleware to monitor and allocate resources
       SETI@home: a grassroots Grid
>1 million years of computer processing time
>3.5 million have downloaded the screensaver
>30 Teraflops rating (ASCI White = 12 Teraflops)
              Spinoff from SETI@home

Spawned a cottage industry
Xpulsar@home, Genome@home, Folding@home,
evolutionary@home, FightAIDS@home, SARS@home...

Spawned a real industry
Entropia, United Devices, Popular Power...


Major limitations:
Only suitable for “embarrasingly parallel” problems
Cycle scavenging relies on goodwill
          Who will use Grids?
• Computational scientists & engineers: large scale
modeling of complex structures

• Experimental scientists: storing and analyzing large
data sets

• Collaborations: large scale multi-institutional projects

• Corporations: global enterprises and industrial
partnership

• Environmentalists: climate monitoring and modeling

• Training & education: virtual learning rooms and
laboratories
              Comments on Grid Computing
         What is Applicability of Grid Computing to the
CSE       Medical Domain and its Applications?
300
         Let’s Review Three Other Presentations Briefly
            http://www.aci-
              agir.org/publis/posterAgirParistic2006.PPT
            http://bmi.osu.edu/resources/presentations/BISR_o
              verview_poster.ppt
            http://www.dma.unina.it/~murli/ISSGC06/session
              -
              31.5/ISSGC06%20Experience%20with%20biome
              d%20applications%20v1.ppt
         All Links on Course Web Page



                                                        MW+SOA-139
                       Final Comments
         Three Converging Technologies:
CSE         Classic (CORBA) and Emerging (Jini, .NET)
300
             Middleware
            Web-Based Service Oriented Architectures and
             Computing
            Grid Computing
         Think back to “Macro Architectures”
            Systems of Systems
            Old + New
            Centralized + Distributed
            Solving “Huge” Problems
            Facilitating Access (Services)




                                                      MW+SOA-140

								
To top