of 5

V2I300110 | Web Service | Semantic Web

All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Published in IJARCSSE
    Volume 2, Issue 3, March 2012ISSN: 2277 128X  International Journal of Advanced Research inComputer Science and Software Engineering Research PaperAvailable online at: www.ijarcsse.com  Basic Approaches to Semantic Web Services : AComparative Study Dr. Rachna Soni * Gurmeet Kaur  Asst. Prof & HoD (CS&A), M.Sc. (CS),MCA,M.Phil,P.hd(P), DAVC, Yamuna Nagar(Haryana) MBU, Shimla grmtkaur02@gmail.com   Abstract  —  It has been recognized that due to the autonomy and heterogeneity of Web services and the Web itself, new approachesshould be developed to describe and advertise Web services. The most notable approaches rely on the description of Web servicesusing semantics. This new breed of Web services, termed semantic Web services (SWSs) aim to improve the possibilities forautomated discovery, composition and invocation of Web Services by providing ontology-based service descriptions expressed in aformal language. Several approaches have been driving the development of Semantic Web Service frameworks such as OWL-S(Ontology Web Language for Services), WSMO (Web Service Modeling Ontology) and IRS-III (Internet Reasoning Service). Thispaper focuses on framework of different approaches of Semantic Web Services and also contrast these approaches to SWS accordingto the proposed dimension.  Keywords  —    SWS, IRS-III, OWL-S, WSMF, WSMO   I.   I NTRODUCTION  Current industry standards for describing Web Services focuson ensuring interoperability across diverse platforms, but donot provide a good foundation for automating the use of WebServices.A key problem with the use of standards for WebService description (e.g. WSDL) and publishing (e.g. UDDI)is that the syntactic definitions used in these descriptions donot completely describe the capability of a service and cannotbe understood by software programs. Semantic Web Services(SWSs) are the result of the evolution of the syntacticdefinition of Web Services and the semantic Web.Representational techniques being developed for the SemanticWeb can be used to augment these standards. The resultingWeb Service specifications enable the development of software programs that can interpret descriptions of unfamiliarWeb Services and then employ those services to satisfy usergoals. The Semantic Web is a set of technologies forrepresenting, and publishing on the Web, computer-interpretable structured information [1]. Semantic WebServices [2] is a research field that endeavours to apply thesetechnologies to the description and use of Web Services.Whereas interoperability is the primary motivation for WebServices, automation of information use and dynamicinteroperability are the primary objectives of Semantic WebServices.  1.1 Semantic Web Services will allow the semi-automatic andautomatic annotation, advertisement, discovery, selection,composition, and execution of inter-organization businesslogic, making the Internet a global common platform byproviding ontology-based service descriptions expressed in aformal language. Semantic Web Services aim to reduce thehuman effort required to build Service Oriented Architecturesby enabling machines to understand the function andinterfaces of Web services through the addition of semantics,by providing formal descriptions with well defined semantics.The research agenda for SWS identifies a number of key areasof concern, namely:  Description/annotation: To effectively perform operationssuch as the discovery of services, the semantics of theinput/output data has to be taken into account. Hence, if thedata involved in Web service operation is annotated using anontology, then the added data semantics can be used inmatching the semantics of the input/output data of the Webservice with the semantics of the input/output data of therequirements.  Discovery: finding the Web service which can fulfill a task.Discovery usually involves matching a formal task descriptionagainst semantic descriptions of Web services. Selection : A selection of services is required if there is morethan one service matching the request. Non-functionalattributes such as cost or quality can be used for choosing oneservice.  Mediation : we can not assume that the software componentswhich we find are compatible. Mediation aims to overcome allincompatibilities involved. Typically this means mismatchesat the level of data format, message protocol and underlyingbusiness processes. Composition : Composition or Choreography often no singleservice will be available to satisfy a request. In this case weneed to be able to create a new service by composing existingcomponents. Artificial Intelligence (AI) planning engines are  Volume 2, Issue 3, March 2012www.ijarcsse.com  © 2012, IJARCSSE All Rights Reserved Page | 183 typically used to compose Web service descriptions fromhigh-level goals.  Execution semantics: of a Web service encompasses the ideasof message sequence (e.g., request-response, request response),conversation pattern of Web service execution (peer-to-peerpattern, global controller pattern), flow of actions (sequence,parallel, and loops), preconditions and effects of Web serviceinvocation, etc. 1.2 SWSs Approaches The Major initiatives in the area of SWSs are documented byrecent W3C member submissions: OWL-S [3], WSMO [4]and IRS-III [8]. The proposals differ in scope, modellingapproach and the concrete logical languages used. Theseapproaches are complementary in many ways. Each initiativecan be characterized in terms of (1) a conceptual model describing the underlying principlesand assumptions; and(2) a language or a set of languages that provide the means torealize the model.2. OWL-SOWL-S (formerly DAML-S) is emerging as a Web servicedescription language that semantically describes the Webusing OWL ontologies. OWL is a W3C standard OWL is aDescription Logic-based Language, provides the basicconstructs to describe ontologies . It provides a framework fordescribing both the functions and advertisements for WebServices, including a process specification language, anotation for defining process results, and a vocabulary forconnecting these descriptions in OWL with syntacticspecifications of service message structure in WSDL (and inother existing notations).OWL-S has been used in verydifferent configurations, from traditional Web Servicearchitectures that adopt the service-oriented architecture (SOA) ‗triangle‘ set of interactions (among a service registry, producer, and consumer). The principal high-level objectivesof OWL-S are(1) to provide a general-purpose representational framework in which to describe Web Services;(2) to support automation of service management and use bysoftware agents;(3) to build, in an integral fashion, on existing Web Servicestandards and existing Semantic Web standards; and(4) to be comprehensive enough to support the entire lifecycleof service tasks.The Overall structure of OWL-S ontology includes threeprimary sub-ontologies: the service profile, process model,and grounding.  Service Profile   The service profile tells what the servicedoes . The profile can be used to advertise a service bydescribing its capabilities. Web Services are viewed asfunctions that produce a transformation in their inputsgenerating outputs. A profile description includes three typesof information:1. A human readable description of the service and itsprovider2. A specification of the functionalities that are provided bythe service3. Attributes which provide additional information andrequirementsThe Service Profile describes what the service does byspecifying the input and output types, preconditions andeffects (IOPE). ã The inputs the service expects. The inputs are the objectdescriptions that the service works on;  ã The output information returned the outputs are the objectdescriptions that it produces.  ã T he preconditions that have to be satisfied in order to use theservice. ã An effect is a proposition that will become true when theservice completes.The expected effects resulting fromrunning the service.In general, these propositions are not statements about thevalues of the inputs and outputs, but about the entities referredto in the inputs and the outputs. For example, a service thatrequires a user to have an account and a credit card mighthave inputs User and CreditCard and precondition:hasAcctID(User, AcctID)& validity(CreditCard, Valid))(AcctID and Valid are local variables). The preconditionrequires the user to actually have an account with the service,with the account identifier AcctID. It also requires the creditcard to have a known status Valid. In general, the effects of aservice vary depending on conditions. In the case at hand, if the credit card is in fact valid, then let us suppose the service will replenish one‘s Pass balance to $25.3 If the credit card isnot valid, then there is no change in the account balance.These are two separateresults. The first might be indicated as:Valid = OK |  –  >output(Outcome<=Success)& AcctBalance(25)The second might be written:Valid = Not- OK |−>  output(Outcome<=Failure)Here, OK and Not-OK are values defined as elements of anOWL class AccountValidity.The value of the output Outcome depends on tests that occurduring the execution of the process, as does the effect fromcondition Valid=OK then AcctBalance(25). (Note that thistest is performed by the service provider, not the serviceconsumer, although if the consumer knew the credit-cardstatus).A profile also allows the definition of servicecharacteristics such as the category (refers to an ontology of services that may be on offer), the degree of quality, thequality guarantees , the geographic radius (refers to thegeographic scope of the service), etc. Process Model   The service model describes ―how a serviceworks‖, to enable invocation, enactment, composition, monitoring and recovery. A process model decomposes intoan ordered collection of processes. A process consists of otherprocesses, in which case it is said to be a composite processand it is organized on the basis of some control flow structure.A process model allows various types of control flowstructure including split, sequence, and non-deterministic  Volume 2, Issue 3, March 2012www.ijarcsse.com  © 2012, IJARCSSE All Rights Reserved Page | 184 choice. The control constructs made available are thefollowing : ã Sequence: a list of processes to be carried out in a specific order. ã Split: a bag of process componen ts to be executedconcurrently. ã Unordered: a bag of process components that can be executed in any order. ã Split Join: consists of concurrent execution of process components with barrier synchronization. ã Choice: allows a choice between alternative and execute one. ã If  -then-else: class has properties if Condition, then, and else,which implement the statement. ã Repeat -until and repeat-while: Iterates execution of a bag of processes until/while a condition holdsIf a process is not decomposable any further, it is said to be anatomic process and corresponds to operations that can beperformed directly. Processes have inputs used to execute theprocess correctly. For a process to be executed, itspreconditions need to be evaluated to true. The results of aprocess are described as a set of outputs. Service Grounding   The grounding maps the constructs of theprocess model onto detailed specifications of message formatsand protocols. Grounding of a service specifies the detailsabout transport protocols, message formats, serialization,addressing, and other service-specific details such as portnumbers used in contacting the service. It answers to the question ―How does a client access a service?‖OWLS uses Web Service Description Language (WSDL) as aspecification for messages exchanged between services andprocesses.3. WSMOWSMO: This initiative defines a model to describe semanticweb services, based on the conceptual design set up in the WSModeling Framework WSMF [5]. The Web Service ModelingFramework (WSMF) provides a model for describing thediverse aspects related to Web services. WSMF is the productof research on modeling of reusable knowledge components.WSMO is moreover accompanied by a formal language, theWS Modeling Language WSML [7], which allows one towrite annotations of WSs according to the conceptual model,and by an execution environment WSMX [6] for the dynamicdiscovery, selection, mediation, and invocation of services.The latter distinguishes four elements: ontologies, services,goals and mediators. WSMF is based on:1)realize an e-commerce application;communicate in a scalable mannerWSMO identifies four main top-level elements: Ontologies that provide the terminology used by otherelements. The main objectives of the use of ontologies are toenhance interoperation by giving formal semantics to theinformation exchanged by Web services and facilitating theinteroperation between humans and Web services. WSMOontologies include concepts, relations, instances, and axioms,and information describing non-functional properties. Thebasic blocks of a WSMO ontology are concepts, relations,functions, instances, and axioms. Concepts are defined using aparent-child hierarchy and their attributes, including rangespecification. Relations describe interdependencies between aset of parameters. Functions are relations that have a unaryrange beside a set of parameters. Instances are individuals of concepts or relations, by specifying concrete values forattributes or parameters. Axioms are specified as logicalexpressions to formalize domain specific knowledge. Goals that state the intentions that should be solved by WebServices. They are described at a high level and describefunctionalities that a Web service should provide from theuser perspective. WSMO follows a goal-driven approach.Requests and services are decoupled. A goal includes arequested capability definition (what is required from theservice), a requested interface definition (which interface isdesired) and some ontology imports for semanticcontextualizing of the involved elements. In WSMO, a goal isdescribed by non-functional properties, imported ontologies,used mediators, requested capability, and requested interface. Web Services descriptions which describe various aspects of aservice. A service definition in WSMO includes fivedescription elements, namely: ãNon -functional properties, for data about the service creator,publisher, date, etc. ãImporte d ontologies, to specify the semantic meaning of theconcepts used in the service description. ãUsed mediators, to assign the mediators used for importing ontologies and other tasks. ãCapability, which depict the functionalities provided by the service in terms of preconditions, postconditions, assumptionsand effects. These properties determine the behaviour of theservice, i.e. what is the state of the world before and after theexecution of the service, and they are expressed as axioms inlogic based language WSML.  Mediators: to resolve interoperability problems.  Mediators connect heterogeneous components of a WSMO descriptionwhich have structural, semantic or conceptualincompatibilities. Mismatches can arise at data level (whenseveral distinct ontologies need to be integrated) or at processlevel (if a translation between communicating elements mustbe carried out). A mediator declaration includes non-functional properties, imported ontologies, a sourcecomponent, a target component and a mediation service.There exist four types of mediators: ontology mediators, goalsmediators, web service-to-goal mediators and web service-to-web service mediators.4. IRS-IIIIRS-III(Internet Reasoning System [8]) following the WSMOframework [9], provides at the semantic level a distinctionbetween goals (i.e. abstract definition of tasks to beaccomplished) and Web services (i.e. description of servicesthat can achieve a goal) and as a result support capability-driven service matching and invocation . IRS-III automaticallytransforms programming code into a Web service. In addition,any service published on IRS-III automatically appears as astandard Web service to other Web service infrastructures. A  Volume 2, Issue 3, March 2012www.ijarcsse.com  © 2012, IJARCSSE All Rights Reserved Page | 185 core design principle for IRS-III is to support capability-basedinvocation . IRS-III will:a) discover potentially relevant Web services;b) select the set of Web services which best fit the incomingrequest;c) mediate any mismatches at the conceptual level;d) invoke the selected Web services whilst adhering to anydata, control flow and Web service invocation constraints.  IRS-III Server  builds upon an  HTTP Server  written in Lispwhich has been extended with a SOAP handler. At the heart of the server is the SWS Library, where the semantic descriptionsassociated with Web services are stored using representationlanguage OCML [10] [Motta, 1998]. The library is structuredinto domain ontologies and knowledge models for goals, Webservices and mediators as described previously . Allinformation relevant to a Web service is stored explicitlywithin the library. Within IRS-III, a Web service is associatedwith an orchestration and choreography definitions.Orchestration specifies the control and data flow of acomposite Web service, whereas, choreography specifies howto interact with a single Web service. The choreographycomponent communicates with an invocation module able togenerate the required messages in a SOAP format. A  Mediation Handler  descriptions including running datamediation rules, invoking mediation services and connectinggoals and Web services. Figure 1 shows framework for IRS-III.  IRS-III Publishing Platforms: Publishing with IRS-III entailsassociating a deployed Web service with an IRS-III Webservice description. When a Web service is published all of the information necessary to call the service - the host, portand path - is stored within the choreography associated withthe Web service. Additionally, updates are made to theappropriate Publishing Platform. IRS-III contains publishing15 platforms to support grounding to stand-alone Java andLisp code and to Web services. Web applications accessible asHTTP GET requests are handled internally by the IRS-IIIserver.  IRS-III Clients & API :   IRS-III was designed for ease of useand,  IRS-III Browser  supports this by providing a goal-centricinvocation mechanism. An IRS-III user simply asks for a goalto be solved and the IRS-III broker locates appropriate Webservice semantic descriptions, using the mediators and theninvokes the underlying deployed Web services. Additionally,the IRS-III client and publishing platforms interact with theIRS-III server through the API.IRS-III, a framework for creating and executing semanticWeb services, which takes a semantic broker based approachto mediating between service requesters and service providers.IRS-III approach provide three different applications todomains of Business Process Management, e-Learning and e-Science.5. SWS approaches comparisonThis comparison discusses the delivered results of IRS-III,OWL-S and WSMO as they represent the main approachesdriving the implementation of Semantic Web Servicecomponents. Some of benefits of using OWL-S are:1) Benefits to application developers: Ease of use, less codeto write, code becomes reusable & less chance of misinterpretation.2) Benefits to community at large: Everyone can understandeach other's data's semantics, since they are in a commonlanguage.But there are some of problems of Owl-S are as:-OWL-S does not separate what the user wants from what theservice provides. OWL-S is restricted to the service profileand cannot expressed the non-functional properties . OWL-Sdefines only one service model per service, so there is onlyone way to interact with the service. OWL-S does notexplicitly provide linkage facilitate of hetero-geneousresources between one another . OWL-S is more mature incertain aspects (like choreography), but does not provides amore complete conceptual model.WSMO provides a more complete conceptual model becauseit addresses aspects like goals and mediators. WSMOdescription of choreography and combination issues (based onAbstract State Machines) is expected to be more detailed andflexible than OWL-S one. It covers most of the problem of OWL-S approaches as nonfunctional properties can beexpressed in any WSMO element, it is expected that therecould be more than one way to interact with a particularservice, WSMO allows the definition of multiple interfacesfor a single service (using choreography and orchestration aschoreography describes the external visible behavior of theservice and an orchestration describes how other services arecomposed in order to achieve the required functionality of theservice) , to facilitate linkage of heterogeneous resourcesbetween one another, various kinds of mediation are required.IRS-III [8] is a framework and implemented infrastructure forSemantic Web Services that implements the WSMOdescriptions & builds upon the previous version (IRS-II) byincorporating and extending the WSMO ontology within theIRS-III server, browser and API. The following table showsthe high-level elements of each approach of SWS, includingthe application tools provided as well.  
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks