Web Services Infrastructure and Organizations

1
Web Services Infrastructure and Organizations
2
Overview of Web Services Infrastructure and Models
3
Overview

• The World Wide Web (WWW)
• Using textual data and graphics
• Web services help applications to interact
  directly with one another and execute
  instructions automatically

4
Introduction to Web Services

• Consider an e-business transaction.
• The transaction appears to be simple, but
  multiple applications are operating in the
  background
• Web services are web-based applications that
  integrate and interconnect with other
  applications to transfer large amount of data
  economically and efficiently across the world.

5
What is Web Services?

• Web services are web-based enterprise
  applications that use open, eXtensible Markup
  Language (XML)
• Web services can access Internet applications,
  such as e-business and banking transaction
  systems
• Multiple applications are sometimes incompatible
  because the applications are portable on
  different operating systems and are developed
  using different languages, databases, and
  middleware technologies

6
Web Services Infrastructure

• XML provides a way to represent data that is
  language-neutral. The development of XML forms
  the foundation for the web services
  infrastructure. The infrastructure establishes a
  structure in which decentralized web services can
  be centrally defined, deployed, and manipulated.
  The infrastructure also enumerates a list of
  components that form the functional basis of the
  web services infrastructure.

7
Entities Used in Web Services Infrastructure

• Web services infrastructure specify the role of
  three basic entities that participate in a web
  services transaction
• service providers,
• service registries,
• service requesters.

8
Entities Used in Web Services Infrastructure
(continued)

• Description enables a service requester to
  discover and use the service by specifying the
  following information
• Data types used by the service
• Operations performed by the service
• Binding information to establish a connection
  with the service
• Location of the service on the network

9
Functional Components of Web Services
Infrastructure

• Functional components form the implementational
  basis of web services infrastructure. A series of
  functional components have been listed by the web
  services infrastructure. However, all of these
  components have not been deployed. Work is still
  on-going for components, such as message
  exchange, correlation, guaranteed message
  exchange, transactions and activities, process
  flow and contract description, and inspection.

10
Functional Components of Web Services
Infrastructure (continued)

• The following functional components are used in a
  web service transaction
• Message envelope
• Binary attachments
• Digital signature
• Encryption
• Service description
• Discovery

11
Web Services Model (WS Model)

• The WS model provides interoperability between
  different systems through standardization of
  communication protocols and data formats. As a
  result, business services can be distributed over
  the Internet and made accessible from different
  types of communication devices.
• The WS model derives its operational and
  functional characteristics from the web services
  frameworks. This model is promoted by
  organizations such as IBM, Microsoft, and Sun
  Microsystems under the W3C initiative.

12
Uses of the WS Model

• The WS model
• Helps organizations to easily engage with their
  customers, partners, and employees
• Enables organizations to extend their existing
  services to new customers
• Helps organizations to work more efficiently with
  their partners and suppliers
• Helps reduce development time and cost of
  developing new projects

13
Specifications in the WS Model

• To make the Internet a global common platform
  where organizations and individuals can
  communicate with each other and facilitate
  commercial transactions, web services require
  technologies built around various specifications.
  These specifications include Simple Object Access
  Protocol (SOAP), Web Service Definition Language
  (WSDL), and UDDI.
• SOAP enables messaging, WSDL provides service
  description, and UDDI maintains the service
  registry or repository.

14
SOAP

• SOAP was developed in 1999 as an extension of the
  XML-RPC specification. SOAP is a message layout
  specification that uses XML for exchanging
  information in a decentralized and distributed
  environment. SOAP is a platform- and
  language-independent protocol that allows
  applications to communicate with each other over
  the Internet. SOAP provides a simple messaging
  framework that is easy to develop and independent
  of any platform, operating system, and
  programming language.
• SOAP enables transfer of XML documents over a
  variety of standard Internet protocols, including
  Simple Mail Transfer Protocol (SMTP), HTTP, and
  File Transfer Protocol (FTP), by specifying a
  standard packaging structure. It also specifies
  encoding and binding standards for transfer of
  non-XML RPC invocations in XML. SOAP provides a
  simple structure for document exchange in RPC.
  Diverse clients and servers can become
  interoperable because of a standard transport
  mechanism.

