Presentation is loading. Please wait.

Presentation is loading. Please wait.

Seminarium on Component-based Software Engineering Jan Willem Klinkenberg CORBA.

Similar presentations


Presentation on theme: "Seminarium on Component-based Software Engineering Jan Willem Klinkenberg CORBA."— Presentation transcript:

1 Seminarium on Component-based Software Engineering Jan Willem Klinkenberg CORBA

2 01/06/2015Seminarium CBSE2 Object Management Group (OMG)  Consortium of Computing Industry  Founded in 1989  Non profit  around 800 members  Goal: standardization of “whatever it takes” to achieve interoperability on all levels of an open market for “objects”

3 01/06/2015Seminarium CBSE3 OMG  Original effort: fix “wiring” problem: How can distributed object-oriented systems implemented in different languages and running on different platforms interact?  Incompatibility between compilers  Differences in object models  Differences in platforms Solution: CORBA

4 01/06/2015Seminarium CBSE4 CORBA  Common Object Request Broker Architecture. Open standard 1991 – version 1.0  Initial version. 1995 – version 2.0  IIOP  OMA  More languages support 2002 – version 3.0  Corba Component Model (CCM)  Scripting languages support

5 01/06/2015Seminarium CBSE5 CORBA  CORBA - Common Object Request Broker Architecture.

6 01/06/2015Seminarium CBSE6 IDL  Interface Definition Language Defines all object interfaces in a common language Bindings are available for C, C++, Java, Python, Smalltalk, Cobol, etc… An IDL compiler generates stubs and skeletons.  Stubs: Looks like local object Marhals arguments Forwards all invocations through ORB to target object  Skeletons: Receives invocations from ORB Unmarshals arguments Invokes target methods Sends back return value

7 01/06/2015Seminarium CBSE7 IDL – example module Example { struct Date { unsigned short Day; unsigned short Month; unsigned short Year; }; interface Ufo { readonly attribute unsigned long ID; readonly attribute string Name; readonly attribute Date FirstContact; unsigned long Contacts(); void RegisterContact(out Date dateOfContact); };

8 01/06/2015Seminarium CBSE8 IDL types  IDL distinguishes between basic and constructed type and CORBA object references.  Before CORBA 2.3, only references  Since CORBA 2.3, call by value is supported -> standard mapping by XML

9 01/06/2015Seminarium CBSE9 DII and DSI Sometimes binding can be too static: DII Dynamic invocation interface DSI Dynamic skeleton interface (since Corba 2.0) These interfaces allow for dynamic selection of methods at client side or server side

10 01/06/2015Seminarium CBSE10 ORB  Object Request Broker Routes the method invocations Interface repository Implementation repository Can load and start object servants Can communicate with other ORBs using IIOP

11 01/06/2015Seminarium CBSE11 CORBA and OMG IDL Dynamic invocation interface IDL stubs ORB interface Object Adapter Object Request Broker (ORB) Applications Programs IDL compiler Object servants IDL Skeletons Dynamic Skeleton interface IDL source

12 01/06/2015Seminarium CBSE12 Object Adapter  Object servants register with ORB via the object adapter.  Servants are loaded and started by ORB via adapter.  BOA – Basic Object Adapter Under specified, deprecated in 1998  POA – Portable Object Adapter Replaced the BOA Essential for several CCM features Creates object references Several possible policies for object creation

13 01/06/2015Seminarium CBSE13 Server, client or both  Separation of client and called object does not impose an asymetric architecture.  The same process can issue and receive calls.  Pure application programs do not require registration with ORB

14 01/06/2015Seminarium CBSE14 CORBA v.1 - Problems  An ORB is essentially an remote incovation service  Replaces sockets and remote procedure calls in distributed applications with a cleaner model So what’s the problem?  Applictions still have to share many conventions to interoperate  OMG had to broaden it’s focus.

15 01/06/2015Seminarium CBSE15 OMA - Object Management Architecure  Since CORBA 2.0  Adds new areas of standardization: CORBAservices  Common object services e.g.: naming, trader event, security CORBAfacilities – defines a specific component framework than can be used to integrate components.  Horizontal: domain independent, focus on specific application models e.g. printing facilities  Vertical: domain specific e.g. healtcare, finance Application object specifications (currently void) CCM - CORBA Component Model (since 3.0)

16 01/06/2015Seminarium CBSE16 CORBA Services supporting enterprise distributed computing  Naming service White pages  Trader service Yellow pages  Event service Send event objects from event suppliers to event consumers.  Notification service Add QoS, filtering, etc. to Event service  Object transaction service  Security Service Encryption, authentication

17 01/06/2015Seminarium CBSE17 CORBA Services supporting architecture using fine-grained objects  Concurrency control service Lock and release resources  Licensing service For non-freeware objects  Lifecycle service Creation, copying, moving and deletion of objects  Relationship service Not used or implemented  Persistant state service Allows storing and retrieving of objects

18 01/06/2015Seminarium CBSE18 CORBA Services continued…  Externalization service Mapping of object into stream and back  Properties service Add/delete and retrieve arbitrary properties to objects  Object query service (not implemented) Locate object instance by attributes  Object collections service (not implemented) Provides collection types like sets, trees, queues or lists.  Time service Provides a universal time for the distributed system

19 01/06/2015Seminarium CBSE19 CCM - Corba Component Model  Introduced with CORBA 3.0 in 2002  Logical extension of Enterprise JavaBeans  Is an architecture for defining components and their interactions  Provides a packaging technology  Provides a container implementation framework (CIF)

20 01/06/2015Seminarium CBSE20 CCM Component My Business Component Component interface Facets Event sources Event sinks Attributes Receptacles OFFERED REQUIRED

21 01/06/2015Seminarium CBSE21 CCM Components features  Ports Facet – provided interface Receptacle – required interface Event sources Event sinks  Primary keys Instance identification for client  Attributes  Home interfaces Provides factory functionality

22 01/06/2015Seminarium CBSE22 CCM packaging CCM Assembly CCM Component Segments Deployment configuration CCM Component

23 01/06/2015Seminarium CBSE23 CCM Containers  Component instances are placed inside containers: Component C Home interface Callbacks Services Components interact with POA as well as transaction, security, persistence and notification services via interfaces on their container Home for C Container

24 01/06/2015Seminarium CBSE24 Components types  There are different types of components: Service Session Entity Process

25 01/06/2015Seminarium CBSE25 CIF  Component Implementation Framework Described in CIDL, Component implementation Definition Language Creates programming skeletons that automate many of the basic behaviors of components, including navigation, identity inquiries, activation, state management, lifecycle management, and so on.

26 01/06/2015Seminarium CBSE26 Questions? ?


Download ppt "Seminarium on Component-based Software Engineering Jan Willem Klinkenberg CORBA."

Similar presentations


Ads by Google