Chapter 10
Prototype System, Application Examples, and Future Work

10.1 RUNNING ENVIRONMENT AND ARCHITECTURE OF THE PROTOTYPE SYSTEM
10.2 IMPLEMENTATION OF THE LCRW
10.3 APPLICATION EXAMPLES
10.4 FUTURE WORK
REFERENCES

This chapter introduces the prototype system of program mining we developed, including the implementation environment, system function design, module structure, implementation method, etc. On this basis, some examples of application of the prototype system are introduced. The application illustrations are used to explain how to apply the program mining technology to acquiring Active Services. In the end, we forecast the development orientations in the studies of Active Services and program mining.

10.1 RUNNING ENVIRONMENT AND ARCHITECTURE OF THE PROTOTYPE SYSTEM

10.1.1 RUNNING ENVIRONMENT OF THE PROTOTYPE SYSTEM

We have developed a program mining prototype system in Tsinghua University, known as COMP, whose hardware environments are an Ethernet connected with the Internet. The setup is shown in Figure 10.1.

The component resource warehouse server maintains the local component resource warehouse (LCRW), storing the reusable components for the

program composition. In the prototype system COMP, we use two component warehouse servers to store component resources; we do it for two purposes: one is to provide redundancy backup, the other is to share the storage task of the individual component resource warehouse and speed up the acquisition of component entity. Other program mining systems can also adopt different organization structure according to the application environment, or adopt a distributed model to establish a component resource warehouse. Then, by means of inter-agent interaction these component resource warehouse servers can maintain the consistency between component resource information and directory information.

The program mining server processes the requests of program mining from the client, activates the corresponding intelligent agent to execute the analysis of the user's requests, divides the advanced requests of the user into functional parts of program, obtains the component composition scheme of the program, then establishes one or more component retrieval agents to retrieve the functionally similar components in the component resource warehouse, downloads them to the local computer, and composes them dynamically so as to form the necessary service. After verification, it submits the service to the user through the user interface agent.

The client offers a user interface, and enables the user interface agent to provide icon selection and natural language input interface. Through this

interface, the user submits computational requests. The interface agent preprocesses the user's requests and then forwards the requests to the requirement analysis agent located in the program mining server for further processing. The client at the same time provides the application framework with the aim of executing the composing of the program. This mined program is activated in the application framework so as to accomplish the required computational functions.

The management workstation in the system offers unified management for the agents in the whole system, supervising the running status of each agent, executing the operations of establishment, start-up, stop, and deletion of each intelligent agent. This management workstation, at the same time runs a monitor to task surveillance displaying each mining missions' description information, process progress, and other task-related information of the intelligent agent.

Table 10.1 lists the hardware configuration of COMP's running environment.

Table 10.2 lists the software configuration of COMP's running environment.

10.1.2 ARCHITECTURE OF THE PROTOTYPE SYSTEM

According to the program mining process introduced in Chapter 4, the prototype system of program mining can be divided into six sub-systems in terms of functions.

• Human–machine interface subsystem
• Requirement analysis and function decomposition subsystem
• LCRW subsystem
• nternet component mining subsystem
• Local component mining subsystem
• Agent platform and system management subsystem, as shown in Figure 10.2.

In Figure 10.2, each subsystem is distributed in the hardware environment shown in Figure 10.1. Through the coordination of an intelligent multi-agent agent, these subsystems can cooperate to handle the user requests, sort out the requisite component or component combination from LCRW, form the target program, and provide the services users need.

The functions of each subsystem are as follows:

1. Human–machine interface subsystem.
   1. Input function. Providing the input and navigation interfaces for the user, and supporting the navigation of icons and the input via voice.
   2. Extraction of requirement description. Forming program mining requirement according to the user's choice, and working with requirements analysis and function decomposition subsystem to generate the keyword list and subfunction sequence list in XML language, which is sent back to be confirmed by the user.
   3. Submitting function. Executing the target program through program mining and submitting the services users need.
   4. Intelligent processing function. Tracking and recording the user's operation, setting up each user's interest model and storing it in the knowledge base. In addition, it refers to the user's habit and interest, providing timely help, amending the user's mis-operation, and recommending a program relative to the user's operation.
   5. Other input and output interaction between the system and the user.
2. Requirement analysis and function decomposition subsystem.
   1. Analyzing the user's input with human–computer interface subsystem and generating the keyword table and subfunction sequence table in XML language.
   2. Further clarifying the searching requirements of the target components by referring to the keyword table.
   3. By referring to the keyword table and subfunction sequence table, judging whether the required services have been completed, and sending the result back to the human–computer interface subsystem.
   4. Starting the Internet component mining subsystem or local component mining subsystem.
3. Internet component mining subsystem.
   1. Monitoring the professional component library on the Internet.
   2. Retrieving a new component from the professional component library on the Internet.
4. Local component mining subsystem.
   1. Searching for the component in the LCRW according to the keyword list.
   2. Confirming the correctness of the retrieved component.
   3. Composing the components according to the subfunction sequence list.
   4. Verifying the validity and coherence of the new-born component as a result of composing.
   5. Submitting the executive power of the generated complete code to the human–computer interface subsystem.
   6. If the component composition scheme is amended in the process of verifying or the mining program is new, the new scheme needs to be stored in the knowledge library.
5. LCRW subsystem.
   1. Setting up the component category information library, storing component description, and classification information.
   2. Offering component category service for the component retrieval agent.
   3. Providing supporting tools for the component category library, and completing functions such as searching, storing, and retrieving of component description signs.
