[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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:anne@manes.net] Sent: Thursday, September 19, 2002 11:19 AM To: uddi-technical@yahoogroups.com 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:
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
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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC