Web Services and More: Integrating Business Processes and Information Across Agencies

1
Web Services and MoreIntegrating Business
Processes and Information Across Agencies

• David Booth, Ph.D.
• W3C Fellow / Hewlett-Packard
• FedWeb Fall 02 Conference
• Arlington, VA, USA
• 29 October 2002
• dbooth_at_w3.org
• http//www.w3.org/2002/Talks/1029-fedweb-dbooth/

2
Speaker Info

• Fellow at W3C (World Wide Web Consortium)
• Sponsored by Hewlett-Packard / Software
• Working on W3C standards and technologies
• Web Services
• Semantic Web
• Ph.D. in Computer Science from UCLA
• Many years of programming and OSs

3
Outline

• Objective
• Integrate business processes across agencies
• Re-use data more easily
• Web Services
• SOAP, WSDL, Semantics
• What fundamental problems will arise?
• Babelization
• How can these problems be addressed?
• Ontologies
• URLs as Unambiguous Names
• RDF

4
W3C

• International consortium
• Mission Lead the Web to its full potential
• Defines Web standards
• XML, HTML
• Digital signatures
• Web Accessibility Initiative (WAI)
• See http//www.w3.org/WAI/
• Web Services
• XMLP Working Group (for SOAP 1.2)
• Web Services Description Working Group (for WSDL
  1.2)
• Web Services Architecture Working Group
• Semantic Web
• . (and many others)

5
What is a Web Service?

• Contrast a Traditional Web Application with a Web
  Service

6
What is a Web Service?
Traditional Web Application

• Human to Machine interaction
• User at browser interacts with application at Web
  Server
• Web App sends HTML to browser for human display
• Protocol is HTTP

7
What is a Web Service?
Web Service

• Human to Machine interaction
• Client application interacts with Web Service
  application
• Client and Service exchange XML
• Protocol may be HTTP or other

8
Integrating Business Processes

• Client and Service are often front ends for
  existing apps/systems
• Any application/component can be exposed as a Web
  Service
• Any granularity
• Fine -- Not a good idea
• Course -- Best value
• Allows clean integration across
• departments, agencies, companies, etc.
• Loose coupling
• Client and Service can use different platforms
  and programming languages
• Only need to agree on interface
• One Web Service can make use of others . . .

9
Travel Service Example

• "Client" and "Service" are relative roles
• Service could be Client of other Web Services

10
Integrating Across Departments, Agencies
Can use Web Services to integrate across
departments, agencies, to companies, etc.
11
SOAP

• Problem Existing protocols are not XML-oriented
• Solution SOAP
• Originally "Simple Object Access Protocol"
• Now just a name
• Protocol for message passing
• Based on XML
• Layered on top of transmission protocols (HTTP,
  etc.)
• SOAP 1.1 produced by individual companies
• SOAP 1.2 is being standardized at W3C

12
Web Service Description
Q How is Client - Service interface defined?A
Web Service Description

• Defines the syntactic-level interface
• Web Service address (URL)
• Message formats, data types, protocols

13
Web Service Description Language (WSDL)

• Language for writing Web Service Descriptions
• Based on XML
• WSDL 1.1 produced by individual companies
• WSDL 1.2 is being standardized at W3C

14
The Need for Semantics

• WSDL only defines syntactic-level interface
• Client and Service must also agree on semantics
• "Semantics" "meaning"
• I.e., what should Client and Service do?

15
Representing Semantics

• Owners of Client and Service must agree on
  semantics
• Can be verbal or written (preferably)
• Can be human-oriented (e.g., English) or
  machine-processable (e.g., RDF)
• Ideally, Web Service Description should point to
  semantics
• E.g. "targetNamespace" URL
• My recommendation Web Service Description should
  reference its semantics

16
Babelization

• Each WSDL document defines a "language" for
  interacting
• Proliferation of "languages" / terms
• ltpublication_authorgt
• ltAuthorgt
• ltDocumentCreatorgt
• ltPub-Creatorgt . . . .
• Meaning may be same, similar or different
• Is ltDocumentCreatorgt the person or the
  organization that the created the document?