6. Agent platform and system management subsystem.
   1. Monitoring running conditions of each agent in the system.
   2. Finishing operations of each agent: Initialization, start, execution, stop, deletion, suspension and removal, etc.
   3. Providing a registry function for the agent.

10.2 IMPLEMENTATION OF THE LCRW

We store over 8,000 components downloaded from the Internet in COMP LCRW as component resources of the program mining prototype system.

10.2.1 STORAGE SCHEME OF THE LCRW

1. Classification of component resource.

In the LCRW of COMP, we classify these 8,000 components into eleven categories according to their application domain, with each application domain further classified into many subcategories, as shown in Figure 10.3. The classification is as follows:

• Development tools
• File manipulation
• Multimedia
• Network tools
• Scientific computing
• Network security
• e-Commerce
• e-Government
• e-Learning

• Miscellaneous
• Others

Each major category can be further classified into many subcategories, and the classification is as follows:

• Development tools—corresponding subcategories. Application Servers, Component Managers, Component Creation Tools, Code Components, Configuration and Initialization Components, Debugging and Testing Components, Installation Tools, Localization Components, Software Licensing Components, Source Code Generators, Software Upgrade Components, Version Control Components, Help Components, Others.
• File manipulation—corresponding subcategories. Compression, Encryption, Convert Tools, File Spit Tools, Icon Tools, File Upload Components, Imaging Components, PDF Tools, Others.
• Multimedia—corresponding subcategories. Audio, MIDI and Sound Components, Speech Recognition Components, DirectX Components, MP3 Components, Video Components, QoS Components, Multimedia Mail, Collaborative, Video Conferencing, 3D Modeling Components, Others.
• Network tools—corresponding subcategories. Chatting Tools, BBS, Dialup Components, CGI, Servlet, Directory Service, Facsimile Components, Firewall, News, Proxy, Network Management, Network Communication, Messaging Components, Serial Communication Components, Others.
• Scientific computing—corresponding subcategories. Signal Processing, Maths and Stats Components, Algorithms, Others.
• Network security—corresponding subcategories. Security Protocol, Calendars/Scheduling, Charts/Graphs, Data Input/Masking, Data Entry Verification, Grids/Tables, Instrumentation, Text Components, Tree view and List Components, Toolbar Components, Menu Components, Diagramming Components, Others.
• e-Commerce—corresponding subcategories. Travel Services, ERP Components, Spreadsheet Components, Database Administration Components, Reporting Components, Others.
• e-Government—corresponding subcategories. Office Automation, e-Tax, File Administration, Information consultation, Organization Management, Policy Issue, Others.
• e-Learning—corresponding subcategories. Courseware, Teaching Tools, Teaching Reviews Tools, Teaching Affair Management, English Learning, Others.
• Miscellaneous—corresponding subcategories. Addressing, Postcode/ ZipCode Components, Barcode Components, Credit Card Authorization Components, Telephony Components, Paging Components, SMS Components, Others.
• Others.

Example 10.1 Components of e-Learning category in the LCRW of COMP

There are 156 components of the e-Learning category in the LCRW of COMP, and the number of components in subcategories and the component examples are demonstrated in Table 10.3. We give a brief description of each below.

1. MSTE-Learning component.
   Component name: MSTE-Learning component in courseware subcategory.
   Component description: MSTE-Learning is a COM component developed by East Golden Bird Company. It simulates the habitual process in which a teacher naturally gives his or her class. By using writing panel and recording microphone in a common computer, a teacher can create specialized courseware. The voice and handwriting of teachers can be 100% reflected on the monitor. Finally, the courseware is made up of animated voice, writing on the blackboard, and a variety of inserted multimedia data and pre-prepared static settings. A teacher only needs 10 minutes of training to start his or her own creation of courseware.
2. DashBoard component.
   Component name: DashBoard component in teaching tools sub-category.
   Component description: DashBoard is a COM component developed by Microsoft. It provides a teaching demonstration

   Table 10.3 Components of e-learning category in the LCRW.
   Subcategory	Number of components	Component example
   Courseware	112	MSTE-Learning
   Teaching tools	23	DashBoard
   Teaching evaluations	5	TeachEval
   Teaching affair	12	RemoteTeachingPlatform (RTP)
   English learning	3	Oral English Learning
   Others	1	e-Learning Mangement
   TOTAL	156

   method based on new concepts. In contrast to the traditional demonstration method using slides, it integrates several tools, such as video, text, and audio into one interface, and makes it easier to shift and operate. It provides a teacher with a more lively demonstration method.
3. TeachEval component.
   Component name: TeachEval component in teaching reviews subcategory.
   Component description: TeachEval is a JavaBean component developed by TeachEval company. TeachEval component can help users make a fast release of a teaching review webpage on the Internet for students to fill in their evaluations on teaching effect, and the component can automatically collect statistics of the results.
4. RemoteTeachingPlatform (RTP) component.
   Component name: RTP component in teaching affairs subcategory.
   Component description: RTP is a COM component developed by the Teaching Affair Center. This component, on the strength of new modern network technology, combines a variety of functions such as multimedia classrooms conducted by the teachers on the Internet, students' intentional selection of courseware on the Internet, communication between teachers and students, educational administration, testing, and reviews, realizing a unified system of teaching and educational administration.
5. Oral English Learning component.
   Component description: Oral English Learning component in English Learning subcategory.
   Component description: Oral English learning is a COM component developed by the English-Learning work team. The component applies teaching methods, such as sound identification and listening training, which make it possible to correct the user's accent and pronunciation errors on time, at the same time improving the user's listening ability.

2. Component storage method in the LCRW of COMP.

