CORBA-Based Enterprise System Development - PowerPoint PPT Presentation

About This Presentation
Title:

CORBA-Based Enterprise System Development

Description:

Mixture of client-server and mainframe-based applications built as ... activating and deactivating object implementations. invoking methods, via skeleton or DSI ... – PowerPoint PPT presentation

Number of Views:30
Avg rating:3.0/5.0
Slides: 61
Provided by: dryi
Learn more at: https://cadse.cs.fiu.edu
Category:

less

Transcript and Presenter's Notes

Title: CORBA-Based Enterprise System Development


1
CORBA-Based Enterprise System Development
2
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

3
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

4
Component Software
  • Uniform access to services
  • Uniform discovery of resources and object names
  • Uniform error handling methods
  • Uniform security policies

5
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

6
Object Management Architecture
7
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

8
Solution Common Object Request Broker
Architecture (CORBA)
9
Role of Object Request Broker
10
How Does ORB Work?
11
Problem II. System Integration and Reuse
  • Key standard component model
  • Issues
  • How to describe an object/server/function/applicat
    ion
  • How to find an object
  • How to compose applications
  • How to reuse object/components

12
Goal Ideal Integration Model
13
Toward A Scalable and Manageable Solution
14
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

15
Mapping Solution to CORBA
16
How Does CORBA Work?
17
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

18
How to Use CORBA - Role of OMG Language Mapping
19
How to Use CORBA - Producing IDL, Client/Object
Implementation
20
How to Use CORBA - Integrating Imported Object
with Client Implementation
21
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)

22
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

23
IDL Example
24
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 sequenceltCoursegt CourseList
  • CourseList class_list()
  • void notify_cancellation (in Course course)

25
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()
  • 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 ()

26
CORBA 2 Overview
27
Role of ORB
28
Role of ORB - A Software Bus
29
Principal CORBA Interfaces
30
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

31
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

32
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

33
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

34
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

35
Understanding the ORB Implementation Side
  • CORBA principle simple client, complex server
  • Object builders must write code to handshake with
    ORB

36
Implementation Side ORB Operation
37
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

38
Scenario - continued
  • BOA calls the servers 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

39
Server-Side Structure
40
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

41
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

42
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

43
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

44
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

45
CORBAservices in OMA
46
CORBAservices Architecture
47
Event Service
  • Defines generic interfaces for passing
    information among multiple sources and consumers
  • Sources and consumers dont 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

48
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

49
Event Service Interfaces
50
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

51
Event Service Scenario
52
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

53
Naming Context Hierarchy Example
54
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

55
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

56
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

57
More Detailed View of OMA
58
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

59
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

60
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 COMPSAC99.
Write a Comment
User Comments (0)
About PowerShow.com