CORBA-Based Enterprise System Development

Problems and Challenges

• • • • • Multiple platforms, languages and systems Mixture of client-server and mainframe-based applications built as stand-alone systems Proprietary, legacy systems Conflicting data formats and semantic definitions Integration not planned in original designs (c) Yi Deng, 1999 2

Possible Solutions

• • • • • • System development as composition rather than programming Middleware, design patterns and frameworks Component-based software engineering Standard-based open system development Building a standardized information technology infrastructure Planning and developing a long term architectural vision (c) Yi Deng, 1999 3

Component Software

• • • • Uniform access to services Uniform discovery of resources and object names Uniform error handling methods Uniform security policies (c) Yi Deng, 1999 4

Where to Begin?

• • • Uniform communication infrastructure – Platform (hardware, operating systems, communication protocols) independence – Uniform interaction protocol Transparent programming in heterogeneous environment – Language independence – – Location transparency Separation of interface and implementation Common building blocks – – Domain independent Domain specific (c) Yi Deng, 1999 5

Object Management Architecture

(c) Yi Deng, 1999 6

Problem I. Common Communication Infrastructure

• • Key: hide difference Issues: – – – – Difference in hardware communication Difference in network protocols and operating systems Difference in languages Difference in invocation methods and exception handling (c) Yi Deng, 1999 7

Solution: Common Object Request Broker Architecture (CORBA)

(c) Yi Deng, 1999 8

Role of Object Request Broker

(c) Yi Deng, 1999 9

How Does ORB Work?

(c) Yi Deng, 1999 10

Problem II. System Integration and Reuse

• • Key: standard component model Issues: – – – – How to describe an object/server/function/application How to find an object How to compose applications How to reuse object/components (c) Yi Deng, 1999 11

Goal: Ideal Integration Model

(c) Yi Deng, 1999 12

Toward A Scalable and Manageable Solution

(c) Yi Deng, 1999 13

Solution: Common Integration Infrastructure

• • • • • Separation of interface from implementation  Interface Definition Language (CORBA IDL) Services not objects  Independent interface specification Unified naming and invocation model Find services through interface repository Common services and facilities (c) Yi Deng, 1999 14

Mapping Solution to CORBA

(c) Yi Deng, 1999 15

How Does CORBA Work?

(c) Yi Deng, 1999 16

How Does CORBA Work? - continued

• • • Using IDL interface to separate client and object implementation from ORB – – Client only sees object interface not implementation Plug-and-play composition Client does not pass request directly to object – Request is always passed through ORB Result: location/language/OS/platform transparency (c) Yi Deng, 1999 17

How to Use CORBA - Role of OMG Language Mapping

(c) Yi Deng, 1999 18

How to Use CORBA - Producing IDL, Client/Object Implementation

(c) Yi Deng, 1999 19

How to Use CORBA - Integrating Imported Object with Client Implementation

(c) Yi Deng, 1999 20

Building CORBA Object: Summary

• • • • • • Define object interface using OMG IDL (p. 24/25) Making choices of – – – – – Implementation language runtime platform and OS the ORB it will connect to whether it will run local to its client or remotely the network hardware or protocol it will use, etc Write code for the object Compile IDL interface, which generates Stub and Skeleton code Linking implementation code with Skeleton code connects the object to the ORB Integrating purchased object/component (p.26) (c) Yi Deng, 1999 21

CORBA IDL

• • • • • • • IDL is pure specification, not implementation IDL file creates multiple language bindings Platform independence An IDL interface not necessarily correspond to single object implementation Interface inheritance supported Supports dynamic binding Supports multiple implementation (c) Yi Deng, 1999 22

IDL Example

(c) Yi Deng, 1999 23

IDL Specification of Course Registration Model