After classifying the download components from the Internet by the above method, the LCRW stores and organizes the components according to the method described in Chapter 7 in order to be used by COMP system.

The LCRW of COMP divides the component information into two parts, Component Description and Component Entity, as shown in Figure 10.4.

Here component entity refers to the component code, and component description refers to component description information. Component description information includes classification information, UCDL description information, and location resource information of the component.

• Component classification information (catalog information) indicates additional information for classification and retrieval. This part of the information is generated by the system or by interaction with the user when components enter the library.
• UCDL description information indicates UCDL description information generated when the downloaded components are undergoing UCDL transformation, such as component name, component size, and component function descriptions.
• Component location resource information indicates the descriptions of the locations where the components are actually stored.

Component description contains a small quantity of data, embodies diversified patterns and forms, and receives frequent visits. Therefore, it is saved in a relative database in the form of data tables for convenience of quick access. Component entity contains a large quantity of data, unified pattern and form, and receives a small number of visits, and therefore, component entity is saved in the form of files.

The LCRW of COMP uses the SQL 2000 database to save the component description, uses the file system of Windows 2003 to save the component entity, and uses the tools of file system and component location resources in the SQL 2000 datebase to link to the component description and component entity.

3. Component organization model in the LCRW of COMP.

We use the method of combining multi-facets and networked architecture, to organize and supervise the relations between components in COMP.

LCRW defines five facets, and from different angles, it classifies and organizes components resources.

• CT: Component type
• RP: Running environment
• AD: Application domain
• CF: Component functionality
• LR: Level of reusing

Inside each facet, LCRW extracts the corresponding attribute value of the facet in the UCDL descriptor, to determine the term table of the facet after an abstract selection. The term table is a tree-like structure based on hierarchical connections among terms, consisting of the subtrees of the facet.

In the component organization of LCRW, the system connects five facet subtrees together and forms a multi-facet directory tree. When a new component is added to the LCRW, the system will first extract the facet terms of this component and match the corresponding nodes of the multi-facet directory tree according to the term values, then link the component under the corresponding nodes in the multi-facet directory tree.

By applying the multi-facet directory tree, we can organize the component resource of the LCRW in COMP as a hierarchical term space, eliminating the mess brought about by the excess of components, and facilitating the management of the components. The orthogonality among facets simplifies the modification of the component library generated in accordance with this scheme, because the modification on one facet will not affect the others. At the same time, this organization model also makes it easier for the user to understand and apply the component library.

Figure 10.5 is an example of application of the multi-facet directory tree to organize components. In this figure, the component resource of the LCRW is organized as a tree-like structure according to the multi-facet directory tree.

4. Data Table Structure Design in the LCRW of COMP. In system implementation, we choose the SQL Server 2000 database. According to the storage and organization methods of the LCRW mentioned above, we design the LCRW data table structure and their mutual relations, establish three data tables in the corresponding SQL Server database and organize them according to their relations, as shown in Table 10.4.

Among them, FacetCategory shows what facet definitions are used in the LCRW and their definitions.

FacetTermTable illustrates all term values in a certain facet and the LCRW will further classify the stored components according to these term values.

ComponentInfoTable stores UCDL descriptions of the components. Each record corresponds to the descriptions of a component and each field corresponds to an element in UCDL descriptions.

In the three tables, FacetCategory and FacetTermTable together maintain facet structure in the LCRW. Each facet definition in FacetCategory corresponds to a FacetTermTable, which lists all the term values of this facet. Each record in ComponentInfoTable corresponds to a component description, and the component resource location in the component description further points out the component entity's location in the file system.

The LCRW organizes the components by means of linking the component descriptions in the ComponentInfoTable under the corresponding terms in FacetTermTable, as shown in Figure 10.6.

The following is the concrete descriptions of the three LCRW data tables and their corresponding field setup in Figure 10.4.

• Table 1: FacetCategory.
  FacetCategory saves the UCDL facet type, name, and the description information of the facet, and is to be indexed to the respectiveposition of the FacetTermTable. The setups and meanings of the fields are shown in Table 10.5.
• Table 2: FacetTermTable.
  FaceTermTable saves the term table of each facet in UCDL. Each record in the table stands for an entry. Besides the keywords, an entry also includes the synonym list of this keyword, and the description information the entry represents. All these constitute the FacetTermTable. The detailed setups and meanings of the columns are shown in Table 10.6.
• Table 3: ComponentInfoTable
  ComponentInfoTable saves the UCDL descriptions of components. Each record corresponds to a description of a component. Each field corresponds to an element in the UCDL description. The detailed setups and meanings of the fields are shown in Table 10.7.

10.2.2 MANAGEMENT OF THE LCRW

The LCRW retrieves the reusable components that can satisfy the users' request for COMP by means of organizing, classifying, storing, identifying,

discovering, and retrieving the component resource. For this purpose, LCRW offers the following operations:

• Component Adding in Operation (CAOP).
• Component Searching Operation (CSOP).
• Component Validating Operation (CVOP).
• Component Maintenance Operation (CMOP).
• Component Feedback Operation (CFOP).
• Classify System Maintenance Operation (CSMOP). See Figure 10.7 for details.

The input/output and realization instructions of each operation are as follows:

1. Component Adding in Operation (CAOP).
   Input: Component classification information, UCDL description of component, and component entity.
   Output: None.
   Notes: CAOP adds a record item to the ComponentInfoTable according to the UCDL description of the component. Then, it saves the component entity under the designed system directory and records the location information to the ResourceLocation field, for the added record in the ComponentInfoTable. As a result, an integral record of the component is generated in the ComponentInfoTable. Meanwhile, the record is indexed under the corresponding node of the FacetTermTable according to the component classification information.
   It is necessary to point out that, if what is added to the warehouse is an online component, the corresponding record of the ResourceLocation field in the ComponentInfoTable will directly point to the Internet URL of this component entity.
