Page 1 Component models Component Models and Technology Component-based Software Engineering Ivica Crnkovic Ivica Crnkovic

Component models Component Models and Technology Component-based Software Engineering Ivica Crnkovic Ivica Crnkovic ivica.crnkovic@mdh.se

Component models Overview qIntroduction qACME Architectural Description Language qJava Bean Component Model qCOM, DCOM, MTS and COM+ qCORBA Component Model (CCM) q.NET Component Model qOSGI Component Model

Component models Architecture Definition Languages q ADLs primarily address the issues related to the early phases of software engineering: l Design l Analysis q They identify a number of concepts, such as: l Architecture, configurations, connectors, bindings, properties, hierarchical models, style, static analysis and behavior.

Component models ACME Architectural Description Language qComponents and Ports qConnectors and Roles q Systems and Attachments qRepresentations and Bindings qProperties, Constraints, Types and Styles

Component models Components and Ports q Components l Represent the computational elements and data stores of a system. q Ports l Are the points of interaction between a component and its environment. Component Port

Component models Connectors and Roles q Connectors l Represent interactions between components such as method calls or an SQL connection between a client and a database server. qThe interface of a connector is defined as a set of roles Connector Role

Component models Systems and Attachments qThe structure of a system is specified by a set of components, a set of connectors, and a set of attachments. q Attachment l Links a component port to a connector role. Attachement

Component models Representations and Bindings Connector Component Port Role Attachement Binding

Component models Component Interactions Iteractions with traditional software entities Interactions with other components Interactions with other components Interactions with component infrastructure Components Traditional software entities Component Infrastructure

Component models Terms in Components-based technologies Interface that satisfies contracts Component implementation Component model Independent deployment Component-type Specific interface Coordination Services (transactions, persistence..) Component Framework

Component models Java Bean Component Model

Component models Key Features "A Java Bean is a reusable software component that can be manipulated visually in a builder tool”. q The Java Bean was designed for the construction of graphical user interface (GUI). q Explicitly tailored to interact in two different contexts: l At composition time, within the builder tool. l At execution time, with the runtime environment.  Any Java class that adheres to certain conventions regarding property and event interface definitions can be a JavaBean.  Properties of a compiled bean can be obtained by introspection mechanism

Component models Interface of a Component q This model defines four types of port: l methods, l properties, l event sources (generate an event) l event sinks called listeners (they receive event) Read-only property Write-only property Property Method Event source Event sink (listener) Bounded property v Vetoable property ro wo 1 Unicast event source Ports

Component models Implementation of a Component q Most bean components are implemented by a simple Java object by naming convention Object Method A simple implementation Properties public void set (PropertyType value) public PropertyType get () Events public viod add ( listener); public viod remove ( listener); public class Y implements Listener { public viod ( evt); }

Component models Components Assembly qAssembly is one of the key features of Java Bean though no not specific solution is provided. l Composition tools (Bean Box) l No composition language qDifferent ways of assembling components are supplied. Component-based assembly Heterogeneous assembly

Component models Packaging and Deployment q Java Beans define a model for packaging components into archives. l Includes the definition of dependency relationships between the package items. q Each package item can be marked "Design Only", so that they can be removed in a final application.

Component models An example  Example of a Cannibal bean, e.g as a part of a computer game  The Example contains: A simple bean with a simple property and a boolean bound property A simple test class for the bean A class which do an introspection on the bean (similar to what a builder tool will do) showing the bean’s services, properties and events

Component models import java.beans.*; //for PropertyChangeListener class Cannibal { private String name; //r simple property private boolean saved; //rw bound boolean property //change listeners list private PropertyChangeSupport change; public Cannibal() { this("Eddy Merx", false); } public Cannibal(String n, boolean s) { name=n; saved=s; change=new PropertyChangeSupport(this); } public String getName() {//property name, get method return name; } public boolean isSaved() {//property saved, isXxx method, bound return saved; }

Component models //property saved, set method public void setSaved(boolean s) { boolean old=saved; saved=s; change.firePropertyChange( "saved", new Boolean(old), new Boolean(s) ); } //bean services //… // Property Change Listener Support Methods public synchronized void addPropertyChangeListener( PropertyChangeListener listener) { change.addPropertyChangeListener(listener); } public synchronized void removePropertyChangeListener( PropertyChangeListener listener) { change.removePropertyChangeListener(listener); }

