(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2007/0067421 A1
`Angelov
`(43) Pub. Date:
`Mar. 22, 2007
`
`US 2007 OO67421A1
`
`(54) SYSTEM AND METHOD FOR DYNAMIC
`WEB SERVICES DESCRIPTOR
`GENERATION USING TEMPLATES
`
`(76) Inventor: Dimitar V. Angelov, Montana (BG)
`Correspondence Address:
`BLAKELY SOKOLOFFTAYLOR & ZAFMAN
`124OO WILSHIRE BOULEVARD
`SEVENTH FLOOR
`LOS ANGELES, CA 90025-1030 (US)
`(21) Appl. No.:
`11/232,717
`Sep. 21, 2005
`(22) Filed:
`
`Publication Classification
`
`(51) Int. Cl.
`(2006.01)
`G06F 15/177
`(52) U.S. Cl. .............................................................. 709/220
`
`ABSTRACT
`(57)
`A system and method for generating a Web services descrip
`tion file is described. In one embodiment, a visualizer
`process metadata from a configuration file and applies the
`metadata to a predefined template to generate a portion of a
`Web services description file. The configuration file stores
`metadata about a service provided by a Web service. The
`template file defines structure and syntax of a portion of a
`Web services description file.
`
`
`
`
`
`
`
`
`
`Templates:
`Binding
`Port Type
`
`Visualizer
`305
`
`WSDL
`309
`
`XSD
`
`Binding
`
`
`
`Service
`
`Page 1 of 18
`
`GOOGLE EXHIBIT 1008
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 1 of 10
`
`US 2007/0067421 A1
`
`
`
`
`
`
`
`
`
`WEBSERVICES
`REGISTRY
`101
`
`SERVICE
`PROVIDER
`102
`
`
`
`
`
`
`
`
`
`SOAP
`MESSAGES
`
`SERVICE
`CONSUMER
`103
`
`
`
`SOAPMESSAGE
`ENVELOPE 105
`--
`----
`
`HEADER
`106
`
`BODY
`107
`
`F.G. 1
`(PRIOR ART)
`
`Page 2 of 18
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 2 of 10
`
`US 2007/0067421 A1
`
`CPxm version="10"?
`<definitions name="PatentFilings"
`targetNamespace="http:lbstz.com/patents,wsd"
`xmins:tns="http://bstz.com/patents.wsdr"
`xmlnsixsd1="http://bstz.com/patents.xs d"
`xmins:soap="http:llschemas.xmlsoap.org/wsdilsoap?"
`xmins="http://schemas.xmlsoap.org/wsd I">
`<types>
`<schema targetNamespace="http://bstz.com/patents.xs d"
`xmins="http://www.w3.org/2000/10/XMLSchema">
`<element name="PatentAppNumber">
`<complexTypes
`gae
`<element name="AppNumber" type="string "P
`<lad
`</complexType
`<lelement>
`Cischema)
`</types>
`<message name="GetStatus">
`<part name="body" element="xsd1:PatentStatus" />
`</message->
`
`<portType name="PatentAppportType">
`<operation name="GetStatus">
`<input message="tns:GetStatusinput">
`<output message="tns:GetStatus.Output"/>
`<loperation>
`<?portType
`
`Types
`201
`
`Message
`2O3
`
`Port Type
`205
`
`-binding name="PatentAppSoapBinding" type="tns:PatentApportType">
`<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"fe
`<operation name="GetStatus">
`<soap:operation soapAction="http://bstz.com/GetStatus "f
`<input)
`<soap:body use="lite ral"f>
`</input-
`<output)
`<soap:body use="lite ral"fe
`</output
`<loperation)
`</binding>
`
`<service name="PatentAppService">
`<port name="PatentAppport" binding="tns:PatentAppSoapBinding">
`<soap:address location="http:lbsta.com/patentap ple
`<?port)
`(service)
`<definitions)
`
`Service
`209
`
`Binding
`2O7
`s
`
`FIG. 2
`PRIOR ART
`
`Page 3 of 18
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 3 of 10
`
`US 2007/0067421 A1
`
`
`
`
`
`
`
`
`
`
`
`
`
`Templates:
`Binding
`Port Type
`
`Visualizer
`305
`
`WSDL
`309
`
`XSD
`
`Binding
`
`
`
`Service
`
`FIG. 3
`
`Page 4 of 18
`
`