15
SOAP (continued)

• To provide a basic, common XML messaging protocol
  for the web, the SOAP specification defines
• The start and end of an envelope that encloses
  the XML document to be transported
• The method by which optional headers are
  represented for additional information
• The method that serializes data-type encodings
  with specific support for RPC-style interactions
• A binding to HTTP to ensure that it carries the
  document correctly to its destination and that
  the destination directs the message to an
  appropriate SOAP processor

16
WSDL

• WSDL provides a standard for describing the
  interface of a web service using XML. WSDL was
  developed primarily by Microsoft and IBM. It was
  later submitted to the W3C. As the number of
  communication formats and protocols used on the
  Internet continues to increase, finding a
  standard way for two machines to communicate with
  each other has become essential. WSDL describes
  the function and location of a web service. The
  design of WSDL allows it to be used with both
  procedure- and document-oriented interactions,
  such as a client server request or the storage
  and retrieval of a file.

17
WSDL (continued)

• WSDL standarizes
• Representation of the input and output parameters
  of an external invocation
• Structure of the function
• Nature of the invocation
• The service's protocol binding
• WSDL enables different clients to interact with a
  web service.
• WSDL includes definitions of parameters and
  constraints for how communication between
  different components should occur at runtime.

18
UDDI

• UDDI is a set of standards that provides a
  mechanism for deploying and locating web
  services. It helps organizations and individuals
  to dynamically look up and discover services
  provided by external business organizations. A
  UDDI registry has two types of clients
• Clients who want to deploy and publish service
  descriptions
• Clients who want to obtain these service
  descriptions deployed and published by other
  clients

19
UDDI (continued)

• UDDI resembles a city directory that contains the
  addresses and descriptions of the entries of the
  individuals and organizations. UDDI contains
  three levels of detail regarding the services.
  The first level or white pages provides
  information such as its address, a description,
  and contact information. The second level or
  yellow pages of the UDDI include a list of
  business services that contains a description of
  the services and a list of categories that
  describes these services. The green pages or the
  third level of UDDI consist of one or more
  binding templates that provide additional
  technical information about a web service.

20
Java EE 5 Web Services APIs

• Many different APIs are available in Java EE 5
  Web Services APIs. Each API serves a definite
  purpose to integrate Java server-based
  functionality into web services. Java EE 5 Web
  Services APIs include
• JAX-WS
• JAXB
• XWSS
• SAAJ

21
Overview of W3C

• The World Wide Web Consortium (W3C) is an
  international consortium formed in 1994 to create
  a set of standards for all organizations
  developing web technologies. W3C aims for
  complete interoperability of web software and
  hardware by publishing open, non-proprietary
  standards for web languages and protocols.

22
Goals of W3C

• W3C has the following goals
• Web for all Make the web accessible to all
  users despite their differences in culture,
  language, education, material resources, access
  devices, and physical limitations
• Web on everything Make the web easily
  accessible from any type of device
• Knowledge base Develop a web that acts as a
  vast database of human and machine processing
  information
• Trust and confidence Promote technologies that
  build a web environment where security,
  confidence, accountability, and confidentiality
  are ensured

23
Principles of Designing for the World Wide Web

• W3C recommends the use of the following
  fundamental principles while designing web
  applications
• Interoperability Developers should use language
  and protocol specifications that ensure
  interoperability of hardware and software on the
  web.
• Evolution The web must be able to accommodate
  future technologies. To make the web work with
  emerging technologies, developers should use the
  design principles of simplicity, modularity, and
  extensibility.

24
Principles of Designing for the World Wide Web
(continued)

• Decentralization The web must be designed in
  such a way that the web architecture does not
  depend on any central registry. This allows the
  web to decrease traffic and errors, and scale to
  worldwide proportions.
