Chapter 6
Universal Component Description Language and Its Conversion

6.1 UNIVERSAL COMPONENT DESCRIPTION LANGUAGE (UCDL)
6.2 CURRENT COMPONENT TECHNOLOGIES AND DESCRIPTION METHODS
6.3 COMPONENT DESCRIPTION METHOD IN PROGRAM MINING
6.4 AN EXAMPLE OF DESCRIBING A COMPONENT WITH UCDL
6.5 CONVERSION BETWEEN UCDL AND OTHER COMPONENT MODELS
REFERENCES

6.1 UNIVERSAL COMPONENT DESCRIPTION LANGUAGE (UCDL)

Component resources on the Internet are the bases of program mining. Although there are many specific component warehouses on the Internet, for example, Alphaworks, ComponentPlanet, ComponentSource, Flashline, which provide various types of components, such as JavaBean/EJB, COM/DCOM, and CORBA, there are still a few difficulties in choosing, searching, retrieving, analyzing, and composing of components in program mining, caused by differences in description, structure organization, and access manner of these component resources. For program mining, the first problem that needs to be resolved is the universal description method between different components.

A component consists of the component entity and component description. Component description refers to the definition of component features and behaviors, which tells us “what” the component is, while component entity refers to the executable code of the component. The software reuse process involves understanding component concrete behaviors through component descriptions and subsequently calling corresponding functions of component entities.

To realize universal access of diversified types of components, component descriptions must provide information regarding the two aspects given below.

• Information on component capacity. Explaining “what the component can do”: this part of component information is based on the component classification specifications. The function descriptions of different types of components are demanded in terms of unified function classification specifications, so as to support coherent access at the upper layer application.
• Information on component behaviors. Illustrating “how to use components”: normally, component behaviors are expressed with one or more interfaces. Each interface has one or more operations, including input/output parameters and constraints. To make heterogeneous component interface syntax descriptions coherent, it is required to have component interface semantics descriptions independent of actual implementation of components, so as to support mutual understanding and interaction of components.

At present, the various types of components, including ActiveX, DCOM, CORBA, JavaBean, and EJB components, are each based on their own specific regulation. Existing components either run short of the abovementioned two aspects of information or are inconsistent in component description information formats for component description. For example, ActiveX and DCOM only supply the syntax format of the component interface while CORBA and JavaBean cannot provide information on the component function classification and organization. This causes the failure of direct coherent access between different types of components.

Figure 6.1 is a description of conversion interfaces for calling and communication between JavaBean components and CORBA, and calling and communication between JavaBean components and ActiveX components.

Such a one-to-one correspondence conversion mode features high conversion efficiency and easy realization, regarding components with only one or two formats in the system. But if many components need to converse, it will become very complex and hard to call and communicate among the components. Since each component model has its respective implementation mode, every pair of different component models requires specific connectors for communication, which are yet a universal but serve only two specific types of components. Using this measure to deal with the data exchanging and coordinated work among N components will need an amount of n(n−1) kinds of converting. Equally, if a random new component is to be added to interact with the original n components, then it needs adding n kinds of mapping. This measure means a great deal of laboring, and obviously, its efficiency is not very high.

To solve the problems discussed above, we propose the Universal Component Description Language (UCDL).

UCDL defines a set of universal component description interfaces. Different format-based heterogeneous component descriptions are able to converse with UCDL. Figure 6.2 furnishes relations among the UCDL, program mining requirement description, and all kinds of heterogeneous components. In Figure 6.2, in addition to UCDL, we have shown the conversion algorithm from various heterogeneous component descriptions to UCDL descriptions. For instance, the conversion algorithm from a CORBA component description message to UCDL is CUMA, and that from JavaBean component description message to UCDL is JUMA. We will present detailed descriptions of UCDL, CUMA, and JUMA conversion algorithms in the following chapters.

6.2 CURRENT COMPONENT TECHNOLOGIES AND DESCRIPTION METHODS

Before discussing the component description method of program mining, it is necessary to introduce the curent component technologies and their description methods. These components include the CORBA of OMG, the EJB of Sun, and the DCOM/COM of Microsoft.

6.2.1 OMG CORBA

The central task of the Object Management Group (OMG) is to establish a system structure and a group of criteria on the basis of applying object technology to implement the integration of applications under the distributing environment and make the object-oriented software reusable, transplantable, and interoperable in the distributing heterogeneous environment. Shortly after its foundation, OMG presented the Object Management Architecture (OMA). Its reference model is shown in Figure 6.3.

It consists of four parts:

1. Object request broker (ORB)—this allows the object to transparently receive requests and send responses in the distributing environment. It furnishes the distributed object with an interoperability tool under the heterogeneous environment.
2. Object services—a set of basic services for implementation and use of objects.
3. Common facilities—a set of shared services for diversified applications.
4. Application objects—OMG does not make any specifications for it in respect to related traditional applications.

In 1991, OMG set up a standard for ORB that is the CORBA (Common Object Request Object Architecture) specification. On the basis of the client/server model, CORBA defines the Interface Definition Language (IDL) and mapping method, single ORB system architecture, and ORB interoperability mechanism.

