Web service is a kind of self-contained, Internet-enabled applications ... China (No.60233010 and No.60496324), the National Key Research and Development.
FECT: A Modelling Framework for Automatically Composing Web Services Lishan Hou1,2 and Zhi Jin2,3 1 2
Graduate School of Chinese Academy of Sciences Academy of Mathematics and Systems Science, CAS {hlslisa, zhijin}@amss.ac.cn 3 Institute of Computing Technology, CAS Beijing 100080, P.R. China
Abstract. In this paper, we propose FECT, a new modelling framework for describing and composing heterogenous Web services to satisfy emergent requirements. In FECT, a three-dimension description pattern, i.e. the Environment, the Capability and the behavior Traces, has been proposed to describe Web services. FECT has the following features, which may distinguish it from other work. Firstly, the environment, with which Web services may interact, has been introduced for characterizing the context of Web services. Secondly, the capability of a Web service is captured as the effects on its environment. Thirdly, the composition process is accomplished by combining the traces of Web services.
1
Introduction
Web service is a kind of self-contained, Internet-enabled applications capable not only of performing activities on its own, but also possessing the ability to engage other Web services in order to complete higher-order activities. Seamless composition of Web services has enormous potential in streamlining business-tobusiness application integration [1]. But there are many inherent difficulties in this new paradigm of application development. Services distributed on Internet are usually developed by different organizations and described by different terms and in different ways. That makes the understanding and communication among them be difficult. As a result, the ability to dynamically and automatically discover, understand and compose heterogeneous Web services becomes a tough problem. These problems, in fact, have been paid many attentions at present. The first effort is about the standards of Web service description, which are trying to provide sufficient information to enable automated discovery, composition, as well as execution. WSDL [2] is an XML format for describing services as a set of
This work was partly supported by the National Natural Science Foundation of China (No.60233010 and No.60496324), the National Key Research and Development Program (Grant No. 2002CB312004) of China, the Knowledge Innovation Program of the Chinese Academy of Sciences and MADIS of the Chinese Academy of Sciences.
W. Fan, Z. Wu, and J. Yang (Eds.): WAIM 2005, LNCS 3739, pp. 320–332, 2005. c Springer-Verlag Berlin Heidelberg 2005
FECT: A Modelling Framework for Automatically Composing Web Services
321
endpoints or ports operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly and bound to a concrete network protocol(SOAP [3], HTTP,etc.). WSDL rests on the communication level description of the messages and protocols used by a Web service. It defines and formats query interactions with a service, but doesn’t provide a model for the semantics of such exchanges. OWLS [4] takes the initiative to provide an ontology markup language expressive enough to semantically represent capabilities and properties of Web services. It provides three essential types of knowledge, i.e. ServiceProfile, ServiceModel, and ServiceGrounding, for a Web service. OWL-S focuses on the representation of what the service does rather than where to find the service. Another effort worthy to be mentioned is on the composition of Web services. BPEL4WS [5] models a Web service as a business process from the industrial view. It defines the interaction protocols between a process and its partners; and also defines an inter-operable integration model that should facilitate the expansion of automated processes. As for formalization, Petri-net [6] and process algebra (e.g. CCS [7]) also contribute some tentative work to the composition of services. Although there have been many efforts on these topics, the discovery and the composition of Web services still face big challenges. All of them model the capabilities of Web services only by input/output transformations. However, the semantic meaning of an application software is in fact the effect it can cause on the environment which the software interacts with [8][9][10]. In other words, the requirements for the software(i.e. a Web service here) are located in the reality, and in the environment. The relationship among environment(E),requirements(R) and software(S) has been revealed as an entailment: E, S R That means that if a Web service(S) is installed in the environment described by E, then the environment will exhibit the properties described in R. Although the relationship is not an implication,it captures the essence that R can be satisfied if a Web service(S) is installed in the environment(E). From this sense, the environment and the effect on it caused by the Web service should be two core aspects to catch the meanings of the Web service. We propose a new modelling framework for describing, discovering and composing Web services automatically. This approach is based on the rationales that the semantics of Web services can be grounded in the environment which Web services are situated in and interact with. The rest of this paper is organized as follows. Section 2 introduces the architecture of our FECT (Framework based on Environment, Capabilities and behavior Traces) approach. The description of Web services based on environment ontology and interaction ontology in FECT is defined in section 3. Section 4 designs the mechanism for the selection and composition of Web services and illustrates the whole process by a trial case. Section 5 reviews some related work and concludes this paper.
322
2
L. Hou and Z. Jin
FECT Architecture
The overall architecture of the FECT is shown in Figure 1. The main components are the Ontology Base, the Service Registry and the FECT Server.
Extractor
Desired services
Ontology Base Composer
Standby services
user
Service Registry FECT Server
Fig. 1. Architecture of composition framework
The Ontology Base provides the description of concept terms, associations and constraints for the environments and interactions used in particular problem domains. It is a sharable conceptualization to support the recognition and understanding of existing published services as well as the emergent request of new Web services. The Registry is a special service whose responsibility is to organize the Web services. A service representation in the Registry contains a pointer to the provider of the service and a port where to access the service like in UDDI[11]. Furthermore, it also includes the declaration on the effect, i.e. the changes of the environment caused by the service, and interaction behavior traces with the environments. Web services can be published and recognized only if they follow the standards of the Registry. The detailed description of services will be discussed in section 3. The FECT server contains two parts: the requirements extractor and the service composer. The requirements extractor elicits the external requirements, models them by using the automated modelling techniques[12][13], and publishes the models on Internet as desired Web services based on the domain ontologies. Once the desired service-models occur, those autonomous Web services which have the ability to complete the tasks or sub-tasks of the requirements models, volunteer to be the candidates. All of these candidates construct a standby service base. Then the service composer combines some services in the base to form short-term partnerships in order to satisfy the emergent requirements.
3
Description of Web Services and Requirements
Appropriate description of the capability is the prerequisite of understanding requirements as well as Web services. Most of the current work in this field
FECT: A Modelling Framework for Automatically Composing Web Services
323
only depend on the description in syntax level. We argue that adaptive and intelligent discovery and composition of Web services can be achieved only after the meaning of the requirements has been well understood and the semantic model of Web services has been built. In order to bridge the gap between requirements and Web services, we use the “environment” the Web services exist in, “effects” of the environment caused by the Web services and the “interactions” of the Web services with the environment, to capture the meanings of the Web services and the requirements. For a Web service, its environment contains the controllable resources which the service visits and acts on, and the incontrollable outer triggers from people, other autonomous Web services, time, etc. The published capabilities of the Web services and the desired capabilities of the requirements are designated on two ontologies, i.e. the domain environment ontology and the environment interaction ontology. These ontologies bring the semantic meanings into the capability description. 3.1
Environment Ontology and Interaction Ontology
The incontrollable triggers are uncertain because of the reactivity of the Web services and the instability of the Internet platform. The environment ontology can be represented in a hierarchy of controllable resources together with the effects on them. Figure 2 shows the top level of the resources in the environment ontology of the Web sale domain.
Participant
Discount
Agreement
Product Quantity Provider
Other currency
Requestor Tangible -Product
Service
Negotiation
Information remittance
Web store
Book
User
Web Service.info service Resource.info
Message
Instance Of
Fig. 2. A hierarchy of resources of the web sale domain
In the environment ontology, each individual resource has one or more attributes to describe itself. These attributes are divided into two groups: the static attributes, i.e. their values are fixed once the attributes are instantiated, and the dynamic attributes, i.e. their values are changeable along different situations. We call the static attributes the “information” of the resource(“info” for short) and call the dynamic attributes the “states” of the resource. We use the state transition graph to stipulate the permitted state changes. All the possible state changes by a Web service just reflect its capabilities. For example, Figure 3
L. Hou and Z. Jin
Type String
StaticAttribute
class class
Name
StaticAttribute
Yes
Product book
info
Author
Type
StaticAttribute
class
String
Publishment
Publication
DynamicAttribute Discount
class Type book bool
No
state
Add(m)
DynamicAttribute Volumn
class Type Keep
Prediction book
Type Float
StaticAttribute Price
info
subclass
Sub(n) state
DynamicAttribute Owner
Type
StaticAttribute
class class
String
PubDate
book book
Transition
Type String
subclass
324
Type
provider
String
Requester ordered
Fig. 3. Ontology description to ”book” of the web sale domain
is a part of resource descriptions, in which, book is a kind of resources in the Internet-based book-selling domain. In the software world, the product-selling process is in fact transmitting the information and managing the product’s state transitions. In this sense, the interaction ontology is designed to specify the interaction between the services and their environments. We assume that an interaction be an atomic behavior. Therefore a sequence of interactions can implement a macro-level or worthy to be observed behavior, denoted as “function” in the paper. Table 1 shows a fraction of the associations among the concepts in the interaction ontology. Table 1. A fraction of the interaction ontology Source conTarget SN cept Association concept Description 2 read MethodOf collect “read” is one of the methods to fulfill the task “collect” 3 (ask,get) MethodOf collect “(ask,get)” is one of the methods to fulfill the task “collect” 4 subscribe MethodOf collect “subscribe” is one of the methods to fulfill the task “collect” 18 subscribe ≡collect receive ≡collect is an equivalence relation, “subscribe” and “receive” are replaceable when fulfilling the task “collect” 22 write precondition read “write” is necessary before “read” is invoked 24 inform precondition receive “inform” is necessary before “receive” is invoked
3.2
Behavior Trace
Besides environments, another feature of FECT is viewing each service (or each piece of requirements) as a process with some kind of interaction behaviors.
FECT: A Modelling Framework for Automatically Composing Web Services
325
CSP [14] expresses a process as a finite sequence of symbols recording the events in which the process has engaged up to some moment in time. The same idea is also suitable to the description of the interaction sequences of Web services. Definition 1. (Behavior Trace) A sequence < x1 , x2 , · · · , xn > is called a behavior trace of a service if x1 , x2 , · · · , xn form a behavior sequence in the interaction process. Here, each xi (1 ≤ i ≤ n) is not an event as that in CSP, but a trigger interaction ω 1 or a single interaction transferring information from the service to its environment or from its environment to the services. Formally, xi = ω or P (r),
1≤i≤n
where P is a behavior concept in the interaction ontology and r is the resource operated by P . Example 1. The trace for ATM verifying the validity of credit cards can be denoted as: . It is necessary to define some operations on the behavior traces and some relations among them. These operations are a bit different from those in CSP. Definition 2. (Catenation ) Let X =< x1 , x2 , · · · , xn > and Y =< y1 , y2 , · · · , ym > be two behavior traces, then X Y =< x1 , · · · , xn , y1 , · · · , ym > is called catenation of X and Y , which means that X takes place before Y . Definition 3. (Trace Ordering ≤) Let X and Y be two behavior traces, X ≤ Y if ∃Z =< z1 , z2 , · · · , zl >, such that X Z = Y . Obviously, ≤ is a relation of partial ordering, i.e. it is reflexive, antisymmetric and transitive. Definition 4. (Behavior Ordering ) Let behaviors X =< x1 , x2 , · · · , xn > and Y =< y1 , y2 , · · · , ym > be two traces, for xi in X and yj in Y , yj xi if yj takes place before xi . Definition 5. (General Catenation ) Let X =< x1 , · · · , xn > and Y =< y1 , · · · , ym > be two behavior traces, there exists a group of behavior orderings {yi k xj k |yi k is in Y, xj i is in X}p < y1 , · · · , yik0−1 > < yik0 , xjk0 > ⎪ ⎪ ⎩ (< xjk0+1 , · · · , xn > < yik0+1 , · · · , yn >) p≥1 1
ω is used to denote the outer trigger from people, other autonomous Web services, time, etc. in the interaction.
326
L. Hou and Z. Jin
”” is a kind of catenation which keeps the underlying behavior orderings. It can be used widely in composing Web services. 3.3
Description Framework
It is time to give descriptions of the services as well as the requests. In order to facility the matchmaking, we adopt the following coincident description elements. – Resource, the controllable environment which the service interact with. It is modelled as two groups of attributes. Res = {r|r |= r.inf o ∪ r.state} Here r is a sort of resources, r.info and r.state are the sets of r’s static and dynamic attributes; – Effect, the transitions of the resource states caused by the service. Ef f ect = {ef f |= r.attr(v1 , v2 , P or X)|r ∈ Res ∧ attr ∈ r.state} That means that the value of r.state changes from v1 to v2 by reason of the interaction(s), P is a single behavior in the interaction ontology and X is a behavior sequence. Effect reflects the capability of the service; It is worthy to note that the transitions in Effect is transitive, i.e. if r.attr(v1 , v2 , P1 ) ∈ Ef f ect and r.attr(v2 , v3 , P2 ) ∈ Ef f ect then r.attr(v1 , v3 , < P1 > < P2 >) ∈ Ef f ect – Action, the interaction sequences of the service with its environment. Action = {X1 , · · · , Xn } In which Xi (1 ≤ i ≤ n) is a behavior trace. – Function, worthy to be observed capability of the service, which is implemented by a sequence of interactions. F unc = {F P |= X or P |X is a behavior trace, P is an interaction} The definition of F P rests with the particular domain knowledge. These elements characterize the service from multi-facets: environment, effects on the environment and interactions with the environment. The published services show their information by the following four-slot frame. Res Effect Action Func
Frame: name of the published Web service controllable environment of the service transitions of the resource states caused by the Web service interactions between the service and its environment worthy to be observed functions of the service
FECT: A Modelling Framework for Automatically Composing Web Services
327
Due to different focuses, requirements are described by Res, Effect, and Action. The requirement is modelled as a group of sub-services in terms of goals, tasks, etc. and published onto Internet. We term these sub-services the desired services because they might be the best solution we expect for the current requirements. The desired services are described with a three-slot frame(Res, Effect, Func). The XML-based abstract description can be represented as: xmlns: Res=”http://www.fect.com/environment/resource/” xmlns: Effect=”http://www.fect.com/environment/resource/” xmlns: Action=”http://www.fect.com/ontology/interaction/” xmlns: Func=”http://www.fect.com/ontology/interaction/” < r1 > < /r1 > · · · (r.attr(v1 , v2 , P ), · · · ) x11 , · · · x1n
2
· · · · · ·
(F P1 , F P2 , · · · )
It is tellable that the above XML-format leaves out the description of the WSDL interface and SOAP protocol in order to emphasize the semantic representation of the Web service.
4
Composition of Web Services
This section uses a meaningful example, i.e. book-selling on Internet, to illustrate the four-step procedure of discovering and composing Web services in FECT. Step 1: Extract Requirements from the Real World Suppose that a request service T , to build and manage a Web-based bookstore, has been put forward in the following form. xmlns: · · · · · · (book) book.owner(store, user, ω) register, login, order, pay
2
For avoiding the symbol conflicts of trace and XML, we substistute “ ” for “< >” when describing services by XML.
328
L. Hou and Z. Jin
Step 2: Model the Requirements and Publish Them on Internet After getting the request, the FECT server models it as three desired sub-services by the role-based modelling techniques[13]: user-manager, book-manager and order-manager. It then publishes them as the desired services in XML style. (Name, Address, Contact, Password) (Authority) < /user> (user.Authority(anonymous, legal, collect(user.info)), user.Authority(legal, online, collect(user.password)), user.Authority(online, anonymous, ω)) (collect(user.info), provide(user.info),alter(user.Authority)) ... ...
Step 3: Select the Competent Ones from the Volunteer Services As autonomous softwares, once recognizing the newly published desired services, the Web services decide whether they can match the descriptions of the desired services and whether they are willing to join in as members according to the rules of themselves. At the same time, the FECT server has also a group of rules to evaluate whether the desired services and the volunteer services are suited. It selects those competent ones as candidates to form the Standby Services Base. Let s1 be a Web service, s2 be an desired service. How to judge whether s1 is competent for s2 ? Here we give the following three qualifications:
1. If there exist r ∈ s2 .Res and r ∈ s1 .Res such that the following statements hold.
(a) r = r or SubClass(r, r ) = T rue. Means r is just r or a subclass of r . (b) r.inf o ⊆ r .inf o. Means the information of r is subset of that of r . (c) r.state ⊆ r .state. Means the set of states of r contains that of r. 2. s1 and s2 have some effects in common, i.e. s1 .Ef f ect ∩ s2 .Ef f ect = ∅ 3. For any interaction f p1 ∈ s1 .F unc, there exists f p2 ∈ s2 .F unc, such that at least one of the following conditions holds: (a) f p1 = f p2 (b) MethodOf(f p1 , f p2 )=True (c) f p1 ≡T f p2 (That means f p1 and f p2 are replaceable mutually when dealing with the task ”T”.) 4. For any trace F P1 ∈ s1 .F unc, ∃F P2 ∈ s2 .F unc, such that F P1 = F P2 . According to the above judgement standards, the services who satisfy 1, 2 and at least one of 3,4 are regarded as candidates. FECT found the following suitable services for the book-selling example.
FECT: A Modelling Framework for Automatically Composing Web Services
329
< /user> (user.Authoriy(free,legal, (user.info)), user.Authority(legal, online, (user.info)), user.Authority(online, legal, ω),user.Authority(legal, free, ω)) ask, ω, get, add, EDask, tell(user.info) ω, alter(user.Authority) (< ask, ω, get >(user.info),(user.info), alter(user.Authority), add(user.info),delete(user.info)) ... ...
Step 4: Compose the Chosen Services Now, suppose that Standby Services Base contains {W S1 , W S2 , · · · , W Sm }. Whether they can cooperate with each other to satisfy the requirement? The composition of services can be regarded as a rotative process: (1) select two composable services W Si and W Sj and compose them as a new Web service W S; (2) update the Standby Services Base by replacing W Si and W Sj with W S. The eventual composite services in the Standby Base are the concurrent processes to implement the requirements together. Before presenting the algorithm for composing two Web services, we introduce ⊕ to denote the composition operators of resources, effects, actions and even Web services. def
– Res1 ⊕ Res2 = Res1 ∪ Res2 . This is the simplest case. def
– Ef f ect1 ⊕ Ef f ect2 = Ef f ect1 ∪ Ef f ect2 ∪ Ef f ect1+2 , in which each element of Ef f ect1+2 is a new member because of the transitivity of the elements in Ef f ect1 ∪ Ef f ect2 . def
– Action1 ⊕ Action2 = Action1 ∪ Action2 ∪ Action1+2 , in which each element of Action1+2 is a catenation of the two traces from Action1 and Action2 respectively.
330
L. Hou and Z. Jin
And some other notations which will be used in the composing algorithm are listed in the following. Let C be an arbitrary service. T r(C): set of behavior traces of service C ; Beh(T r(C))): set of single behaviors of T r(C); X \ x: trace after removing behavior x from X ; h(X): head element of trace X ; H(T r(C)) = ∪h(X) where X ∈ T r(C); Re(C): set of resources operated by C ; (C : r.attr): attributes of r operated by C ; P (r): single behavior from the interaction ontology on r, P is a set of P ; P re(P (r)): state of r before being operated by P ; P ost(P (r)): state of r after being operated by P ; P RE(P) = ∪P re(P ) where P ∈ P; T (r.state) = (v1 , v2 ):transition of r.state from v1 to v2 ; ss(v(s)): set of transition sequences of state s, beginning with v(s) and without any loops; ST: set of resource states; SS(ST ) = ∪ss(v(s)) where v(s) ∈ ST ; +: append a single behavior to the behavior orderings. The following algorithm is given for modelling the composition process of the two services A and B. It provides an automatically composition way of Web services driven by the final behavior traces(T r). Algorithm 1. (Model the composition of Web services) Input: < Res(A), A.Ef f ect, A.Action > and < Res(B), B.Ef f ect, B.Action > Output: fail or < Res(A) ∪ Res(B), A.Ef f ect ⊕ B.Ef f ect, A.Action ⊕ B.Action > 1. Judge whether A and B have Resources in common or not. If Res(A) ∩ Res(B) = ∅ then return fail; else for each r ∈ Res(A) ∩ Res(B), do step 2 to step 5; 2. Initialize the behavior orderings set BO with the interaction pairs, between which the association is ”Precondition”. BO = {tell get, subscribe inf orm, inf orm receive, ...} 3. Initialize H0 = H(T r(A)S ) ∪ H(T r(B)S ), S0 = P RE(H0 ); 4. Append the behavior orderings to BO according to the effects of A and B. forall sq in SS(S0 ){bo = ∅ forall T = (v, v ) in sq and P in Beh(T r(A)S ) ∪ Beh(T r(B)S ){ if (P re(P ) = v and P ost(P ) = v ) {then bo = bo + P ; break} }endfor BO = BO ∪ {bo} }endfor 5. Do general catenation with the restriction of BO. Tr = ∅ forall X in T r(A)S and Y in T r(B)S { Z1=X Y based on BO, Z2=Y X based on BO, Tr=Tr∪Z1 ∪ Z2 }endfor 6. return < Res(A) ∪ Res(B), A.Ef f ect ⊕ B.Ef f ect, T r >
Back to the above mentioned example, OrderManager001 can combined with UserManager001 for transferring user’s information; OrderManager001 can be integrated with BookManager001 for transferring book.info and order.state while UserManager001 and BookManager001 cooperate concurrently and run severally. Figure 4 shows the composition result of the three Web services.
FECT: A Modelling Framework for Automatically Composing Web Services Order.state
Boo k .in fo
UserManager001
User.info
OrderManager001
331
Outer world
BookManager001
Book.state
Service Resource
Control flow
Resource flow
Fig. 4. Composition result of Web bookstore
5
Related Work and Conclusions
Apart from DAML-S and BPEL4WS, there are many other schools in the field of composing Web services. WSCI [15] provides mechanisms for describing how Web services can be assembled to participate in the shared business processes. EFlow [16] models a composite service by the graph that defines the order of execution among the nodes in the process. The graph is created manually and updated dynamically. Self-Serv [17] develops a relatively complete but a bit fuzzy middle-ware infrastructure for the composition of Web services. IRS-II [18], a framework and implemented infrastructure, bridges requirements and Web services by mapping the task models and the PSMs(Problems Solving Methods). However, all of these thoughts are absorbed in the composition at the execution level. FECT is a framework to model the automatic composition of Web services based on domain ontology and behavior trace. Compared with the related work, FECT has its own significant features. It is the first try to make the services selfdescribed by using the effect on their environments and the interaction traces. In nature, FECT introduces a bottom-up and automated composition process of Web services via the combination of behavior traces based on domain ontologies. At this stage, many further works are needed for improving FECT, including establishing meaningful meta-ontology, formalizing the service description, and developing the verification method of composite services.
References 1. J. Koehler and B. Srivastava. Web service composition: Current solutions and open problems. In ICAPS 2003 Workshop on Planning for Web Services, pages 28–35, 2003. 2. Web services description language (WSDL) 1.1. http://www.w3.org/TR/wsdl, 2001. 3. SOAP version 1.2. http://www.w3.org/TR/soap/, 2004. 4. A.Ankolekar et al. DAML-S: Semantic markup for web services. Proceedings of the International Semantic Web Workshop, 2001.
332
L. Hou and Z. Jin
5. S.Weerawarana. Business process with BPEL4WS: Understanding BPEL4WS. http://www-106.ibm.com/, 2002. 6. R. Hamadi and B. Benatallah. A petri net-based model for web service composition. In Proceedings of the 14th Australasian Database Conference (ADC’03), pages 191– 200. Australian Computer Society, February 2003. 7. Robin Milner. A Calculus of Communicating Systems-Lecture Notes in Computer Science. Number 92. Springer-Verlag, 1980. 8. D.L.Parnas and J.Madey. Functional documentation for computer systems. Science of Computer Programming, 25(1):41–61, 1995. 9. M.Jackson. The meaning of requirements. Annals of Software Engineering, 3:5–21, 1997. 10. M.Jackson. Problem Frames: Analyzing and structuring software development problems. Addison-Welsley, 2001. 11. UDDI executive overview: Enabling service-oriented architecture. http://uddi.org/pubs/, 2004. 12. Z.Jin, D.A.Bell, F.G.Wilkie, and D.G.Leahy. Automated requirements elicitation: Combining a model-driven approach with concept reuse. International Journal of Software Engineering and Knowledge Engineering, 13(1):53–82, 2003. 13. Eric SK.Yu. Towards modelling and reasoning support for early-phase requirements engineering. pages 6–8, Washington D.C., USA, Jan. 1997. 14. C.A.R.Hoare. Communicating Sequential Processes. Prentice Hall INternationsl, 1985-2004. 15. Web service choreography interface (WSCI) 1.0. http://www.w3.org/TR/wsci, 2002. 16. F.Casati et al. Adaptive and dynamic service composition in eflow. In Proc. of the International Conference on Advanced Information Systems Engineering, 2000. 17. B.Benatallah, Q.Z.Sheng, and Marlon Dumas. The self-serv environment for web services composition. IEEE Internet Computing, 7(1):40–48, 2003. 18. Enrico Motta1, John Domingue1, and Liliana Cabral1. Irs-ii: A framework and infrastructure for semantic web services. In Proceedings of the 2nd International Semantic Web Conference 2003 (LNCS), volume 2870, pages 306–318, Florida, USA, October 2003. Springer-Verlag GmbH.