`

`
`
`
`
`
`
`Oyu]UOHeINBYyUoDOyu}UONeINBYyUOD
`
`
`adh!WodadkWodjasMoe‘ue9
`
`
`adh]HOgpodu|adAtHOYyoduy
`ayejdwayayejdwatsole
`
`
`
`[O20}01qjO00}Old
`GerVer
`
`
`
`ayejdwae,BuipuigNajejdwey
`
`
`
`
`SulpuygpoduryBuipurgpodwy
`
`
`
`uojeinByuo0yws|BuipuiguoneunByuog
`ayeiduiayNaejdwes
`L0Plp
`
`
`terOlyJOuo!HOgJOuolLog
`
`
`
`aye|dwayayeidweya}a1NU0Dpeo7aJaINUuoypeo
`
`
`
`
`
`penjsqypeoypeysgypeoy60roP
`
`TGSMsjeleuady
`
`Addypuesaiaiod
`
`
`
`TIP
`
`Ud$91D|[OgAddy
`
`
`
`ayejdwa,Buipuig
`
`110
`
`adh|YOguo
`
`aye|dwa,
`
`Zev
`
`v-Old
`
`Patent Application Publication Mar. 22,2007 Sheet 4 of 10
`
`US 2007/0067421 Al
`
`
`
`
`
`ysanbeyBurpuig
`
`ber
`
`
`
`Ter
`
`
`
`
`
`ysanbayadA]yod
`
`COP
`
`
`
`
`
`JUsWNIOGBdlAJaSTGSMa}e18Ua5)
`
`SOP
`
`
`
`JAPNO1dSdIAISqaAj0)JSsanbey
`
`
`pue(s)ajyuonemnByuoduleyuleEyy
`
`
`
`$9)e|dwW93}
`
`TOP
`
`Page 5 of 18
`
`Page 5 of 18
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 5 of 10
`
`US 2007/0067421 A1
`
`
`
`Port Type Template
`505
`
`Binding Template
`503
`
`Service Document
`501
`
`FIG. 5
`
`Page 6 of 18
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 6 of 10
`
`US 2007/0067421 A1
`
`REQUEST FOR
`WSDL BENDING OR
`PORT TYPE
`
`LOADWSDL
`TEMPLATES AND
`METADATA
`
`RETRIEVE
`RELEVANT
`MARSHALLERS
`
`
`
`USE MARSHALLER
`TO CONVERT
`METADATATO
`
`
`
`COMBINE
`ASSERTION
`ELEMENTS INTO
`POLICY
`
`
`
`611
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`63
`
`REPEAT FOR ALLWSDL
`LEVELS
`
`609
`
`REPEAT FOR ALL
`MASHELLERS
`RETURNED IN 605
`
`FIG.6A
`
`Page 7 of 18
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 7 of 10
`
`US 2007/0067421 A1
`
`USE CONVERTER
`TO GATHERKNOWN
`PREOPERTIES
`
`615
`
`ID PROPERTY FOR
`POLICY DOMAN
`
`617
`
`CONVERT TO
`ASSERTIONS
`
`619
`
`
`
`
`
`
`
`FIG.6B
`
`Page 8 of 18
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 8 of 10
`
`US 2007/0067421 A1
`
`721
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`EXTRACT
`ELEMENTS NAMES
`FROM WSDL
`
`701
`
`RETRIEVE
`RELEVANT
`MARSHALLERS
`
`GATHER
`ASSERTIONS
`SUPPORTED
`
`
`
`IDENTIFY
`CONVERTIBLE
`ASSERTIONS
`
`CONVERT
`ASSERTION
`ELEMENTS INTO
`PROPERTIES
`
`APPLY DEFAULT
`PROPERTIES AS
`NECESSARY
`
`CHECK FOR
`VALIDITY
`
`
`
`FIND WARIANT
`
`FORM
`CONFIGURATION
`
`
`
`
`
`
`
`
`
`717.
`
`719
`
`FIG.7
`
`Page 9 of 18
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 9 of 10
`
`US 2007/0067421 A1
`
`
`
`
`
`
`
`Default
`803
`
`
`
`
`
`
`
`
`
`
`
`Generic Marshaller
`801
`
`Security
`805
`
`Reliable
`Messaging
`807
`
`FIG. 8
`
`Page 10 of 18
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 10 of 10
`
`US 2007/0067421 A1
`
`PROCESSOR(S)
`901
`
`DISPLAY
`907
`
`GRAPHICS
`PROCESSOR
`906
`
`SYSTEM
`MEMORY
`903
`
`
`
`
`
`
`
`
`
`FIG. 9
`
`Page 11 of 18
`
`