• Accessibility The web must be designed so that
  people with disabilities are able to understand,
  navigate, and interact with it. They should also
  be able to contribute to the web. For example,
  the browser should be made accessible from a
  keyboard for the people who are blind. Also,
  there should be support for screen reader
  technology, which interprets screen content and
  directs it to either a speech synthesizer or a
  refreshable Braille device for the blind.

25
W3C Activities

• W3C has work groups tasked with the following
  initiatives
• Making the web accessible to people with
  disabilities
• Developing and extending XML
• Defining mathematics and graphics standards
• Developing new HTML and style standards
• Developing standards for synchronized multimedia
• Supporting web access from different devices
• Standardizing and internationalizing web services
• Developing rich web clients
• Developing tools for XML key management

26
Web Services Enabling Technologies
27
SOAP Overview

• The Simple Object Access Protocol (SOAP) is used
  by heterogeneous applications to exchange
  messages. In addition to simple eXtensible Markup
  Language (XML)-based messages, SOAP can also
  transport additional data or payload. This
  inter-application communication in a distributed
  environment takes place over transport protocols,
  such as the Simple Mail Transport Protocol (SMTP)
  and the Hypertext Transfer Protocol (HTTP).

28
SOAP

• Remote Procedure Calls (RPCs) were used to
  communicate between distributed applications.
• SOAP was developed to enable distributed
  applications to communicate over the Internet.
• SOAP is an XML-based protocol. It is language-
  and platform-independent and, therefore, enables
  applications to exchange messages.

29
SOAP Message

• A SOAP message is a well-formed XML document
  that contains the following primary elements
• Envelope
• Header
• Body

• lt?xml version"1.0"?gt
• ltEnvelopegt
• ltHeadergt
• ...
• ...
• lt/Headergt
• ltBodygt
• ...
• ...
• ltFaultgt
• ...
• ...
• lt/Faultgt
• lt/Bodygt
• lt/Envelopegt

30
The Envelope Element

• The Envelope element is mandatory and is the root
  element.
• The Envelope element must always be associated
  with the http//www.w3.org/2001/12/soap-envelope
  namespaceURI.

• lt?xml version"1.0"?gt
• ltEnvelope xmlnssoap"http//www.w3.org/2001/12/so
  ap-envelope" encodingStyle"http//www.w3.org/2001
  /12/soap-encoding"gt
• ltHeadergt
• ...
• ...
• lt/Headergt
• ltBodygt
• ...
• ...
• ltFaultgt
• ...
• ...
• lt/Faultgt
• lt/Bodygt
• lt/Envelopegt

31
The encodingStyle Atrribute

• The encodingStyle attribute specifies the rules
  that define how data is represented in a SOAP
  message.
• where the SOAP specification suggests that the
  namespaceURI should be http//www.w3.org/2001/12/s
  oap-encoding. This namespaceURI points to the XML
  schema that defines the encoding rules for a SOAP
  message.

• lt?xml version"1.0"?gt
• ltEnvelope xmlnssoap"http//www.w3.org/2001/12/so
  ap-envelope" encodingStyle"http//www.w3.org/2001
  /12/soap-encoding"gt
• ltHeadergt
• ...
• ...
• lt/Headergt
• ltBodygt
• ...
• ...
• ltFaultgt
• ...
• ...
• lt/Faultgt
• lt/Bodygt
• lt/Envelopegt

32
The Header Element

• The Header element is optional and contains
  header information.
• The Header element must be the first child
  element of the Envelope element.
• The child elements of the Header element must be
  namespace-qualified.
• In the code example, Trans is a child element of
  the Header element and http//www.school.com/trans
  action/ is the namespaceURI.

• lt?xml version"1.0"?gt
• ltEnvelope
• xmlnssoap"http//www.w3.org/2001/12/soap-envelop
  e"
• encodingStyle"http//www.w3.org/2001/12/soap-enco
  ding"gt
