04031707

7/29/2019 04031707

1/8

A Presentation Feature Based Approach to Improving Interactive Web

Service Discovery in Web Portals

Jingyu Song , Jun Wei, Shuchao Wan and Hua ZhongTechnology 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 enterprisecomputing and portal-based composite applicationsare the mainstream to realize it. Such applications use

portlet and interactive web service, which usuallyoffers several portlets, as their basic constituents.

Hence, portlet description and discovery are the keyissues that have to be considered. This paper proposesa novel concept POI (Presentation Oriented Interface)to describe the presentation features of a portlet, sothat interactive web services may be extended to

facilitate the selection and interoperation of portlets.Interactive web services discovery can be effectivelyachieved based on the calculation of POI similarity

that considers both type and structure similarity.Experiments show that the proposed approach canimprove the satisfaction of service discovery, therebyachieving better application integration at

presentation level.

1. Introduction

Presentation level integration now becomes animportant and fast growing trend in enterprisecomputing [7]. The advent of portals and thestandardization of the component model in portalsbring a new and flexible mechanism for constructing

portal-based composite applications that are themainstream to realize the integration at presentationlevel.

Portal enables the aggregation of interactiveinterfaces of different applications and services ascomponents on the same web page [3]. Portlet is thebasic component of a portal, which represents aninteractive web mini application and is deployed on a

portal server [6]. A portlet may represent the userinterface 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 webservice manner. Usually an interactive web serviceoffers one or more portlets. At present, interactive webservice is widely accepted as common means for thedevelopment of portal-based composite applications.

To construct a portal-based composite applicationusing interactive web services, a developer will firstselect portlets offered by the interactive web services,and then establish associations between these portlets.Two basic issues have to be dealt with in such aprocess:1)portlet description and discovery;2)portletinteroperation. There are already some research workson the later issue [4, 14]. This paper mainly focuses on

the former, i.e. the description and discovery of portletsoffered by interactive web services.Portlet discovery is based on the descriptions of the

interactive web services where the portlets areencapsulated. Currently, the descriptions mainly focuson functional properties such as supported portletmodes, supported window states and portlet functions,etc. The presentation features and properties of eachportlet are ignored. However, a normative and effectivedescription of the presentation features of a portlet maybe more important to portals whose target ispresentation level integration.

This paper proposes a concept PresentationOriented Interface (POI) to define the presentation

features of a portlets interactive interface. In this paper,POIs are introduced as additional descriptions for aportlet that an interactive web service offers. Weemploy SOA and provide infrastructures for suchextended interactive web services in portal, therebyachieving flexible and effective support for integrationand collaboration in web portals. A portal-basedcomposite application can then be constructed easilybased on such capabilities.

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

7/29/2019 04031707

2/8

The remainder of this paper is structured as follows:In Section 2, we outline the background of interactiveweb services, existing related specifications and thelimitations considering interactive web servicediscovery in contemporary portals. Section 3 presentsour proposed approach in detail. We first give anoverview of extended interactive web service, and thenpresent the technical details of POI. A POI matchingalgorithm is presented and analyzed based on thecalculation of POI similarity. In Section 4, we discussthe implementation and experimental results of theproposed approach. Section 5 contains a description ofrelated works. The main contributions of our approachare summarized in Section 6.

2. BackgroundDepending on the context, when we refer to the

terminology interface in this paper, it may representtwo different meanings. The first represents a graphicalwindow that is usually used by an end-user, as it is usedin user interface. The second represents a functiondescription, as it is used in application programminginterface. To avoid confusion, we use interactiveinterface to represent the former, and interface thelatter.

2.1. Data-oriented Web Services and

Interactive Web Services

A web service is an interoperable unit of applicationlogic that transcends programming languages,operating systems, network communication protocols

and data representation dependencies. There are twokinds of web services: traditional data-oriented webservices and presentation-oriented, user-facing,interactive web services.

