Middleware, Service-Oriented Architectures and Grid Computing

1. Middleware, Service-Oriented Architectures and Grid Computing 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.

2. What is a Distributed Application? • Distributed Computing/Applications are … • Systems of Systems • 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!

3. What is a Distributed Application? Java Client Database Database Legacy COTS COTS Java Client Server Server Legacy Client DB Client COTS Client Legacy System of Systems Network Centric Environment Heterogeneity Hardware OS, PLs High-Availability Performance Dynamic Environment Increase Productivity New/Innovative Information Use Transparent Interoperation

4. Premise: Artifacts - set of DB, Legacy, COTS, GOTS, Each w/ API Premise: Users New and Existing Utilize Artifact APIs Distributed Application, DA Artifacts + Users What are the Issues? How Do they Interact? Heterogeneity Security Concerns Different Programmatic Models Etc. Etc. Etc. Another View – Today’s Reality Java Client Database COTS Legacy Legacy Client GOTS NETWORK GOTS Client Legacy Database Database Client COTS Client

5. Why is Distributed Computing Needed? • Today’s Environments Contain Applications … • Created with Multiple Prog. Languages • 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

6. Striving for New Techniques/Technologies • We Must Diverge from Business as Usual • C Programming with RPC • 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!

7. Who are the Players? • Stakeholders • Software Architects (Requirements) • 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?

8. Why a Distributed Application? • Reasons: • Data used is Distributed • Computation is Distributed • Application Users are Distributed • 2 Key Issues for Solution: • Platform-Independent Models and Abstraction Techniques • Hide Low-Level Details • Provide a Well-Performing Solution • Works Today and Tomorrow! Shared Objects • Easy to Re-use • Easy to distribute • Easy to maintain

9. Distributed Systems Fundamental Realities of Distributed Systems

10. 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

11. Service Registry Find Register Service Consumer Service Provider Bind, Execute What is Service Oriented Architecture (SOA)? • An SOA application is a composition of services • A “service” is the atomic unit of an SOA • Services encapsulate a business process • Service Providers Register themselves • Service use involves: Find, Bind, Execute

12. Service Registry Find Register Service Consumer Service Provider Bind, Execute SOA Actors • 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

13. Service Registry Find Register Service Consumer Service Provider Bind, Execute SOA Benefits Business Benefits • Focus on Business Domain solutions • Leverage Existing Infrastructure • Agility Technical Benefits • Loose Coupling • Autonomous Service • Location Transparency • Late Binding

14. What is a Service Oriented Architecture? • Solutions that Focus on Services that Need to be Available to Meet Need of Users (Entities) • 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

15. Middleware-Based SOA • Distributed Object Computing Platforms are Well Established in the Field - Historically • 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#

16. What Must All SOA Provide? • Both Middleware & Web-Based SOAs Must Provide • Middle Layer Infrastructure that Provides Bridge 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

17. SOA Akin to CBD

18. Supplier /Consumer Model SUPPLY Build New Wrap Existing Buy CONSUME Assemble Applications MANAGE Publish Subscribe Catalog Browse

19. Objectives of SOA • Can SOAs Support Highly-Available Distributed Applications? • 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?

20. Overview of Presentation • Objective is to Explore CORBA, JINI, and .NET • Various Aspects of Three Technologies • 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

21. What is CORBA? • Common Object Request Broker Architecture • Architecture to Allow: • 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

22. What is CORBA? • CORBA is a Specification for Interoperability • OMG (Object Management Group) Supplies a Set of Flexible Abstraction and Concrete Services • Vendors Must Follow Standard CORBA Language Mappings Ada C and C++ COBOL Java to IDL Lisp CORBA Scripting Language Smalltalk Others Perl Haskell Python Eiffel PHP/ORBit

23. What is CORBA? • Differs from Typical Programming Languages • Objects can be … • Located Throughout Network • Interoperate with Objects on other Platforms • Written in Ant PLs for which there is mapping from IDL to that Language

24. What is CORBA? • CORBA Provides a Robust set of Services (COS) • Services to Support Integration and Interoperation of Distributed Objects • Services Defined on top of ORB as standard CORBA Objects with IDL interfaces • Vendors Must Implement CORBA Services (COS) Object Life Cycle Naming Events Relationships Externalization Transactions Trader Query Property

25. What is CORBA? • Allow Interactions from Client to Server CORBA • Installed on All Participating Machines

26. CORBA: Architectural Goals • Simplicity • Consistency • 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