2. Component Searching Operation (CSOP).
   Input: Searching conditions of component (keyword, component properties, facet terms, etc.).
   Output: Component (or components) satisfying the searching conditions.
   Notes: CSOP selects different component searching methods according to the input conditions of component retrieval. At present, the available component searching methods in the LCRW consist of value-based search, keyword search, facet search, etc. As to different searching methods, CSOP will build a related SQL search sentence according to the component searching conditions, retrieve corresponding components from the database, and return the results to the user. While no appropriate component is available, CSOP will support the interaction with the user; by browsing the component list, selection icon, or other means, CSOP can help the user clarify the searching conditions and finish the component retrieval task.
3. Component Validating Operation (CVOP).
   Input: Component to be validated.
   Output: TRUE | FALSE
   Notes: At present, the LCRW mainly supports interaction-based component validating methods. CVOP sends the component to be validated to the user by means of interaction with the user, who downloads the components for execution and completes the validating task, and records the validating result to the LCRW. As for the component unable to be validated, the LCRW can forward the component to the developers for modification.
4. Component Maintenance Operation (CMOP).
   Input: Component to be maintained.
   Output: None.
   Notes: As for different modification requirements in the usage of the component, CMOP makes different maintenance on the component needed to be repaired, such as property modification, keyword modification, facet term modification, inter-component relation modification, and re-upload of component entity.
5. Component Feedback Operation (CFOP).
   Input: Component used by the user and feedback information from the user.
   Output: None.
   Notes: The user can submit the feedback information concerning the component usage through CFOD, such as the application and composing of the component. The user can also use CFOP to browse the existing feedback to improve the application of the component.
6. Classify System Maintenance Operation (CSMOP).
   Input: None.
   Output: None.
   Notes: CSMOP is mainly used to maintain and manage the classification structures and the related data in the LCRW. It mainly includes: the facet maintenance tool, which is used for the addition, modification, deletion, and restoration of the facets; the term space maintenance tool, which is used for the addition, deletion, and modification of the terms under a certain facet, or the addition, deletion, and modification of the synonyms of the same term; the keyword index maintenance tool, which is used for maintaining the structure of the hash table and for establishing the index relation between the domain keyword and component.

10.3 APPLICATION EXAMPLES

10.3.1 APPLICATION EXAMPLE 1: CUSTOMIZING A TOUR PLAN

Suppose there is a user who needs a plan for the tour from Beijng to Xi'an between September 30 and October 3. The program mining system is expected to help him/her book the flight ticket and hotel. The program mining process is as follows:

1. Requirement Inputting and Analyzing.
Suppose the input content is (Figure 10.8) “I need to make a travel plan from Beijing to Xi'an from September 30 to October 3. Please help me reserve ticket, hotel, and guide service.”

The program mining system first analyzes the user requirement and the process analysis is as follows:

Step 1: Extract the keyword table of the user requirement. The system uses the forward maximum matching method to parse the user's input and thereby gets the keyword list of the user requirement, as shown below:

The keyword list of user requirement:

{travel, reserve, air ticket, hotel, guide}

Step 2: Confirm the application domain of the user requirement. According to the keywords of the user requirements, the system interacts with the user to settle that the service filed should be “Travel” (Figure 10.9).

Step 3: Functional decomposition of user requirements. When the system confirms that “Travel” is the application domain of the user requirement, the system then extracts the functional module classification and the property wordlist of this field, verifies the keywords extracted in Step 1 , and finds out the corresponding subfunctional module of each keyword.

In this example, the keyword “Air ticket” corresponds to a subfunctional module of air ticket reservation. In order to express the user requirement description in the XML document generated subsequently in a more convenient way, COMP labels this subfunctional module as an ID number, “SubfunctionTS01.” The keyword “Hotel” corresponds to a subfunction module of hotel reservation, and COMP labels this sub-function module as an ID number, “SubfunctionTS02.” The keyword “Guide” corresponds to a subfunction module of guide reservation, and COMP labels this subfunction module as an ID number,

“SubfunctionTS03.” The keyword “Reserve” corresponds to the subfunction module of user interface, which is served to reserve the service, “tour plan,” and COMP labels this subfunction module as an ID number, “SubfunctionTS04.” The keyword “Travel” has no corresponding subfunction module.

After settling the application domain and subfunction modules corresponding to the user requirement keywords, COMP will request the user to fill in the specific service parameters, such as the location of hotel and price requirements, which correspond to the keywords, “airline,” “hotel,” and “guide,” according to the property information of each subfunction module in the domain dictionary. The whole process is shown in Figures 10.10 to 10.12.

By means of interaction, the COMP system gains the service parameters of function modules corresponding to the key words:

1. Service parameters (of the subfunctional module that corresponds to the keyword “airline”) of Subfunction TS01.
   • Date: Sept. 30, 2004
   • From: Beijing
   • To: Xi'an
     
2. Service parameters (of the subfunctional module that corresponds to the keyword “hotel”) of SubfunctionTS02.
   • Date: from Sept. 30 to Oct. 3, 2004
   • Location: Xi'an
   • Price: = 300
3. Service parameters (of the subfunctional module that corresponds to the keyword “guide”) of SubfunctionTS03.
   • Company: China International Travel Agency or China Youth Travel Agency