Data-oriented web services receive SOAP requestsand return data objects encoded in XML documents inthe SOAP response. It is the responsibility of theservice consumer to process the received data in aservice-specific manner and generate any requiredpresentations. While this approach works well forapplications that require specific data and can use andprocess the received data, it is inappropriate to be usedby portals and portal-based composite applications,

which need to quickly integrate content andapplications from a variety of sources, because thatdata-oriented web services disregard the presentationintegration functions.

Interactive web services include presentation as apart of the service itself. Instead of simply providingraw data for processing and presentation by the

consumer, interactive web services produce markupfragments that can be easily aggregated by portals.Interactive web services may also include userinteraction and are well suited for integration and usein portals. They can participate in an action processingin a generic way with no service-specific presentationcode required on the consumer side.

2.2. WSRP and JSR168

Currently, standards for integrating applications atpresentation level include the Java PortletSpecification(a Java Specification Request, usuallycalled JSR168) [6] and the Web Services for RemotePortlets(WSRP) Specification[8].

WSRP is an OASIS standard whose goal is toprovide web service based access capability for portalservers. It defines a web service interface for accessingand interacting with interactive web services. WSRPstandardizes the way that portals communicate

remotely with remote services that can extend the corecapabilities of portals.

However, WSRP says nothing about how portletsare to be developed. JSR168 addresses this issue forJava. The JSR168 specification defines Java-basedAPIs that provide means for aggregating severalcontent sources and applications front ends.

According to JSR168, portlet descriptions can beadded to a portlet application deployment descriptor,but in a free-text style. WSRP presents portletdescription in a relatively formal way. It defines aservice description interface that returns theinformation of producers capabilities and offered

portlets.However, neither of the two specifications provides

an effective and formal definition for portletdescription to facilitate the portlet discovery. There aremainly two limitations:1.descriptions are proposed in a free-text style instead

of a formal style, which cannot be processed bycomputer effectively;

2.neither of the two specifications considers thepresentation features of a portlet.In fact, the definitions of portlet description in both

WSRP and JSR168 are aimed to help the developmentof a general portlet container or a general service

consumer, which can manage any compatible portletsor interactive web services. The two specifications didnot define any agreements for the descriptions of theinteractive interface of a portlet, which are moreimportant to the service discovery in portals.


7/29/2019 04031707

3/8

3. Extended Interactive Web Service

We extend current interactive web service based onthe concept Presentation Oriented Interface (POI).Intuitively, a POI defines the structure information andthe semantics of the elements in the interactive

interface of a portlet that is offered by an interactiveweb service.Figure 1 depicts a POI visually. Different from

function-oriented interface, when a portlet implementsa POI, it indicates that the portlet can generateinteractive interfaces that conform to the given POI.

We use POIs as additional descriptions to define thepresentation features of each portlet that an interactiveweb service offers. To distinguish the portlet offered byan interactive web service from conventional portlet,we call the former extended portlet. We call theinteractive web service that offers extended portletextended interactive web service. Figure 2 depictsthe relationships between extended interactive webservice, extended portlet, POI and portlet.

The key to POI definition is to identify the elementsin an interactive interface of an extended portlet. Weuse Information Extraction Path in our approach. Wefirst discuss ontology used in POI and the definition ofInformation Extraction Path in the following sections,and then give POI definition in section 3.3.

3.1 Ontology used in POI

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

achieving semantic data type match. We refer to W3COWL-S Atomic Processes ontology [12] to defineportal ontology. Our ontology is organized in threecategories: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 theconcepts for the various application domains, forexample, order, customer and product, etc.

3.The infrastructure-specific ontology contains POI,IOPara, type, and IEPath, etc. They are the basicconcepts of our extended interactive web serviceinfrastructure. The infrastructure-specific ontologyis mainly used by portal internally.We introduce two extended properties,

isComposedOf and canbeConvertedTo, to supportsemantic data association. Let CA, CB be concepts inontology, 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 datawith type CB. Each isComposedOf orcanbeConvertedTo statement needs a conversionfunction to fulfill transformation. Conversion functionscan be the calculation of a simple arithmetic function, adatabase access, or an invocation of an external service.Conversion functions can be specified in the underlyingontology if they are domain-specific and application-independent. Application-specific conversion functionsmay be defined and stored in an application-specificconversion library and will overwrite those given in theontology.

