RE: [uddi-spec] WSDL best practice

John,

 

Are 
you referring to the V1.07 Best Practice document, dated May 21, 
2002?

 

This 
document still suggests including the <binding> elements in the abstract 
service description (pointed to by the tModel). One of the points I was raising 
is that the <binding> element often contains implementation-specific 
information (e.g., SOAPAction and header elements). This information isn't 
really part of an abstract service description, so it doesn't belong as part of 
the tModel service type definition.

 

I'm 
proposing that the Best Practice document be changed to recommend that the 
tModel's WSDL file should contain only <types>, <message>, and 
<portType> elements. Then we should spend some time thinking about the 
best way to let service providers indicate what type of binding they 
support.

 

One 
way is to create a different tModel for each possible protocol and transport. 
But this approach will result in a whole bunch of tModels. I think it would be 
useful if you could perform a query and search for providers who offer a 
particular service type (defined by a tModel) that supports SOAP 1.2 over HTTP 
transfer protocol using the HTTP GET Web Method and returns a 
signed message in document/literal format (all of which would be specified 
within the bindingTemplate). 

 

Might 
we consider creating a binding taxonomy rather than a different tModel for each 
possible value of each binding attribute (XML protocol, transfer protocol, 
message style, encoding style, SOAP features, header processing, security, 
reliability, transactions, etc, etc.)?

 

Anne

  
-----Original Message-----
From: John Colgrave 
  [mailto:]
Sent: Tuesday, September 24, 2002 
  9:12 AM
To: Anne Thomas Manes; Uddi-Spec
Subject: Re: 
  [uddi-spec] WSDL best practice

  
Anne,

  
 

  
I think these comments are addressed by the new 
  WSDL Technical Note, except that we only provide tModels for the 
  SOAP protocol and the SOAP/HTTP transport.  We acknowledge that other 
  protocols and transports can be used, and we should consider adding more 
  tModels to the UDDI Business Registry for accepted standard protocols and 
  transports.

  
 

  
John

  
    
----- Original Message ----- 

    
From: 
    Anne Thomas Manes 
    

    
To: Uddi-Spec 

    
Sent: Thursday, September 19, 2002 4:38 
    PM

    
Subject: [uddi-spec] WSDL best 
    practice

    

    
I'm not sure if we're ready to get into issues yet, 
    but I'd like to put this one on the table.

    
 

    
I 
    have some misgivings about the current WSDL best practices document. I've 
    outlined the issue in the email below.

    
Some recommendations:

    
 

    
- We create a set of 
    canonical tModels to represent various types of 
    bindings

    
- 
    We update the best practices document to state that the <binding> 
    information should be separated from the abstract interface description. We 
    also define best practices for using the binding type 
    tModels.

    
 

    
Anne

    
 

    
-----Original Message-----
From: Anne Thomas Manes 
    [mailto:]
Sent: Thursday, September 19, 2002 11:19 
    AM
To: 
Subject: RE: 
    [uddi-technical] T-model and wsdl

    
Francesco,

    
 

    
Here is the official UDDI best practices document that explains 
    how to use WSDL with UDDI:

    
http://www.uddi.org/pubs/wsdlbestpractices-V1.07-Open-20020521.pdf

    
 

    
This best practice describes how to divide your WSDL document into 
    two sections: one that describes the abstract interface of your service 
    (aka, the service type -- the tModel represents the service type) and one 
    that describes the service implementation (the businessService and the 
    bindingTemplate represent your service implementation). According to 
    this best practice document, the abstract interface WSDL description 
    contains the <types>, <message>, <portType>, and 
    <binding> elements, and the service implementation WSDL description 
    includes or imports the abstract WSDL description and adds the 
    <service> element. 

    
 

    