IDL language is a neutral language defined in CORBA. IDL is used to describe the object interface and does not involve the concrete implementation of objects. The mapping from IDL to the language C/C or SmallTalk is also defined in CORBA. The architecture system of a single ORB is shown in Figure 6.4.

The ORB architecture consists of two major sides: clients and object implementation. Clients include IDL stubs and dynamic calling interface, while the object implementation side involves the IDL framework, Dynamic Skeleton Interface (DSI) and object adapters (OA). The client side and the implementation side access the ORB kernel via the ORB interface for inter-communication. ORB defines the static and dynamic calling modes among programs, which are furnished, respectively, by the IDL pile and IDL framework, dynamic invoke interface (DII), and DSI. The above parts have the following implications and functions.

• ORB kernel and ORB interface. In the ORB system, components supply services. Clients send out requests to ORB via the ORB interface according to their own requirements, and service components execute corresponding operations in line with client requests. The ORB kernel plays the role of delivering client requests to service components and returning corresponding results to clients. This process is fully transparent to clients: clients do not have to know where components stay on the Website, how components communicate with each other, and how components are implemented, stored, and executed.
• Interface Definition Language. The IDL language is used to define component interfaces, which include a series of naming operations and their parameters. With IDL definition, CORBA components are mapped into different programming languages. Specific component implementation tells clients which operations are applicable and how to activate these operations via the IDL language. But the IDL language is only a descriptive language, not for implementation. To really implement the component functions defined in the IDL source file, it is necessary to map the corresponding IDL description to a designated program language and implement them.
• IDL stub and IDL framework. The IDL stub and IDL framework program supply the static invoke mode and static implementation mode. First, the IDL compiler compiles IDL files in which the service component interfaces are described. Then, the compiler generates the IDL stub and IDL framework program corresponding to concrete programming language. The IDL stub is responsible for encoding user requests, sending them to the component implementation end, interpreting received processing results, and returning the results or exception information to users. The IDL framework decodes user requests, locates requested object methods, executes the methods, and collects and sends the execution results or coded abnormal messages back to the clients.
• DII and DSI. DII and DSI furnish dynamic invoke and implementation methods. Through querying related service object interface description messages and using DII to dynamically invoke the ORB kernel interface, users may construct client requests and send them to the component implementation party. The implementation side may use DSI to dynamically distribute the user request mechanism so as to dynamically dispose client side requests.
• Object adapters (OAs). OA is a major method for components to access ORB for services. Each type of component implementation may have a corresponding OA, reducing ORB kernel burdens. Services supplied by OA generally include component application generation and interpretation, method invoking, alternation security, and component example activation and release.

CORBA specifications are put forward with the following significances:

1. The concept of “Broker” is introduced into the specification CORBA. One broker has at least three functions: complete the mapping of abstract service request sent from the client side; automatically find and search for the address of the component implementing party; automatically appoint a route to finish the component execution. Therefore, when a user programs in the client, instead of knowing many details, he only needs to give a complete description of the demanded tasks and goals of the client.
2. The adoption of the broker mechanism implements the entire separation of the client program and server program, which essentially differs from the Client/Server pattern based on the procedure calling mechanism.
3. The definition of CORBA specification is object-oriented programming and implementation method. There are many advantages resulting from the combination of distributing computation and object-oriented ideas—for example, the redundancy will be controlled at the lowest level, an object can be used by client programs as well as by server programs, the change of object implementation does not affect the program implementation of both sides, and the reuse rate of software will be raised.
4. By providing the software bus mechanism, CORBA allows any application program, software system, and tool to be conveniently integrated into the CORBA system, so long as they have interface definitions harmonizing with the interface specifications. The interface specifications are independent of any implementation language and environment.
5. CORBA adopts the layer-based design principle and implementation method. CORBA is merely a standard used for ORB in OMA architecture; however, the application-oriented object can be defined and implemented in gradual steps and tiers in the OMA application object or application developing environment.

CORBA integrates object-oriented concepts into distributed computing to define a set of interface modes irrelevant to implementations. It borrows the broker mechanism to separate the client and server, allowing CORBA specifications to become an open, client/server-based model, and an object-oriented distributed computing industrial standard.

In one word, CORBA is a huge and complete specification with very good mutual operation and openness. The shortcoming of CORBA is that it is too big and complex, and the relative slowness involved in technical and standard renovation. So far, CORBA has not been widely applied in actual applications.

6.2.2 SUN's EJB

EJB is an important part of J2EE, which is a Java-based server-side component specification introduced by Sun. The EJB technology of Sun is a server-oriented distributing application component technology, which is developed by Sun on the basis of Sun's JavaBean technology. It is based on the Java language and provides a Java byte code based way of software reuse.

EJB gives the server-side distributing component specification, including the specification of the component, component container interface and the standards for component packaging and component configuration. The introduction of the EJB technology makes it possible to develop server-side distributing applications with the component-based method of Java. The software manufacturer can implement the EJB server according to EJB specifications. The application program developer can concentrate on supporting the commerce logic that the application needs without worrying about the implementation of servers and surrounded frameworks. At the same time, when a third party EJB groupware developed according to the EJB specification is integrated into an application system, it is not necessary to change its implementation code or to do recompiling.