Module CourseRegistration { // Forward Declarations Interface Course; Interface FacultyMember; Interface Student { attribute string name; attribute string address; attribute unsigned long studentId; attribute string major; attribute float gradePointAverage; exception ClassFull {}; void enroll (in Course course) raises (ClassFull); exception HasNotCompleteReqts {}; void graduate () raises (HasNotCompleteReqts); Typedef sequence CourseList; CourseList class_list(); void notify_cancellation (in Course course); } (c) Yi Deng, 1999 24

IDL Specification - continued

interface Course { attribute string courseSubject; attribute unsigned short maxSize; enum SchoolSemesters {FALL, SPRING, SUMMER}; attribute SchoolSemesters semester; attribute unsigned long time; attribute string days; attribute unsigned short year; void register_student (in Student student); exception RoomSpaceUnavailable {}; void request_scheduling (in Time time, in string days, in SchoolSemesters semester, in unsigned short year, raises (RoomSpaceUnavailable); void cancel_class(); }; (c) Yi Deng, 1999 Interface FacultyMember { attribute String name; struct OfficeHours { string time, duration, days; }; attribute OfficeHours office_hours; attribute string office_address; attribute string department; exception TeachingLoadExceeded {}; void assign_class (in Course course) raises (TeachingLoadExceeded); typedef unsigned short TeachingHours; TeachingHours current_teaching_load (); }; }; 25

CORBA 2 Overview

(c) Yi Deng, 1999 26

Role of ORB

(c) Yi Deng, 1999 27

Role of ORB - A Software Bus

(c) Yi Deng, 1999 28

Principal CORBA Interfaces

(c) Yi Deng, 1999 29

Understanding the ORB: Client Side

• • • • • • Client requests may be passed to ORB through either static invocation interface (SII) or dynamic invocation interface (DII) SII decide object type and operation at compile time (static typing), DII at runtime (dynamic typing) Both allow dynamic binding – can select target object instance at runtime DII cannot check argument type correctness at compile time One IDL stub for each SI, while one DII shared by all dynamic invocations SII invocations generally synchronous (blocking), DII may be invoked synchronous, asynchronous or deferred synchronous (c) Yi Deng, 1999 30

IDL Stubs

• • • • • Client stub is automatically generated by IDL compiler Client specifies target object instance via its object reference and through object IDL interfaces Client-to-stub interface (marshalling) is defined by standard OMG language mapping Stub-to-ORB interface proprietary The role of client is simply to request services. Object activation, deactivation, suspension, etc. are either performed automatically by the ORB or by customized services located outside the client (c) Yi Deng, 1999 31

Dynamic Invocation Interface

• • • • • Trade off compile time type checking for runtime flexibility Gives a client the capability, at any time, of invoking any operation on any object it may access over the network Useful for accessing objects for which the client has no stub or discovered via naming or trading services.

Server cannot distinguish between SI an d DI 4 steps to a DI – Identify the object to be invoked (e.g. via Trader Service) – – – Retrieve its interface Construct the invocation Invoke the request and receive the request (c) Yi Deng, 1999 32

Management of IDL Interfaces - Interface Repository

• • Allows IDL definitions for objects be stored, modified, and retrieved Can be used by ORB to: – Provide interoperability between different ORB implementations – Provide type-checking of request signatures, whether a request was issued through the DII or a stub – To check the correctness of inheritance graphs (c) Yi Deng, 1999 33

Interface Repository - continued

• • For client objects and users – To manage installation and distribution of interface definitions around your network – To browse or modify interface definitions or other info stored in IDL – Compilers could compile stubs and skeletons directly from IR instead of from the IDL files Access IR – – Use utilities provided by ORB vendor Write code that invokes the standard IR IDL interface mandated by OMG (c) Yi Deng, 1999 34

Understanding the ORB: Implementation Side

• • CORBA principle: simple client, complex server Object builders must write code to handshake with ORB (c) Yi Deng, 1999 35

Implementation Side ORB Operation

(c) Yi Deng, 1999 36

Scenario of Object Invocation on Server Side

• • • • A server process runs distinct from the ORB ORB receives a request targeting an object in the server. ORB checks its repository and determines that neither the server nor the object is currently active ORB activates server, and server is passed the info it needs to communicate with the BOA Server calls

impl_is_ready

on the BOA, indicating that the server is ready to activate objects (c) Yi Deng, 1999 37

Scenario - continued

• • • • • BOA calls the server’s object activation routine for the target object, passing it the object reference. Server activates the object BOA passes the invocation to the object through the skeleton and receives the response, which it routes back to the client BOA may receive and pass additional request to the object Server may shut down an object using

deactivate_obj

Server may shut down entirely (c) Yi Deng, 1999 38

Server-Side Structure

(c) Yi Deng, 1999 39

Server-Side Components

• • • Object adapter provides interfaces between ORB and object, implementation depends on specific object implementation model ORB uses Dynamic Skeleton Interface (DSI) to create a proxy skeleton for objects, typically remote, whose static skeletons are not bound to it ORB interfaces provides operations on object references, access to interface and implementation repository (c) Yi Deng, 1999 40

Object Implementation Structure

• • • • • • Most objects are not running and active all the time ORB, CORBAServices work together to activate the objects when necessary Context switch hidden from user Responsibility of handling object state changes shifted to object implementor When writing an OMA-compliant object, you have to provide a way to save the object state at shut down and to checkpoint the object state No standard enforcement on this implementor responsibility (c) Yi Deng, 1999 41

Object Adaptors

• Responsible for – – – registering implementations generating and interpreting object references mapping object references to their corresponding implementations – – – activating and deactivating object implementations invoking methods, via skeleton or DSI coordinating interaction security, in cooperation with the Security Object service (c) Yi Deng, 1999 42

Server-Side Summary

• • • • • Thin clients, fat servers ORB handles transparent communication Object adapter provides interfaces between ORB and object implementation & represents implementation of object model To client, server always there, always available and always in consistent state Object implementation must support the realization of this client-side simplicity (c) Yi Deng, 1999 43

CORBAservices

• • • • • • • Representing basic functions needed by most application developments Reduced effort for application development and encourages compatible systems Bases for component-based software development Real savings for end-user companies adopting OMG technology Declared in IDL Explicit operation sequencing dependencies No implementation descriptions (c) Yi Deng, 1999 44

CORBAservices in OMA

(c) Yi Deng, 1999 45

CORBAservices Architecture

(c) Yi Deng, 1999 46

Event Service

• • • Defines generic interfaces for passing information among multiple sources and consumers Sources and consumers don’t need to have direct knowledge of each other, thus de-coupling consumers from event sources with grouping and delivery mechanism managed by the Service Can be used as multicast mechanism without direct connection between sender and receivers (c) Yi Deng, 1999 47

Event Service Functions

• • • • • Supports multiple styles of interaction (between application and the Service; two principal styles: push and pull PUSH - event source makes out call to consumers PULL - event source waits for consumer to make a call back in order to receive the next event notification PULL consists of polled and blocking mode Supports different styles of interactions simultaneously all interoperating at the same time through the same event channel (c) Yi Deng, 1999 48

Event Service Interfaces

(c) Yi Deng, 1999 49

Event Service Objects

• • Event factory object implements the Lifecycle service operations specific to the Event service, and responsible for creating event channel objects Event channel object supports several interfaces for event notification and other operations (c) Yi Deng, 1999 50

Event Service Scenario

(c) Yi Deng, 1999 51

Naming Service

• • • • • • A general directory service to be used by most applications Provides mapping between object name and reference Can be used as an interface wrapper over existing naming directory services Names maybe object names or operation names Name bindings are always relative to a scope called naming context; names are unique to their naming context Name resolution is mapping from name to object within a context (c) Yi Deng, 1999 52

Naming Context Hierarchy Example

(c) Yi Deng, 1999 53

Naming Services

• • • • Key operations: bind and resolve Primary objects in the Naming service are

naming context objects

Schema that defines the directory trees and the naming conventions used in these trees is an application design choice Names are represented as a sequence of structures. Each structure is a (name, kind) pair. The intention is that the structure sequence would be converted into path names for use in platform specific environment (c) Yi Deng, 1999 54

Naming Service

• Naming service usually requires following conventions defined – Definition of the local naming schema • • structure of naming contexts rules for extending the context – Definition of the local naming conventions • Well-known names • • conventions for new names semantics and values for the kind field (c) Yi Deng, 1999 55

Overview of CORBAdomains and CORBAfacilities

• • • CORBAdomains address interoperability within a vertical domain, e.g. healthcare, manufacturing, telecom, financial services, etc.

CORBAfacilities address interoperability across vertical domains by providing a set of common facilities, e.g. compound documents and system management facilities, needed by multiple domains CORBAservices focus on enabling capabilities, CORBAfacilities and CORBAdomains focus on interoperability issues (c) Yi Deng, 1999 56

More Detailed View of OMA

(c) Yi Deng, 1999 57

Horizontal CORBAfacilities

• • Distributed Document Component Facility (DDCF) – for transparent manipulation of compound documents in distributed environment – Based on OpenDoc specifications Common Management Facilities – – based on submission from X/Open consortium System management automates the handling of computer support services across a distributed enterprise, e.g. remote update & installation, monitoring and maintenance of security policies, etc (c) Yi Deng, 1999 58

Horizontal CORBAfacilities

• • Internationalization and Time Operations Facilities – Former supports multinational data types including output formats and conversions among formats – – Latter defines similar capabilities on time objects and conversions E.g. character classification, date/time formats, numeric formatting, monetary formatting, etc.

Data Interchange Facility – Interpretation, conversion and exchange among different data formats (c) Yi Deng, 1999 59

Primary Source of Information

• • • L. Bass, P. Clements and R. Kazman, “Software Architecture in Practice”, Addison Wesley, 1998 T.J. Mowbray and W.A. Ruh, “Inside CORBA - Distributed Object Standards and Applications”, Addison-Wesley, 1997 K. Wreder and Y. Deng, “Architecture-Centered Enterprise System Development and Integration Based on Distributed Object Technology”, Proceedings of COMPSAC’99.

(c) Yi Deng, 1999 60