270 likes | 436 Views
A Bottom-Up Approach to Automating Web Service Discovery, Customization, and Semantic Translation. Dan Mandell and Sheila McIlraith Knowledge Systems Lab Stanford University ESSW 2003. Overview. Bottom-Up approach to Web service interoperation Motivating example
E N D
A Bottom-Up Approach to Automating Web Service Discovery, Customization, and Semantic Translation Dan Mandell and Sheila McIlraithKnowledge Systems LabStanford University ESSW 2003
Overview • Bottom-Up approach to Web service interoperation • Motivating example • BPEL4WS and automated Web service execution • The Semantic Discovery Service (SDS) and automated Web service discovery, customization, and semantic translation • Summary: contributions, future directions
A Bottom-Up Approach • Web services long-term goal: seamless interoperation between programs and devices • Industry provides standards, computing infrastructure, and recently choreography models akin to work in process modeling • These include WSCI, BPML, XLANG, WSFL, WSCL, WSFL, WSCL, BPSS, now BPEL4WS • Still far from seamless interoperation
A Bottom-Up Approach • In parallel, Semantic Web community developed languages and computing machinery for authoring and reasoning about unambiguous, machine interpretable Web content • Efforts are based on AI technology, and include RDF, RDF(S), DAML+OIL, DAML-S, and OWL • Though powerful, these efforts remain largely disconnected from industrial standards and infrastructure
A Bottom-Up Approach • We argue that: • Web Services must embrace representation and reasoning ideas from Semantic Web community • Must also recognize evolutionary influence of industry standards and machinery on Semantic Web services • From this viewpoint, we build on BPEL4WS • A leading process modeling framework • Co-authored by IBM, Microsoft, BEA, SAP, Siebel • Merges ideas from XLANG and WSFL • Integrate Semantic Web technology to enable automated service discovery, customization, and semantic translation
A Motivating Example • Consider integrating services to provide a loan finding service:
A Motivating Example • Possible scenario:
A Motivating Example • Questions: • How are the service partners • Selected? • Ordered? • Invoked? • Integrated?
BPEL4WS - Automated Service Execution • BPEL4WS • A BPEL4WS document • Provides notation for describing WS interactions as business processes, following in tradition of workflow modeling • Integrates services by treating them as partners that fill roles in a process model • Directs workflow using traditional control constructs: if, then, else, while-loop • Communication level params (e.g. service partner bindings) are described in accompanying WSDL docs
BPEL4WS - Automated Service Execution • BPWS4J • Engine released by IBM alongside BPEL4WS • Implements subset of features defined in BPEL4WS • Consumes a BPEL4WS doc along with accompanying WSDL docs defining service partner bindings to physical ports • Establishes a single endpoint for accessing BPEL4WS process as a Web service
BPEL4WS - Automated Service Execution • BPEL4WS and the loan example • A service provider writes a BPEL4WS doc describing the loan finding process model -- a program that orchestrates interaction of the service partners • BPEL4WS allows service partners to be unbound to physical ports until runtime through dynamic assignment of Service References • Current implementation of BPWS4J does not implement Service Reference assignment, so author selects service partners at design time
BPEL4WS - Automated Service Execution • Critical analysis of BPEL4WS automation: • Limitations in BPWS4J • Service provider assigns partners a priori • System cannot customize partner selection for each user. • Loan finder example: user may wish to use in-state lender to benefit from in-state tax incentives • If service provider defines lending partner prior to receiving user’s request, the preference is ignored • Manual work means more responsibility and maintenance time demands for service provider
BPEL4WS - Automated Service Execution • Critical analysis of BPEL4WS automation: • Limitations in BPEL4WS • Relies on expressivity of XML / XML Schema • Interface-oriented: insufficient for automating many tasks. • E.g., credit assessor for an ex-UK resident provides UKCreditReports, while lending service comsumes USCreditReports. Even if differ only in representation of dates, failing to recognize their semantic compatibility leaves a potentially successful integration unrealized • Need service-oriented descriptions of service form and function in an well-defined ontology language
Automated, Customized, Service Discovery with SDS • To alleviate shortcomings in BPEL4WS / BPWS4J, introduce a Semantic Discovery Service (SDS) to enable • automated service discovery • automated service customization • automated semantic translation • Use Semantic Web technologies to enable description of services in computer interpretable format and discovery of services with desirable properties
Automated, Customized, Service Discovery with SDS • Supporting technologies • DAML-S: A well-defined ontology based on DAML+OIL, used to describe services • DAML Query Language (DQL): Language and protocol used for querying repositories of DAML-S service profiles. DQL server interfaces with automated reasoner operating over knowledge base (KB) of DAML-S profiles • Java Theorem Prover (JTP): Hybrid reasoning system based on FOL model elimination. Use as DQL server’s automated reasoner
Automated, Customized, Service Discovery with SDS • Form and function of the SDS • Sits between a BPWS4J process and potential service partners • Locates appropriate partners, acts as dynamic proxy between them and BPWS4J
Automated, Customized, Service Discovery with SDS • The SDS is portable between BPWS4J actions and processes because it is: • Agnostic as to the content of the service descriptions and invocation messages it receives • Stateless, with no knowledge of prior interactions or service-specific properties • The SDS enables automated service customization and semantic translation
Automated, Customized, Service Discovery with SDS • Automated service customization:
Automated, Customized, Service Discovery with SDS Interaction flow between BPWS4J, SDS, DQL server, and discovered service partners
Automated, Customized, Service Discovery with SDS • Automated semantic translation • In the Web services context, semantic translation means redefining well-defined data types in terms of their relationships to each other via translational axioms • Enables integration of service partners operating on messages that differ syntactically but are semantically translatable
Automated, Customized, Service Discovery with SDS • Automated semantic translation • Uses translational axioms encoded as Web services to integrate partner inputs and outputs • Uses a back-chaining algorithm to find sequence of service invocations, or service chain
Automated, Customized, Service Discovery with SDS • SDS and the loan example • Recall ex-UK resident seeking a loan from an in-state lender • BPWS4J could not satisfy request given the constraints • Lender located in user’s state • UKCreditReport represents dates as MM/DD/YYYY, US version uses DD/MM/YYYY
Automated, Customized, Service Discovery with SDS • SDS and the loan example • With SDS, the request is satisfiable • Automated service customization: include DAML-S restriction that lender partner be physically located in the user’s state in request message • Automated semantic translation: back-chaining algorithm inserts a DateTranslator translational axiom: • DateTranslator translates between UKCreditReport and USCreditReport • Forms service chain (Assessor -> DateTranslator -> Lender) which can successfully complete request
Summary • Seamless interoperability is critical for Web services to provide an infrastructure for ubiquitous computing • Towards this goal, the bottom-up approach brings Semantic Web technology to industrial standards and computing machinery
Summary • By integrating the SDS with BPEL4WS, the industrial system gained the following abilities: • Automatic, runtime binding of service partners • Selection between multiple service partners based on user-defined constraints • Integration of service partners with syntactically different but semantically translatable service descriptions
Summary • To work towards seamless interoperation, it is critical that: • Web service providers publish descriptions of Web service form and function in a well-defined ontology language like DAML-S • Web service interoperation frameworks embed semantic technology into their systems and specificaitons that is capable of reasoning about such descriptions