In terms of the multi-layer structure of enterprise application, unlike JavaBean, EJB belongs to the middleware technology of the business logic layer. It provides transaction processing ability. Since the emergence of the tri-layer structure, the middle-layer, i.e. the business logic layer has become the core of transaction processing. It separates from the data storage layer and replaces most of its positions. Regarding distributed computing, just like CORBA, EJB supplies distributed technology and communication measures among objects. From the viewpoint of Internet technology application, EJB is becoming the technology standard for next generation application servers. The EJB architecture is demonstrated in Figure 6.5.

As shown in Figure 6.5, the EJB architecture consists of two major parts: clients and EJB servers. Clients and EJB servers interact and communicate in line with EJB specifications. Offering EJB containers, EJB servers can realize the interaction and communication functions. EJB containers consist of five

parts: home interface, home object, remote interface, EJB object, and EJB bean.

Home Interface defines methods to create, delete and locate EJB objects. It is practically implemented with Home Object. Clients establish actual EJB objects with Home Interface. Remote Interface is used to define methods that clients are able to access. It is actually implemented with EJB Object. Clients access EJB Bean via Remote Interface. EJB Bean comprises the actual implementation of EJB components. The EJB defines three types of Beans: Session Bean, Entity Bean, and Message-Driven Bean. Session Bean represents the interaction session between client program and EJB components. The function finished by it may be a read–write operation in database or a simple mathematic computing. Entity Bean is used to provide an object-type view in the EJB server of the records in the database. An entity bean represents a line of records in the database table. Message-Driven Bean offers message mechanism-driven operations.

Figure 6.5 shows the actual process of invoking EJB components.

1. Clients invoke Home Interface to create EJB Object examples.
2. Home Object, Home Interface implementation target, applies the example-based method to establish the EJB Object.
3. Return the EJB Object citation back to clients.
4. In accordance with the received EJB Object citation, clients tap Remote Interface to access concrete EJB Bean-furnished services.

6.2.3 MICROSOFT COM/DCOM

The full name for COM is Component Object Model, which is a group of specifications—a group of binary and network standards proposed by Microsoft to solve the problem of communication between two components.

The COM component has its own attribute and methods; however, all of these are packaged by COM. When the client calls the method of COM, the only way is through its interfaces. Interfaces are the only channel through which COM interacts and communicates with the outside. Figure 6.6 shows the relationship between interfaces and the COM component.

From Figure 6.6, it is obvious that a COM component consists of two parts: one is the interface definition and the other is the implementation of the COM component. In the specification of COM, the interface definition and COM component implementation are relatively independent.

• Interface definition. The interface definition follows the MIDL; it is an expansion of IDL by Microsoft. As seen in Figure 6.6, interfaces contain a set of function data structures which is responsible for defining functions.When a component is established, interfaces will generate interface pointers and a virtual function table. The interface pointers point to the virtual function table (the table becomes an aggregate of a set of function pointers). Each function pointer points to the corresponding function implementation code in the “COM component implementation” part. Interface specifications are not set up on the basis of any programming languages. Any language with sufficient data expression capacity may describe interfaces.
• Implementation of the COM component. The implementation of the COM component includes the codes for implementing all the methods in the COM component. COM defines the ways of interaction via interface between components and clients. It enables the client and component to communicate with each other without any intermediate components.

6.3 COMPONENT DESCRIPTION METHOD IN PROGRAM MINING

These days, manufacturers have developed many heterogeneous components of diversified formats. These components offer various functions. In the process of program mining, we need to organize heterogeneous

components to ensure completing user required service functions. Obviously, if there are no consistently specified description interfaces, the system will have no way of exploring these heterogeneous components with different functions. Under such a circumstance, it is necessary to provide a unified access interface for heterogeneous components, screen the difference among various component libraries, and give the program mining well-organized component resources. This is the basis of component organization, classification, management, storage, identification, discovery, search, assembly, and other component processing operations in program mining. To be specific, the component description used for program mining needs to meet the following requests.

• To provide the description of component functions as much as possible to help the user and computer understand the component behavior.
• To provide sufficient information on component organization, classification, and application filed, so as to conveniently facilitate establishing relations between user requirements and components.
• To provide a precise description of semantic information regarding component behavior and the context dependency, convenient for the intelligent agent and other automatic tools to assemble the components or do other operations.
• To support the traditional keyword-based component searching and other more precise component searching based on specification-matching.
• To provide information on component location and resources, support component locating and dynamic loading under the network environment.
• The descriptors of the component description should be free from any specific component technology and new description information can be added according to the demands.
• The descriptors of the Component description can be used in different component frameworks and can be integrated seamlessly into heterogeneous networks and application programs.

6.3.1 COMPONENT MODEL IN PROGRAM MINING

In program mining, we use the component model in catalysis specification as the basis of component description. This model is widely used in component development and software research, for instance, Microsoft Repository, COOL, Gen, and so on. According to this model, each component includes

