280 likes | 459 Views
CS590L Distributed Component Architecture References: - Objects, components, and framenworks with UML, Ch 6-9 - A Component Based Services Architecture for Building Distributed Applications , R. Bramley, K. Chiu, S. Diwan, et al. Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu
E N D
CS590L Distributed Component ArchitectureReferences: - Objects, components, and framenworks with UML, Ch 6-9 - A Component Based Services Architecture for Building Distributed Applications, R. Bramley, K. Chiu, S. Diwan, et al. Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu www.sice.umkc.edu/~leeyu
Framework • A Framework is a template model (of business, specs, design,...) defined in a Package; • the parameters of that template, • any assumptions made in that model about the intended substitutions for those parameters, can be made explicit. • the predefined rules of composition for combining the properties (imported and existing ones) • Frameworks are useful for many sorts of patterns at all levels of modeling: types, actions, collaborations, refinements, scenarios, • A framework is used via Framework Application
Motivation for Frameworks and Patterns • Developing software is hard • Developing reusable software is even harder • Proven solutions include patterns and frameworks
Overview of Patterns and Frameworks • Patterns support reuse of software architecture and design • Patterns capture the static and dynamic structures and collaborations of successful solutions to problems that arise when building applications in a particular domain • Frameworks support reuse of detailed design and code • A framework is an integrated set of components that collaborate to provide a reusable architecture for a family of related applications. • Together, design patterns and frameworks help to improve software quality and reduce development time • e.g., reuse, extensibility, modularity, performance
Frameworks 1. Frameworks are semi-complete applications • Complete applications are developed from patterns and framework components 2. Frameworks provide domain-specific functionality • business applications, telecommunication applications, window systems, databases, distributed applications, OS kernels 3. Frameworks exhibit inversion of control at time • the framework determines which objects and methods to invoke in response to events
Case Study: Common Component Architecture (CCA) • Major Focuses: • Components (software objects that implement a set of required behaviors) • Frameworks (A runtime environment, A set of services used by components) • Draws ideas from CCM, SciRun (Univ of Utah), etc. • Designed for • efficient coupling of SPMD (Single Progrogram and Multiple Data) components running on very large cluster-based parallel computers. • Coupling of components that execute on widely distributed (Grid) resources. I.e. A visualization app with a remote simulation and a data analysis component. A Component Based Services Architecture for Building Distributed Applications,R. Bramley, K. Chiu, S. Diwan, et al.
Main CCA Ideas • Components: Autonomous interchangeable parts • Applications are developed by connecting components • Ports: define the public interfaces that a component uses or provides. • Builders: the tools used to select and link components together. eg: JBuilder • Framework: defines a mechanism to link “uses ports” of one component to the “provides” ports of another. Component A Component B Uses Port is a call site for an interface to an external component Provides Port - an interface to a service provided by that component.
CCA Framework Services • The framework must provide a set of standard services • Directory Service • To locate components based on port type and other attributes • Registry Service • To locate executing instances of components • Creation Service • To create an executing instance of a component • Connection Service • To connect the ports of two running component instances • Event Service • A framework for publish/subscribe messaging between services and components.
Services and the Grid • A computational “Grid” is a networked set of computational and data resources that are tied together by a ubiquitous collection of “services” • Traditional Grid “services” • Authentication/Security • File/data management • Authorization/ User services • Job Management (incl. co-scheduling, QOS) • Information Services • about resources, people, applications
Common Component Architecture Toolkit • A CCA-compliant framework for distributed “Grid-based” applications. • To enable the design of Grid Application Services as software components. • Is an experiment to test CCA. • CCA architecture is rich enough that the framework and services can be built as components • In particular: application builders can be components. • “Federation of Components” design allows framework to be layered on top of Globus, Jini, e-speak or Legion • There may be a better way to specify information (metadata) about components than a traditional IDL
CCAT Services Architecture • Designed to operate over Grid middleware systems • Chose Globus as the basic framework (could have used Legion too.) • Abstracts out the core services for component architecture and layer on top of existing grid services • CCAT has five CCA framework service components • Directory • Registry • Creation • Connection • Events
CCAT experimental results • To test the idea of going beyond traditional IDLs: • Uses XML as the interface definition language and to describe component metadata • To test the generality of the CCA design: • A services architecture has been built following CCA specifications - all services are components. • To see if components can be reused in the design of application builders: • Four different application builder components have been constructed
Corba-IDL • Traditional distributed computing is based on the specification of public interfaces with simple type language called “Interface Definition Language” • standard in Corba, DCOM and Java/Jini. • Corba component model goes far beyond standard interface type specs. • it requred OMG to define an extensive extension to the standard corba IDL. • The result is a very specialized, non-extensible new specification language.
The Experiment: Use XML as an IDL • Simple canonical syntax : • Possible to describe IDLs in XML • Transformation: • Easy to transform using programs (or XSLT) • Also possible to describe meta-data associated with a component • where is the component from • who wrote it and author comments • interface and port inheritance info • Shortcoming: • XML as a Type system is very weak
IDS: Information Directory Service • Stores Component descriptions in XML • Used to search databases and remote repositories • Context: a storage specific implementation of the IDS interface • Two contexts provided: WebDAV and local-file-system Contexts WebDAV repository Request component info Information Directory Service Component RDBS File system Return XML specs. LDAP
Specification Fragment: Defining an Interface in XML <port-type> <type-name>SparseLinearSystem_idl</type-name> <method-list> <method> <method-name>sendSparseLinearSystem</method-name> <method-param-list> <param-info> <param-name>sls</param-name> <param-dir>in</param-dir> <param-type>SparseLinearSystem</param type> </param-info> </method-param-list> <return-value>int</return-value> </method> </method-list> </port-type>
Registry Service • Stores instance information (runtime configurations) • Used by components to advertise their existence and search other instances • Allows collaboration between CCAT sessions Find a running instance of component X Executing Component Registry Service Component Returns: remote reference to component instance
Creation Service • Used to create a running instance of another component • Encapsulates authentication issues Globus managed resource Y Launch an instance of component X on resource Y Creation Service Component X Returns: remote reference to new component instance
Connection Service • A component that can be used to connect a “uses” port of one component to the “provides” port of another. • Makes it possible to build nested components. X Port Connection Service Component A Connect port A of component X to port B of component Y B Y
x x Event Service • Channel for publish-subscribe event model • Components use it to subscribe to event streams like creation and connection events • Application users can use it for asynchronous information transfer C Subscribe to listen for events of type X Event Channel Service Component x Notification of publication of events of type X A x B
Building builders as components • Builder: A tool used to select and link components together • Component Architecture systems need to provide a tool to work with components • Build these builders as components so that the component model extends throughout
CCAT Builders • Swing based GUI • JPython scripting interface • Matlab • Web
JPython Example import ccat stringDump = ccat.createComponent(‘StringDump’) printer = ccat.createComponent(‘Printer’) ccat.setCreationMechanism(stringDump, ‘gram’) ccat.setCreationMechanism(printer, ‘gram’) ccat.createInstance(printer) ccat.createInstance(stringDump) ccat.connectPorts(stringDump, ‘outputString’, printer, ‘inputString’)
A Web Builder The builder is both a cca component and a java servlet.
Conclusions • XML does not have a strong-enough type system • Replace XML with schemas • Deploy a multiprotocol system for communication • Globus Nexus good for big data, but not for small messaging • Propagate events in a runtime system that is orthogonal to the one in which computation is being done • Building framework services as components was a good idea