Based on these properties, we give the definition ofontology concept matching as follows.

Definition 1. Ontology concept matching. Givenontology concept CA, CB, CA is a matched concept ofCB, denoted by CA CB, iff

CA is the same as CB canbeConvertTo(CA, CB)

isComposedOf(CA, CB)

3.2 Information Extraction Path.

An Information Extraction Path (IEPath) is aconcatenation of node identifiers along a path from the

root to the specified element. Each element identifierconsists of a tag name and an index i, which indicatesthis node is the ith sibling that has the same tag name.We define the syntax of IEPath as follows:

IEPath ::= Step| IEPath/StepStep ::= tagname[i]| text(regular-expression)

Extended Interactive

Web Service

Extended Portlet

PortletPOI

encapsulates

1 1...*

consists of

consists

of

1

1...*

1

1

Fig 2. Relationship of extended interactive web

service, extended portlet, POI and portlet

Portlet

render(), processAc tion(),...

Portlet and its

Interactive Interface

POI

Portlet API

Portlet ContainerUnderlying Infrastructure

Fig. 1 POI and Portlet API


7/29/2019 04031707

4/8

The semantics of an IEPath is the same as thesemantics 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 havemulti-set of output data candidates. For example theexpressionHTML[1]/BODY[1]/TABLE[1]/TR[i]/TD[2]indicates a set of nodes, which are all the secondcolumns of each row in a table. Each node can be anoutput candidate. Implementation wise, links areneeded in the fragment to start the output action.

2.The step text(regular-expression) captures asubstring of the inner text. Let e be an HTMLelement obtained by IEPath p, and let rlrcrr be theinner text of e, then the text identified by thefollowing expression:p/text(rl (*)rr) is rc.

3.3 POI Definition

Traditional interface definition is function oriented.

A component Comp implements an interface I meansthat Comp provides the implementations for themethods defined in I, i.e. an interface defines thefunctional constraints for a component. We extend suchan idea to the presentation layer. This is the concept ofPOI.

Definition 2. Presentation Parameter defines anelement in a page P, IOPara=(type, path),

where type is the parameter type; path is an IEPathwhich defines its location in P.

To support semantic data type match, we useontology concepts to describe data type i.e. the value oftype is an ontology concept.

Definition 3. Presentation Oriented Interfacedefines the structure and the semantic properties thatthe interactive interfaces of an extended portlet shouldconform to.

POI=(IP, OP, actionLink),where IP and OP are input/output parameter tables,

each of which is an IOPara set; actionLink is anIEPath and usually represents a Submit button, bywhich user can get output using given input data.

Figure 3 gives an example of POI. The left are twointeractive interfaces of an extended portlet. The lowerinterface is generated when the Submitbutton is clickedin the upper interface, i.e. the two interfaces are

consecutive. In the right we give the descriptions of theelements 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 locationof the input parameter in the upper interactive interface.

The POI has three output parameters op1, op2 andop3 OP, where op1.type = FirstName, op2.type = Sexand op3.type = Occupation. Again each parameter pathspecifies the location of the output parameter in thelower interactive interface.

The presented POI defines such interactive interfaceconstraints at presentation level for the extended portlet:two interactive interfaces could be generated during theruntime of the component. After input a data withCustomerID type in the specified location in the firstinteractive interface and click on the element definedby actionLink, a user can obtain output data with typeFirstName, Sex and Occupation at correspondinglocations from the second interactive interface.

The definition of IEPath is based on the interactiveinterface where the path is located. However, anextended portlet can usually generate severalinteractive interfaces, so the definition of POI shouldconsiders the interactive-interface locating problem:1. In theory, the parameters in IP are defined in the

same interactive interface where the actionLink islocated; the parameters in OP are defined in theinteractive interface which is generated byactionLink. ActionLink itself can be identified byits URL value. So we can use actionLink asreference to locate parameters in IP and OP.