three parts—specification, implementation, and executable parts—as Figure 6.7 shows. The followings are the details of each part.

• Component specification. Component specification refers to the definition of component behaviors. It accounts for the component “do what?” Generally, the component behavior is defined by one or more interfaces, which fall into two types: provided and needed. The interfaces commonly consist of a set of custom-usable naming operations. In the component specification, the format and semantics of each operation need precise definition. The component specification serves as a contract between the component provider and component requestor and a reference for implementing the component.
• Component implementation. It refers to the inner logic to carry through the component specification and the corresponding code. Component implementation and component specification should be independent of each other. Thus, as long as the component specification is followed, the modification of component implementation (such as algorithm renewing, structure alteration) brings no changes toward a component requestor. A component specification may correspond with many different component implementation methods; only if the implementation follows the definition of component behaviors in the specification, can the languages and methods of component implementation be selected flexibly.
• Executable module. This part is closely related to component implementation and the operation platform. It consists of a set of executable modules that can accomplish specific functions. These modules may be files of diversified forms, including executable files (exe), dynamic linking library (dll), and Java archived files (jar).

6.3.2 STRUCTURE OF UCDL

The component model in Figure 6.7 is the basis of component description in the program-mining framework. It defines component specifications, implementation conditions, and execution platforms. However, with continuous increase in the number of components, it is necessary to classify and organize components according to certain classification models and give a unified description of heterogeneous components of various formats. Therefore, component descriptions should also include component organization, classification, and functional information. For this purpose, on the basis of the above-mentioned component models, we introduce descriptions of related component functions and organizations, called Universal Component Description Language (UCDL).

UCDL makes reference to the OCL language and WSDL component description language to classify component descriptions into five parts.

• CBI—Component Basic Information
• CRL—Component Resources Location
• CCI—Component Classification Information
• CIS—Component Interface Specification
• CED—Component Extended Description

The UCDL composition is shown in Figure 6.8.

1. Component basic information. This part indicates the nonbehavior features of components defined by component developers (such as component name, author, version, manufacturer, and scale size).Nonbehavior feature messages are mainly illustrative messages of the component. This part includes the following entries:

   • ID	Unique identification of component descriptors in the whole range
   • Name	Component name
   • Author	Author who developes the component, including author's name, address, and messages for contact
   • Vendor	Supply information on component manufacturer or organization, including company name, address, and contact messages
   • Version	Component's current version and revision numbers
   • Date	Date of publishing and quoting the component
   • Size	Size of the component, measured in K bytes
   • Functional description	Literal description of component accomplished functions, indicating the component's main features, functions, and other valuable messages. Keyword list may be extracted from the description in support of traditional component retrieval based on keyword matching.

2. Component resources location. This part indicates information about component executable sections, source codes, related resource files, and their locations. It might also include detailed documents, comments, notes, tests, and demonstration of application documents. Components may be executed in the forms of dll, exe, and jar files, with locations generally marked with the URL.
3. Component classification information. This part illustrates the information that is used for classifying component resources. In allusion to requirements on component applications in program mining, UCDL classifies components from the viewpoint of application domain, component function, component type, programming language, running platform, and level of reuse (LR). In subsequences, CCI covers the following entries:
   • Application domain. Indicate the domain of actual applications of the component, including E-Government, E-Commerce, and E-Learning.
   • Component function. Indicate the software functions furnished by the component in the original or possible software systems, including user interface design, network functions, file operation, graphics processing, and so on.
   • Running platform. Show the operating platform of the component, including the operating system for component running and supporting platform software, etc.
   • Component type. Indicate component formats, including JavaBean, EJB, and ActiveX, etc.
   • Programming language. Point out programming languages for component implementation, including Java Visual C# etc.
   • Reuse level. Show the level of component reuse (LCR). LCR is the level of application of components at various stages of program mining and software reuse. For instance, some component is an integral application by itself, whose LCR is located at the “application” level. As for source code components, the LCR is at the “coding” level.
   In UCDL, CCI is able to designate attribute values of single components at the above entries and assist component users to understand component application domains and functional classifications. Meanwhile, when the program mining system converts component resources acquired from the Internet with the UCDL format and goes on with organization and management, UCDL CCI may also be used as the foundation for component resources organization and classification. We will illustrate the issue in later sections of this chapter.