Component models public class Foo implements PropertyChangeListener { private Cannibal can; public static void main(String[] args) { new Foo(); } public Foo() { can=new Cannibal(); // create a Cannibal // add self to the Cannibal's listener list can.addPropertyChangeListener(this); // change the cannibal to saved can.setSaved(true); // fires property change event } public void propertyChange(PropertyChangeEvent event) { if (event.getPropertyName().equals("saved") ) { System.out.println( "The cannibal "+can.getName()+" has been converted.“ ); System.out.println("old saved status was: "+event.getOldValue()); System.out.println("new saved status is: "+event.getNewValue()); }

Component models Output from execution of Foo The cannibal Eddy has been converted old saved status was: false new saved status is: true

Component models import java.lang.reflect.*; public class IntrospectCannibal { public static void main(String[] args) { try { // obtain class object for class Cannibal Class classObject = Class.forName("Cannibal"); // get Constructor, Field and Method objects Constructor[] cons=classObject.getDeclaredConstructors(); Field[] fields = classObject.getDeclaredFields(); Method[] methods = classObject.getDeclaredMethods(); System.out.println("Class Cannibal"); System.out.println("\nConstructors:\n"); for (int i=0; i<cons.length; ++i) System.out.println(cons[i]); System.out.println ("\nFields:\n"); for (int i=0; i<fields.length; ++i) System.out.println(fields[i]); System.out.println("\nMethods:\n"); for (int i=0; i<methods.length; ++i) System.out.println(methods[i]); } catch(Exception e) {e.printStackTrace(System.out);} }

Component models Output from IntrospectCannibal Class Cannibal Constructors: public Cannibal(java.lang.String,boolean) public Cannibal() Fields: private java.lang.String Cannibal.name private boolean Cannibal.saved private java.beans.PropertyChangeSupport Cannibal.change Methods: public java.lang.String Cannibal.getName() public boolean Cannibal.isSaved() public void Cannibal.setSaved(boolean) public void Cannibal.hunt(java.lang.Object) public synchronized void Cannibal.addPropertyChangeListener(java.beans.PropertyChangeListener) public synchronized void Cannibal.removePropertyChangeListener(java.beans.PropertyChangeListener)

Component models Java Remote Method Invocation (Java RMI)  RMI is an interface used over two protocols Java Remote Method Protocol (JRMP) Internet Inter-ORB Protocol (IIOP) Java Client CORBA Object Java Object RMI JRMP, IIOP

Component models Java RMI-Based Technologies RMI Remote Java Application Java Bean Java App. EJB EJB Container Machine XMachine Y RMI Client

Component models Enterprise JavaBeans  Architecture for distributed applications (distributed components)  Framework for creating middleware EJB Server EJB Container Enterprise bean EJB client Clients accesses JBs via containers

Component models Calling an Enterprise Bean Home Object EJB Container/Server Client Application 1. Call a method Enterprise Bean EJB Object 2. Acquire a bean and delegate the call to the bean 3.Return result 4. Return to client

Component models Creating the EJB Object Home Object EJB Container/Server Client Application 1. Create EJB Obj. Enterprise Bean EJB Object 2. Create EJB Object 3. Return EJB Obj. Ref.

Component models 1. Retrive home object 2. Return reference JNDI Java Naming and Directory Interface Client Application Naming Service

Component models 1. Retrive home object 2. Return reference JNDI One More Time Home Object EJB Container/Server Client Application 3. Create EJB Obj. Enterprise Bean EJB Object 4. Create EJB Object 5. Return EJB Obj. Ref. Naming Service 6. Call a method 7. Acquire a bean and delegate the call to the bean 8.Return result 9. Return to client

Component models Java Application Server Technologies EJB Applications EJB HTTP Listener Windows NT, Unix, Others DBMS JSP Applications Browser Client Rich Client HTTP RMI/IIOP Various Java Tools Various JSP Tools Servlets JDBC

Component models J2EE (Java 2 Platform, enterprise edition)  Defines an architecture for building large scale multi-tier distributed applications Uses standardized modular components Provides standard services for those components Automatically replaces many aspects of the application programming from the developer Thinner clients

Component models J2EE architecture components  J2EE Platform Specification Specification of the APIs to be provided Descriptions of the support levels expected for containers, clients, and components  J2EE Sun’s Reference Implementation Free implementation of the specified technologies, sample applications, tools, and documentation  J2EE Compatibility Test Suite Test implementations of the platform  J2EE Sun BluePrint Documentation, examples, and design guidelines

Component models J2EE application model  Business logic in Enterprise JavaBeans components  Client interaction presented through different technologies Plain Html Java applets Java servlets JSP  Components communicates transparently using different standards Html XML RMI

Component models The J2EE architecture (Pic. Sun Microsystem, http://java.sun.com/j2ee/overview3.html)

Component models COM/DCOM

Component models Interfaces and Assembly q A COM interface is seen as a C++ virtual class and takes the form of a list of data and function declarations without associated code. q All interfaces are descendants of the IUnknown interface. Component interface Interface Component implementation

Component models A Simple COM Object  A COM interfaces can have methods and properties Language independent – binary standard  All Access is through the interface Supports multiple interfaces Each interface has a GUID

Component models IUnkown  All COM objects must implement IUnknown AddRef Release QueryInterface IUnknown

Component models IUnknown  Contains only three methods HRESULT QueryInterface(GUID iid, void **iptr); ULONG AddRef(); ULONG Release();  QueryInterface is used for Interface Navigation  AddRef and Release is used for reference counting A form of collaborative carbage collection

Component models IDL Example interface ISpellCheck : IUnknown { [in] BSTR *word, [out] bool *correct HRESULT check( [in] BSTR *word, [out] bool *correct ); }; interface ICustomSpellCheck : IUnknown { [in] BSTR *word HRESULT add( [in] BSTR *word ); [in] BSTR *word HRESULT remove( [in] BSTR *word ); }; library SpellCheckerLib { coclass SpellChecker { [default] interface ISpellCheck; interface ICustomSpellCheck; };

Component models Invocation of a method  Remote Procedure Call (RPC) is used  The RPC in DCOM is called Object RPC Based on Microsoft RPC Which is itself based on DCE RPC Operating System DCOM COM/Win32 COM

Component models COM-Based Technologies COM DCOM Remote Server ActiveX Local Server MTS MTS Container Machine XMachine Y DCOM Client

Component models Creating a local object Object Server Client Application COM Library 1. CoCreateInstance 3. Return pointer to interface 4. Invoke methods 2. Locate server object CLSID_X CLSID_YPath to server Y Path to server X Registry

Component models Creating a local object using a class factory Object Server Client Application 1. IClassFactory::CreateInstance 4. Invoke methods 2. Create Object and get interface pointer Class Factory 3. Return pointer to interface

Component models Creating a remote object Object Server Client Application COM Library 1. CoCreateInstance 2. Locate server object 3. Return pointer to interface 4. Invoke methods CLSID_X... C:\X.exe Registry CLSID_X CLSID_YD:\Y.exe Idt.mdh.se Registry Idt.mdh.semrtc.mdh.se

Component models Microsoft Application Server Technologies COM Applications MTS IIS Windows NT DBMS ASP Applications ADO Browser Client Rich Client HTTP DCOM VB VC++ VJ++ Visual InterDev

Component models CORBA and Component Model (CCM)

Component models CORBA  Common Object Request Broker Architecture  Standard for writing distributed object systems  Language independent  Not controlled by one company  Optional value added services

Component models CORBA (Common Object Request Broker Architecture) CORBAapps CORBAdomains CORBAfacilities CORBAservices OMA Overview Transactions Event Security Naming OMA–Object Management Architecture

Component models

Component models Remote invocation

Component models CORBA 3.0  Internet Integration Firewall Specification Interoperable Name Service  Quality of Service Control Asynchronous Messaging and Quality of Service Control Minimum, Fault-Tolerant, and Real-Time CORBA  The CORBAcomponent architecture Components Scripting

Component models

Component models CORBA ORB architecture  Object -- This is a CORBA programming entity that consists of an identity, an interface, and an implementation, which is known as a Servant.  Servant -- This is an implementation programming language entity that defines the operations that support a CORBA IDL interface. Servants can be written in a variety of languages, including C, C++, Java, Smalltalk, and Ada.  Client -- This is the program entity that invokes an operation on an object implementation. Accessing the services of a remote object should be transparent to the caller. Ideally, it should be as simple as calling a method on an object, i.e., obj->op(args). The remaining components in Figure 2 help to support this level of transparency.  Object Request Broker (ORB) -- The ORB provides a mechanism for transparently communicating client requests to target object implementations. The ORB simplifies distributed programming by decoupling the client from the details of the method invocations. This makes client requests appear to be local procedure calls. When a client invokes an operation, the ORB is responsible for finding the object implementation, transparently activating it if necessary, delivering the request to the object, and returning any response to the caller.  ORB Interface -- An ORB is a logical entity that may be implemented in various ways (such as one or more processes or a set of libraries). To decouple applications from implementation details, the CORBA specification defines an abstract interface for an ORB. This interface provides various helper functions such as converting object references to strings and vice versa, and creating argument lists for requests made through the dynamic invocation interface described below.  CORBA IDL stubs and skeletons -- CORBA IDL stubs and skeletons serve as the ``glue'' between the client and server applications, respectively, and the ORB. The transformation between CORBA IDL definitions and the target programming language is automated by a CORBA IDL compiler. The use of a compiler reduces the potential for inconsistencies between client stubs and server skeletons and increases opportunities for automated compiler optimizations.  Dynamic Invocation Interface (DII) -- This interface allows a client to directly access the underlying request mechanisms provided by an ORB. Applications use the DII to dynamically issue requests to objects without requiring IDL interface-specific stubs to be linked in. Unlike IDL stubs (which only allow RPC-style requests), the DII also allows clients to make non-blocking deferred synchronous (separate send and receive operations) and oneway (send-only) calls.  Dynamic Skeleton Interface (DSI) -- This is the server side's analogue to the client side's DII. The DSI allows an ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of the object it is implementing. The client making the request has no idea whether the implementation is using the type- specific IDL skeletons or is using the dynamic skeletons.  Object Adapter -- This assists the ORB with delivering requests to the object and with activating the object. More importantly, an object adapter associates object implementations with the ORB. Object adapters can be specialized to provide support for certain object implementation styles (such as OODB object adapters for persistence and library object adapters for non-remote objects).

Component models CORBA Component Model  A Framework for Server Applications  Built on the Portable Object Adaptor  Provides interfaces for CORBA Services transactions security events persistence  Uses Callbacks for instance management  Empty container for user-defined frameworks

Component models CORBA Component Model q A component interface is made of ports divided into: l Facets - for interaction with clients l Receptacles – references o external code l Event sources l Event sinks Component interface Attribute Facet Event source Event sink Ports Receptacle Segment Component implementation

Component models Defined Container Frameworks ComponentComponent Container ORB/POA TransactionSecurityPersistenceEvents Callback Interfaces Internal Interfaces External Interfaces

Component models Real-Time CORBA  See RT-CORBA page 18… See RT-CORBA page 18…

Component models Portable End-to-End Priorities Problem: How can we map global priorities onto heterogeneous native OS host thread priorities consistently end-to-end? Solution: Use Standard RT CORBA priority mapping interfaces

Component models Obtaining Portable ORB End-system Priorities OS-independent design supports heterogeneous real-time platforms CORBA priorities are “globally” unique values that range from 0 to 32767 Users can map CORBA priorities onto native OS priorities in custom ways No silver bullet, but rather an ``enabling technique'‘  i.e., can’t magically turn a general-purpose OS into a real- time OS!

Component models Preserving Priorities End-to-End Problem: How can we ensure requests don’t run at the wrong priority on the server? e.g., this can cause major problems if edge_alarm() operations are processed too late!!! Solution: Use RT CORBA priority model policies

Component models Preserving Priorities End-to-End  RT CORBA priority model policies l SERVER_DECLARED  Server handles requests at the priority declared when object was created l CLIENT_PROPAGATED  Request is executed at the priority requested by client  Priority is encoded as part of client request

Component models Problems that RT-CORBA solves Problem: How can RT-CORBA client application change the priority of operations? Problem: How to ensure that certain operations always run at a fixed priority? Problem: How can we prevent bursts or long-running requests from exhausting maximum number of static & dynamic threads in the lane? Problem: How can we support real-time applications that need more buffering than is provided by the OS I/O subsystem Problem: An ORB & application may need to use the same type of mutex to avoid priority inversions e.g., using priority ceiling or priority inheritance protocols

Component models Problems that RT-CORBA solves Problem: How can we minimize priority inversions, so that high-priority operations are not queued behind low-priority operations? Problem: How can we handle the fact that CORBA one-way operation semantics aren’t precise enough for real-time applications?  Problem: How can we simultaneously Prevent clients from blocking while long-duration requests complete & Allow many requests to be issued concurrently

Component models Concluding Remarks RT-CORBA  RT CORBA 1.0 is a major step forward for QoS-enabled middleware e.g., it introduces important capabilities to manage key ORB end-system/network resources  We expect that these new capabilities will increase interest in--and applicability of--CORBA for distributed real-time & embedded systems  RT CORBA 1.0 doesn’t solve all real- time development problems, however It lacks important features:  Standard priority mapping manager  Dynamic scheduling –Addressed in RT CORBA 2.0 Portions of spec are under-specified  Thus, developers must be familiar with the implementation decisions made by their RT ORB Our work on TAO has had the following impact: Advanced middleware for distributed real-time & embedded systems by implementing RT CORBA in an open- source ORB Provide feedback to users & OMG Provide affordable access to RT CORBA

Component models minimumCORBA  minimumCORBA defines a profile (or subset) of CORBA, whereas CORBAservices, CORBAsecurity etc. define optional extensions to the CORBA specification.

Component models.NET

Component models What is.NET?  NET is a platform that enables: Software as services, especially over the web Distributed computing Componentization Enterprise services

Component models.NET Platform Operating Systems Common Language Runtime Base Class Library ADO.NET and XML ASP.NETWindows Forms Common Language Specification VBC++C#JScript… Visual Studio.NET

Component models.NET Framework Components  Common Language Runtime (CLR) Common type system for all languages Runtime environment  Class libraries (.NET Framework) Base class libraries, ADO.NET and XML Windows Forms for, Win32 applications  Web application platform ASP.NET Interactive pages Web services that are SOAP enabled

Component models.NET Component Model - Implementation q A component (assembly) is made of modules, which are traditional executable files (DLL). q Modules cannot be assemblies, thus the.NET model is not hierarchical. Component interface Attribute Method Event source PortsComponent implementation Modules

Component models Framework q.NET relies on the traditional programming approach : the framework is seen as the language run-time support. l MISL – Microsoft Intermediate language (similar to Java Byte code) l Common Runtime Language (similar to Java Virtual Machine) q Transaction control relies on MTS.

Component models Lifecycle  Assemblies (and their modules) are local to an application, and thus different DLLs with same name can run simultaneously.  Each assembly has a versioning information about itself and about the assemblies it depends on. Version control is delegated to the dynamic loader, which selects the “right” version. q Significantly improve the application packaging and deployment.

Component models Other component models q OSGI Component Model q KOALA component model q IEC 61131-3 standard languages (functional blocks) q Real-time components

Component models C C2C2 C1C1 C3C3 ms A Koala Component A module A switch Interfaces Subcomponent

Component models OSGI Component Model qComponents qInterface of a Bundle Component qAssembly of Bundle Components qImplementation of a Bundle Component

Component models Components q A bundle use three kinds of ports to express its interactions with l Traditional technology l Other components The run-time environment  Bundles may listen to events published by the framework such as the insertion of a new component in a system.

Component models Interface of a Bundle Component Package export Package import Service use Ports Service interface static dynamic Interface of a bundle component

Component models Assembly of Bundle Components  A system is an evolving set of bundle components. q A bundle component publishes a service interface It can attach to it a set of properties describing its characteristics. q A component requires an interface for its use, It will select one via a query expression based on these properties.  This flexibility also has its counterpart There is no guarantee than the service will continue to be available

Component models Implementation of a Bundle Component q JAR archive containing: l Service components l Java packages l Other resources files Package Resource Service component Activator

Page 1 Component models Component Models and Technology Component-based Software Engineering Ivica Crnkovic Ivica Crnkovic

Similar presentations

Presentation on theme: "Page 1 Component models Component Models and Technology Component-based Software Engineering Ivica Crnkovic Ivica Crnkovic"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Page 1 Component models Component Models and Technology Component-based Software Engineering Ivica Crnkovic Ivica Crnkovic

Similar presentations

Presentation on theme: "Page 1 Component models Component Models and Technology Component-based Software Engineering Ivica Crnkovic Ivica Crnkovic"— Presentation transcript:

Similar presentations

About project

Feedback