I 
    have some misgivings about this approach, though, because the 
    <binding> information shouldn't really be part of the abstract service 
    type. It works fine as long as you are the only one offering an 
    implementation of the service. It doesn't work nearly as well if the service 
    is offered by many different companies. The <binding> element contains 
    information (such as SOAPAction) that is specific to a particular 
    implementation. Also, if you offer multiple protocol bindings for your 
    service (e.g., HTTP and SMTP), you would need to define multiple tModels to 
    distinguish these bindings. There really should be one tModel that describes 
    the abstract service, and the binding information should be associated with 
    the service implementation's bindingTemplate. (And doesn't it make more 
    sense to publish binding information in the 
    bindingTemplate?)

    
 

    
Systinet has developed an alternate best practice, which recommends 
    dividing the WSDL document a little differently. The Systinet approach views 
    a WSDL document as consisting of three parts: the WHAT part, the HOW 
    part, and the WHERE part. The WHAT part describes the abstract interface. It 
    contains the <types>, <message>, and 
    <portType> elements. The HOW part descibes a binding. It includes 
    or imports the WHAT part and adds the <binding> element. The WHERE 
    part describes a specific service implementation. It includes or imports the 
    HOW part and adds the <service> element.

    
 

    
According to the Systinet approach, the tModel should point to the 
    WHAT part, and the bindingTemplate should point to the HOW part (or perhaps 
    to the WHERE part, which includes the HOW part -- but the "where" 
    information (the Access Point) is already specified in the bindingTemplate 
    accessPoint element, so the "where" information doesn't need to also be 
    included in the WSDL unless you want to put it there). In any case, the 
    WHERE part should always be co-located with your service URL -- for example, 
    http://my.example.com/serviceurl?wsdl.

    
 

    
Systinet also recommends that you create a 
    set of tModels that represent the various types of bindings, such as 
    SOAP or XML-RPC, etc. If a service supports a SOAP binding, then 
    it should include a reference to the SOAP tModel in its bindingTemplate. 
    (This convention makes it very easy to identify services that support SOAP.) 
    You might want to extend this approach and create more fine-tuned 
    binding type tModels, such as SOAP over HTTP and SOAP over JMS or SOAP 
    RPC/Encoded-style and SOAP Document/Literal-style. Since you're 
    building a private registry, you can define your own model and conventions 
    to suit your requirements.

    
 

    
Systinet provides a set of utilities that 
    automate the UDDI registration process. (They support both the UDDI.org best 
    practice method and the Systinet best practice method.) These utilities are 
    included with the WASP Server for Java product (see http://www.systinet.com/index.php?nav=/products/wasp_jserver/overview -- 
    it's free for development purposes). I believe that you can use these 
    utilities to register services developed using other tools, too. (They 
    generate the UDDI registration from the WSDL document.)

    
 

    
You might find the Systinet WASP documentation helpful. 
    

    
http://www.systinet.com/doc/wasp_jserver/utilityWebServices/wsDiscovery.html#utilityWebServices.wsDiscovery.details.methods

    
It 
    goes into great detail about the mappings between WSDL and UDDI using both 
    the UDDI best practice approach and the Systinet 
    approach.

    
 

    
Best regards,

    
Anne

    
      
-----Original Message-----
From: 
       
      [mailto:]
Sent: Thursday, September 
      19, 2002 6:42 AM
To: uddi-technical
Subject: 
      [uddi-technical] T-model and wsdl

      
Hi all 
      (again),

      
 

      
I am working with IBM 
      uddi private registry, and I want to publish my wservices including wsdl 
      documents I need to explain them to clients (my ws are invoked by 
      SOAP server using wsdl documents); do you know how uddi allows 
      me to register them?

      
I have to consider a 
      wsdl document as a T-model? or as a bindingTemplate?

      
 

      
Thanks

      
 

      
francesco 

To unsubscribe from this 
      group, send an email 
      to:


Your 
      use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 
      

    
      
      

        Yahoo! Groups 
          Sponsor

      

        
          
            
            

              ADVERTISEMENT

      

        

To 
    unsubscribe from this group, send an email 
    to:


Your 
    use of Yahoo! Groups is subject to the Yahoo! Terms of Service.