• ltHeadergt
• ltmTrans
• xmlnsm"http//www.school.com/transaction/"gt
• lt/mTransgt
• lt/Headergt
• ltBodygt
• ...
• ltFaultgt
• ...
• lt/Faultgt
• lt/Bodygt
• lt/Envelopegt

33
The actor Attribute

• lt?xml version"1.0"?gt
• ltEnvelope
• xmlnssoap"http//www.w3.org/2001/12/soap-envelop
  e"
• encodingStyle"http//www.w3.org/2001/12/soap-enco
  ding"gt
• ltHeadergt
• ltmTrans
• xmlnsm"http//www.school.com/transaction/"
  soapactor"http//www.school.com/stock/"gt
• lt/mTransgt
• lt/Headergt
• ltBodygt
• ...
• ltFaultgt
• ...
• lt/Faultgt
• lt/Bodygt
• lt/Envelopegt

• The actor attribute is used to direct a header
  block to a particular endpoint.
• The actor attribute, if not specified, indicates
  that the message is intended for the final
  recipient.
• The syntax for the actor attribute is
  actor"namespaceURI
• In the code example, the actor attribute is used
  in the Header element. The path name
  http//www.school.com/stock/ is the namespaceURI
  that indicates the endpoint.

34
The mustUnderstand Attribute

• lt?xml version"1.0"?gt
• ltEnvelope
• xmlnssoap"http//www.w3.org/2001/12/soap-envelop
  e" encodingStyle"http//www.w3.org/2001/12/soap-e
  ncoding"gt
• ltHeadergt
• ltmTrans
• xmlnsm"http//www.school.com/transaction/"
  actor"http//www.school.com/stock/"
• soapmustUnderstand"1"gt
• lt/mTransgt
• lt/Headergt
• ltBodygt
• ...
• ltFaultgt
• ...
• lt/Faultgt
• lt/Bodygt
• lt/Envelopegt

• The mustUnderstand attribute indicates whether
  the recipient must process the header block.
• The recipient is indicated by the actor element.
• The syntax for mustUnderstand is
  soapmustUnderstand"01"
• where 1 or true indicates that it is mandatory
  for the receiver to recognize and process the
  element. Elements not annotated with the
  mustUnderstand attribute, or those that contain a
  value of 0 or false, are optional and need not be
  processed.

35
The Body Element

• lt?xml version"1.0"?gt
• ltEnvelope
• xmlnssoap"http//www.w3.org/2001/12/soap-envelop
  e" encodingStyle"http//www.w3.org/2001/12/soap-e
  ncoding"gt
• ltHeadergt
• ltmTrans
• xmlnsm"http//www.school.com/transaction/"gt
• lt/mTransgt
• lt/Headergt
• ltBodygt
• ltmgetBook
• xmlnsm"http//www.school.com/books"gt
• ltmItemgt
• Pride and Prejudice
• lt/mItemgt
• lt/mgetBookgt
• lt/Bodygt
• lt/Envelopegt

• The Body element is mandatory and contains the
  message payload.
• A SOAP message can have only one Body element.
• The Body element can contain an XML document
  fragment as its child element, which might be
  namespace-qualified.
• The Body element can contain a Fault element.
• The Body element must be an immediate child
  element of the Envelope element or follow the
  Header element, if the Header element is present.

36
Transmitting Binary Data

• A SOAP message can carry binary data. The binary
  data is packaged with the SOAP message.
• The packaged data is sent as a single stream over
  transport protocols, such as HTTP, SMTP, or the
  File Transfer Protocol (FTP).
• The SOAP Messages with Attachments (SwA)
  specification is an abstract model that provides
  the basis for packaging attachments with a SOAP
  message.
• The SwA specification is designed as a compound
  document structure that consists of a primary
  SOAP message part and zero or more secondary
  attachment parts.
• The SwA specification is primarily implemented
  through Multipurpose Internet Mail Extension
  (MIME) and Direct Internet Message Encapsulation
  (DIME).

37
Extensibility Feature in SOAP

• SOAP is an extensible protocol because it can be
  layered with additional functionalities.
