----- Original Message -----
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
Francesco,
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
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:
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.