`

`US 2007/0067421 A1
`
`Mar. 22, 2007
`
`SYSTEMAND METHOD FOR DYNAMIC WEB
`SERVICES DESCRIPTOR GENERATION USING
`TEMPLATES
`
`BACKGROUND
`
`0001)
`1. Field of the Invention
`0002 This invention relates generally to the field of data
`processing systems. More particularly, the invention relates
`to a system and method for improving Web services descrip
`tion generation and maintenance including the formation of
`WSDL files.
`0003 2. Description of the Related Art
`0004) The term “web services' can be viewed as a
`technology for engaging in business relationships (e.g.,
`buying and selling) in a partially or wholly automated
`fashion over a network such as the Internet. FIG. 1 shows a
`web services model 100 that includes a registry 101, a
`service provider 102 and a service consumer 103. A service
`consumer 103, or “service requester, is generally under
`stood to be an entity that seeks and (in cases where a Suitable
`web service is found) uses a particular web service through
`a network 104.
`0005 The registry 101 includes listings of various “avail
`able” services, and, may assist the service consumer 103 in
`searching for a suitable service provider based on the web
`servicing needs of the service consumer 103. A service
`provider 102 is the provider of one or more web services that
`can be accessed over the network 104. Because of the vast
`expanse of the Internet and interest in automated business
`engagements, many registries, service consumers and Ser
`Vice providers may be in operation at any instant of time.
`0006 Presently, the responsibilities of the most prevalent
`registry function 101 that is associated with the web services
`effort are defined in various Universal Discovery, Descrip
`tion and Integration (UDDI) specifications provided by
`uddi.org. Besides providing listings of available services, a
`UDDI registry 101 may also make available to a service
`consumer 103 additional details that pertain to any particular
`web service such as: 1) the location of the web service (e.g.,
`its URI specified by a specific network destination address
`or name); 2) the capabilities of the web service (e.g., specific
`methods that are supported by the web service and that may
`be called upon by the service consumer), and, 3) commu
`nication semantics needed for invoking the web service
`through the network 104 (e.g., the structure of a messaging
`format and/or protocol needed to properly communicate
`with the web service).
`0007 According to one widely adopted approach, such
`“additional details” are described in Web Services Definition
`Language (WSDL) text documents written in extensible
`Markup Language (XML). Here, for example, for each web
`service that the registry 101 maintains a listing of the
`registry 101 also maintains a WSDL document that
`describes the location, capabilities and communication
`semantics of the web service. Presently, a WSDL document
`for a particular web service is expected to include an
`“abstract interface' description of the web service (which
`includes the web service's methods and the data passed
`between the web service provider and web service con
`Sumer) and a “concrete implementation” description of the
`web service (which includes specific protocol and data
`
`format specifications for communicating with the web ser
`vice (referred to as a “binding) and the location of the web
`service (referred to as a “port')).
`0008 According to another widely adopted approach,
`with respect to the actual communication that occurs
`between the service consumer 103 and the service provider
`102. Such communication is implemented through an
`exchange of Simple Object Access Protocol (SOAP) text
`messages written in XML.
`0009 WSDL files are created in the XML format that
`describe a Web service provider's services as a set of
`endpoints (or ports) operating on messages containing either
`document-oriented or procedure-oriented information. For
`example, a SOAP message may be directed toward a par
`ticular port of a Web services provider from a remote client.
`FIG. 2 illustrates an exemplary WSDL file.
`0010) A WSDL file generally contains information for
`types 201, messages 203, port types 205, bindings 207, and
`services 209 supported by the Web service provider. From
`this WSDL file a client may determine how to communicate
`with a Web service and what functionality the Web service
`provides.
`0011 A type describes for data type definitions using a
`type system. For example, the type system may be XSD
`(XML Schema Descriptor). In the example of FIG. 2, the
`type 201 is an XSD file called patents.xsd. This file is
`located on the Web service provider's server (here bst/-
`.com).
`0012 Messages in a WSDL file are described abstractly
`and define the data being communicated between endpoints
`or ports. For example, the message 203 is called “GetStatus'
`and provides the patent status in the body of the message.
`0013 Port types are abstract collections of operations
`supported by a Web service. Each operation describes a
`function supported. The port type 205 illustrated describes
`the operation “GetStatus’ including the input and output
`message format to be adhered to.
`0014 Bindings are concrete protocols and define the
`particular data format for a particular port type. In the
`example, the binding 207 associates the “GetStatus' opera
`tion with a SOAP message.
`0015. A port is defined by binding a network protocol and
`message format. A collection of these ports define a service.
`The service 209 ties the “Patent AppSoaPBinding to the port
`“PatentAppPort.”
`0016 Current WSDL document generation requires
`manual intervention to describe the Web service. Either a
`program such as GLUE is run or the WSDL file is generated
`manually. In either case, these WSDL files cannot be auto
`matically generated based upon a request to the service
`provider.
`0017 Additionally, WSDL files were generated from web
`service artifacts such as Virtual Interface, WSD and web
`services-deployment-descriptor which were inside a web
`service archive. The WSDL generation was done at the
`deployment time of a web service. Accordingly, when
`request is made for WSDL visualization, the WSDL simply
`read from the file system. In this approach it is impossible
`
`Page 12 of 18
`
`

`

`US 2007/0067421 A1
`
`Mar. 22, 2007
`
`for a configuration to be edited/removed/added at runtime
`without editing the web service artifacts, updating the
`archive, and redeploying it.
`
`SUMMARY
`0018. A system and method for generating a Web services
`description file is described. In one embodiment, a visualizer
`process metadata from a configuration file and applies the
`metadata to a predefined template to generate a portion of a
`Web services description file. The configuration file stores
`metadata about a service provided by a Web service. The
`template file defines structure and syntax of a portion of a
`Web services description file.
`
`FIGURES
`0019. The present invention is illustrated by way of
`example, and not limitation, in the figures of the accompa
`nying drawings in which like references indicate similar
`elements and in which:
`0020 FIG. 1 shows a Web services model (prior art):
`0021 FIG. 2 illustrates an exemplary WSDL file (prior
`art):
`0022 FIG. 3 illustrates an embodiment of a system for
`generating a WSDL document from templates and configu
`ration data;
`0023 FIG. 4 illustrates an embodiment of the flow of
`dynamically creating a WSDL document;
`0024 FIG. 5 illustrates the reference principles of tem
`plates applied in the creation of a WSDL document accord
`ing to an embodiment;
`0025 FIG. 6A illustrates an embodiment of the flow for
`generating WSDL policies;
`0026 FIG. 6B illustrates an embodiment of the flow for
`the conversion of metadata to assertion elements;
`0027 FIG. 7 illustrates an embodiment of the flow for
`generating a configuration file from a policy annotated
`WSDL:
`0028 FIG. 8 illustrates the inheritance properties of mar
`shallers according to one embodiment; and
`0029 FIG. 9 is a block diagram of a computing system
`that can execute program code stored by an article of
`manufacture.
`
`Detailed Description
`0030 Described below is a system and method for
`dynamically generating a WSDL document. Throughout the
`description, for the purposes of explanation, numerous spe
`cific details are set forth in order to provide a thorough
`understanding of the present invention. It will be apparent,
`however, to one skilled in the art that the present invention
`may be practiced without some of these specific details. In
`other instances, well-known structures and devices are
`shown in block diagram form to avoid obscuring the under
`lying principles of the present invention.
`0031 One embodiment of the invention generates a
`WSDL document from the abstract and concrete data stored
`in a configuration file as applied to templates for binding and
`port type.
`
`Dynamic WSDL Generation
`0032). In Web services systems, a WSDL file provides the
`outside world with the requirements for communicating with
`and utilizing the services of a service provider. As described
`earlier, these WSDL files are usually generated after a
`complete Web service has been defined by a provider and are
`likely to be an afterthought to the complex design process
`used to create a Web service. Dynamic creation and/or
`changing of WSDL documents allows for a Web service
`provider to describe new services or remove services easier.
`In one embodiment, as the WSDL document is updated or
`created without human intervention to create the WSDL
`document. For example, as soon as a new service is provided
`the WSDL document for the Web service provider is updated
`to reflect this change without having to manually create the
`new WSDL document.
`0033 FIG. 3 illustrates an embodiment of a system for
`generating a WSDL document from templates and configu
`ration data. These templates and configuration data were not
`available in the prior art. In an embodiment, a web services
`archive file contains WSDL templates and configuration
`file(s). These templates are generated during web service
`design time and are packaged inside the archive. This
`approach allows for dynamical edition/remove/add of a web
`service configuration. When a request for WSDL visualiza
`tion is received, a WSDL file is generated dynamically using
`the WSDL template and configuration data. Each template
`stores information regarding the structure and syntax of a
`portion of a WSDL document. For example, the binding
`template contains information relating to the protocol con
`figurations of the service.
`0034). Upon a request (HTTP, HTTPS, FTP, etc.), a visu
`alizer 305 uses at least one configuration file 313 which may
`contain multiple configuration components 301, 303, 311
`and a template (binding, port type, etc.) stored in an archive
`307 to create at least a portion of a WSDL document (for
`example, the port type, service, or binding section of the
`WSDL). In one embodiment, the template is stored in an
`EAR (Enterprise Archive) file. For example, an HTTP
`request made to the visualizer 305 causes the visualizer 305
`to apply the relevant metadata configuration components
`301,303, 311 available to the port type template of the EAR
`307 to create a service for the WSDL 309. Likewise a
`binding request to the visualizer 305 creates a WSDL
`binding reference for the WSDL309. This technique may be
`applied to existing Web services by maintaining (or creating)
`configuration components or files in addition to the main
`taining the EAR file(s) that is already deployed. In one
`embodiment, there is a template for every portion of the
`WSDL document. For example, there is a template for types,
`messages, port types, bindings, and services.
`0035). Each configuration 301, 311, 303 stores WSDL
`metadata about a service provided by the Web service
`provider. In an embodiment, configuration components of a
`configuration file are also specific to a particular policy
`domain Such as security, reliable messaging, etc. For
`example, configuration component CFG 1301 contains
`metadata regarding the security protocol that is to be used by
`the Web service for a particular service. The policy domain
`for security may include the type of encryption used and/or
`the type of signature required. A client that has retrieved the
`WSDL file that was created using this configuration file will
`
`Page 13 of 18
`
`

`