4. Component interface specification. Interface specifications refer to the dynamic behavior features of components that might show up in component containers or execution environments in the process of composing and running. Since existing component interface descriptions are generally associated with component implementation languages, different component model interfaces are defined in different ways. To allow different components “understand” each other's interface messages, UCDL makes unified descriptions of component interfaces on the basis of XML, which is the CIS.
   In UCDL, interaction information among components is abstracted into messages. Each message has its own definition. Components exchange messages via interfaces. The appearance of a message in an interface will trigger off the component to take a certain action, accomplish corresponding functions, create related output messages according to execution results, and put it out with corresponding interfaces.
   UCDL component interface specifications comprise a set of such interfaces. Each interface further consists of the interface name, interface type, input message, and output message. Of this, input and output messages are given by message definition.
   Figure 6.9 shows the composition structure of UCDL component interface specifications; these are described below.
   1. Message definition. The message definition part defines messages for interaction among components. Each message includes one or more elements, whose data types may be basic data types defined inadvance, or self-defining data types that the component author defines with basic data types.
      • Basic type definition. For the neutrality of the platform, UCDL selects to use XML Schema Definition (XSD) as the basic type system.
      • Self-defining type definition. Since it is impossible to use one data type system to describe all abstract data types of the present stage, UCDL allows defining self-defining data types.
   2. Interface definition. Each interface represents a channel for the interaction between user and component, including the input and output messages. The name is expressed in its own “name” attributes:

      • Name	Indicate interface name
      • Description	Describe interface functions
      • Input Message	Show the input message of the interface. The contents of the message are defined by the Message Definition part.
      • Output Message	Show the output message of the interface. The contents of the message are defined by the Message Definition part
      • Constraints	Indicate constraints of interface behaviors. If the Precondition is satisfied, the interface is completed to ensure satisfying the Postcondition.
      • Precondition	Precondition
      • Postcondition	Postcondition

   3. Interface specification definition. Component interface specifications make unified description of component interface behaviors. They consist of a set of interfaces.
5. Component description extension (CED). UCDL furnishes extensible description capacity with CED. Component users may add other messages needed in the use of the component according to the actual situation of the application, including such component reuse messages as component application examples and composing records, and user feedback on the use of components. Such information of UCDL adopts the text-based description method.

6.3.3 UCDL XML EXPRESSION

To satisfy UCDL requirements independently of specific component technologies and openness to extension, we select the XML to express the UCDL component descriptor after settling the composition of all its parts.

Regarding the first three parts of the UCDL descriptor, we may directly define the corresponding XML tag for each descriptor, such as <ID></ID>, <Name></Name>, and <Author></Author>. As for the descriptor of interface specifications, we may first apply OCL expression to define the interface operation and event and then envelop the expressions in XML tags. Since the OCL expression is also recorded in the form of an ASCII code, it is easy to read and analyze and validate with the OCL Parser.

Figure 6.10 is a UCDL document structure based on XML descriptions. The root element of the UCDL document is <Component>, marking the beginning and ending of component description messages. Sub-elements under the root element <Component> are composed of the following in accordance with UCDL makeup:

1. <BasicDescription> element. The <BasicDescription> element defines elements for the description of component basic information (CBI), including

   <ID>	Unique identification of component descriptors on the whole range, automatically generated by the system
   <ComponentName>	Name of the component
   <Author>	Author establishing the component, including the name, address and messages for contact

   <Vendor>	Supply information on component manufacturer or organization, including company name, address, and contact messages
   <FunctionalDescription>	Literal descriptions of functions accomplished by the component.
   <Date>	Date of the publishing of the component
   <Version>	Current version and revision number of the component
   <Size>	Size of the component as measured with K bytes.

2. <ResourceLocation> element. The <ResourceLocation> element indicates the location of the component, normally the URL address of the component, with which the program mining system may find requested components.
3. <Classification> element. This element defines the elements for the description of component functions from multiple facets, including

   <ApplicationDomain>	Indicate application domain of the component
   <ComponentFunctionality>	Show function classification information of the component. The element consists of two tiers:
   <PrimaryCategory>	element pointing out function classifications of the component and
   <Sub Category>	element further elaborating more detailed subfunction classifications under it.
   <RunningPlatform>	Show the supporting software platform for the running of the component
   <ComponentType>	Show the component type of the component
   <ProgrammingLanguage>	Show the programming language for the implementation of component
   <ReuseLevel>	Show the level of component reuse
   <OperatingSystem>	Show the operating system upon which the component can run

4. <InterfaceSpecification> element. The <InterfaceSpecification> element contains the interface specification information of the component. It includes one or more <Interface> elements. The “name” attribute defined by the interface specification expresses the name of the interface. Each <Interface> consists of <Inputmessage> and <Outputmessage>.
   Each message contains one or more message parameters <part>. The name attributes of the message parameters show the name of the message parameters, while the type attribute indicates the data type of message parameters. The data type may be XSD basic data type, or user self-defined data type. The definition of the self-defining type is in the <complexType> tag. Each <element> tag represents one basic or self-defining data type.
5. <Extension> element. The <Extension> element expresses the description extension part of the UCDL. At present, the element is defined as text description. Component users may add in this part composing records, application examples, and feedback messages.

6.4 AN EXAMPLE OF DESCRIBING A COMPONENT WITH UCDL

To clarify the UCDL structure, we use UCDL to describe an FTP Protocol component as follows:

The FTP Protocol component is a JavaBean component developed by IBM and published at Alphaworks. It implements the function of file transmission protocol.

The FTP Protocol component works with interface component FTP UI to form a FTP Client application, as shown in Figure 6.11. The FTP UI component receives the user's FTP command and delivers it via messages to the FTP Protocol component. The FTP Protocol component realizes the FTP protocol.

With the information published by the FTP Protocol component, we acquire basic information on the FTP Protocol component, as shown in Table 6.1.