• SOAP provides extensibility through
• Message handlers
• Messaging styles
• Encoding styles
• Protocol bindings

38
Message Handlers in Web Services

• SOAP message traverses between a sender and a
  receiver along the message path.
• SOAP header blocks can be intercepted and
  processed by message handlers.
• SOAP message handlers enable intermediate
  processing and help extend functionalities.

39
Message Handlers in Web Services (continued)

• The SOAP message handlers are defined in the
  webservices.xml deployment descriptor file, which
  is stored at the web service endpoint.
• A group of handlers form a handler chain.
• The handler contains a method for a SOAP request
  and response.
• The handlers intercept either the SOAP request or
  response message between the client and the
  server and process SOAP header blocks.

40
Encoding Styles in SOAP

• SOAP messages are extensible because they support
  a variety of data types.
• Simple data types, such as string, integer, and
  boolean, can be directly or literally
  represented.
• Complex data types require an algorithm to
  determine how the data types are represented in
  an XML format.
• SOAP supports Section 5 encoding or SOAP encoding
  and literal encoding styles.

41
Type Systems Used by SOAP Encoding Struct

• struct AllStudent
• string sRegNum
• string sFirstName
• string sLastName
• int nAge
• AllStudent student "A108, "Rob", "Jenkins",
  14

• ltstudent xsitype"xAllStudent"gt
• ltsRegNum xsitype"xsdstring"gt
• A108
• lt/sRegNumgt
• ltsFirstName xsitype"xsdstring"gt
• Rob
• lt/sFirstNamegt
• ltsLastName xsitype"xsdstring"gt
• Jenkins
• lt/sLastNamegt
• ltnAge xsitype"xsdinteger"gt
• 14
• lt/nAgegt
• lt/studentgt

42
Simple and Compound Types Array

• An array is a compound type.
• An array uses ordinal positions to refer to its
  parts.
• The array type is indicated by the xsitype
  attribute.
• The namespace associated with an array type is
  http//schemas.xmlsoap.org/soap/encoding.

• ltnumbers xsitype"SOAP-ENCArray"
  SOAP-ENCarrayType"xsdinteger5"gt
• ltitemgt1lt/itemgt
• ltitemgt2lt/itemgt
• ltitemgt3lt/itemgt
• ltitemgt4lt/itemgt
• ltitemgt5lt/itemgt
• lt/numbersgt

43
SOAP Over SMTP, HTTP, and FTP

• SMTP can carry a SOAP message that is packaged in
  a MIME structure.
• HTTP is another protocol that is used for
  transporting SOAP messages.
• FTP provides secure messaging because access to
  FTP servers are authenticated.

44
WSDL Overview

• Hosting a web service alone will not help you
  realize its full potential. You need to describe
  your web service. The Web Service Definition
  Language (WSDL) uses XML schema, to organize such
  information in the form of a WSDL document. You
  can further use a WSDL document to create a web
  service client and server.

45
WSDL

• Web services need to be described in a standard
  format.
• WSDL provides the language for describing web
  services.
• The latest version of WSDL is available at
  http//www.w3.org/TR/wsdl.
• WSDL defines various components, such as
  operations, data types, and protocols that can be
  reused to describe web services in a WSDL
  document.
• A WSDL document specifies the location of a web
  service and the operations the web service
  exposes.
• A WSDL document represents the external interface
  of a web service.

46
WSDL Document Structure

• A WSDL document uses elements to describe the web
  services. The root element of a WSDL document is
  definitions.
• The syntax for the definitions element is
• ltdefinitions namedefinitionName
  targetNamespace"NamespaceURI"gt
• where definitionName is the name of the WSDL
  document and NamespaceURI is the value for the
  targetNamespace attribute. The targetNamespace
  attribute specifies the namespace for the names
  declared within the definitions element. The
  default namespace is http//www.w3.org/2006/01/wsd
  l.
• In the code example, SchoolLibrary is the name of
  the WSDL document and http//www.school.com/Librar
  y.wsdl is the namespace.

