260 likes | 277 Views
This seminar explores the use of the Common Object Request Broker Architecture (CORBA) in component-based software engineering. It covers the concepts of CORBA, its Object Request Broker (ORB), Interface Definition Language (IDL), and the various services it provides for enterprise distributed computing and fine-grained object architecture.
E N D
Seminarium onComponent-based Software Engineering CORBA Jan Willem Klinkenberg
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” Seminarium CBSE
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 Seminarium CBSE
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 Seminarium CBSE
CORBA • CORBA - Common Object Request Broker Architecture. Seminarium CBSE
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 Seminarium CBSE
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); }; }; Seminarium CBSE
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 Seminarium CBSE
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 Seminarium CBSE
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 Seminarium CBSE
CORBA and OMG IDL IDL source Applications Programs IDL compiler Object servants Dynamic invocation interface IDL stubs ORB interface Object Adapter IDL Skeletons Dynamic Skeleton interface Object Request Broker (ORB) Seminarium CBSE
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 Seminarium CBSE
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 Seminarium CBSE
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. Seminarium CBSE
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) Seminarium CBSE
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 Seminarium CBSE
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 Seminarium CBSE
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 Seminarium CBSE
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) Seminarium CBSE
CCM Component Component interface My Business Component Facets Receptacles OFFERED REQUIRED Event sinks Event sources Attributes Seminarium CBSE
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 Seminarium CBSE
CCM packaging CCM Assembly CCM Component CCM Component Segments Deployment configuration Seminarium CBSE
CCM Containers • Component instances are placed inside containers: Home interface Home for C Component C Callbacks Services Container Components interact with POA as well as transaction, security, persistence and notification services via interfaces on their container Seminarium CBSE
Components types • There are different types of components: • Service • Session • Entity • Process Seminarium CBSE
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. Seminarium CBSE
Questions? ? Seminarium CBSE