Step 4: Confirm the functional sequence of subfunction modules. The keyword table generated after functional decomposition corresponds to the subfunctional modules. They can be used to search components. To compose the components, we still have to confirm the functional sequence between the subfunctional modules.

In this example, the calling relation between several subfunctional modules is shown in Figure 10.13.

As shown in Figure 10.13, the user requirement is separated into four subfunctional modules.

• SubfunctionTS01, the subfunctional module of airline reservation
• SubfunctionTS02, the subfunctional module of hotel reservation
• SubfunctionTS03, the subfunctional module of guide reservation
• SubfunctionTS04, the subfunctional module displaying the user interface.

The functional sequence the four subfunctional modules correspond to is as follows:

1. PreCondition “SubfunctionTS01” “SubfunctionTS04”
2. PreCondition “SubfunctionTS02” “SubfunctionTS04”
3. PreCondition “SubfunctionTS03” “SubfunctionTS04”
4. PostCondition “SubfunctionTS04” “SubfunctionTS01”
5. PostCondition “SubfunctionTS04” “SubfunctionTS02”
6. PostCondition “SubfunctionTS04” “SubfunctionTS03”

Thus, the system generates the XML document describing the user requirement according to the above analysis.

Here, the first step of program mining, that is, the user requirement inputting and analyzing, is completed.

2. Component Searching and Retrieving.
When the requirement obtainment is finished, the COMP system searches for components satisfying the user requirement in the LCRW in accordance with the user requirement description XML document.

Step 5: Build the expression formula of component retrieval keywords. The keyword table, which COMP extracts from the XML document of the user requirement description, is used for component searching.

The first step of component searching is to generate the keyword expression formula for the searching component according to the correlation between the keyword and the subfunctional module. In this

example, according to the results of user requirement analysis and functional decomposition in Step 3 , the service request is separated into four subfunctional modules. Accordingly, we set up the following keyword expression formulas:

P1 = “Travel” + “Hotel”
P2 = “Travel” + “Airline”
P3 = “Travel” + “Guide”
P4 = “Travel” + “Reservation”

Step 6: Search the component according to keyword expression. According to the searching conditions in keyword expression, the system uses CSOP to retrieve the appropriate components from the LCRW.

In the keyword expression P1, for the first keyword “Travel,” CSOP obtains a group of candidate components that corresponds to the keyword “Travel” according to the keyword index retrieved by the keyword “Travel.” Similarly, for the second keyword “Hotel,” according to the keyword index, we obtain a group of candidate components that corresponds to the keyword “Hotel.” Pick up the intersection of the two sequences of the candidate components according to the “AND” relation of retrieval defined in the keyword expression. Thus, we can get the retrieval result of keyword expression P1, that is, the component of hotel reservation, as shown in Figure 10.14.

Adopting the same method, the system can retrieve the component corresponding to each keyword. Eventually, the component retrieval result is formed as follows:

After the LCRW finds out the corresponding components by means of keyword retrieval, COMP will compose the discovered components according to the function sequence table.

3. Component Composing and Program Publishing.
The process of Component Composing is divided into five steps: graphic modeling, confirming the graphic composing plan, generating the running script, producing the UCDL component agent, and generating the running code.

Step 7: Graphic modeling. In Step 6 , four related components are retrieved: TravelingReservation, HotelReserve, SuperFlight and GuardTrip.

According to the result of the user requirement analysis, the function sequence of the four components is as follows. The interface component of TravelReservation, by means of interaction with the user, confirms the service items and detailed service parameters of the reservation, and sends the information to the corresponding components. It is up to the components, such as HotelReserve, SuperFlight, GuardTrip, to finish the reservation tasks accordingly.

According to the function sequence of the four components, COMP system first displays the components in the graphic Component Composing tool and generates the connection between the components' exterior interfaces in advance.

Step 8: User confirms graphic Component Composing plan. The user finally confirms the Component Composing plan after the choice and adjustment of the connection relation between exterior interfaces. It is shown as Figure 10.15.

This figure shows the graphic Component Composing plan. The rectangles with a blue mark represent the components needed to be composed. Those with a red mark represent the interface information of the components. This plan defines the composing relation of the components by the links between interfaces. In this case, the user's interface component TravelReservation will pack different information, and then through interface SendTravellInfo, the information will be sent to the corresponding interfaces of the components, HotelReserve, SuperFlight, and GuardTrip, and thus the composing of components is completed.

Step 9: Generate running script. According to the Component Composing plan, we call the generation module of the running script, and the corresponding running script is generated. It is shown in the following:

Step 10: Start up UCDL component agencies. According to the Component Composing relationship defined in the running retrieve, the system will retrieve the components TravelReservation, HotelReserve, SuperFlight, GuardTrip, and the interface descriptions of the components in UCDL and calling conditions, then start up corresponding UCDL component agencies. In the following Component

Composing process, the UCDL component agent will be used to call other corresponding component entities.

Step 11: Generate Running Code. With the support from the explanation tools of the running script, according to the calling relation of the components defined in the running script, the system starts up UCDL component agencies, to call corresponding component entities. Then, the system will further map the running script into the code realization frame, and generate the component code executable in the middleware supporting platform. This is shown in Figure 10.16.

Figure 10.16 shows the program of TravelReservation of COMP. By running the new program, we can provide services demanded by the user.

In this example, by using this program, the system provides the user the following results.

1. Air ticket reservation.
   The ticket information for Sept. 30 from Beijing to Xi'an is shown in Figure 10.17. The ticket information includes airplane type,airline company, departure and arrival, ticket delivery, and price information. By comparison, the system recommends flight number CA1203 of Air China to the user. The user can also choose a more suitable flight number in the supplementary list provided by the system.