• ltdefinitions nameSchoolLibrary
• targetNamespace"http//www.school.com/Library.wsd
  l"gt
• ltxmlnsxsd"http//www.w3.org/2001/XMLSchema"gt
• ltmessagegt
• ...
• lt/messagegt
• ltinterfacegt
• ...
• lt/interfacegt
• ltservicegt
• ...
• lt/servicegt
• ltbindinggt
• ...
• lt/bindinggt
• lt/definitionsgt

47
Abstract Interface Definition

• The abstract interface definition provides a
  generic description of the web services
  interface. The definition is derived from the
  following elements
• An interface element interacts with a web
  service, which is a collection of web services
  operations.
• An operation element represents a web service
  function that needs to interact with multiple
  input and output messages.
• A message element represents a unit of data that
  is exchanged in an operation and is represented
  by the part child element.
• A type element specifies the data types used in a
  message.

48
Abstract Interface Definition message Element

• A unit of data exchanged during an operation is
  called a message.
• A message can be specified by using the message
  element.
• A message can contain one or more input or output
  parameters, which are defined in the part child
  element.

• ltdefinitions nameSchoolLibrary
• targetNamespace"http//www.school.com/Library.wsd
  l"gt ltxmlnsxsd"http//www.w3.org/2001/XMLSchema"gt
  
• ltmessage name"getBookRequest"gt
• ltpart name"Title" type"xsdstring"/gt
• lt/messagegt
• ltmessage name"getBookResponse"gt
• ltpart name"return" type"xsdstring"/gt
• lt/messagegt

49
Abstract Interface Definition operation Element

• An operation is an interaction between a web
  service consumer and provider.
• An operation is described in an operation element
  and consists of a set of input and output
  messages.
• The input and output messages are specified using
  the input and output child elements of the
  operation element.
• where OperationName is the name of the operation
  and inputMsg and outputMsg are values for the
  message attribute.
• In the code example, getBook is the name of the
  operation. The values getBookRequest and
  getBookResponse are names defined in the message
  element.

50
Abstract Interface Definition interface Element

• The interface element defines the communication
  pattern for a message.
• The communication pattern is made up of a
  collection of logically related operations that
  are defined in the operation element.
• The syntax for the interface element is
• ltinterface nameInterfaceNamegt
• where InterfaceName is the name of the port or
  interface.
• In the code example, LibInterface is the name of
  the interface.

• ltdefinitions nameSchoolLibrary
• targetNamespace"http//www.school.com/Library.wsd
  l"gt ltxmlnsxsd"http//www.w3.org/2001/XMLSchema"gt
  
• ltinterface nameLibInterfacegt
• ...
• lt/interfacegt
• lt/definitionsgt

51
Concrete Implementation Definition

• The concrete implementation definition specifies
  implementation details.
• A concrete implementation definition is derived
  from the following elements
• A service element contains a collection of
  endpoints.
• An endpoint element contains data, such as the
  physical address and protocol information.
• The endpoints then bind to the underlying
  operation using the bind element.

52
Concrete Implementation Definition binding
Element

• The binding element describes the format and
  transport protocol for each message in an
  operation defined in the interface element.
• The binding element corresponds to the interface
  element.
• where the name attribute specifies the binding
  name and the type attribute points to the
  interface being bound. In the operation element,
  name specifies the operation name.
• In the code example, LibBinding is the binding
  name and LibInterface refers to the interface
  being bound.

53
Concrete Implementation Definition service
Element

• The service element describes the network
  endpoints that deliver the web services.
• The endpoints can be defined by using the
  endpoint child element, which specifies the
  network address to bind the web service.
• The binding can be specified by using the binding
  attribute of the endpoint child element.
• where ServiceName is the name of the service and
  PortName is the name of the endpoint. The
  BindingName refers to the binding name defined in
  the name attribute of the binding element.
• In the code snippet, LibService is the service
  name and LibServicePort is the endpoint name. The
  LibBinding refers to the binding name defined in
  the name attribute of the binding element. The
  soapaddress element within the port states that
  the specified port receives SOAP messages
  directed to the URL http//localhost8088/school/B
  ooks/.

