580 likes | 717 Views
ソフトウェア工学特論 (4). 田中 譲. Component Integration. Component Integration.
E N D
ソフトウェア工学特論 (4) 田中 譲
Component Integration • While the highly advanced production technologies today heavily depend on computer systems, especially on their software, the production of software today is much like the production of hand-crafted goods in the nineteenth century. • Software development is labor intensive; it takes too long to build and costs too much. • Once their development has been completed, today’s software systems are typically inflexible and difficult to repair or to modify.
The highly advanced production technologies today is the result of factoring out frequently used mechanisms as standard components and trying to design systems as compositions with such standard components. • The detail design of each component is not referred to in the design of how to assemble components.
This chapter gives a brief introduction to software components; the necessity to reuse existing software components, architectures for defining and assembling them, frameworks for their visual representation and direct manipulation, and integration of legacy software systems. • We will also focus on the maintainability of composed systems; flexible composition structures may provide ease of composition, but may result in poor maintainability.
Components expose only their interfaces, which is usually not sufficient to imagine how to reuse them. • The ways of using each component are not independent from its contexts. • In this chapter, we will also focus on the use of sample compositions as representations of component contexts.
Object Reusability • Object-oriented programming has opened up two ways of reusing existing software. • One is the reuse of defining codes, and • the other is the reuse of running object instances as components. • Software development based on either or both of these two types of reusing existing software is called component-based software development.
The reuse of a code fragment requires knowledge both of its original context and of its reuse context. • One mechanism that allows this type of reuse is property inheritance. • This type of reusing codes requires programming expertise. • This type of reuse improves the programming cost only by a constant factor; it cannot significantly improve application development performance.
Another mechanism that allows the reuse of codes is the definition of a new class as a composite class constructed with existing classes. • For example, the class of technical reports may have the following component classestitle, author, abstract, chapter, and reference. • Component classes are just called components. • The definition of a composite class requires not only programming expertise, but also knowledge on its components; their messages, message formats, parameter types, and return value types.
Meme media should exploit the reuse of running object instances since they are reused not by programmers but by end users who have no programming expertise. • They should be provided with a sufficiently large library of components, which should be open for future extension by many different component providers.
Components and Application Linkage • Some messages invoke methods of components, while some others access properties of components. Some messages may work as events to components. • Some component systems such as ActiveX Controls and JavaBeans distinguish these different uses of messages. • However, these are all essentially nothing but messages. • The use of such an exposed message of an application object by a program to invoke its method is called an application linkage between the program and the application object.
The reuse of components by a program code • The programmer needs to know a priori the interface of each component he or she reuses.
Pluggability: component-integration environment • Dispsend:message(j) to:comp(i) with: parameters • Disp : message dispatcher
Dispsend:message(j) to:comp(i) with: parameters • You may consider each pair of a component and one of its exposed messages as an object. Such an object is called a ‘slot’. Now the above-mentioned component access statement is replaced with the following. • Dispsend: (comp(i), message(j)) with: parameters • This may be further replaced with the following. • Slotof: (comp(i), message(j)) send: parameters • Now the message ‘send:’ is interpreted as a message accepted by any slot. • We may further extend the slots to accept more than one standard message, where ‘sendi:’ is the i-th message accepted by any of the slots.
Standard messages to slots • Slot set: value • Slot gimme
Standard messages to slots • A ‘set:’ message sends a parameter value to a slot, while a ‘gimme’ message requests a return value from a slot. • Our meme media components exploit this model. • The parameter of a ‘set:’ message and the return value of a ‘gimme’ message may have different value types even if they access the same slot. • The pair of these two value types defines the slot type.
Systems for component reuse by program codes • Systems for component reuse by program codes do not require component pluggability, and provide no standard framework such as component and message placeholders for the implicit specification of reused components and messages. • ActiveX and Java including JavaBeans both fall in this category. • JavaBeans however has several component integration environment systems such as Java Studio from Sun Microsystems, JBuilder from Borland, and VisualAge from IBM. • Java Studio, for example, uses a wiring window to define linkages among components, and another separate window to define the layout of forms corresponding to some components. • A form is a display object of a component, and works as an input/output cell. • Most component integration environment systems separately treat the definition of functional linkages among components, and the layout definition of input/output forms.
Compound Documents and Object Embedding / Linking : View Integration Object Linking Object Embedding
Generic Components • A component is more generic if it imposes less restriction on components it can be combined with. • Components that do not explicitly specify which components to access are more generic than those that explicitly specify which components to access. • Components that explicitly specify neither which components to access nor which messages to use for these accesses are further more generic.
The exploitation of slots with standard slot-access messages allows each component to implicitly access some slots with explicitly specified standard slot-accessing messages. • This also makes the components sufficiently generic. • The parameter and the return value of such an implicit component-access statement may take different object types for different combinations of place fillers. • Components that automatically perform necessary conversions for different types are more generic than those without this function. • However, this function may introduce too much overhead to each component.
Components may have some messages that can be accepted by any component. • Some components may just neglect some of these messages after accepting them. • These messages can be explicitly used in programming a component without making this component less generic. • An example of such messages is an ‘update’ message that is used to notify the fact that the sender component has just been updated. • This ‘update’ message takes no parameters. • The ‘copy’ message is another example. It replicates each component. • In a system in which all components have display representation, the ‘move’ message to change their location on the display, and the ‘resize’ message to resize them are also examples of such messages.
Pluggability of Components • The pluggability of a composite component in a composition depends on how many different plugs are used to connect this composite component to the remaining. • The fewer plugs lead to the higher pluggability of the composite component. • The simplest case uses no more than one plug to connect a composite component to the remaining.
What to reuse, components or sample compositions? • Components expose only their interfaces, which is usually not sufficient for us to imagine how to reuse them. • Many projects on reusable components have failed in the past for this specific reason. • The ways of using each component are not independent of its context. • Various contexts of a component provide information about varieties of its use.
Contexts of a component can be presented as sample compositions using this component. • When provided with sample compositions, component libraries provide much more information about components and the ways to reuse them. • Furthermore, instead of providing a component library, we may provide a library of sample compositions. • Each component in a sample composition may be associated with those components that may be substituted for the original component in this context. • Here, what are reused are not components but sample compositions.
Reuses and Maintenance • The rapid prototyping with components does not necessarily lead to the good maintainability of the developed applications. • The maintainability of a composite application indicates how easy we can replace each of its primitive and composite components with a new version or with a different component that has similar functionality.
Reuses and Maintenance • A component with more plugs to connect itself to the remaining is harder for us to replace with another than a component with fewer plugs. • Compositions with cyclic connections are also harder for us to maintain than those without cyclic connections.
The simplest case is the acyclic uniplug composition model. • In theacyclic uniplug composition model, pulling out a plug always decomposes any composition to two independent composite components. • The reuse of components should take into account the ease of future maintenance of whatever is composed. • The acyclic uniplug composition model provides each composite application with good maintainability.
While all the implicit component accesses are performed along the edges of this tree, some explicit component accesses with standard messages need not be performed along these edges. • Explicit component accesses independent from these edges also make the maintenance of composite applications difficult. • Their maintenance becomes much easier if we restrict explicit component accesses to those along these edges. • The acyclic uniplug composition model that satisfies this further restriction is called the tree composition model.
Because of the simple connection structures among components, the tree composition model is likely to complicate the data structures of parameters and return values that are exchanged between components in compositions. • Components with multiple plugs can rather simplify these data structures, but lead to spaghetti-like connections and seriously reduce the maintainability. • The complex data structures of connections in the tree composition model, when interpreted as the semantics of each connection, provide useful information for the maintenance of each connection.
Some readers may think that the tree composition model cannot decompose programs with loops into components. • Actually, it can decompose such programs in a restricted but desirable way. • A single program loop, for example, consists of a loop skeleton and a sequence of procedures in this loop. • The tree composition model decomposes such a program loop into a single base component that represents the loop skeleton and as many child components as those procedures. • The base component has as many slots as the number of child components. • Each child component is connected to the corresponding slot of the base component. The base component periodically invokes these child components in the specified order. • The tree composition model does not break the loop structure of the original program, which is desirable from the view point of maintainability.
Integration of Legacy Software • By adding an additional code, any program can be wrapped with a new exposed interface through which it is accessed, and through which it implicitly accesses other components. • Such an additional code is called a wrapper. • Components are not necessarily objects defined in some object-oriented system. .
Whether the migration of a legacy system into a components environment will succeed or not depends heavily on whether this legacy program allows us to invoke a sufficiently large set of its functions from its outside.
Visual components need to interact with user operations. • When a user event is applied to a visual component, the event dispatcher detects this event and sends a corresponding appropriate standard message to this visual component. • When applied to a wrapped legacy system, such an event is handled either by the wrapper or by the internal legacysystem. • If the legacy system has no GUI, its wrapper can handle all such events. • Otherwise, some events should be dispatched to the GUI of the legacy system. • The program of the legacy system must be able to accept such dispatched events as messages.
Furthermore, the event interpretation by the GUI of the legacy system should be consistent to the standard event interpretation by visual components. • Otherwise, some inherent direct operations of the legacy system may be interpreted as some of the standard operations of visual components. • In such cases, we have to redefine the mapping between events and operations of the legacy system, which is usually a difficult task.
Furthermore, the migration of a legacy system with GUI into a visual component environment requires special consideration on its drawing function. • The drawing by a visual component may damage, or be damaged by, the drawing by another component, which requires each visual component to have the capability of redrawing and managing damaged areas. • The required capability is usually more than what is required for the GUI of the original legacy system. • This difference should be programmed when we wrap this legacy system, which is again usually not an easy task. • An often-used solution to this problem makes the legacy draw its display output off the screen, and maps this image as a texture onto its visual component representation. This solution is sometimes called a ‘shadow copy’ mechanism; it was used in HP NewWave architecture [8]. User events on the visual component need to be dispatched to the off-the-screen GUI of the legacy system.
Distributed Component Integration and Web Technologies • Systems using objects distributed over a network as their components need to use a standard protocol for exchange messages among component objects. • They also need a lookup service to find out a desired component object from a component repository, and to get its reference as a proxy object as well as a method to access it through the proxy. • Such a lookup service varies from a naming service to a content-addressable lookup service. • A naming service accepts an object name and returns its reference, while a content-addressable lookup service accepts a quantification condition of desired objects and returns their proxies.
CORBA (Common Object Request Broker Architecture) • proposed by OMG (Object Management Group) • APIs called GIOP (General Inter-ORB Protocol) for the communication between CORBA objects using ORBs (Object Request Broker) • IIOP (Internet Inter-ORB protocol) as an intermediate protocol to bridge GIOP and TCP (Transmission Control Protocol). • An ORB is a program that enables each distributed object to exchange messages with other distributed objects. • CORBA objects may use any language, while each of them needs to install a special interface to send and receive messages through an ORB. • Each CORBA object uses two kinds of interface codes, i.e., a stub for sending messages going through an ORB, and a skeleton for receiving messages coming through an ORB. • The coding of stubs and skeletons uses a special language called IDL (Interface Definition Language).
JavaBeans and EJB • for Java program components called Beans. • JavaBeans specifies API between components. • In Web applications, when a sever-side Java servelet receives a client request, it invokes the Bean for the requested processing with input parameters. • When the Bean completes its processing, the servelet sends back the result to the client. • EJB (Enterprise JavaBeans) is a specification introducing distributed object technologies to JavaBeans. • EJB allows us to invoke components stored in different machines through a network. • Its components are called Enterprise Beans. • They are classified into two categories. Session Beans manage client requests and control the processing, while Entity Beans perform database processing.
Each EJB client application accesses an EJB server, and gets information about registered objects using JNDI (Java Naming and Directory Interface). • JNDI provides API to access the naming service that manages distributed objects with their names. • Using JNDI, you can invoke any object registered in an EJB server without knowing its location. • Each client application, then, asks an EJB container to create a Home object, which is responsible for creating and deleting Enterprise Bean instances. • When creating an Enterprise Bean instance, the Home object also creates an EJB object that mediates the method invocation of the Enterprise Bean instance. • The EJB client application becomes able to invoke the methods of this Enterprise Bean through this EJB object. The processing result is sent back to the client through this EJB object.
DCOM (Distributed Component Object Model) • DCOM (Distributed Component Object Model) is an extension of COM to cope with distributed objects. • To use a COM component in a server machine, a client uses RPC (Remote Procedure Call) to ask the SCM (Service Control Manager) on the server machine for the instantiation of the COM component and the invocation of this object. • In DCOM, the communication between a client and a COM object on different machines use a proxy at the client side and a stub at the server side. A proxy converts the COM object ID and parameters to the transportation format, while a stub reconverts the transportation format data for the COM object to understand. • These two conversions are respectively called the marshalling and the unmarshalling.
Web services and their integration • Web Service is a technology for application programs distributed over the Internet to mutually utilize their services. • Web Service provides the three mechanisms, namely, • the publication mechanism for each application to register itself as a Web service into a registry, • the inquiry mechanism for a client or a Web service to find another registered Web service based on its provider’s name, service name, service category, or service interface information, • the binding mechanism for the requesting client or Web service to invoke the retrieved Web service.
UDDI (Universal Description, Discovery and Integration) allows applications to register themselves as Web services in a UDDI directory, and allows clients or Web services to search a UDDI directory for those Web services satisfying the requirements. • UDDI is also a Web service. • UDDI works as a service broker, while the requesting client (or application) and the registering application respectively works as a service requester and a service provider. • The registration of a Web service uses WSDL (Web Service Description Language) to describe its detail information. • WSDL is an XML-based language to describe, for each Web service, the methods and parameters it accepts, and its output format.
Clients can invoke a Web service in a different machine through a SOAP proxy as if it invokes a local program, which is a program to invoke the Web service, and to obtain its processing result. • SOAP (Simple Object Access Protocol) is an XML based standard common interface between components distributed over the Internet. • In CORBA and DCOM, components in different specifications cannot communicate with each other. Therefore, these technologies are mainly used in local network environments. • The interoperation of components distributed over the Internet requires a standard common API based on both a standard message format and a standard RPC protocol over the Internet, which leads to the proposal of SOAP. • SOAP uses XML to represent access requests and return value data. • Each request message in XML format is sent to a target component using POST method. • SOAP allows both COM objects and CORBA objects to communicate with each other.
The Internet as a platform and universal document interface • Microsoft.NET is a new technology to make the Internet work as a single platform. • Microsoft Windows use ActiveX technologies for embedding a Windows document in another Windows document of a different type. • Windows applications including Words and Excel are ActiveX objects. • Web documents and applications running on Web pages, however, use XML and SOAP technologies that are different from ActiveX technologies. • Microsoft.NET tries to unify these two different worlds of applications and documents.
The Internet as shared memory spaces for objects • Sun Microsystems proposed a new technology called Jini for various service-providing objects distributed over the Internet to dynamically organize a federation, or a dynamically defined flexible network, of objects. • Some of these objects may not need to run on client computers nor on servers, but may run in electronic appliances or other devices connected to the Internet by wire or radio. • The essential function of Jini is its Lookup service, which works as a broker between service provider objects and client objects. • Neither of them need to know each other in advance. • Jini’s Lookup service organizes participating objects into service groups. • More than one Lookup service can maintain the same service group. • One Lookup service may work as a gateway to another Lookup service.