2.A POI may not have IP and actionLink, whichmeans that the extended portlet could provideoutput parameters directly. In such cases, we usethe assumption below to identify the page.

3. In our implementation, we define the followingassumptions:1)If a POI contains IP and actionLink,they are defined in the first interactive interface ofthe extended portlet;2)If a POI only contains OP,the OP parameters are defined in the firstinteractive interface of the corresponding portlet. Inmost practice scenarios, these assumptions can besatisfied, whereas they decrease the implementationcomplexity greatly.

...

actionLink

IP

OP

IEPath: TABLE[1]/INPUT[2]

IEPath: TABLE[1]/INPUT[1]

type: CustomerID

IEPath:TABLE[1]/TR[2]/TD[2]

type:FirstName


type:Sex


type:Occupation

Fig.3 An example of POI


7/29/2019 04031707

5/8

3.4 POI Matching

3.4.1 Definitions POI matching is used to decidewhether an extended portlet offered by an extendedinteractive web service can satisfy a POI request. Forexample, given two POIsIA,IB and an extended portlet

EP.EP implementsI

A

denotes thatEP can satisfyI

A

. IfIA is a matching POI toIB, thenEP can also satisfyIB.In such case, EP can be used in anywhere that acomponent, which implementsIB, is needed.

Definition 4. Parameter Set Type Matching.Given two presentation parameter setsPSA={ps1

A,,psmA} and PSB={ps1

B,,psnB}, PSB

matchesPSA, denoted by PSAPSB, if(psi

APSA)(psj

BPSB)(psj

B.typepsiA.type) and

for each psjB.typepsi

A.type, i k, we have

pslB.typepsk

A.type, forjl.There are two types of POI matching: type

matching and structure matching. These two types

can be further divided into inclusive matching andcomplete matching. The definitions of POI matchingare shown as follows.

Definition 5. Type Matching. Given two POIsPOIA=(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

POI

A

, if POI

B

inclusively type-matches POI

A

andfor each pair of type-matched parameters

psj.type psi.type psj.path = psi.path;2.POIB is a complete structure matchingPOI ofPOIA,

If POIB inclusively structure-matches POIA, and

(|IPB| = |IPA|) (|OPB| = |OPA|).Intuitively, given a POI IA and its input parameter

setIPA, an extended portletEPA that implements POIIAcan generate an interactive interface from which theoutput parameters defined inIA can be extracted. IfIB isan inclusive type matching interface ofIA, then anextended portlet EPB that implements POI IB can alsogenerate an interactive interface conforming to IA using

IP

A

. The differences between EP

A

and EP

B

are asfollows:1.EPB may need fewer input parameters than EPA and

EPB can provide more output data thanEPA2.The locations of input/output parameters ofEPA and

EPB may be different.

If the number of input/output parameters ofEPA isequal toEPB, the matching is a complete type matching.If the locations of the matched parameters are also thesame, the matching is a complete structure matching. Ifthe locations of matched parameters are the samewhereas the numbers are not equal, the matching is aninclusive structure matching.

3.4.2 POI Similarity Service Discovery refers to theprocess of finding a service that offers a portlet whichimplements a matched POI to a request POI. Instead ofusing the matching concept defined in the formersection strictly, we achieve service discovery based onPOI similarity in practice. There are at least tworeasons for the introduction of POI similarity:1. In practice, users usually do not require that the

service POI matches the request POI precisely. Apartially matched service may also satisfy a usersrequirements.

2.There are always several services matched to therequest. However, such services have differentsimilarity to the request POI. We can rank allresults and choose the best service based on POIsimilarity.The ranking process is going to decide which

matched services are more reasonable to the onerequested. POI similarity is presented based on thecalculations of type similarity and structure similarity.

Definition 7. Parameter Set Type Similarity.Given two presentation parameter setsPSA={ps1

A,,psmA} and PSB={ps1

B,,psnB}, Parameter

Set Type Similarity from PSA to PSB is defined asfollow:

),( BApst PSPSSim

=

04031707

Documents