Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components Tiny Components A Component Model for Small, Embedded or Mobile devices

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components What is a component architecture  Most important principle: Separation of Concerns  Functional concerns of an application are factored into reusable Components  Technical concerns are provided by a standardized entity, a so-called Container  Components are accessed only through a Component Interface  Functionality of a Component is well defined, thus reusable.

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components What is a component architecture (II) Taken from Voelter, Schmid, Wolff, Server Component Patterns, Wiley 2002

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components So, then, what is a Component?  Additional properties of the kinds of Components we are interested in:  a component is coarse grained  principle of separation of concerns is employed  components can be accessed remotely “A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.” Definition by Szyperski

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components Components in the enterprise environment  There are several popular component architectures in the enterprise environment:  Enterprise Java Beans (EJB), a Java-only component model that is part of the Java 2 Enterprise Editition  CORBA Components (CCM), a component-extension to OMG's object request broker technology,  Micorsoft's COM+, a widely-used component architecture limited to Windows operating systems.  Many other component architectures that have been designed specifically for a specific system

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components Why are they successful in enterprise apps  A Typical application structure:  database contains business data  processes that manipulate this data  usually in the context of transactions.  It is relatively easy to separate the functional from the technical concerns, and they can be implemented generically.  Standards and commercially available containers  People and their skills suit the sep. of concerns well  Standardized Programming Model

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components Target Platform: Small Systems  We consider the following kinds of devices to be „small systems“:  Mobile Phones  PDAs, Organizers  Embedded computers, such as controllers or ECUs in vehicles or airplanes

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components Characteristics of small devices  Non-homgeneity, almost every device is different  Limited memory, only some hundred kB or some MB are available  Limited computing power because the device often contain only small processors  Limited electrical power because the device might be battery powered  Timing requirements can be more stringent:  No real time  Soft real time  Hard real time (out of scope!)  Network connection can either be permanent or intermittent

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components Typical software architecture for small devices  An OS Abstraction Layer hides some of the details of the underlying (realtime) operating system.  A more sophisticated approach, especially for product families, is the use of a framework – provides reuse for repeating aspects.

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components Software architecture with components  Using a component container is basically a framework that uses separation of concerns and optionally generative techniques.  Reuse is simplified by only accessing components through their interfaces.  OS Abstraction Layer + Framework + Separation of Concerns + Reuse = Component Architecture

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components Software architecture with components II  In a last step, the container and the OS Abstraction Layer, as well as the operating system can be integrated to improve performance and reduce footprint even more.

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components Main characteristics of a component model for small devices  Platform independent. The component architecture and ideally, the programming language should be available on several systems  Simple: An API should be as simple as possible, much simpler that EJB or CCM  Modular: not all containers need to provide all possible features. Necessary to run the system on limited devices.  Reflective: Components must know what their requirements are regarding the container and the containers must know what they provide.  Network-aware: Different network transport protocols must be pluggable without changing the component implementations (CORBA, Sockets, RMI,...)

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components Container Features (Technical Concerns)  Scheduling  Interrupt Handling  Storage Service  Simple Event service  Generic driver interface  Pluggable transport  Security  Store and forward  Paging ...

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components Related Technologies  Jini is a platform for spontaneous networking  Ninja is a project by the University of Berkeley that defines an architecture for intelligent network-centric services.  OSGi is a platform to manage services on small devices. Maybe it could be used as a basis.  WebServices defines an XML over HTTP based RPC mechanisms for use in the internet.  Apache SF project to build a framework for server apps  MQ everyplace is a version of the MQSeries messaging middleware that is available for small devices.  Java could be useful as a platform independent programming language.  TAO is a well-known and modular ORB that might be useful as a communication backend.

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components Related Technologies: OSGi  OSGi, the Open Services Gateway Initiative:  OSGi allows the deployment of services to a „host“ and  Tracks dependencies and versions  Manages installation and deinstallations  Manages dependencies to external resources The Open Services Gateway Initiative (OSGi), established in 1999, is an independent, non-profit corporation working to define and promote open specifications for the delivery of managed broadband services to networks in homes, cars and other environments. OSGi also works to proliferate these open specifications through the sponsorship of technology, market, and user education programs.

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components Related Technologies: OSGi  OSGi comes with a set of additional services,  Package Admin Service: Status information of packages and bundles, minimal update  Permission Admin Service: permission management for bundles before, during or after installation  LogService: handling of log messages  HttpService: simple framework for http servers  Device Access Spec: Generice devices driver model

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components Related Technologies: OSGi  OSGi provides a set of useful services, but  It provides no separation of concerns  Does not address any of the issues we mentioned before (scheduling, interrupts, events,...)  So, it could serve as a basis for the Small Component Architecture, but it is not extensive enough.  OSGi is a standard, implementations are  Sun‘s Java Embedded Server (JES)  IBM‘s Service Management Framework (SMF)  IBM‘s Websphere Everyplace suite

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components Architectural/Implementation considerations  A real big, generic, monolithic application server is certainly useless in small devices.  Generative Programming techniques, especially code generation can help to reduce the footprint.  Aspect Orientation can provide a useful means to decompose the system.

Tiny Components – a collection of initial ideas copyright © 2003 Tiny Components It‘s time to start NOW!  The patterns community is exploring the embedded applications domain (see DRE Patterns Workshop at OOPSLA)  there are CORBA implementations for embedded devices (TAO, Orbacus/E)  systems are extending into the embedded domain (minimumCORBA, RealtimeJava)  and generative programming can help to get things small and efficient