[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.