A Presentation Feature Based Approach to Improving Interactive Web Service Discovery in Web Portals

Jingyu Song , Jun Wei, Shuchao Wan and Hua Zhong Technology Center of Software Engineering, Institute of Software, Chinese Academy of Sciences, Beijing 100080, P.R.China {songjy,wj,wsc,zhongh }@otcaix.iscas.ac.cn

Abstract
Presentation level integration now becomes an important and fast growing trend in enterprise computing and portal-based composite applications are the mainstream to realize it. Such applications use portlet and interactive web service, which usually offers several portlets, as their basic constituents. Hence, portlet description and discovery are the key issues that have to be considered. This paper proposes a novel concept POI (Presentation Oriented Interface) to describe the presentation features of a portlet, so that interactive web services may be extended to facilitate the selection and interoperation of portlets. Interactive web services discovery can be effectively achieved based on the calculation of POI similarity that considers both type and structure similarity. Experiments show that the proposed approach can improve the satisfaction of service discovery, thereby achieving better application integration at presentation level.

1. Introduction
Presentation level integration now becomes an important and fast growing trend in enterprise computing [7]. The advent of portals and the standardization of the component model in portals bring a new and flexible mechanism for constructing portal-based composite applications that are the mainstream to realize the integration at presentation level. Portal enables the aggregation of interactive interfaces of different applications and services as components on the same web page [3]. Portlet is the basic component of a portal, which represents an interactive web mini application and is deployed on a

portal server [6]. A portlet may represent the user interface of part or the whole of one application. Interactive web services [8] are proposed to allow remote portlets to be developed and consumed in a web service manner. Usually an interactive web service offers one or more portlets. At present, interactive web service is widely accepted as common means for the development of portal-based composite applications. To construct a portal-based composite application using interactive web services, a developer will first select portlets offered by the interactive web services, and then establish associations between these portlets. Two basic issues have to be dealt with in such a process:1)portlet description and discovery;2)portlet interoperation. There are already some research works on the later issue [4, 14]. This paper mainly focuses on the former, i.e. the description and discovery of portlets offered by interactive web services. Portlet discovery is based on the descriptions of the interactive web services where the portlets are encapsulated. Currently, the descriptions mainly focus on functional properties such as supported portlet modes, supported window states and portlet functions, etc. The presentation features and properties of each portlet are ignored. However, a normative and effective description of the presentation features of a portlet may be more important to portals whose target is presentation level integration. This paper proposes a concept Presentation Oriented Interface (POI) to define the presentation features of a portlets interactive interface. In this paper, POIs are introduced as additional descriptions for a portlet that an interactive web service offers. We employ SOA and provide infrastructures for such extended interactive web services in portal, thereby achieving flexible and effective support for integration and collaboration in web portals. A portal-based composite application can then be constructed easily based on such capabilities.