`US 2007/0067421 A1
`
`Mar. 22, 2007
`
`be able to ascertain the security protocol is being utilized by
`the provider and how to properly construct messages from
`the client to the provider using this protocol. Other configu
`ration components 303, 311 contain other metadata about a
`service provided. For example, CFG 2311 contains session
`data and CFG N 303 contains security and reliable mes
`saging data about a service. Configuration components may
`be dynamically added, removed, or modified depending
`upon the services that are to be provided by the Web service.
`0036) There are two types of data available in most
`WSDL implementations: abstract and concrete data.
`Abstract data is design time configuration data and is
`associated with a port type, type, and/or message. Runtime
`configuration data (concrete data) is associated with a bind
`ing, service, and/or port. In one embodiment, each configu
`ration is associated with only a single port. The use of
`configuration files allows for the separation of abstract and
`concrete WSDL data which was not possible in prior art
`systems. This separation allows for the dynamic creation
`and/or changing of a WSDL document. A WSDL document
`could be separated into abstract (port type) and concrete
`(binding) parts. The configuration data from the configura
`tion file(s) is additional metadata which again could be
`separated to abstract and concrete. This configuration meta
`data represents additional information, which cannot be
`described by the standard WSDL elements (types, messages,
`port types, bindings, services, ports) such as specific kinds of
`securities (signature, encryption), quality of service for
`message delivery (exactly one, exactly one in order, etc.),
`etc. An example of abstract configuration data is “I want
`encryption' with the concrete configuration data being “the
`encryption will be DES.”
`0037 FIG. 4 depicts an embodiment of the flow of
`dynamically creating (visualizing) a WSDL document. Of
`course it should be understood that the WSDL document
`may already exist and is modified accordingly. Template and
`configuration files and/or components for a Web service are
`maintained at 401. Throughout the life of the Web service
`these files are updated, including being added, removed, or
`modified, to reflect the current requirements for accessing
`and using the service.
`0038 A service request to the Web service provider from
`a client is made at 403. In an embodiment, exemplary
`requests include HTTP requests, HTTPS requests, binding
`requests, etc.
`0039. The service portion of the WSDL document is
`generated at 405 if a service request has been made by the
`client connecting to the provider. During the generation of a
`service document, a service data is obtained from a service
`data registry of the provider. This data includes the correct
`binding and port names are gathered from a based on the
`URI provided by the client. For example, the visualizer 305
`of FIG.3 obtains binding and port names from the templates
`of the EAR 307.
`0040. A binding request is made from the client to the
`provider for a specific port at 409. This binding request
`initiates the importing of a stored binding template at 407,
`413. As illustrated in FIG. 4, several ports may have their
`relevant binding template imported. In this example, Bind
`ing Template 1 is associated with port 1 and Binding
`Template N is associate with the Nthport of the providers
`service. Accordingly, a binding request for port 1 initiates
`the importing of Binding Template 1.
`
`0041. With the appropriate binding template imported,
`the concrete portion of the configuration file associated with
`that binding template is loaded at 409, 415. For example, the
`protocol(s) definitions described in a configuration file asso
`ciated with Binding Template 1 are imported into the
`WSDL service document.
`0042 WSDL policies are generated using the concrete
`data loaded at 411. An embodiment of this generation will be
`described in detail later in FIGS. 6A and 6B. WSDL policies
`may be Web service specific (for example, a policy may be
`a feature of a particular Web service implementation such as
`those deployed by IBM, SAP, Microsoft, etc.) or generic (for
`example, a policy may apply to a Web service specification
`like WS-Security or WS-ReliableMessaging). For ease of
`understanding, the term policy or policies encompasses both
`policy types unless otherwise noted.
`0043. These generated WSDL policies are then applied to
`the binding template at 417 to create the binding elements of
`the WSDL file.
`0044) A request for port type initiates the importing of a
`port type template at 431. Like binding, several port type
`templates may be imported 419, 423 based on the particular
`request.
`0045. The abstract portion of the relevant configuration
`file is loaded at 421, 425 into a port type template. The
`abstract portion describes the set of operations Supported by
`the port. For example, in FIG. 2 the “GetStatus' operation
`is supported by the bsta.com Web service.
`0046) WSDL policies are generated by applying these
`abstract portions on the port type template at 427 to create
`the port type portion of the WSDL file. In one embodiment,
`this generation is done in a manner similar to that of WSDL
`policy generation for binding at 411. An embodiment of this
`generation will be described in detail later in FIGS. 6A and
`6B.
`0047 AWSDL document is created or modified when the
`port types, bindings, and services have been created and/or
`modified. The service document imports one or more bind
`ing WSDL documents. By reading the import data from
`service WSDL document the WS consumer “understands'
`on what URL to request the binding WSDL document(s).
`Each binding WSDL document imports only one port type
`WSDL document. By reading the import data from the
`binding WSDL document the WS consumer “understands'
`on what URL to request the port type WSDL document.
`Thus, a complete WSDL document consists of at least three
`separate WSDL files which are downloaded from different
`URLs and which relate to one another via WSDL import
`elements as described below.
`0048 FIG. 5 illustrates the import principles of templates
`applied in the creation of a WSDL document according to an
`embodiment. At least three documents and/or templates are
`used to create a WSDL file. A service document 501 is
`generated upon request. The service document describes
`services and their ports and addresses.
`0049 Binding templates 503 describe protocol configu
`rations used in a Web service implementation. The binding
`template(s) 503 imports a port type WSDL document. The
`port type 505 template imports nothing.
`
`Page 14 of 18
`
`

`

