(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2007/0067421 A1
`
`
` Angelov (43) Pub. Date: Mar. 22, 2007
`
`US 20070067421A1
`
`(54) SYSTEM AND METHOD FOR DYNAMIC
`WEB SERVICES DESCRIPTOR
`GENERATION USING TEMPLATES
`
`(76)
`
`Inventor: Dimitar v_ Angelov, Montana (BG)
`
`Correspondence Address:
`BLAKELY SOKOLOFF TAYLOR & ZAFMAN
`12400 WILSHIRE BOULEVARD
`SEVENTH FLOOR
`LOS ANGELES, CA 90025-1030 (US)
`
`(21) Appl. No.:
`
`11/232,717
`
`(22)
`
`Filed:
`
`Sep. 21, 2005
`
`Publication Classification
`
`(51)
`
`Int- Cl-
`(2006.01)
`G06F 15/177
`(52) US. 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.
`
`fl Templates:
`
`Visualizer
`
`
`
`Binding
`Port Type
`
`
`
`WSDL
`
`fl
`
`
`X80
`
`
`1
`Binding
`1
`
`Service
`
`Exhibit 1019
`
`Page 01 ofl8
`
`Adobe Inc. v. Express Mobile, |nc.,
`|PR2021 -XXXXX
`
`
`
`US. Pat. 9,928,044
`
`Exhibit 1019
`
`Exhibit 1019
`Page 01 of 18
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 1 0f 10
`
`US 2007/0067421 A1
`
`
`
`
`WEB SERVICES
`REGISTRY
`
`m1
`
`
`
`
`
`
`SERVICE
`SERVICE
`PROVIDER
`CONSUM ER
`
`
`
`m
`M
`
`
`
`SOAP
`M ESSAGES
`
`
`
`SOAP M ESSAGE
`ENVELOPE 105
`
`réL—fl
`LT_IL_W_J
`HEADER
`BODY
`106
`107
`
`FIG. 1
`
`(PRIOR ART)
`
`Exhibit 1019
`
`Page 02 of 18
`
`Exhibit 1019
`Page 02 of 18
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 2 0f 10
`
`US 2007/0067421 A1
`
`<17me version="1.0"?>
`
`<deflnilions name="PatentFilings"
`targetNamespace="http:l/bstz.comlpatents.wsd |"
`xmlns:tns="http:l/bstz.com/patents.wsd I“
`xmlnszxsd1="http://bstz.com/patems.xs d"
`xmlns:soap:"http:l/schemas.xmlsoap.org/wsdllsoa pl"
`xmlns="http:llschemas.xmlsoap.orglwsdl I">
`<types>
`<schema targetNamespace="http:/lbstz.com/patents.xs d"
`xmlns="hltp:l/www.w3.orgl2000/1OIXMLSchema">
`<element name=“PatentAppNum ber">
`<complexTyp e>
`<al|>
`<element name=“AppNumber' type="string "/>
`<lall>
`<lcomplexTyp e>
`<le|eme nt>
`<lsche ma>
`<ltyp es>
`
`<message name="GetStatus ">
`<part name="body" element="xsd1:PatentStatus" />
`
`<lmessage>
`
`<portType name=“PatentAppPortType">
`<operation name="GetStatus ">
`<input message="tns:GetStatuslnpu t"/>
`<output message="tns:GetStatusOutpu t"l>
`<loperati on>
`</portTyp e>
`
`Types
`2.01
`
`I
`
`Message
`203
`
`—
`
`Port Type
`205
`—
`
`<binding name="PatentAppSoapBinding" type="tns:PatentAppPor tType">
`<soapzbinding style="document" transport“http://schemas.xmlsoap.0rg/soap/http“l>
`<operation name="GetStatus ">
`<soapzoperation soapAction="http://bstz.comlGetStatus ‘/>
`<in put>
`<soap2body use="lite ra|"/>
`<fin put>
`<out put>
`<soap2body use="|ite ml"/>
`<lout pu1>
`<loperati on>
`<lbinding>
`
`<service name="PatentAppService">
`<port name=“PalentAppPort” binding="tns:PatentAppSoapBind ing">
`<soapzaddress location="http:llbstz.com/patentap p"l>
`<lp on>
`<lservic e>
`<ldefinitions>
`
`Service
`
`&
`
`Binding
`207
`...__
`
`FIG. 2
`
`PRIOR ART
`
`Exhibit 1019
`
`Page 03 of 18
`
`Exhibit 1019
`Page 03 of 18
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 3 0f 10
`
`US 2007/0067421 A1
`
`fl Templates:
`
`Visualizer
`
`
`
`Binding
`Port Type
`
`
`
`WSDL
`
`fl
`
`
` XSD
`
`i
`Binding
`i
`
`Service
`
`FIG.‘3
`
`Exhibit 1019
`
`Page 04 of 18
`
`Exhibit 1019
`Page 04 of 18
`
`

`

`WaP
`
`0.Ua.wm
`
`.Ua.w
`
`m
`
`US 2007/0067421 A1
`
`
`
` ZI0:0_QE0HW5:0:23:00m:_0:_m:0:m::m::oomag:05:80:o5:80
`
`.5w>>0:20:006255:053:00955:053:00M.8890 Eapm0:0.0E0k20350.:00%:M0%.:ton.003.:on_.8205S00:8208..
`
`09.3,:08..0%a903:5:
`
`
`
`
`
`
`
`
`
`
`:002260209‘
`
`m:_0:_m
`
`
`
`
`
`
`
`.5m>>0:90:0090.0%....m:_0:_m_
`
`
`
`003.tom:0
`
`203:0...
`
`fl
`
`
`
`209‘0:000_0__on_Haw
`
`v.0_n_
`
`
`
`
`
`
`
`ZI0HmEE0...ton.08::MamaMEmEEB.a059:8.05060.:0:05:000030.0.9.00000..n003.
`
`
`
`ton.009:.0:3.
`
`
`
`
`
`n9.050:85.9.050tons:
`
`
`
`
`
`
`
`nE0E200n.023840m;0:90:00
`
`
`
`
`
`
`
`
`
`WamIP“00:00".003.ton.mov
`
`0.
`
`
`
`
`
`
`
`
`5:053:0053:52M;:w0sc0wmlms:_:0So:00.20300000:00mflwmmEBmm.0.m0.a.ma>>IK0:032:
`
`
`
`
`
`Exhibit 1019
`
`Page 05 of 18
`
`Exhibit 1019
`Page 05 of 18
`
`
`
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 5 0f 10
`
`US 2007/0067421 A1
`
`Port Type Template
`§Q§
`
`.521.
`
`Binding Template
`fl
`
`Service Document
`
`FIG. 5
`
`Exhibit 1019
`
`Page 06 of 18
`
`Exhibit 1019
`Page 06 of 18
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 6 0f 10
`
`US 2007/0067421 A1
`
`REQUEST FOR
`
`WSDL BINDING OR
`
`PORT TYPE
`
`LOAD WSDL
`
`TEMPLATES AND
`
`METADATA RETRIEVE
`
`
`
`613
`
`USE MARS HALLER
`
`METADATA T0 609
`LEVELS
`
`
`RELEVANT
`
`MARSHALLERS
`
`TO CONVERT
`
`REPEAT FOR ALL WSDL
`
`REPEAT FOR ALL
`
`MASHELLERS
`
`
`
`
`
`RETURNED IN 605
`
`ASSERTION
`
` COMBINE
`
`
`ELEMENTS INTO
`
`POLICY
` 611
`
`FIG. 6A
`
`Exhibit 1019
`
`Page 07 of 18
`
`Exhibit 1019
`Page 07 of 18
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 7 0f 10
`
`US 2007/0067421 A1
`
`515
`
`617
`
`619
`
`USE CONVERTER
`
`TO GATHER KNOWN
`
`ID PROPERTY FOR
`
`POLICY DOMAIN
`
`PREOPERTIES
`
`
`CONVERT TO
`ASSERTIONS
`
`
`FIG. GB
`
`Exhibit 1019
`
`Page 08 of 18
`
`Exhibit 1019
`Page 08 of 18
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 8 0f 10
`
`US 2007/0067421 A1
`
`
` EXTRACT
`701
`ELEMENTS NAMES
`
`FROM WSDL
`
`
` RETRI EVE
`
`RELEVANT
`
`
`
`MARSHALLERS
`
`GATHER
`ASSERTIONS
`SUPPORTED
`
`I
`IDE TIFY
`
`
`CONVERTIBLE
`ASSERTIONS
`
`721
`
`CONVERT
`ASSERTION
`ELEMENTS INTO
`PROPERTIES
`
`
`
`VALIDITY
`
`
`
`
`
`
`
`
`APPLY DEFAULT
`
`PROPERTIES AS
`NECESSARY
`
`CHECK FOR
`
`
`
`FIND VARIANT
`
`717.
`
`CONFIGURATION
`
`FORM
`
`719
`
`FIG. 7
`
`Exhibit 1019
`
`Page 09 of 18
`
`Exhibit 1019
`Page 09 of 18
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 9 0f 10
`
`US 2007/0067421 A1
`
`
`
`
`Generic Marshaller
`
`fl
`
`
`
`&
`
`FIG. 8
`
`Exhibit 1019
`
`Page 10 0f18
`
`Default
`
`Security
`
`
`
`
`
`&
`
`
`
`
`
`
`
`Reliable
`
`Messaging
`
`M
`
`Exhibit 1019
`Page 10 of 18
`
`

`

`Patent Application Publication Mar. 22, 2007 Sheet 10 of 10
`
`US 2007/0067421 A1
`
` PROCESSOR(S)
`
`
`
`
`M
`
`GRAPHICS
`
`
`
`
`SYSTEM
`
`
`DISPLAY
`MEMORY
`PROCESSOR
`
`
`fl
`
`
`
`%
`
`
`$1.3-
`
`
`
`FIG. 9
`
`Exhibit 1019
`
`Page 11 of 18
`
`Exhibit 1019
`Page 11 of 18
`
`

`

`US 2007/0067421 A1
`
`Mar. 22, 2007
`
`SYSTEM AND 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: l) 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 OiML). 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
`OCML 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 bstz-
`.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 “PatentAppSoaPBinding 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
`
`Exhibit 1019
`
`Page 12 of 18
`
`Exhibit 1019
`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
`
`invention is illustrated by way of
`[0019] The present
`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
`an);
`
`[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
`
`In Web services systems, a WSDL file provides the
`[0032]
`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.
`
`FIG. 3 illustrates an embodiment of a system for
`[0033]
`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
`
`to the visualizer 305 creates a WSDL
`binding request
`binding reference for the WSDL 309. 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
`
`Exhibit 1019
`
`Page 13 of 18
`
`Exhibit 1019
`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 (porttype) 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,
`porttypes, 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 Nth port of the provider’s
`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 bstz.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] A WSDL 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.
`
`FIG. 5 illustrates the import principles of templates
`[0048]
`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.
`
`Exhibit 1019
`
`Page 14 of 18
`
`Exhibit 1019
`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
`
`[0051] Policy domains are sets of assertions for a particu-
`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.
`
`[0052] 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.
`
`[0055] 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.
`
`[0058] 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.
`
`In one embodiment, there is a single generic mar-
`[0060]
`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. Apart of this conversion is to create
`metadata property names from assertions in the XML
`(WSDL) document.
`
`FIG. 7 illustrates an embodiment of the flow for
`[0062]
`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.
`
`Exhibit 1019
`
`Page 15 of 18
`
`Exhibit 1019
`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 pr