IEEE International Conference on e-Business Engineering (ICEBE'06) 0-7695-2645-4/06 $20.00 2006

The remainder of this paper is structured as follows: In Section 2, we outline the background of interactive web services, existing related specifications and the limitations considering interactive web service discovery in contemporary portals. Section 3 presents our proposed approach in detail. We first give an overview of extended interactive web service, and then present the technical details of POI. A POI matching algorithm is presented and analyzed based on the calculation of POI similarity. In Section 4, we discuss the implementation and experimental results of the proposed approach. Section 5 contains a description of related works. The main contributions of our approach are summarized in Section 6.

consumer, interactive web services produce markup fragments that can be easily aggregated by portals. Interactive web services may also include user interaction and are well suited for integration and use in portals. They can participate in an action processing in a generic way with no service-specific presentation code required on the consumer side.

2.2. WSRP and JSR168

Currently, standards for integrating applications at presentation level include the Java Portlet Specification(a Java Specification Request, usually called JSR168) [6] and the Web Services for Remote Portlets(WSRP) Specification[8]. WSRP is an OASIS standard whose goal is to provide web service based access capability for portal servers. It defines a web service interface for accessing and interacting with interactive web services. WSRP standardizes the way that portals communicate remotely with remote services that can extend the core capabilities of portals. However, WSRP says nothing about how portlets are to be developed. JSR168 addresses this issue for Java. The JSR168 specification defines Java-based APIs that provide means for aggregating several content sources and applications front ends. According to JSR168, portlet descriptions can be added to a portlet application deployment descriptor, but in a free-text style. WSRP presents portlet description in a relatively formal way. It defines a service description interface that returns the information of producers capabilities and offered portlets. However, neither of the two specifications provides an effective and formal definition for portlet description to facilitate the portlet discovery. There are mainly two limitations: 1. descriptions are proposed in a free-text style instead of a formal style, which cannot be processed by computer effectively; 2. neither of the two specifications considers the presentation features of a portlet. In fact, the definitions of portlet description in both WSRP and JSR168 are aimed to help the development of a general portlet container or a general service consumer, which can manage any compatible portlets or interactive web services. The two specifications did not define any agreements for the descriptions of the interactive interface of a portlet, which are more important to the service discovery in portals.

2. Background
Depending on the context, when we refer to the terminology interface in this paper, it may represent two different meanings. The first represents a graphical window that is usually used by an end-user, as it is used in user interface. The second represents a function description, as it is used in application programming interface. To avoid confusion, we use interactive interface to represent the former, and interface the latter.

2.1. Data-oriented Web Interactive Web Services

Services

and

A web service is an interoperable unit of application logic that transcends programming languages, operating systems, network communication protocols and data representation dependencies. There are two kinds of web services: traditional data-oriented web services and presentation-oriented, user-facing, interactive web services. Data-oriented web services receive SOAP requests and return data objects encoded in XML documents in the SOAP response. It is the responsibility of the service consumer to process the received data in a service-specific manner and generate any required presentations. While this approach works well for applications that require specific data and can use and process the received data, it is inappropriate to be used by portals and portal-based composite applications, which need to quickly integrate content and applications from a variety of sources, because that data-oriented web services disregard the presentation integration functions. Interactive web services include presentation as a part of the service itself. Instead of simply providing raw data for processing and presentation by the

IEEE International Conference on e-Business Engineering (ICEBE'06) 0-7695-2645-4/06 $20.00 2006

3. Extended Interactive Web Service

We extend current interactive web service based on the concept Presentation Oriented Interface (POI). Intuitively, a POI defines the structure information and the semantics of the elements in the interactive interface of a portlet that is offered by an interactive web service. Figure 1 depicts a POI visually. Different from function-oriented interface, when a portlet implements a POI, it indicates that the portlet can generate interactive interfaces that conform to the given POI.
POI

Portlet and its Interactive Interface

Portlet
render(), processAction(),... Underlying Infrastructure Portlet API Portlet Container

Fig. 1 POI and Portlet API We use POIs as additional descriptions to define the presentation features of each portlet that an interactive web service offers. To distinguish the portlet offered by an interactive web service from conventional portlet, we call the former extended portlet. We call the interactive web service that offers extended portlet extended interactive web service. Figure 2 depicts the relationships between extended interactive web service, extended portlet, POI and portlet.
encapsulates Extended Interactive Extended Portlet Web Service 1...* 1

1
consists of

1...* POI

Portlet

Fig 2. Relationship of extended interactive web service, extended portlet, POI and portlet The key to POI definition is to identify the elements in an interactive interface of an extended portlet. We use Information Extraction Path in our approach. We first discuss ontology used in POI and the definition of Information Extraction Path in the following sections, and then give POI definition in section 3.3.

achieving semantic data type match. We refer to W3C OWL-S Atomic Processes ontology [12] to define portal ontology. Our ontology is organized in three categories: 1. The basic representation ontology contains the basic numeric and character data types, URL, currency, date and time, etc. 2. The domain-specific ontology contains the concepts for the various application domains, for example, order, customer and product, etc. 3. The infrastructure-specific ontology contains POI, IOPara, type, and IEPath, etc. They are the basic concepts of our extended interactive web service infrastructure. The infrastructure-specific ontology is mainly used by portal internally. We introduce two extended properties, isComposedOf and canbeConvertedTo, to support semantic data association. Let CA, CB be concepts in ontology, if a statement CA isComposedOf CB exists, then the data with type CA can satisfies a data request for CB type. A statement, CA canbeConvertedTo CB, means that data with type CA can be converted to data Each isComposedOf or with type CB. canbeConvertedTo statement needs a conversion function to fulfill transformation. Conversion functions can be the calculation of a simple arithmetic function, a database access, or an invocation of an external service. Conversion functions can be specified in the underlying ontology if they are domain-specific and applicationindependent. Application-specific conversion functions may be defined and stored in an application-specific conversion library and will overwrite those given in the ontology. Based on these properties, we give the definition of ontology concept matching as follows. Definition 1. Ontology concept matching. Given ontology concept CA, CB, CA is a matched concept of CB, denoted by CA CB, iff CA is the same as CB canbeConvertTo(CA, CB) isComposedOf(CA, CB)

consists of

3.2 Information Extraction Path.

An Information Extraction Path (IEPath) is a concatenation of node identifiers along a path from the root to the specified element. Each element identifier consists of a tag name and an index i, which indicates this node is the ith sibling that has the same tag name. We define the syntax of IEPath as follows: IEPath ::= Step| IEPath/Step Step ::= tagname[i]| text(regular-expression)

3.1 Ontology used in POI

We use ontology to describe the semantics of an element in a portlets interactive interface, thereby

IEEE International Conference on e-Business Engineering (ICEBE'06) 0-7695-2645-4/06 $20.00 2006

The semantics of an IEPath is the same as the semantics of a location path in XPath expression except: 1. IEPath allows instance with variable index. This is used to deal with situations that a page may have multi-set of output data candidates. For example the expression HTML[1]/BODY[1]/TABLE[1]/TR[i]/TD[2] indicates a set of nodes, which are all the second columns of each row in a table. Each node can be an output candidate. Implementation wise, links are needed in the fragment to start the output action. 2. The step text(regular-expression) captures a substring of the inner text. Let e be an HTML element obtained by IEPath p, and let rlrcrr be the inner text of e, then the text identified by the following expression: p/text(rl (*)rr) is rc.

The POI has three output parameters op1, op2 and op3 OP, where op1.type = FirstName, op2.type = Sex and op3.type = Occupation. Again each parameter path specifies the location of the output parameter in the lower interactive interface. The presented POI defines such interactive interface constraints at presentation level for the extended portlet: two interactive interfaces could be generated during the runtime of the component. After input a data with CustomerID type in the specified location in the first interactive interface and click on the element defined by actionLink, a user can obtain output data with type FirstName, Sex and Occupation at corresponding locations from the second interactive interface.
actionLink
IEPath: TABLE[1]/INPUT[2]

3.3 POI Definition

Traditional interface definition is function oriented. A component Comp implements an interface I means that Comp provides the implementations for the methods defined in I, i.e. an interface defines the functional constraints for a component. We extend such an idea to the presentation layer. This is the concept of POI. Definition 2. Presentation Parameter defines an element in a page P, IOPara=(type, path), where type is the parameter type; path is an IEPath which defines its location in P. To support semantic data type match, we use ontology concepts to describe data type i.e. the value of type is an ontology concept. Definition 3. Presentation Oriented Interface defines the structure and the semantic properties that the interactive interfaces of an extended portlet should conform to. POI=(IP, OP, actionLink), where IP and OP are input/output parameter tables, each of which is an IOPara set; actionLink is an IEPath and usually represents a Submit button, by which user can get output using given input data. Figure 3 gives an example of POI. The left are two interactive interfaces of an extended portlet. The lower interface is generated when the Submit button is clicked in the upper interface, i.e. the two interfaces are consecutive. In the right we give the descriptions of the elements in the POI definition. The POI only has one input parameter ip1IP, where ip1.type = CustomerID, ip1.path = TABLE[1]/INPUT[2]. The path specifies the location of the input parameter in the upper interactive interface.

IP
IEPath: TABLE[1]/INPUT[1] type: CustomerID

OP
IEPath:TABLE[1]/TR[2]/TD[2] type:FirstName IEPath:TABLE[1]/TR[3]/TD[2] type:Sex IEPath:TABLE[1]/TR[4]/TD[2] type:Occupation

...

Fig.3 An example of POI The definition of IEPath is based on the interactive interface where the path is located. However, an extended portlet can usually generate several interactive interfaces, so the definition of POI should considers the interactive-interface locating problem: 1. In theory, the parameters in IP are defined in the same interactive interface where the actionLink is located; the parameters in OP are defined in the interactive interface which is generated by actionLink. ActionLink itself can be identified by its URL value. So we can use actionLink as reference to locate parameters in IP and OP. 2. A POI may not have IP and actionLink, which means that the extended portlet could provide output parameters directly. In such cases, we use the assumption below to identify the page. 3. In our implementation, we define the following assumptions:1)If a POI contains IP and actionLink, they are defined in the first interactive interface of the extended portlet;2)If a POI only contains OP, the OP parameters are defined in the first interactive interface of the corresponding portlet. In most practice scenarios, these assumptions can be satisfied, whereas they decrease the implementation complexity greatly.

IEEE International Conference on e-Business Engineering (ICEBE'06) 0-7695-2645-4/06 $20.00 2006

3.4 POI Matching

3.4.1 Definitions POI matching is used to decide whether an extended portlet offered by an extended interactive web service can satisfy a POI request. For example, given two POIs IA, IB and an extended portlet EP. EP implements IA denotes that EP can satisfy IA. If IA is a matching POI to IB, then EP can also satisfy IB. In such case, EP can be used in anywhere that a component, which implements IB, is needed. Definition 4. Parameter Set Type Matching. Given two presentation parameter sets PSA={ps1A,,psmA} and PSB={ps1B,,psnB}, PSB matches PSA, denoted by PSAPSB, if (psiAPSA)(psjBPSB)(psjB.typepsiA.type) and for each psjB.typepsiA.type, i k, we have pslB.typepskA.type, for jl. There are two types of POI matching: type matching and structure matching. These two types can be further divided into inclusive matching and complete matching. The definitions of POI matching are shown as follows. Definition 5. Type Matching. Given two POIs POIA=(IPA, OPA, aLA) and POIB=(IPB, OPB, aLB), 1. POIB is an inclusive type matching POI of POIA, if (IPBIPA)(OPAOPB); 2. POIB is a complete type matching POI of POIA, if POIB inclusively type-matches POIA, and (|IPB| = |IPA|) (|OPB| = |OPA|). Definition 6. Structure Matching. Given two POIs POIA=(IPA, OPA, aLA) and POIB=(IPB, OPB, aLB), 1. POIB is an inclusive structure matching POI of POIA, if POIB inclusively type-matches POIA and for each pair of type-matched parameters psj.type psi.type psj.path = psi.path; 2. POIB is a complete structure matching POI of POIA, If POIB inclusively structure-matches POIA, and (|IPB| = |IPA|) (|OPB| = |OPA|). Intuitively, given a POI IA and its input parameter set IPA, an extended portlet EPA that implements POI IA can generate an interactive interface from which the output parameters defined in IA can be extracted. If IB is an inclusive type matching interface of IA, then an extended portlet EPB that implements POI IB can also generate an interactive interface conforming to IA using IPA. The differences between EPA and EPB are as follows: 1. EPB may need fewer input parameters than EPA and EPB can provide more output data than EPA 2. The locations of input/output parameters of EPA and EPB may be different.

If the number of input/output parameters of EPA is equal to EPB, the matching is a complete type matching. If the locations of the matched parameters are also the same, the matching is a complete structure matching. If the locations of matched parameters are the same whereas the numbers are not equal, the matching is an inclusive structure matching. 3.4.2 POI Similarity Service Discovery refers to the process of finding a service that offers a portlet which implements a matched POI to a request POI. Instead of using the matching concept defined in the former section strictly, we achieve service discovery based on POI similarity in practice. There are at least two reasons for the introduction of POI similarity: 1. In practice, users usually do not require that the service POI matches the request POI precisely. A partially matched service may also satisfy a users requirements. 2. There are always several services matched to the request. However, such services have different similarity to the request POI. We can rank all results and choose the best service based on POI similarity. The ranking process is going to decide which matched services are more reasonable to the one requested. POI similarity is presented based on the calculations of type similarity and structure similarity. Definition 7. Parameter Set Type Similarity. Given two presentation parameter sets PSA={ps1A,,psmA} and PSB={ps1B,,psnB}, Parameter Set Type Similarity from PSA to PSB is defined as follow: Sim pst ( PS A , PS B )

1 n m A B ( max ( f td ( psi , ps j ))) if m n = 1 i n =1 (1) = jm n 1 ( max A B ( f td ( psi , ps j ))) if m < n n j =1 i =1 where ftd(psiA, psjB):PSAPSB[0,1] is the type distance of psiA.type and psjB.type in ontology and given matched pair (psiA, psjB) and (pskA, pslB) that are used in the calculation, ikjl. Some approaches to the calculation of ftd have been proposed in [2]. In practice, ftd can also be assigned manually for each matched concept pair. Definition 8. Parameter Set Structure Similarity. Given two presentation parameter sets PSA={ps1A,,psmA} and PSB={ps1B,,psnB}, Parameter Set Structure Similarity from PSA to PSB is defined as follow:

IEEE International Conference on e-Business Engineering (ICEBE'06) 0-7695-2645-4/06 $20.00 2006

|MP|

(2) | MP | where MP={(mp1A,mp1B),,(mphA,mphB)}, h min(m,n) , mpkAPSA, mpkBPSB and (mpkA, mpkB) is the matched pair used in the calculation of Simpst(PSA, PSB) defined in (1). The function fsd(mpkA, mpkB) [0,1] calculates the structure distance of mpkA.path and mpkB.path. Definition 9. Parameter Structure Distance. Given two parameters p1 and p2, function fsd(p1,p2) is defined as follow: same( p1 . path, p 2 . path) f sd ( p1 , p 2 ) = (3) max(| p1 . path |, | p 2 . path |) where same(p1.path,p2.path) calculates the number of same steps in p1.path and p2.path, |p.path| calculate the step number in the path. Definition 10. POI Similarity. Consider a request POI rp and an extended interactive web service s which implements a POI sp, where rp has an IP IPR and an OP OPR, and sp has an IP IPS and an OP OPS. Function Sim(sp,rp)[0,1], calculating the POI Similarity from sp to rp, is defined as follows: Sim(sp,rp) = ((Simpst(IPR,IPS)+Simpst(OPS,OPR)) +(1-)( Simpss(IPR,IPS)+Simpss(OPS,OPR)))/2 (4) where 0<<1 is a variable as increase, the dependency to structure similarity will decrease. If =1, the POI similarity depends on type matching completely. 3.4.3 Matching Algorithm It is easy to give an algorithm to evaluate if a service is a matching service to a POI request based on the POI similarity calculation. Given an extended interactive web service set S and a service request with a POI rp, the service discovery algorithm is shown in Figure 4. Function add(s,similarity) adds s to the ordered result set with the order similarity. Furthermore, to increase the efficiency of portlet discovery, a keywordbased matching is usually done first to filter out unrelated services.

Sim pss ( PS A , PS B ) =

f
k =1

sd

A B (mp k , mp k )

OncePortal portal system of ONCE platform[9]. OncePortal is a JSR168 and WSRP compatible portal, which can integrate different resources from Internet, Intranet and application systems, and then aggregates them into personalized pages. We use WSDL[13] for reference to describe a POI. In our implementation, we embed POI description in portlets deployment descriptor for local portlet or add such information in the returned message of getServiceDescription operation for remote extended interactive web services. After the introduction of POI, an end-user customizes a portal page based on the location and the semantics of elements in the page. The portal will find and bind to a matched extended portlet at runtime dynamically. To achieve this goal, we improved the page aggregation implementation in OncePortal. Moreover, to ensure the compatibility with WSRP and JSR168 specifications, all extensions were done without modifications to the interfaces between portlet and its container as well as the interfaces between service consumer and producer.
Input: S, rp Output: ordered service set RS Algorithm: foreach sS foreach POI sp implemented by s inputpst=Simpst(rp.IP,sp.IP) outputpst=Simpst(sp.OP,rp.OP) ts=(inputpst+outputpst)/2 if tst inputpss=Simpss(rp.IP,sp.IP) outputpss=Simpss(sp.OP,rp.OP) ss=(inputpss+outputpss)/2 similarity=((*ts)+(1-)*ss)/2 if similarity add(s, similarity) end if end if end foreach end foreach

Fig. 4 Service Discovery Algorithm

4.2 Experiments
In order to test and evaluate the proposed approach, we constructed a set of extended interactive web services to be used as test base. We first find out the web sites that provide the services for required functions in Google, and then use the approach proposed in [5] to construct the interactive web services by wrapping the web sites. POI descriptions

4 Implementation and Experiments

4.1 Implementation
We have validated POI and the interactive web service discovery algorithm based on it by extending

IEEE International Conference on e-Business Engineering (ICEBE'06) 0-7695-2645-4/06 $20.00 2006

are added to each service to transform it to extended interactive web service. We have totally constructed 134 extend interactive web services, where 32 services for flight search, 28 services for train schedule, 29 services for weather forecast, 27 services for stock query and 18 news services. Most services have the parameters with type City and Date, which can be used to test the calculation of type similarity. We designed the ontology for such concepts. The main relationships defined in the ontology are taxonomy relationships. For example, City can be classified as First Level City and Second Level City, First Level City can be further divided into Province Capital and Common City. Usually, a flight search service accepts First Level City as its input parameter, whereas a weather forecast only accepts Province Capital as its input. The type Date also has several types. In the evaluation test, we set t=0.4 =0.6, and the type distances between concepts are defined manually. We design two service discovery requests, FlightSearch and WeatherForecast, and then test the precision rate and recall rate of the portlet discovery when is decreased from 1 to 0. The results of the experiments are presented in Figure 5. The results from the evaluation test demonstrate that structure similarity has different effects to precision result and recall result. When decreases from 1 to 0, both precision rate and recall rate are decrease, and the impact to recall is bigger. When <0.5, recall rate decreases quickly. The impact of to precision rate is not so obvious compare to recall rate. The structure complexity of the request POI also affects the discovery results. The FlightSearch request POI has 4 input parameters and 5 output parameters. The WeatherForecast has 2 input parameters and 2 output parameters. So affects the recall results of FlightSearch bigger, but the precision rates of FlightSearch are higher than WeatherForecasts. Though the introduction of Structure Similarity does not improve the recall and precision results of service discovery, it enables users to search a portlet based on
FlightSearch 100 80 60 40 20 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 WeatherForecast

City

City

Month

Day

Fig.6a Request POI

Fig.6b Search Result(=1)

Fig.6c Search Result(=0.8) its presentation features. Figure 6a presents the interactive interface defined in FlightSearch request POI. Figure 6b and Figure 6c are the search results when =1 and =0.8 respectively. Though the portlet offered by the service given by Figure 6c does not match the request POI completely, it maybe more likely to be accepted by the user when consider the structure of the interactive interface and the locations of each parameter in the interactive interface.

5 Related Works
Paolucci et al.[10] and Sirin et al.[11] proposed semantic approaches for web service location and composition. The semantic match between a services
FlightSearch 100 80 60 40 20 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 WeatherForecast

Fig.5a Recall Result

Fig.5b Precision Result

IEEE International Conference on e-Business Engineering (ICEBE'06) 0-7695-2645-4/06 $20.00 2006

outputs and another services input are determined by the minimal distance between concepts in a taxonomy tree. Agarwal et al.[1] describe the use of deep annotation for web service integration. WSDL files are extended with an ontology that is used to describe input and output parameters. However, all these works only consider service discovery at functional level, whereas the presentation features are ignored. The main difference between our work and the above researches is that our approach targets at improving service discovery based on presentation features in portals. We first analyze the deficiency of interactive web service discovery in current portals, and then point out that the fundamental reason for such limitations roots in the fact that the interactive web services lack a description mechanism for presentation features as well as a discovery mechanism based on it. We then give a solution to overcome such limitations by defining the concept POI and by extending interactive web services.

Acknowledgement
This paper was supported by the National Natural Science Foundation of China under Grant No. 60573126; the Major State Basic Research Development Program of China (973 Program) under Grant No.2002CB312005.

References
[1] S.Agarwal, S. Handschuh, S. Staab. Surfing the ServiceWeb. In International Semantic Web Conference, volume2870 of Lecture Notes in Computer Science, Springer, 2003. pp.211-226. J.Cardoso, A.Sheth. Semantic e-Workflow Composition. Journal of Intelligent Information Systems. 2003, 21(3): 191-225. S.Clarke. Standards for Second-Generation Portals. IEEE Internet Computing, 2004,8(2): 54-60. O.Daz, J.Iturrioz, and A.Irastorza, Improving portlet interoperability through deep annotation, In 14th International Conference on World Wide Web. NewYork: ACM Press, 2005. pp.372-381. O.Daz, I.Paz. Turning Web Applications into Portlets: Raising the Issues. In 2005 Symposium on Applications and the Internet. Washington, DC: IEEE Computer Society, 2005. pp.31-37. Java Community Process. JSR 168 Portlet Specification. http://www.jcp.org/en/jsr/detail?id=168. 2003. B. McDonough. Enterprise Portal Survey, 2004: An Examination of Business Processes Driving Adoption.http://www.marketresearch.com/map/prod/10 45547.html.2004. OASIS. Web Services For Remote Portlets Specification. http://www.oasis-open.org/. 2003. Once Platform. http://www.once.com.cn/. 2005. M. Paolucci, T. Kawamura, T. R. Payne, K. Sycara.Semantic Matching of Web Services Capabilities. In 1st International Semantic Web Conference, Springer-Verlag, 2002. pp.333347. E. Sirin, J. Hendler, B. Parsia. Semi-automatic Composition of Web Services using Semantic Descriptions. In 1st Workshop on Web Services: Modeling, Architecture and Infrastructure. ICEIS Press, 2003. pp.17-24. W3C Consortium. OWL-S: Semantic Markup for Web Services, 2004. http://www.w3c.org/Submission/OWLS/. W3C Consortium.Web Services Description Language (WSDL). http://w3.org/2002/ws/desc/. 2004. R.Weinreich, T.Ziebermayr. Enhancing Presentation Level Integration of Remote Application and Services in Web Portals. IEEE International Conference on Services Computing(SCC 2005), 2005. pp.224-236.

[2]

[3] [4]

6 Conclusions
This paper presents a novel concept POI to define the presentation features of a portlet. POI is similar to traditional functional interface, but it is interactiveinterface oriented. We extend interactive web service by adding POIs as additional descriptions of each portlet that the interactive web service offers. We employ SOA and provide infrastructure to support the extended interactive web service in portal. Experiments demonstrate that the proposed approach can return more reasonable results that satisfy a request in both semantic and structure aspects. The main contributions of this paper can be concluded as follows: 1. Proposes a concept POI to define the presentation features of an extended portlet. We give the details about ontology used in POI, IEPath and the definition of POI. 2. Defines POI similarity based on the type and structure similarity of given POIs, and then proposes a service discovery algorithm based on the calculation of POI similarity. 3. Evaluates the proposed approach based on a carefully designed interactive web services base, and then analyzes the impact of the introduction of POI to the service discovery process. In the future, we plan to further investigate the details of the presentation features of interactive web services, and then improve the definition of POI. We will further optimize the calculation method of POI similarity, especially structure similarity.
[5]

[6] [7]

[8] [9] [10]

[11]

[12]

[13] [14]

IEEE International Conference on e-Business Engineering (ICEBE'06) 0-7695-2645-4/06 $20.00 2006