According to the UCDL classification specifications, the FTP Protocol component has classification messages as shown in Table 6.2.

The FTP Protocol component cooperates with other components through event triggering and method invoking to supply the file transmission service. The main events and methods furnished by the component are shown in Table 6.3.

Describing and expressing the messages in Table 6.3 with the UCDL language, we have the following UCDL description document of the FTP Protocol component. All the tags are in bold.

6.5 CONVERSION BETWEEN UCDL AND OTHER COMPONENT MODELS

In the following we describe how to convert a heterogeneous component description into the unified UCDL using as an example the conversion of CORBA to UCDL (CUMA).

6.5.1 CONVERSION FROM THE CORBA COMPONENT DESCRIPTION TO UCDL

1. Descriptions of the CORBA Component. In the CORBA specifications, XML documents are used to describe component information. There are two major documents here: CORBA Software Descriptor (CSD) and CORBA Component Descriptor (CCD). The former one mainly includes CORBA component basic description messages and classification messages. The latter one contains component interface specification messages.
   1. CORBA software descriptor. CSD is used to describe the contents of the software, with a suffix “.csd” (CORBA Software Descriptor). The description file mainly covers the following elements: general information about the software (including software title, author, descriptions, license), link information of the IDL file and its attribute file, platforms for component implementation (operating system, processor, programming language, compiler, ORB, and other types of library files), linking information of the implementation file and deployment requests, attribute files, CORBA component description file location, and entry point.
   2. CORBA component descriptor. The CORBA component descriptor contains component interface specification information (i.e. information of the component interface for interaction with the outside), with a suffix “.ccd” (CORBA Component Descriptor). CORBA component description documents include various component features used in design and deployment. The two elements associated with UCDL descriptions are as follows:
      1. <componentrepid> element
         The <componentrepid> element is used to identify the component in the interface warehouse. The value is also used to point to the main <componentfeatures> element of the component in the descriptor, so as to distinguish from the <componentfeatures> element of the inherited component. Its “repid” attribute is practically the identificaiton value of the component in the interface warehouse.
      2. <componentfeatures> element
         The <componentfeatures> element describes the following aspects of the component: other components the component inherits, interfaces the component supports, and various ports the component used for interacting with the outside. In addition to the main component, features of other components it inherits are also described in the respective <componentfeatures> element.
   The <componentfeatures> element has two attributes: “name” and “repid.” Of this, the “name” attribute is used to express the alias of the component—thus it is not exclusive. But the “repid” attribute is the unique identification of the component. It is the id of the component in the interface warehouse. It matches the “repid” attribute of the <Componentrepid> element. Information of the component ports for interaction with the outside are described in the sub-element <ports>.
   The subelement <ports> contains five subelements to express different ports of the component: “uses,” “provides,” “emits,” “publishes,” and “consumes.”
   The <uses> element is used to show the component exterior interface. Its “usesname” attribute is applied to express the variable name of the interface defined in the IDL file. The “repid” attribute is used to indicate the identification of the component applied interface type in the interface warehouse.The <provides> element is used to express the component furnished interface (facet). Its “providesname” attribute is applied to show the variable name of the facet defined in the IDL file. The “repid” attribute is used to indicate the identification of the component supplied interface type in the interface warehouse. And the “facettag” attribute expresses the tag of the facet for realizing the segmentation of linking components.
   Since the <emits>, <publishes>, and <consumes> elements do not have counterparts in UCDL, they are not conversed. Therefore, we do not elaborate on them here.
2. Algorithm of generating UCDL from CORBA component descriptions. The process of generating UCDL from CORBA component descriptions is to obtain related information from corresponding XML-based CORBA component description files to fill in the UCDL structure. The XML parser generates a DOM tree with input CORBA component description documents. The DOM tree uses the tier mode to identify the CORBA component structure, and converts the structure into the DOM tree of the UCDL structure under a certain strategy. Then, it exports the result in the XML form to generate a “.ucdl” file. The practical process is as follows:
   1. Acquiring component basic information (CBI) from the CORBA component package description documents
      Step 1: Allocate a whole-range identifier as the “ID” element value in the UCDL structure. Record the current time as the Date element value and the size of the software package as the Size element value.
      Step 2: Obtain basic information of other components (CBI). Figure 6.12 shows how to acquire needed UCDL component basic information from the CSD. The arrowheads in the figure indicate the corresponding relationship between the CORBA component description messages and the UCDL elements. For instance, the “Name” element of UCDL comes from the “Name” subelement of the CORBA “softpkg” element. The “Author” element of the UCDL comes from the “Name” subelement of the “author” element in the CORBA component description. The sources of other UCDL CBI elements are shown in Figure 6.12.
   2. Analyze and acquire component classification information (CCI) from the CSD
      Step 3: Information about the operating system and programming language in UCDL can be acquired from the fields corresponding to the CSD, as shown in Figure 6.12.
      Step 4: Fill the UCDL Component Model descriptor with the “pkg-type” element of CORBA description information. Fill the UCDL Programming Language describer with the “os” sub-element of the Implementation element in the CORBA description information. Fill the UCDL Programming Language describer with the “Programming-Language” subelement of the Implementation element in the CORBA description information.
      Step 5: Use the natural language processing module to retrieve the keyword of the “Description” field contents of CORBA components. According to the level of matching between the keyword and the domain dictionary, acquire the contents of “Application Field” and “Component Function,” descriptors of the application domain and component function of the component, and fill them to the UCDL tags <ApplicationField> and <ComponentFunction>.
   3. Acquiring component interface information from CORBA component description documents.
      The relationship between the CORBA component description element and UCDL description element is shown in Figure 6.13.
      Step 6: Read the “repid” attribute of the <componentrepid> element in the CORBA component description file to acquire the id of the component interface.
      Step 7: The conversion program compares the component interface id with the “repid” attribute of each <componentfeatures> element of the descriptor. If the two match, it proves that the description element of the interface has been found.Step 8: Read the <ports> subelement of the <componentfeatures> element to acquire a description of the interface linking the component with the exterior.
      Step 9: Join the <componentrepid> and <componentfeatures> to create the corresponding UCDL interface.
      Step 10: Convert the <uses> interface and <provides> interface of the ports into UCDL interfaces, and create the same amount of interfaces according to the <facettag> values, as shown in the following:Step 11: Omit emits, publishes, and consumes interfaces.
      Step 12: Generate XML description file (.ucdl) corresponding to UCDL according to the converted tree.
   4. Fill in component resource location messages
      Step 13: Fill in the current location of the component in the UCDL ResourceLocation element.