54
Binding SOAP to WSDL

• ltdefinitions name"SchoolLibrary"
• targetNamespace"http//www.school.com/Library.wsd
  l"gt
• ltxmlnsxsd"http//www.w3.org/2001/XMLSchema"gt
• ltmessage name"getBookRequest"gt
• ltpart name"Title" type"xsdstring"/gt
• lt/messagegt
• ltmessage name"getBookResponse"gt
• ltpart name"return" type"xsdstring"/gt
• lt/messagegt
• ltinterface nameLibInterfacegt
• ltoperation name"getBook"gt
• ltinput message"getBookRequest"/gt
• ltoutput message"getBookResponse"/gt
• lt/operationgt
• lt/interfacegt

• SOAP messages need to be bound to a WSDL document
  by including the soapbinding element within the
  WSDL binding element.
• The soapbinding element takes two attributes,
  transport and style.
• The syntax to include the soapbinding element
  within the WSDL binding element is
• ltbinding name"BindingName" type"InterfaceName"gt
• ltsoapbinding transport "http//schemas.xmlsoap.o
  rg/soap/http"
• style"rpcdocument"/gt
• ...
• lt/bindinggt
• where the transport attribute indicates the
  transport protocol, such as HTTP or SMTP, and the
  style attribute specifies the format of the
  message.
• In the code snippet, http//schemas.xmlsoap.org/so
  ap/http indicates that the transport protocol is
  HTTP and the format of the message is RPC.

55
Encoding

• ltdefinitions name"SchoolLibrary"
• targetNamespace"http//www.school.com/Library.wsd
  l"gt
• ltxmlnsxsd"http//www.w3.org/2001/XMLSchema"gt
• ltbinding name"LibBinding" type"LibInterface"gt
• ltsoapbinding
• transport"http//schemas.xmlsoap.org/soap/htt
  p"
• style"rpc"/gt
• ltoperation name"getBook"gt
• ltsoapoperation soapAction"getBook"/gt
• ltinputgt
• ltsoapbody encodingStyle
• "http//schemas.xmlsoap.org/soap/enoding/"
• use"encoded"/gt
• lt/inputgt
• ltoutputgt
• ltsoapbody encodingStyle
• "http//schemas.xmlsoap.org/soap/encoding/"
• use"encoded"/gt

• After binding has been specified, you need to
  determine how a SOAP message will be encoded
  within a WSDL document.
• The use attribute in the WSDL document defines
  the encoding style and can contain either of the
  two values, encoded or literal
• If the value of use is encoded, it specifies that
  encoding will follow the rules defined in the
  SOAP 1.1 specification.
• If the value of use is literal, it indicates that
  the rules to encode the message parts are
  specified by an XML schema.
• This combination of binding and encoding produces
  the following modes of messaging
• RPC/encoded
• RPC/literal
• Document/encoded
• Document/literal
• Document/literal wrapped

56
Creating Web Service Endpoints and Clients

• Two approaches can be used to develop web service
  endpoints and clients implementation-first and
  WSDL-first.
• In the implementation-first approach, you start
  with an endpoint and generate the WSDL document
  and skeletons from it.
• In the WSDL-first approach, you can begin by
  first generating the server-side skeletons from
  the WSDL document. After the skeletons have been
  developed, you can generate the stubs.

57
Tools for Creating Web Service Endpoints and
Clients

• The Java API for XML-based Remote Procedure Call
  (JAX-RPC) implementation provides tools to
  generate server-side skeletons and client-side
  stubs from a WSDL document. Some of the tools
  include
• WSDL2Java It is a tool provided by Axis to
  generate web service clients from a WSDL
  document. The tool can be used to create stubs,
  skeletons, and data types from a WSDL document.
• wscompile It is a tool provided by the Sun
  JavaTM System Application Server (Application
  Server), which generates Java classes for the
  stubs during compile time.
• And many others