you referring to the V1.07 Best Practice document, dated May 21,
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.
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
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).
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.)?
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
----- Original Message -----
Sent: Thursday, September 19, 2002 4:38
Subject: [uddi-spec] WSDL best
I'm not sure if we're ready to get into issues yet,
but I'd like to put this one on the table.
have some misgivings about the current WSDL best practices document. I've
outlined the issue in the email below.
- We create a set of
canonical tModels to represent various types of
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
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
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
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,
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.
goes into great detail about the mappings between WSDL and UDDI using both
the UDDI best practice approach and the Systinet
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?
To unsubscribe from this
group, send an email
use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
unsubscribe from this group, send an email
use of Yahoo! Groups is subject to the Yahoo! Terms of Service.