3. Example of generating UCDL from CORBA component descriptions. Here, we use UCDL to describe “Accumulate,” an adder component of CORBA format, to illustrate the process involved in the CUMA algorithm.
   The main function of the adder component “Accumulate” is to add up two integers. It has one interface, with an “add” named operation. The parameter is the two integers. The return value is an integer, the sum of the two parameters. The IDL file “Accumulate.IDL” that corresponds to the component is as follows:We first acquire the concrete contents of the CSD and component description file of the adder Accumulate component, which are based on XML.
   Of this, CSD contains component basic information and classification information, as shown in the following:In CSD, we use the <author> element to describe detailed information about the component developer. The <idl> element is used to designate idl interface files. The <descriptor> element appoints the component description files in the software package. The <implementation>element specifies related information of the implementation files in the software package (including the operating system, programming language, and execution file names that are significant for the implementation, and reliance on other types of libraries).
   The component description file includes component interface specification messages. The corresponding XML descriptions are as follows:With the CSD and component description files of the adder component, we will be able to acquire the requested contents to follow the previously mentioned method that extracts UCDL descriptions from CORBA component description messages.Having completed the above steps, save the UCDL component general interface descriptions in the XML file format.

6.5.2 MAPPING FROM OTHER COMPONENT DESCRIPTIONS TO UCDL

We can adopt corresponding mapping methods for other types of component descriptions also, which are similar to the method of CORBA-to-UCDL (CUMA). We convert the information of the component itself into the corresponding UCDL descriptor structure, resulting in unification descriptions in order to support program mining and other applications. For example, aiming at the JavaBean component, we introduce the mapping method of JavaBean-to-UCDL(JUMA), and aiming at the ActiveX component, we introduce ActiveX-to-UCDL(AUMA).

1. Mapping algorithm of JavaBean-to-UCDL (JUMA).
   If the component type is determined to be the JavaBean component, then the mapping method adopted in this invention includes the following steps:
   1. According to the UCDL structure generate an empty XML file with all empty descriptors, making preparations for filling component information.
   2. Allocate a unique ID and fill it into the “id” element of the component package as the overall identification of component package.
   3. Then, read the “Bean information” class of the JavaBean component; it is defined by the JavaBean component specification.
   4. According to the structure of Bean information defined in the JavaBean component specification, we obtain the Name, Author, Vendor, Version, Date, and Size of the component and fill these into the corresponding descriptors in the basic information part of the UCDL package.
   5. Fill the descriptor Functional Description, of the Description field information in the Bean information class into the corresponding elements in the basic information part of UCDL.
   6. Use the existing natural language processing module to retrieve and analyze the Description in Bean information through keywords extraction, and fill the results of Application Field and Component Function into the basic information of the UCDL package.
   7. Fill the Component Model description of the UCDL package with “JavaBean”, and Program Language “Java”.
   8. Start the selfcheck mechanism of JavaBean; we get, event and method of the component.
   9. Fill the corresponding descriptor in property information of JavaBean into the property description part of interface information offered by the UCDL package.
   10. Fill the corresponding descriptor in event information of JavaBean into the event description part of interface information offered by the UCDL package.
   11. Fill the corresponding descriptor in method information of JavaBean into the method description part of interface information offered by the UCDL package.
   12. Traverse all the fields of UCDL, leave the empty fields as defaults.
   13. According to the storage location information of the JavaBean component, fill the location description value of the component to point to the URL of the component.