2. Hotel reservation.
   By the program mining the system searches for the following information of hotel reservation in Xi'an from Sept. 30 to Oct. 3, including the hotel name, rank, room type, price and address, as shown in Figure 10.18. By comparison, the system recommends Xi'an Jianguo Hotel to the user. The user can also choose other hotels from the supplementary list.
3. Tourist guide reservation.
   The system will provide the information for guide reservation in Xi'an from Sept. 30 to Oct. 3, including tourist guide's name, gender, age, hobby, and contact method, as shown in Figure 10.19.

Step 12: Publish program mining result. Having finished the Component Composing, and providing Active Services to the user by operating program mining results, the COMP system publishes the composed program according to the user's choice. The COMP system publishes this component to the LCRW, and generates corresponding related descriptive information so that next time when a user requires for similar services, the system can quickly find similar examples in the program mining and provide more support for active services.

10.3.2 APPLICATION EXAMPLE 2: MULTIMEDIA PLAYER

Suppose there is a user, who needs a player that can play many types of multimedia documents. The program mining process is as follows:

1. Requirement Inputting and Analyzing.
First, the user can input the service requirement by the human–machine interface of the program mining system (Figure 10.20).

In this example, the user inputs the service request “I need a multimedia player” through the COMP human–machine system. The corresponding analysis of user requirements is as follows:

Step 1: Extract the keywords table of the user requirement. The COMP system uses the forward maximum matching method to parse the user's input, and confirms the keyword table of the user requirements is as follows:

The keyword table of the user requirement: {Multimedia, player}

Step 2: Confirm the application field of the user requirement. According to the keywords of the user requirement, the system interacts with the user to confirm the service domain should be “MultiMedia.”

Step 3: Function division of the user requirement. The system extracts the entries related to MultiMedia from the attribute vocabulary table, and presents them to the user through the human–machine interface. Through human–machine interaction, the system comfirms the subfunction modules of the keyword “MultiMedia,” as shown in Figure 10.21.

In Figure 10.21, the user does icon choice among the keywords of the service domain provided by COMP. Through interacting with the system, the user can finally confirm that the corresponding function decomposition plan of “multimedia” should be “MP3,” “AVI,” “MPEG.”

And the keyword list generated after the function decomposition is {MP3, AVI, MPEG, Multimedia, Player}.

Step 4: Confirm the function sequence of subfunction modules. The keyword list generated after the function decomposition corresponds to the subfunctional modules. In this example, the keyword “MP3” corresponds to one subfunction module of the MP3 decoder. The COMP system gives the ID number of SubfunctionMP01 to this subfunction module. The keyword “AVI” corresponds to one subfunction module of the AVI decoder, and the COMP gives the ID number Subfunction MP02 to this subfunction module. The keyword “MPEG” corresponds to one subfunction module of the MPG decoder, and the COMP gives the ID number Subfunction MP03 to this subfunction module. The keyword “Player” corresponds to one subfunction module of user interface, and the COMP gives the ID number Subfunction MP04 to this subfunction module.

The calling relation between the several subfunction modules is shown in Figure 10.22.

The functional sequence among the subfunction modules corresponding to the four keywords is as follows:

PreCondition “AVI” = “player”
PreCondition “MPEG” = “player”
PreCondition “MP3” = “player”
PostCondition “player” = “AVI”
PostCondition “player” = “MPG”
PostCondition “player” = “MP3”

According to the above analysis, we get the following XML document describing the user requirements.

We have completed the stage of the user requirement inputting and analyzing and the COMP system has entered the stage of component searching and obtaining.

2. Component Searching and Obtaining.
In the stage of component searching and obtaining, COMP extracts the keyword list according to the XML document of the user requirement description and builds keyword expression formulas according to the corresponding relations between keywords and sub-function modules. They are used for searching and obtaining components related with the subfunction modules in the LCRW of COMP.

The keyword list obtained from the XML document of the user requirement description by the COMP system is as follows:

{MP3, AVI, MPEG, multimedia, player}

In this example, according to the results of the user requirement analysis and function decomposition, the user's service requirement is separated into four atomic subfunctions. Correspondingly, we build the following keyword expression formulas:

P1 = “multimedia” “MP3”
P2 = “multimedia” “AVI”
P3 = “multimedia” “MPEG”
P4 = “player”

Each keyword expression formula corresponds to one component searching condition. The “+” in the expression formulas means that the relation between the keywords is “and.”

According to the keyword expression formulas, the system calls CSOP operation in the LCRW, searches and retrieves the related components, and the result is as follows:

3. Component Composing and Program Publishing.
In the stage of Component Composing, COMP gets a function sequence table according to the analysis of the user requirement, and then composes and links the components searched from the LCRW. The composing process is divided into several steps: graphic modeling, confirming graphic composing plan, generating running script, mapping running script, and generating the executable code.

The COMP system first makes the function sequence table according to the analysis of the user requirement, and gets the calling relationship between the components which are composed as follows.

The interface component MultiMediaViewer of multimedia player receives user's input, and produces calling information <filename, filetype> according to the position and type of the document that the user requires, and then triggers the corresponding decoder component.

The decoding components MP3Decoder, AVIDecoder, and MPGDecoder of multimedia player receive the calling information <filename, filetype> from the component MultiMediaViewer and then finish the decoding function of the multimedia document <filename>.

According to the calling relationship among the four components, the system displays the four components in graphic composing tool, and generates the connections between the components' exterior interfaces beforehand, as shown in Figure 10.23. In this figure, the broken arrowheads refer to the interface calling relationship produced beforehand by the system according to the function sequence table. After the user confirming, the broken lines will become real lines.

