WebServices.html 30.4 KB

Raw Blame History Permalink

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta name="generator" content=
    "HTML Tidy for Mac OS X (vers 31 October 2006 - Apple Inc. build 13), see www.w3.org" />
    <title>
      Web Services overview - Design Issues
    </title>
    <link rel="Stylesheet" href="di.css" type="text/css" />
    <meta http-equiv="Content-Type" content="text/html" />
  </head>
  <body bgcolor="#DDFFDD" text="#000000" lang="en" xml:lang="en">
    <address>
      Tim Berners-Lee<br />
      Originally created: 2002-10, last change:
    </address>
    <address>
      $Date: 2009/08/27 21:38:10 $<br />
      Status: Rough amalgam of input from generally reliable
      sources. Editing status: draft. This is really a set of
      pointers, as the web services architecture is being
      elaborated by a whole communit, with the WS-Arch group
      playing a specific role. Started as notes from W3C Web
      Services Workshop [@@].
    </address>
    <p>
      <a href="./">Up to Design Issues</a>
    </p>
    <hr />
    <h1>
      Web Services
    </h1>
    <blockquote>
      <p>
        Program Integration across Application and Organization
        boundaries
      </p>
    </blockquote>
    <h3>
      Introduction
    </h3>
    <p>
      Web Services mean many things to many people. In the end,
      there will be a set of standards which allow us to do things
      we could not do before, but in the mean time different people
      and companies approach them from different positions, and
      with different expectations. In 2001-2, Web Services have
      also been a buzzword used repeatedly and claimed to be one of
      the hot new technologies. The common themes are:-
    </p>
    <ul>
      <li>A departure from the web as a quasi-static information
      space to one in which interactions are the primary model
      </li>
      <li>A use of HTTP, XML and other standards from the web
      architecture as the building blocks
      </li>
      <li>A typical focus on enterprise wide and inter-enterprise
      operations
      </li>
    </ul>
    <p>
      The Web in Web Services is, from the first point, a misuse:
      the term Internet Services would be more appropriate. The Web
      comes from the second point - the use of the HTTP and XML is
      already in use as a well-understood and well-debugged set of
      protocols which support the Web, and so it makes sense to
      reuse them in providing remote operations and those things
      connected with them. The third point is what makes web
      service requirements so different from a local RPC system.
      The fact that data is exchanged for business purposes and
      between different social entities means that accountability
      is required, rather than just reliable transmission.
    </p>
    <ul>
      <li>The vendors of software see web services as way to
      repackage existing capability in a way which makes it
      interoperable with other systems.
      </li>
      <li>The security requirements for web services are dictated
      by the trust environments, whether it is intranet or b2b or
      b2c, etc
      </li>
      <li>For b2b one needs not just reliabilioty but
      accountability.
      </li>
    </ul>
    <p>
      The architecture of Web Services is the scope of the W3C Web
      Service Architecture Working Group.
    </p>
    <h3>
      Philosophy
    </h3>
    <p>
      Other articles have dealt with the fundamental architectural
      difference between remote operations and the architecture of
      the information space, and the mappings between the two.
    </p>
    <ul>
      <li>
        <a href="Axioms.html">Axioms of web architecture</a>
        (1990s) talks about the information space concept
      </li>
      <li>
        <a href="PaperTrail.html" rel="chapter">Paper Trail</a>-
        Discusses the relationships between two patterns:
        read/write state derived from read-only documents in real
        life. Which came first, the journal or the database?
      </li>
      <li>
        <a href="Conversations.html">Conversations and State</a>
        (1998) discusses the trends in many areas away from shared
        information spaces, from Web Services to Voice browsing.
      </li>
    </ul>
    <p>
      The Web Services architecture group has produced various
      drafts:
    </p>
    <ul class="deliverables">
      <li class="wd">
        <a href="http://www.w3.org/TR/2002/WD-wsa-reqs-20021114"
        rel="details" class="title">Web Services Architecture
        Requirements</a> (<span class="date">2002-11-14</span>)
      </li>
      <li class="wd">
        <a href="http://www.w3.org/TR/2002/WD-ws-arch-20021114/"
        rel="details" class="title">Web Services Architecture</a>
        (<span class="date">2002-11-14</span>)
      </li>
      <li class="wd">
        <a href="http://www.w3.org/TR/2002/WD-ws-gloss-20021114/"
        rel="details" class="title">Web Services Glossary</a>
        (<span class="date">2002-11-14</span>)
      </li>
      <li class="wd">
        <a href=
        "http://www.w3.org/TR/2002/WD-ws-arch-scenarios-20020730/"
        rel="details" class="title">Web Services Architecture Usage
        Scenarios</a> (<span class="date">2002-07-30</span>)
      </li>
    </ul>
    <p>
      The architecture uses the following diagram for the highest
      level:
    </p>
    <p>
      <img src=
      "http://www.w3.org/TR/2002/WD-ws-arch-20021114/Triangle.png"
      alt="Basic Web services architecture graphic" />
    </p>
    <p>
      However, the essential part of Web services is the
      <em>Interact</em> relationship between a Service provider and
      Service requestor. This is the Web Service. Discovery
      agencies need not be used - they will in some cases but not
      in others. The discovery agencies are well represented as a
      cloud, rather than being a well-defined module in the web
      services architecture. They will become interface to a huge
      world of data and query services which provide data about web
      services as well as many other things.The Interact between
      between requestor and provider is the essential defining
      element to web services. As we shall see, the metadata about
      web services
    </p>
    <h2>
      Technologies within the Web Servcies umbrella
    </h2>
    <p>
      There is a mass of different pieces being bolted onto the
      foundations of Web Services provided by WSDL and SOAP 1.2 and
      th diagram implies things considerably. The management layer
      is a supervisory layer allowing the conrol of the many agents
      involved in a web services-based operation. The "Application
      semantics" layer indicates the necessity, for any useful
      interoperability, to have
    </p>
    <p>
      <img alt=
      "Stcak based on XML, and HTTP has WSDL and SOAP 1.2 as WS foundation."
      src="diagrams/ws-stack.png" />
    </p>
    <h3>
      Run Time messaging
    </h3>
    <p>
      The design work of web services is divided between the run
      time protocols and the descriptions of services.
    </p>
    <p>
      The W3C work at runtime based on HTTP transport of
      XML-encoded messages, using the SOAP protocol. (Here by SOAP
      we mean SOAP 1.2, previous versions including early
      proprietory submissions which are not standards or guaranteed
      to interoperate) . There is a bifurcation in the design at
      this point, as SOAP operates basically in two modes.
    </p>
    <p>
      In one, the XML message is used to encode the parameters to a
      remote operation in much the same way as remote method
      invokation in for example, Corba, DCOM, or RMI. In this mode,
      XML is used as the marshalling style, but the system is a
      distributed using remote procedure call in a fairly
      traditional way.
    </p>
    <ul>
      <li>There is a standard marshalling syntax
        <p>
          Interfaces between software modules have well-defined
          functions, which in turn have well-defined and typed
          input and output parameters
        </p>
        <p>
          Stubs (dummy routines which similate the remote procedure
          by a local one which communcates with the remote one) can
          be generated directly from the WSDl definition
        </p>
      </li>
      <li>The remoteness can be transparent, making the design of a
      distributed system similar to the design of a program.
      </li>
    </ul>
    <p>
      In the other mode, SOAP carries an XML document, and the task
      of the receiver is seen more as a document processing
      operation. This is less rigid than the RPC style.
    </p>
    <ul>
      <li>The interface a service provides is defined just by the
      XML schema. This defines the acceptable document types, which
      can allwo extension in many ways, using XML namespaces.
        <p>
          The communication is more apparent to the application
          writer, who deals with the document object model (DOM) of
          the recived message, rather than having parameters
          unmkarshalled automatically.
        </p>
        <p>
          XML tools such as XSLT and XML-Query, and XML encryption
          and so on can be used.
        </p>
        <p>
          It is simpler to use message exchange patterns other than
          the request/response.
        </p>
      </li>
    </ul>
    <p>
      The document mode of SOAP seems to be getting the most
      traction in the ecommerce stack. This is not an accident. The
      XML mode is more flexible than the RPC mode. It is easier in
      principle to extend an XML-based message system to include
      more information as a system grows. In fact, RDF is
      especially powerful in this area, as new information can be
      parsed into an entity-relationship form by old agents, and it
      becomes logically clear which parts can be ignored by those
      who do not understand them.
    </p>
    <p>
      Functionality which has been mentioned as required above the
      basic layer at runtime includes:
    </p>
    <ul>
      <li>Routing. Routine data within message for processing bu
      different agents; defining workflow path of message. Black
      box or white box patterns of design.
      </li>
      <li>Security. Prolfiling existing security technologies for
      use in ebusiness applications using web sevices.
      Authentication and key management.
      </li>
      <li>Packaging of attachments to messages. XML Packaging.
      </li>
      <li>Reliable messaging (delivery, non-duplication, ordering)
      for the case in which the transport layer (such as TCP under
      the HTTP) doesnot provide this. (TCP does provide this
      reliability but (a) systems are not designed to keep TCP
      connections open for the weeks or years over which a web
      service may run, and (b) TCP does not provide accountability
      so you can show the tax man the acknowledgement of receipt 7
      years later.)
      </li>
    </ul>
    <h3>
      <a name="Descriptio" id="Descriptio">Description</a>
    </h3>
    <p>
      The descriptions of services are made at various different
      models and different levels of abstraction in different specs
      proposed as part of the stack, though there is agreement on
      WSDL as the modelling of the lowest level, the message or
      request/response interaction, and the binding to the specific
      HTTP (say) port at which it happens.
    </p>
    <p>
      <img alt="Lots of concepts interconnected" src=
      "../2003/Talks/0521-hh-wsa/wsa_concepts.png" />
    </p>
    <p>
      Higher layers in the description above WSDL are known
      variously as coordination, orchestration, choreography,
      composition.
    </p>
    <p>
      They involve (compared with basic WSDL), for example:
    </p>
    <ul>
      <li>Protocols involving more than two messages
      </li>
      <li>Protocols having a common shared state over a long period
      </li>
      <li>Protocols having more than two parties involved; web
      service workflow
        <ul>
          <li>structured version (ws-*, damls process model)
          </li>
          <li>precondition-postcondition style (DAMLS)
          </li>
        </ul>
      </li>
      <li>The protocols as business protocols, in terms of common
      business functions
      </li>
      <li>The relationship between allowed transitions in the
      protocol and the content of messages. For example, the
      requirement for a transaction ID to match across a
      transaction, or for possible responses to be a function of a
      request code.
      </li>
    </ul>
    <h3 id="Choreograp">
      Composability and Choreography
    </h3>
    <p>
      Composability of web services refers to the building, from a
      set of web services, of something at a higher level,
      typically itself exposed as a larger web service.
    </p>
    <p>
      Choreography refers more abstractly the part of the
      description of web services which defines a way, or the ways,
      in which a acyual invokations to various web services work
      together. (Peltz uses <em>Choregraphy</em> when it involves
      multiple parties, and <em>Orchestration</em> when it is
      internal to one party. Thus the former crosses application
      boundaries, the latter also crosses organization boundaries.
      here we use Choregorahy in general for both.)
    </p>
    <p>
      There is so small amount overlap here, which has led to some
      confusion. To be general, one might say, for example, that a
      flight confirmation must involve an already reserved flight.
      This the actual constraint. One can describe a particular
      choregraphy (a particular dance, if you like) in which a
      flight query service is called, and produced a list of
      flights, and then a reservation service is called to reserve
      the flight, that is successful, and the resulting reservation
      is passed to the confirmation service. It may be that there
      are other ways -- other choreographies -- in which one could
      have achived a reserved flight. The engineer has the choice
      of modelling the many possible ways all in one choreogrpahy,
      or of making several choreographies.
    </p>
    <p>
      Web services <em>can</em> be combined in such as way that
      messages are passed around in a very random fashion. However,
      a particular design techniqe is for a master process to
      delegate to other services in a recusive tree-like manner, as
      has been de rigueur in programming languages since Pascal.
      For example, if the consumer asks the travel agent and the
      the travel agent books a hotel, the hotel will reply to the
      travel agent, not to the consumer. This makes everything
      orderly.
    </p>
    <p>
      WSCI, BPML and BEPL take this approach to choreography. This
      is a programming language approach with
    </p>
    <ul>
      <li>Sequential, Parallel and Exception execution, loops &amp;
      conditionals
      </li>
      <li>Message-passing rendezvous between processes
      </li>
      <li>Calls: Web Services
      </li>
      <li>Data: bits of XML
      </li>
      <li>Assignment to variables
      </li>
      <li>Expressions: XPath 1.0 plugable in BPEL
      </li>
      <li>Does not handle actual calculations, rules etc.
      </li>
    </ul>
    <p>
      WSCI has the empahsis on description, and BPEL on being able
      to compile to an executable agent. As neither is intended to
      do the actual calculations or business rules, it would be
      closer to compare themm with scripting shells such as bash
      which handle concurrency and synchronization but actually
      call programs (or rather web services) to do the real work.
    </p>
    <p>
      See:
    </p>
    <ul>
      <li>WS Choreography Group
      </li>
      <li>IBM, Microsoft and BEA, under OASIS, <em>BPL4WS</em> (not
      W3C, not RF).
      </li>
      <li>BPMI, Business Process Modelling Language BPML
      </li>
      <li>Sun et al: <em>Web Services Choreography Interface
      (WSCI),</em> W3C Note
      </li>
      <li>IBM specs ws-coordination, ws-transaction,
      ws-orchestration
        <p>
          Chis Peltz, Hewlett Packard, <em><a href=
          "http://devresource.hp.com/drc/technical_white_papers/WSOrch/WSOrchestration.pdf">
          Web Services Orchestration</a> - a review of emerging
          technologies, tools, and standards.</em>
        </p>
      </li>
    </ul>
    <p>
      @@ Different attitudes - top down program design, or
      bottom-up agent design, bottom up document design.
    </p>
    <h3>
      Message-oriented choregraphy
    </h3>
    <p>
      The <a href="PaperTrail.html">Paper Trail</a> concept is that
      the state of a mult-agent multi-process system can be looked
      at, sometimes rather effectively, as a function of the
      documents which have been transmitted.
    </p>
    <p>
      The process-oriented attitude to a bank-customer relationship
      may be "In parallel, the customer writes checks, merchants
      pay in checks, credit card transactions happen, all month.
      Then, the charges, interest are assessed and a bank statement
      sent from the bank to the customer". The document-, or
      message-oriented one is more like "Every month a bank balance
      lists valid transaction dated that month. A cleared incoming
      check in a valid transaction. A cleared outgoing check is a
      valid transaction. A validated credit card debit is a valid
      transaction. A check is cleared if it is incoming and there
      is a matching transfer from the payee bank", and so on. This
      builds the relationships up in a bottom-up, weblike way. The
      process-oriented attitude suggests the bank be written as a
      procedure in a top-down way using for example WSCI and BPL.
      The document-oriented attitude suggests the use of business
      rules systems triggered by the receipt of new information --
      new documents, in this case new web services messages.
    </p>
    <p>
      (Web service messages are of course documents just like
      documents sent in email. Messages are particular in that they
      have a particular time of transmission, and their document
      content sdo not change. They do of course generally have
      identifiers, and even though they can only be accessed by
      sender and explicit receivers, they can still be regarded as
      part of the web by those parties.)
    </p>
    <p>
      Whether the design process is a top-down process-oriented one
      or a bottom-up document-oriented one, the design will have to
      be translated into a set of agents and their responses to
      incoming messages. This manipulation can of course be done
      automatically.
    </p>
    <p>
      A concern in all this frantic design is it evolution with
      time. A BPEL script sets out to be a description of a a
      business process at a high level. The critical values which
      decide on conditional execution, or which correlate a
      particular process with a given transaction, are expressed as
      parts of the structure of the XML messages. This may lead to
      what has been called "DTD fragility". What happens which you
      change the DTD? The design of the message types with XML
      schema is the sort of thing which is difficult to get
      everyone in a company to agree on, and tents to change with
      time. There are many arbitrary choices made as to how the
      knowledge in the message is serialized as XML. Moving to RDF
      may, by removing a layer of arbitrary design, reduce that
      fragility and allow web sevice choregraphy to evolve with
      time within and outside a company.
    </p>
    <h3>
      <a name="Process" id="Process">Process modeling</a>
    </h3>
    <p>
      When considering a business system with multiple agents and
      multiple concurrent processes, one would like to have an
      automated way of checking some fundamental questions.
    </p>
    <ul>
      <li>Will the process necessarily terminate?
      </li>
      <li>Will the service respond within a given time?
      </li>
      <li>Will the net gain from a sale always be positive?
      </li>
      <li>Will we ever promise to ship something we do not have in
      stock?
      </li>
    </ul>
    <p>
      and so on.
    </p>
    <p>
      The pi calculus and other calculi derived from it are formal
      ways of modeling systems with multiple agents and multiple
      processes. They can do some way to answering these questions.
      Rule-based systems can also be designed so that proofs can be
      found of these sort of conjecture. This is a good reason for
      keeping the languages involved as simple as possible It may
      be the design reason for the limitations on computational
      power in WSCI and BPEL.
    </p>
    <p>
      See petri nets (IBM; and stadford), Pi calculus @@ refs.
    </p>
    <p>
      Much of the functionality is seen in terms of tying web
      services down to well-known functionality such as exiting
      transaction processing systems, PKI trust infrastructure, and
      so on.
    </p>
    <h3>
      <a name="Discovery" id="Discovery">Discovery</a>
    </h3>
    <p>
      In a large number of applications, web servcies will be
      provided by on one hand and used by on the other peers who
      have established relationships. Indeed, until a trust
      infrastructure is fairly developed it is not reasonable to
      expect computers to do automatic comparison shopping for very
      many services. Web services will probably (like the web in
      1993, and the Semantic Web in 2003) spread first within the
      corporate firewall, where security problems are minor and
      mistakes less embarassing than inter-enterprise or
      publically. However, the goal is that so many web services
      should be available that it will be important to be able to
      find them in all kinds of ways.
    </p>
    <p>
      The UDDI project and the related work on description and
      query systems is aimed at this. A positive aspect of UDDI is
      the definition of an ontology for web services. Problems with
      it are that it is centralized by design, both in the
      single-tree ontology, and in the design based fundamentally
      on a central registry, with inter-registry operation as a
      secondary thing.
    </p>
    <p>
      From the semantic web point of view, web services are simply
      one aspect of the many things which will be searched for.
      Indeed, the fact that a web service is provided may in fact
      be rather incidental to the essential nature of the business
      item which is discovered -- a trader in stocks, a seller of
      lawnmowers, and so on. The semantic web aims to describe any
      aspect of anything, including the catalogs, parts, materials,
      services organization, relationships and contracts. A query
      system which addresses web services only makes sense when
      smoothly integrated with the rest of the web of enterprise
      knowledge.
    </p>
    <h3>
      <a name="Services" id="Services">Web Services and Semantic
      Web</a>
    </h3>
    <p>
      The question of the relationship between these two activities
      is constantly in the air.
    </p>
    <ul>
      <li>The whole description side is a clear semantic web
      application, and so long as XML languages are defined which
      introduced with english language specs but no RDF mapping,
      there is a potential ambiguity which will have to be resolved
      later in making that mapping, there is an inability to use
      common semnatic web tools, and there is cost down the road
      assuming semantci web tools will eventually be used.
      Essentailly, web serv ices become instant legacy technoplogy
      for the semantic web.
      </li>
      <li>The DAML-services collalition of researchers is tackling
      the job of service description at a higher level.
      </li>
      <li>Many things which are described as web services can in
      fact be described as the publication of a series of semantic
      web documents, just as the billing of a peer company is in
      reality effected by the issuance of an invoice.
      </li>
      <li>When Semantic Web agents query each other, they could use
      SOAP (though a direct encoding into an HTTP URI may also be
      effective).
      </li>
      <li>When Semantic Web agents update each other, they should
      use SOAP, running typically over HTTP POST.
      </li>
    </ul>
    <p>
      The argument against integration of the technologies is
      mainly social. It is costly to coordinate very large groups.
      It is much more effcient to develop WS and SW independently.
      Neither side has a great incentive to take on the learning
      required to absorb the needs and potentials fo the other.
      Using technology in preparation by another group takes a
      great leap of faith, and does really add to the development
      time. These are real issues. So while it may take more effort
      in the long run, it is a better parallelization of the design
      task to allow web services and semantic web to proceed in
      together without a mandated link. (This was the apparent
      consesnsus of the W3C AC meeting in Nice, 2000/11)
    </p>
    <p>
      That said, wherever overlap of expertise between the
      technologies occurs, those who form a bridge should do their
      best to make the conceptual differences as small as possble.
      There is a Semantic Web Services group, connected to the
      ______
    </p>
    <h3>
      Service design tools
    </h3>
    <p>
      Most modern software design differentiates strongly between
      the design of an interface, and the design of the software
      which implements it.
    </p>
    <p>
      Web services are required to be composable - you should be
      able to make a web service implmentation by building it out
      of component web services. At the low level, think of making
      a latittude/longitude to state code converter composed from a
      latittude/longitude to postal code converter and a postal
      code to state code converter. At a high level, think of a
      making a vacation being composed of resrvations of flights,
      hotels and entertainment.
    </p>
    <h3>
      Runtime System management
    </h3>
    <p>
      Real web services have multiple agents running commerical
      environments, in which downtime is expensive, and incorrect
      operation could be disasterous. The running, monitoring,
      provisioning and upgrading of such systems clearly requires
      tools, but their design is out of scope for this overview.
    </p>
    <hr />
    <h2>
      <a name="References" id="References">References, Fodder</a>
    </h2>
    <ul>
      <li>Hugo Hass, <a href="../2003/03/ws-specs.html">List of Web
      Services Specifications.</a> This lists the specs from
      various sources in the web services area.
      </li>
    </ul>
    <ul>
      <li>W3C Web Servicess Workshop procedings. These position
      papers were an early exposition of web services plans.
      </li>
      <li>
        <a href="http://www.w3.org/2002/ws/">W3C WSeb Services
        Activity</a> - all groups and documents, but
        specifically:roups therein.
      </li>
      <li>
        <a href="http://www.w3.org/2002/ws/arch/">W3C Web Services
        Architectrue Working Group</a>
      </li>
      <li>White papers
      </li>
    </ul>
    <p>
      http://www.bpmi.org/
    </p>
    <p>
      web ser vices orchestrationa review of emerging technologies,
      tools, andstandards,
      http://devresource.hp.com/drc/technical_white_papers/WSOrch/WSOrchestration.pdf
    </p>
    <p>
      Related activites elsewhere
    </p>
    <ul>
      <li>Rosettanet, UDDI, various Oasis activties.
      </li>
    </ul>
    <p>
      RPC history
    </p>
    <ul>
      <li>Sun/RPC, Apollo domain, DCOM, OMG's Corba, XML/RPC
      </li>
    </ul>
    <p>
      See: @@@ <a href="../2003/03/ws-specs.html">Web Services
      Specs</a>
    </p>
    <h3>
      From W3c Web Services Workshop
    </h3>
    <p>
      IBM, Microsoft: "<a href="../2001/03/WSWS-popa/paper51">Web
      Services Framework</a>"
    </p>
    <p>
      http://www.w3.org/2001/03/WSWS-popa/paper51
    </p>
    <h3>
      Other white papers
    </h3>
    <p>
      @@ HP's ESpeak papers - Web Services roots
    </p>
    <p>
      From IBM:
    </p>
    <p>
      http://www-106.ibm.com/developerworks/library/w-ovr/
    </p>
    <p>
      From Microsoft:
    </p>
    <p>
      http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglo
      bspec/html/ws-securitypolicy.asp
    </p>
    <p>
      http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-trust.asp?frame=true
    </p>
    <p>
      http://msdn.microsoft.com/webservices/understanding/whatsnext/default.aspx
    </p>
    <h3>
      Fodder
    </h3>
    <p>
      @@@@@
    </p>
    <p>
      BPSS From FAQ: Q. What is the relationship between WSCI and
      ebXML BPSS? A. There is no direct relationship between BPSS
      and WSCI. They are used for different purposes and have
      different design centers. BPSS is used for defining the
      semantics of commercial collaboration between businesses. Its
      design center is the commercial transactions between two
      business partners, and as such it provides full commercial
      semantics, and is designed to work in with conjunction with
      the ebXML Collaboration Partner Profile/Agreement (CPP/CPA).
      In contrast, WSCI is used for describing a Web service and
      the operations performed by that Web service. Its design
      center is the WSDL service definition, and it describes the
      relationship between multiple WSDL operations that are
      performed by a given Web service. Because WSCI is generic to
      all Web services, it does not provide any explicit commercial
      semantics, nor does it have any notion of a trading
      collaboration partner agreement. ]]] -- <a href=
      "http://wwws.sun.com/software/xml/developers/wsci/faq.html">http://wwws.sun.com/software/xml/developers/wsci/faq.html</a>
    </p>
    <p>
      @@ concept diagram
    </p>
    <p>
      Other areas one can contemplate include:
    </p>
    <ul>
      <li>Constraints on the semantics of the messages as opposed
      to merely their syntax
      </li>
      <li>Trust structures
      </li>
      <li>What sort of a service this is
        <ul>
          <li>classification of things bought and sold etc
          </li>
        </ul>
      </li>
    </ul>
    <hr />
    <p>
      <a href="Overview.html">Up to Design Issues</a>
    </p>
    <p>
      <a href="../People/Berners-Lee">Tim BL</a>
    </p>
  </body>
</html>