17
Re-using Data Across Agencies

• Data developed independently
• Administered separately
• "Silos"
• Difficult to re-use data
• Meaning, formats don't always match

18
Common Problems

• Different terms, same meaning
• Not such a problem
• Rule can say ltDocumentCreatorgt is the same as
  ltAuthorgt
• Same terms, different meaning
• Is postal code 5 digits or 54?
• Much bigger problem
• How do meanings relate?
• If I understand ltPlaneTicketgt , what can I
  understand about ltNonRefundablePlaneTicketgt ?

19
Underlying Needs

• Need machine processable
• Common vocabularies (Ontologies)
• Unambiguous names (URLs)
• Common language for expressing information (RDF)
• (Especially meta-data)

20
Ontologies

• Ontology Formal description of concepts and
  their relationships
• Example
• Definition of "plane ticket" and "non-refundable
  plane ticket"
• A "non-refundable plane ticket" is-a-kind-of
  "plane ticket"
• Common, machine-processable "vocabulary"

21
Example Ontologies

• Dublin Core
• Defines 14 basic concepts for documents and
  publishing
• "title", "creator", "subject", "publisher"
• DAML / DAMLOIL
• DAML-S
• Ontology for Web Services
• And many others
• How can concepts be unambiguously identified?

22
URLs as Globally Unambiguous Identifiers

• URL has two different uses
• 1. Unambiguous name for something
• 2. Location of a document
• Name is still useful even without a location
• URLs can be used to identifying concepts
• Especially useful for ontologies metadata
• Also useful for other data
• Document at URL can describe the concept

23
Examples of URLs as Identifiers

• http//www.example.org/staffid/85740
• Identifies a particular person (e.g. "John
  Smith")
• http//purl.org/dc/elements/1.1/creator
• Defines Dublin Core concept of a document's
  "creator"
• Recommendation Use URLs as unambiguous
  identifiers!

24
Standardizing Ontologies

• Option 1 Standardize on one big ontology
• Not realistic or practical
• Option 2 Allow arbitrary, conflicting ontologies
• Not good either
• Option 3 Allow multiple ontologies, but use URLs
  to avoid accidental conflicts
• Can be merged later

25
W3C Web Ontology Working Group

• Defining a common language ("OWL") for writing
  ontologies
• W3C WebOnt Working Group
• Based on RDF

26
What is RDF?

• "Resource Description Framework"
• (But think "Relational Data Format")
• (Or "Reusable Data Format")
• W3C Recommendation
• Language for making statements about things
• Often used for metadata
• E.g., Author, Title, Subject
• Has XML syntax
• Simple, universal data format

27
RDF Triples

• Info expressed as triples       Subject - Verb
  - Object  Or        Subject - Property - Value
• Subject, Verb and Object can all be URLs
• Globally unambiguous

28
Example Triple

• (Not RDF/XML syntax)
• http//www.example.org/foo.html
  (Subject)
• http//purl.org/dc/elements/1.1/creator (Verb)
• http//www.example.org/staffid/85740 (Object)
• Meaning "Web page foo.html was created by John
  Smith"

29
RDF Uses

• Best for
• Meta-data
• Descriptive data
• Database field table definitions
• Configuration information
• Diverse data
• Expressing relationships between data
• Unknown or changing data requirements

• Not Good For
• High volume, repetitive data
• Numeric data
• Very regular, structured, fixed-format data

30
Why RDF?

• "Future proof" your data
• New data can be merged without conflict
• New relationships can be added
• "Insurance policy"
• Globally unambiguous
• Simple, universal format

31
Outline

• Objective
• Integrate business processes across agencies
• Re-use data more easily
• Web Services
• SOAP, WSDL, Semantics
• What fundamental problems will arise?
• "Babelization"
• How can these problems be addressed?
• Ontologies
• URLs as Unambiguous Names
• RDF

32
End

• W3C Mission Lead the Web to its full potential