2. Mapping Algorithm of ActiveX-to-UCDL (JUMA).
   If the component type is judged to be the ActiveX component, then the mapping method that the invention adopted includes the following steps.
   1. According to the UCDL structure generate an empty XML file with all empty descriptors, making preparations for filling component information.
   2. Allocate a unique ID and fill it into the “ID” element of the component package, and make it the overall identification of the component package.
   3. According to the component standard and the basic information field of ActiveX field we obtain the Name, Author, Vendor, Version, Date, and Size of the component and fill them into the basic information part of the UCDL package.
   4. Use the natural language processing module to retrieve and analyze the Type library in ActiveX control through keywords extraction, and fill the results of Application Field and Component Function into the basic information part of the UCDL package.
   5. Fill the Interfaces information of ActiveX into the interface information of UCDL.
   6. Traverse all the fields of UCDL and leave the empty fields as defaults.
   7. According to the storage location information of the ActiveX component, fill the location descriptor of the packaging component to point to the URL of the component.
   After taking all the steps above, different types of components such as CORBA, JAVABEAN, and ActiveX, can choose different mapping methods to converse the information into the unified UCDL structure. For other types of components, based on the mapping methods above, corresponding methods can be developed to generate the UCDL general descriptor, so as to form a united component description to support program mining and other applications.

REFERENCES

Alphaworks. http://www.alphaworks.ibm.com/

Baker, A. D., Van, D. P. H., and Erol, K. (1999). Agents and the Internet: infrastructure for mass customization. IEEE Internet Computing, 3(5), 62–69.

Bellavista, P., Corradi, A., Montanari, R., and Stefanelli, C. (2003). Dynamic binding in mobile applications. IEEE Internet Computing, 7(2), 34–42.

Ben-Shaul, I., Kaiser, G. (1998). Coordinating distributed components over the Internet. IEEE Internet Computing, 2(2), 83–86.

Buhler, P. A., and Huhns, M. N. (2001). Trust and persistence [software agents]. IEEE Internet Computing, 5(2), 85–87.

COM:Component Object Model Technologies. http://www.microsoft.com/com/tech/DCOM.asp

ComponentPlanet. http://www.componentplanet.com

ComponentSource. http://www.componentsource.com

Dou, Y. H., Zhang, Y. X., and Li, X. (2004). An XML-based software component description method for program mining. Chinese Journal of Electronics, 13(1), 100–104.

Enterprise JavaBeans Specification 1.1. http://java.sun.com/products/ejb/docs.html

Flashline. http://www.flashline.com

Fuentes, L., and Troya, J. M. (1999). A Java framework for Web-based multimedia and collaborative applications. IEEE Internet Computing, 3(2), 55–64.

Gorton, I., and Liu, A. (2003). Evaluating the performance of EJB components. IEEEInternet Computing, 7(3), 18–23.

Hood, C. S., and Chuanyi, J. (1998). Intelligent agents for proactive fault detection.IEEE Internet Computing, 2(2), 65–72.

Huhns, M. N. (2000). Agent teams: building and implementing software. IEEE Internet Computing, 4(1), 93–95.

Huhns, M. N. (2003). The sentient Web. IEEE Internet Computing, 7(6), 82–84.

IDL/LanguageMappings Specifications. http://www.omg.org/technology/documents/idl2x_spec_catalog.htm

Maurer, F., and Dellen, B., et al. (2000). Merging project planning and Web enabled dynamic workflow technologies. IEEE Internet Computing, 4(3), 65–74.

McFall, C. (1998). An object infrastructure for Internet middleware: IBM on Component Broker. IEEE Internet Computing, 2(2), 46–51.

Mei, H., and Yang, F. Q. (2002). Building enterprise reuse program-A model-based approach. Science in China (Series F), 45(3), 161–173.

Menasce, D. A. (2004). QoS-aware software components. IEEE Internet Computing, 8(2), 91–93.

Object Management Architecture. http://www.omg.org/oma/

Object Management Group. http://www.omg.org/

Port, D., and Kaiser, G. (1998). Collaborative technologies for evolving software systems. IEEE Internet Computing, 2(6), 79–83.

Rosenberg, D. (1998). Bringing Java to the enterprise: Oracle on its Java server strategy. IEEE Internet Computing, 2(2), 52–59.

Seacord, R. C., Hissam, S. A., and Wallnau, K. C. (1998). AGORA: a search engine for software components. IEEE Internet Computing, 2(6), 62.

Sheth, A., and Bertram, C., et al. (2002). Managing semantic content for the Web. IEEE Internet Computing, 6(4), 80–87.

Steel, C. M. (2002). Building a multisite Web architecture. IEEE Internet Computing, 6(5), 59–66.

Sun Microsystems, Inc. (1997). Java Bean Specification Version1.01.

The OMG's CORBA Website. http://www.corba.org/

Yang, F. Q., and Mei, H., et al. (2002). Some discussion on the development of software technology. Acta Electronica Sinica, S1, 1901–1906.

Zhang, S. K., Wang, L. F., and Yang, F. Q. (2002). Hierarchical message bus-based software architectural style. Science in China (Series F), 45(2), 111–120.

Zhang, Y. X., Fang, C. H., and Liu, B. (2004). An Encapsulation and Unified Access Scheme for Components (Chinese Patent), Publication No. 200410030654.5.