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:colgrave@hursley.ibm.com]
Sent: Tuesday, September 24, 2002 9:12 AM
To: Anne Thomas Manes; Uddi-Spec
Subject: Re: [uddi-spec] WSDL best practiceAnne,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 ManesTo: Uddi-SpecSent: Thursday, September 19, 2002 4:38 PMSubject: [uddi-spec] WSDL best practiceI'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:anne@manes.net]
Sent: Thursday, September 19, 2002 11:19 AM
To: uddi-technical@yahoogroups.com
Subject: RE: [uddi-technical] T-model and wsdlFrancesco,Here is the official UDDI best practices document that explains how to use WSDL with UDDI: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.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: bernardini@dis.uniroma1.it [mailto:bernardini@dis.uniroma1.it]
Sent: Thursday, September 19, 2002 6:42 AM
To: uddi-technical
Subject: [uddi-technical] T-model and wsdlHi 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?Thanksfrancesco
To unsubscribe from this group, send an email to:
uddi-technical-unsubscribe@egroups.com
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:
uddi-technical-unsubscribe@egroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.