Having preliminarily generated the connections between the component exterior interfaces, the graphic composing tool checks the consistency between component exterior interfaces. It is found that the exterior interface of the component MultiMediaViewer is connected with three decoder components. At this time, graphic composing tool displays a tip—“Please Confirm Interface link Type, Flow or Switch?”—and requires the user to make sure whether to have <Flow> or <Switch> relationship between MultiMediaViewer and the decoders.

In this example, the user confirms that the connections between the interfaces are <Switch>. Then the graphic composing tool adds the <Switch> structure at the interfaces, and the user should confirm that the judgment condition for the Connections of <Switch> is that component MultiMediaViewer sends calling information “filetype” of <filename, filetype>. The connections of <Switch> are as follows:

• When the component MultiMediaViewer sends calling information “filetype == AVI,” this component calls the component AVIDecoder.
• When the component MultiMediaViewer sends calling information “filetype == MP3,” this component calls the component MP3Decoder.
• When the component MultiMediaViewer sends calling information “filetype == MPG,” this component calls the component MPGDecoder.

According to the interaction results, the system produces the structure <Switch> at the exterior interface SendMediaFile of the component MultiMediaViewer. So the composing relationship among the components is further clarified.

The finally confirmed graphic Component Composing plan is shown in Figure 10.24.

According to the graphic Component Composing scheme and the generation method of running script stated in Section 8.2, the system will call the running script producing modules, and thus, the running script based on XML description is generated automatically. It is shown in the following:

With support from the explanation tools of the running script, according to the control flow defined in the running script, the system will further map the running script into a code realization frame and generate the component code executable in the supporting platform of the component, as shown in Figure 10.25.

After mining the related results, the user can run the result program to obtain the required services.

For example, if a user wants to open an AVI document named “flower.avi,” the multimedia player the mined result program will finish the file decoding task correspondingly by calling the component AVIDecoder. It then sends back the decoding result of the file “flower.avi” by the interface component MultiMediaViewer and provides the service that the user requires, as shown in Figure 10.26.

When a user opens an MPG file named “rain.mpg,” the multimedia player will finish the corresponding decoding task by calling the component MPGDecoder. Then, it sends back the decoding result of the document “rain.mpg” by the interface component MultiMediaViewer and provides the service for the user, as shown in Figure 10.27.

Similarly, the interface when a user opens an MP3 file named “songs.MP3,” is shown in Figure 10.28.

After COMP finishes composing the multimedia player, as the last step for program mining, the COMP system publishes the multimedia player which has been composed according to the user's choice. Users can choose this program as a Web Service to provide for the human–machine interface of the program mining system. Through the service provided by the human–machine interface, this program can also be stored into the LCRW database after adding related description information.

10.4 FUTURE WORK

This book mainly discusses how to search and mine the existing component resources under the Internet environment, and how to organize and use them to provide new Active Service.

The development of mobile telecommunication techniques has brought changes to the Internet—earlier it was connected to the PC, but now to different mobile devices and electrical products. Now, it has become an important trend in the development of Internet techniques to ensure compatibility with small-sized devices, such as cell phones, which use different services such as web telecommunication, information searching, interactive game, electronic business, and various application and computings.

Obviously, for small-sized and mobile equipments, they should support more application services, which require the supporting platforms to support active dynamic cutting services. People pay more attention to this than the ordinary computer.

For example, at present, the platforms widely used in mobile telecommunication, such as J2ME (Java 2 Micro Edition), BREW (Binary Runtime Environment for Wireless), Microsoft.Net, and the operation systems supporting these platforms such as Symbian OS (Symbian is a union specializing in the operation systems of cell phones, set up by the manufacturers of Motorola, Siemens, and Nokia in 1987), Windows Mobile, PalmOS (32 digits embedded operation system developed by the Palm Company), and LinuxOS are all developing in such a way as to make it possible for the cell phone and PC to download application programs from the Internet and to create an executable environment, thus providing more services for users. It is estimated that mobile devices' successes will be determined in the future by the following: to what degree do mobile devices support the application programs; how many opened programming interfaces there are, and how convenient it is. In fact, all these are for one purpose, that is, to provide more services for users.

The research on Active Services and program mining is still in the preliminary stage. The discussion in our book is pretty preliminary too, and many

problems demand further study. These problems involve different areas, such as computers, communication, linguistics, and psychology. The following are some of the cases that need further discussion.

