Software Components and Distributed Systems INF5040/9040 Autumn 2017 Lecturer: Eli Gjørven (ifi/uio) September 12, 2017
Outline Recap distributed objects and RMI Introduction to Components Basic Design Concepts Distributed Components Main Technologies for Distributed Components Summary 2
Remote Procedure Call Ideally: make a remote call look as a local one in other words: achieving access transparency The basic idea: Client Stub Server Stub 3
RPC + Remote objects = RMI Idea: Make it possible to send messages to remote objects using mechanisms similar as RPC Remote client objects can only invoke the remote interface Local client objects can invoke: the methods in the remote interface + other methods implemented by the object Result: Access transparency! 4
RMI-software Example: Object A invokes a remote object on object B RMI-software: Proxy, skeleton and dispatcher Translates between local method invocations and remote invocations (including marshalling) Uses communication module to send request and receive reply 5
Limitations of Object-Oriented Middleware Objects do provide a clean separation between the specification of an object and its implementation RMI enables access transparency BUT: Object model is based on fine-grained classes with complex and implicit relationships and dependencies Objects need to handle explicitly Naming, RORs, binding, lifecycle, state.. Non-functional concerns like security, transactions, coordination and replication Through the middleware, or by own implementation No support for deployment 6
Software Components Some Definitions A unit of composition with contractually specified interfaces and explicit dependencies. (Clemens Szyperski) A piece of self-contained, self-deployable code, assembled with other components through its interface. (Wang and Qian) A nearly independent, and replaceable part of a system with a clear function, implementing a set of interfaces. (Philippe Krutchen, Rational Software) For example: JavaBeans, COM, CORBA, OSGi 7
Four Basic Design Concepts I. Component Model A component has a set of required and provided interfaces Several components may require or provide the same interface Required Interfaces (RI) Component Provided interfaces (PI) Impl. by Impl. by Component 1 Component 2 Component contract : For a component to function correctly, every required interface must be bound ( connected ) to a provided interface of another component. If a component provides an interface which is invoked by another component hosted in a different computer passing messages to it across a network, we have a DS. 8
Four Basic Design Concepts cont d II. Connection Model Describes a connection as a binding between a required and a provided interface through connectors, which are pre-defined composition operators. Main styles of connector interfaces: Method-based interface: RMI Event-based interface: Distributed events (ref lecture Communication paradigms ) Component 1 Method invocation Event Component 2 9
Four Basic Design Concepts cont d III. Composition Idea: Explicitly defined required and provided interfaces enables development of software as a composition of components: A set of components which are to be connected at runtime One component can be reused in different software compositions. A component in a composition can be replaced by another component that requires and provides the same interfaces Component 1 Interface 2 Impl. by Impl. by Component 2.1 Component 2.2 10
Four Basic Design Concepts cont d IV. Deployment Model Describes the process and activities for component and composition installation and configuration: Install components on the same or different computers Ensure components can be correctly connected Ensure that the middleware is configured to provide the right level of support for the components E.g., EJB produces a XML-based deployment descriptor 11
Designing a Component Platform The underlying foundation to construct, assemble, deploy and manage components Defines rules for deployment, composition and activation of components. To deliver and deploy components: a standardized archive format that packages component code and meta-data Embraces four component design concepts: component model, connection model, composition and deployment model Designed as a set of contractually specified interfaces 12
Inversion of control pattern The component model is suitable for the inversion control and dependency injection patterns Component 1 Dependency Component 2 Activate () addconnector (comp1) Component platform Dependency injection is a specific type of inversion of control. 13
Distributed Component Middleware Advantages of distribution Load sharing Increased availability Heterogeneity Replication Computer 1 Computer 2 App1 App2 Comp 1 Comp 2 Inter-process Comm. (Middleware) Local OS 1 Local OS 2 Network Distributed component middleware characteristics of components + functionality of middleware systems inter-process communication across machine boundaries 14
Revisit Distributed Object Middleware Distributed object middleware Infrastructure for access to remote objects transparently based on the Remote Procedure Call (RPC) Client Stub Explicit Middleware Distributed Object Skeleton API API API Database Driver Security Service Transaction Server Application logic must handle logic for life cycle management, transactions, security, persistence, etc. explicitly Object developer Objects can be difficult to reuse in different settings 15
Implicit Middleware No explicit references to middleware services from application logic Better support for separation of concerns Client Distributed Component Stub Request Interceptor Skeleton Implicit Middleware API API API Database Driver Security Service Transaction Server Enables changing middleware services separately without changing the application code 16
Component-based Middleware Distributed Components + Container => Implicit middleware Distributed Component The designer only focuses on the component logic, not burdened with the implementation of location, persistence, transactional capabilities and security. Container Responsibilities of the container life cycle management, system services (e.g., transactions), security dynamic deployment and activation of new components e.g., resolving dependencies dynamically or activating components requested in method calls Front-end for remote communication including interception of incoming invocations (cf. implicit middleware) Middleware that supports the container pattern: Application Server 17
Application Servers: Key Players 18
Distributed Components- Main Technologies Sun/Oracle defined the Enterprise Java Beans (EJB) specification as part of their Enterprise Edition of the Java 2 platform. OMG defined the CORBA Component Model (CCM), providing a distributed component model for languages other than Java. Microsoft defined the Distributed Component Object Model (DCOM), supporting distributed communication under Microsoft's COM+ application server. 19
Enterprise JavaBeans A server-side component model based on a three-tier architecture Beans in EJB: capture business logic Beans hosted by the EJB container supporting key distribution services: transactions, security and lifecycle EJB services can be container-managed: injecting calls to the associated services bean-managed: developer takes more control over these services 20
EJB Component Model Bean: a component offering business interfaces (remote and local) Session beans: stateless and stateful Message-driven beans: listener-style interface Bean implementation Plain Old Java Object (POJO) with annotations, e.g.: @Stateful public class eshop implements Orders {...} @Remote public interface Orders {...} A significant number of annotations for container services 21
EJB dependency injection and interception Dependency injection in container: managing and resolving the relationships between a component and its dependencies, e.g. @Resource javax.transaction.usertransaction ut; Interception: to associate particular action(s) with an incoming call on a business interface, e.g. public class eshop implements Orders { public void MakeOrder (...) {...} @AroundInvoke public Object log(invocationcontext ctx) throws Exception { System.out.println( invoked method: + ctx.getmethod().getname()); return invocationcontext.proceed(); } } 22
An Example: Transactions @Stateful @TransactionManagement(BEAN) public class eshop implements Orders { @Resource javax.transaction.usertransaction ut; public void MakeOrder (...) { ut.begin();... ut.commit(); } } Bean-Managed @Stateful @TransactionManagement(Container) public class eshop implements Orders { @TransactionAttribute(TransactionAttributeType.REQUIRED) public void MakeOrder(...){... } Container-Managed } 23
Fractal Component Model A lightweight component model developed by the open source consortium OW2 Programming with interfaces Uniform model for provided and required interfaces Explicit representation of the architecture No support for deployment, container patterns, etc. Configurable and reconfigurable at runtime Programming language agnostic model Implementations of the model available in several programming languages (Java, C, C#, Smalltalk, Python) Mostly used by research projects to develop experimental middleware 24
Fractal Component Model cont d Server (provided) and Client (required) interfaces Composition: bindings between interfaces Primitive Binding: client and server within the same address space Composite Binding: arbitrarily complex architectures consisting of components and bindings, implementing communication between two or more interfaces potentially on different machines (fx. CORBA) Component model is hierarchical a component: subcomponents and associated bindings subcomponents may themselves be composite System is fully configurable and reconfigurable: including components and their interconnections 25
Fractal: Component Structure 26
Fractal: Example Describing components through Architecture Description Language (ADL) <definition name="helloworld"> <interface name= r" role="server" signature= Runnable"/> <component name="client"> <interface name= r" role="server" signature= Runnable"/> <interface name="s" role="client" signature="service"/> <content class="clientimpl"/> </component> <component name="server"> <interface name="s" role="server" signature="service"/> <content class="serverimpl"/> </component> <binding client="this.r" server="client.r"/> <binding client="client.s" server="server.s"/> </definition> 27
Fractal: Example cont d Resulting Architecture HelloWorld r r client s s server Client Impl Server Impl 28
Limitations of components Explicitly defined dependencies works within organizations but not so well between organizations Not always an advantage to make middleware services for transactions, security,.. transparent Main concepts tightly coupled to complex middleware (container + middleware services) Common component middleware is tightly coupled to specific technologies (Java, CORBA, Microsoft COM, Fractal) What about Internet applications? 29
Summary: Components vs. Objects classes and object Object-Oriented data types and hierarchies implementation technology tightly coupled: low-level reuse Fine-grained classes with complex and implicit relationships and dependencies components Component-based interfaces and composition packaging & distribution technology loosely coupled: high-level reuse Coarse-grained software units with explicit relationships and dependencies Object-based middleware Explicit references to the middleware and its services from application code No support for deployment and configuration Component-based middleware No explicit references to the middleware and its services from application code Handles deployment of components to a container Container handles life-cycle management and system services Both: Most suitable for DS within an organization 30