`US 2007/0067421 A1
`
`Mar. 22, 2007
`
`0050. Of course it should be understood that requests for
`service, binding, or port type may come in any order.
`
`Server Side Policy Generation
`Policy domains are sets of assertions for a particu
`0051
`lar protocol. Each assertion is an XML element defined by
`a particular Web services specification (for example, WS
`Security, WS-ReliableMessaging, etc.) having some specific
`semantic and syntax. For example, in the security policy
`domain the assertions are the types of encryption or signa
`tures used by the particular Web services provider. Configu
`ration file information is converted into policies (non-imple
`mentation specific) or features (implementation specific)
`during the creation of WSDL documents.
`0.052
`FIG. 6A illustrates an embodiment of the flow for
`generating WSDL policies. A request for a WSDL binding or
`port type component is made to a visualizer at 601. The
`relevant WSDL template associated with the request is
`loaded along with metadata from at least one configuration
`file at 603 (ror example, configurations of a configuration
`file is loaded with the request).
`0053. The set of relevant marshallers (converters) needed
`to process a configuration file is retrieved from a registry
`(marshaller factory) or other storage location on the Web
`services provider at 605. Each marshaller provides function
`ality to convert configuration file properties into assertion
`elements. There is at least one marshaller per each policy
`domain.
`0054) A marshaller from the set is used to convert con
`figuration metadata into assertion elements at 607. An
`embodiment of this conversion is described in greater detail
`in FIG. 6B.
`0.055
`Each converter from the set performs the conver
`sion of 607 at 609. In other words, the conversion process
`should be repeated for each policy domain. The results of all
`of the conversions, assertion elements, are combined to form
`a policy element at 611. This policy element is applied to the
`WSDL template loaded at 603 to create the WSDL compo
`nent requested at 601.
`0056. This conversion from metadata to a policy element
`may be repeated at 613 for the other WSDL levels until a
`complete policy annotated WSDL is formed. For example, if
`the request at 601 was for a port type, the conversion may
`be repeated for binding. Of course, it should be understood
`that if the policy annotated WSDL is being updated for a
`particular component (binding, port type, etc.) then the other
`components may not need to be updated and the conversion
`from metadata to policy element does not need to occur.
`0057 FIG. 6B illustrates an embodiment of the flow for
`the conversion of metadata to assertion elements. Each
`marshaller is aware of a few properties that a particular
`policy domain Supports. In other words, each marshaller
`may only process properties that it Supports. The names of
`these known properties for a specific policy domain are
`gathered by a marshaller from the configuration file that the
`marshaller is associated with at 615.
`0.058. These property names are compared to the con
`figuration metadata to identify which properties are stored in
`the metadata and therefore convertible by the marshaller at
`617. In other words, the marshaller not only has the capa
`
`bility to process a particular metadata but the configuration
`file contains the metadata. In one embodiment, this com
`parison is done by a so-called configuration builder. This
`builder is also responsible for gathering the marshallers from
`the registry.
`0059) The identified metadata is then converted into
`assertion elements by the marshaller at 619. This process of
`retrieving property names that the marshaller Supports the
`conversion of identifying the metadata that is available to be
`converted by this particular marshaller, and converting this
`metadata into assertion elements is repeatable for each
`marshaller from the set of marshallers of the marshaller
`factory.
`0060. In one embodiment, there is a single generic mar
`shaller to perform operations on every type policy domain.
`Therefore, certain tasks described above may be eliminated.
`For example, the comparison at 617 may be eliminated.
`Client Side Configuration Creation
`0061. As described earlier, clients retrieve WSDL docu
`ments from Web service providers. These WSDL documents
`need to be “converted into an understandable form (WS
`metadata) for the client. A part of this conversion is to create
`metadata property names from assertions in the XML
`(WSDL) document.
`0062 FIG. 7 illustrates an embodiment of the flow for
`generating a configuration from a policy annotated WSDL.
`From one WSDL, a configuration file is generated, which
`file could contain serveral configurations, depending how
`many endpoints (ports) the WSDL has. Assertion element
`names for a specific WSDL level (for example, port type,
`binding, etc.) are gathered from the policy annotated WSDL
`at 701. Each marshaller provides functionality to convert
`WSDL assertions into metadata properties. In one embodi
`ment, there is one marshaller per each assertion. Each
`marshaller is aware of a few properties that a particular
`assertion Supports. In other words, each marshaller may only
`process assertions that it supports.
`0063. Using these assertion element names, the associ
`ated marshallers are retrieved from a registry or other
`storage location of the client, such as a marshaller factory, at
`703. For a particular marshaller retrieved at 703, the mar
`shaller gathers the set of assertions that the marshaller
`supports at 705. In other words, this set identifies which
`assertions the marshaller is able to process into metadata
`properties.
`0064. These assertion element names are compared to the
`WSDL to identify which assertions are in the WSDL and are
`therefore convertible by the marshaller at 707. In other
`words, the marshaller not only has the capability to process
`a particular assertion but the WSDL contains the assertion.
`In one embodiment, this comparison is done by a so-called
`configuration builder. This builder is also responsible for
`gathering the marshallers from the registry.
`0065. The marshaller used at 703 converts the assertion
`elements of the WSDL into metadata properties at 709. Each
`marshaller from the set performs the conversion of 709 at
`711. The results of all of the conversions, metadata proper
`ties, are combined to form a property list. Because there are
`properties for which no match could be found at 707, default
`properties of the marshaller are applied to the property list
`at 713.
`
`Page 15 of 18
`
`

`

`US 2007/0067421 A1
`
`Mar. 22, 2007
`
`It is possible that two or more properties cannot be
`0066.
`combined into the same metadata. In other words, the
`property list may have conflicting entries. For example, the
`property list may show that the for security purposes a
`signature is required but later in the list shows that a
`signature is not required. For this reason, the updated
`property list is checked for validity at 715 and any problems
`are reported to the client. If there are problems, the process
`ing is stopped and requires further investigation to determine
`the proper course of action. For example, the property list
`may need to be manually adjusted. Each WSDL level should
`perform the above operations at 721.
`0067. The marshaller checks for abstract properties that
`correspond to a specific concrete property and returns a list
`of possible abstract configurations (variants) at 717. This
`relates