1. Active Services and the mobile environment. As mentioned above, mobile devices are being used increasingly to connect to the Internet. How to provide personalized service to users after connecting mobile equipment to the Internet has become the topic for further discussion and study. At present, the mobile development platform and the mobile device operation system are focusing on intellectualizing interface to the internet, and multiplying and intellectualizing the application program choice. In the future, we should try to reduce the limitations on users, which are related to using mobile devices, and try to provide as many personalized services as possible to users. All these demand Active Services.
2. Active Services and development. The development platforms discussed in this book are all based on Web Services or Java components, such as Microsoft.Net, SUNOne, WebSphere, etc. Up to now, though these platforms have provided corresponding developing tools and operation tools, which are used for setting up, publishing, and consuming the corresponding Web Services, they cannot provide Active Services that meet users' requirements. Studying and developing a corresponding supporting platform is one of the important topics in the researches of active services and program mining.
3. Active Services and service quality. The service quality is always one important question related to the Internet. Especially with the massive use of distributive multimedia applications, Web transmission speed, synchronization of sound and image, transmission delaying, and jumping are all influencing the development of the Web. Under the Active Services model, the problem of service quality becomes more prominent. For example, when a user requires corresponding service, will the delay produced by Web transmission and program mining satisfy the user's demand for responding time? Is the composed result from component in accordance with user requirement? All these demand further study.
4. Active service and security. Active service needs adequate programs to support it. How does one guarantee the security of these programs? The security of the programs searched for and mined from the Internet, especially, is a matter of important concern for realizing Active Services.
5. Active services and management. The management of Active Services is different from that of Internet data or the telecommunication network. It involves different areas, such as service building, publishing, using, and consuming. At the same time, it also involves the interaction with users, input/output methods of users, and recording/tracking the services for users. For setting up Active Services, its management also involves protocol standard and description interface at different layers, such as controlling and management of XML, UCDL, etc. Component mining and composing are also related with the management of Active Services. Due to the distribution environment of Active Services and program mining, the multi-agent techniques will play an important role in Active Services management.
6. Active services. As for the Active Sevices itself, further study should be concentrated on the following: the concept and definition of Active Services, the Active Services model and architecture, protocol, and description language in each layer of the architecture. Besides, though this book has discussed techniques for realizing active services in detail, this discussion is not complete and is limited by current techniques. We need to make progress in many fields, such as user interface, component searching and finding, heterogeneous Component Composing, verifying and testing, construction of the LCRW, etc.

REFERENCES

Benatallah, B., Sheng, Q. Z., and Dumas, M. (2003). The self-serv environment for web services composition. IEEE Internet Computing, 7(1), 40–48.

Chandrasekaran, S., Silver, G., Miller, J. A., Cardoso, J., and Sheth, A. P. (2002). Web service technologies and their synergy with simulation. Winter Simulation Conference Proceedings, 1 (pp. 606–615). IEEE (IEEE Press).

Chiu, D. K. W., Karlapalem, K., and Li, Q. (2001). E-ADOME: Enacting composite E-services in an advanced workflow environment. Proceedings—IEEE Computer Society's International Computer Software and Applications Conference (pp. 311–316). IEEE (IEEE Press).

Cho, K. M., Kang, K. W., Kang, Y. H., et al. (2003). Grid services building mechanism using web services model based on OGSA. Proc. of the International Conference on Communications in Computing (pp. 161–165). IEEE (IEEE Press).

Chris, P. (2003). Web services orchestration and choreography. IEEE Computer, 36(10), 46–52.

Davis, L., Gamble, R. F., and Kimsen, S. (2004). A patterned approach for linking knowledge-based systems to external resources. IEEE Transactions on Systems, Man, and Cybernetics, Part B, 34(1), 222–233.

Fan, I. Y. H., and Chao, S. C. (2003). Service creation with web services and SOA. Transactions Hong Kong Institution of Engineers, 10(4), 31–34.

Fang, C. H., Zhang, Y. X., and Xu, K. G. (2003). An XML-based data communication solution for program mining. Intelligent Data Engineering and Automated Learning, 4th International Conference (pp. 569–575). Hong Kong, Berlin Heidelberg: Springer-Verlag.

Hull, R., Benedikt, M., Christophides, V., and Su, J. W. (2003). E-Services: a look behind the curtain. Proc. of the ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems, 22, 1–14. ACM Press.

McIlraith, S. A., Son, T. C., and Zeng, H. (2001). Semantic web services. IEEEIntelligent Systems and Their Applications, 16(2), 46–53.

Nunez, S. J., O'sullivan, D., Brouchoud, H., et al. (2000). Experiences in the use of FIPA agent technologies for the development of a personal travel application. Proc. of the International Conference on Autonomous Agents (pp. 357–364). IEEE Press.

O'sullivan, D., and Lewis, D. (2003). Semantically driven service interoperability for pervasive computing. Proc. of the Third ACM International Workshop on Data Engineering for Wireless and Mobile Access: MobiDE 2003 (pp. 17–24). ACM Press.

Raman, B., and Katz, R. H. (2003). Load balancing and stability issues in algorithms for service composition. Proceedings—IEEE INFOCOM, 2 (pp. 1471–1487). IEEE Press.

Tosic, V., Pagurek, B., Esfandiari, B., et al. (2002). Management of compositions of E- and M-business web services with multiple classes of service. IEEE Symposium Record on Network Operations and Management Symposium (pp. 935–939). IEEE Press.

Vidal, J. M., Buhler, P., and Stahl, C. (2004). Multiagent systems with workflows. IEEE Internet Computing, 8(1), 76–82.

Xia, D. L., Zhang, Y. X., and Fang, C. H. (2003). Design and implementation of an agent-based program mining system. Chinese Journal of Electronics, 31(5), 793–796.

Xu, H. N. (2003). Web services oriented architecture for electronic commerce. IEEE International Engineering Management Conference (pp. 479–483). IEEE Press.

Xu, K. G., Zhang, Y. X., and Fang, C. H. (2003). Introducing XML to program mining. Proc. of the International Conference on Telecommunications (pp. 163–168). Beijing: Publishing House of Electronics Industy.

Zhang, R. Y., Budak, A. I., and Boanerges, A. M. Automatic composition of semantic Web services. Proc. of the International Conference on Web Services (pp. 38–41). IEEE Press.

Zhang, Y. X., Fang, C. H., and Wang, Y. (2004). A feedback-driven online scheduler for processes with imprecise computing. Journal of Software, 15(4), 616–623.

Zhang, Y. X., Wang, X. C., and Zhao, Y. B. (1999). Computer network and Internet tutorial. Beijing: Tsinghua University Press.