27. Role of an Object Request Broker (ORB) • ORB Provides the Underlying Infrastructure for Supporting Interoperating Software Systems (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

28. Interface Definition Language, IDL • Key Component of CORBA Is the Interface Definition Language, IDL • 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

29. ORB and High Level View of Requests • The Request Consists of • Target Object • Operation (Method) • Parameters • Request Context (Optional)

30. CORBA Components and Interfaces Client Object Implementation Object Adapter Dynamic Invoke Client Stubs ORB Interface Implementation Skeletons ORB Core One interface ORB internal interface One interface per object adaptor One interface per object operation • Client Stub: Client Invokes a Particular Object Op. • Dynamic Invocation: Run-Time-Construction of 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

31. Interfaces IDL Interface Definitions Implementation Installation Interface Repository Implementation Repository Client Stubs Implementation Skeletons Access Includes Includes Describes Client Object Implementation • Objects are Defined in IDL via Interfaces • Object Definitions (Interfaces) are Manifested as Objects in the Interface Repository, as Client Stubs, and as Implementation Skeletons • Descriptions of Object Implementations are Maintained as Objects in the Impl. Repository

32. CORBA: Repositories • Interface Repository • Client access to definitions • Type checking for signatures • Traversal of inheritance graphs • Implementation Repository • Location of implementation • Activation information • Administration control • Security • Resource allocation

33. Client Side Client Object Repository Object Implementation Dynamic Invoke Client Stubs ORB Interface Implementation Object Adapter Skeletons ORB Core • Clients Perform Requests Using Object References • Clients Issue Requests through Object Interface Stubs (Static) or DII (Dynamic Invocation Inter.) • Clients May Access General ORB Services: • Interface Repository (IR) • Context Management • Request Management

34. Object Implementation Side Object Implementation Implementation Repository Client Implem. ORB Interface Skeletons Dynamic Invoke Client Stubs Object Adapter ORB Core • Implementations Receive Requests Thru Skeletons • Object Adapter Adapts to Specifics of Object Implementation Schemes • Basic Object Adapter (BOA) Provides: • Management of References • Method Invocation • Authentication • Implementation Registration • Activation / Deactivation

35. CORBA • Basic Object Adapter (BOA) • Provides Basic Services to Allow Variety Of 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

36. CORBA: POA Policies • Provided to Programmer for Control Over an Object’s Identity, State, Storage and Life-cycle • 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

37. CORBA: POA Policies • Thread Policy - Depends on Number of Objects the Application Will Have • 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

38. CORBA: POA Policies • ID Assignment Policy - To specify whether Object ID was generated by the application or ORB • 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

39. Dynamic Invocation Interface (DII) • DII Allows Clients to Dynamically: • Discover Objects • Discover Objects’ Interfaces • 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

40. Request Components • Object Reference -- Identifies the Target Object • Operation -- Identifies Which Operation to Invoke (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

41. Repositories: Interface and Implementation • Interface Repository • Dynamic Client Access to Interface Definitions to 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

42. Three Types of ORBs Client Object Request ORB Client Object Request ORB • Single Process Library Resident • Client and Implementation Resident ORB and implementations implemented as libraries (routines) resident in the client. ORB implemented as libraries (routines) resident in the clients and in the implementations.

43. Three Types of ORBs Client Object Request ORB • Server or Operating System Based ORB is implemented as a server (separate process) which brokers requests between client and implementation processes. ORB is part of the operating system.

44. Three Types of Implementations Object Implementation Single Process Single method invocation Implementation is a single process that is activated upon the request delivery Object Implementation Single Process Method C Method B Method A • Single Process “one shot” Object • Multi-Threaded “resident” Object Implementation is a permanent or resident multi-threaded process

45. Three Types of Implementations Object Implementation Process 1 Method A Process 2 Method B Process 3 Method C • Multi-Process Object Implementation is a set of processes dedicated to a particular (group of) method(s) Processes can be distributed

46. Interface Definition Language, IDL • Language used to describe the interfaces that client objects call and object implementations provide. • 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”

47. IDL: Modules and Interfaces • Module: Used to scope IDL identifiers. • Mapped to C++ namespace with the same 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.

48. IDL: Basic Types

49. IDL: Complex Types • Structures: • struct FixedLengthStruct { 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};

50. IDL: Complex Types (cont.) • Sequences: One-dimensional array with maximum size (fixed at compile time) and length (set at run 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.