OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: How to model information with tModels


I need to associate behavioral information (described in a xml
document) to Web services. The xml file describe a WSDL:portType
behaviour. In the xml document there are the WSDL URL and the
WSDL:portType name.

My problem is how to model and integrate this new specification in UDDI.

I think I can adopt two possible solutions:

Solution A
Step A.1: Generate a Specification tModel (categorized as
"specification") for the new class of information to describe in UDDI:
<tModel tModelKey="BEHAV-TMODEL-KEY" >
    <name>
        Behavior Specification tModel
    </name>
    <overviewDoc>
         <overviewURL>
            http://www.myspecifications.com/serviceBehav.xsd
         <overviewURL>
    <overviewDoc>
<categoryBag>
 <keyedReference
    tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
    keyName="uddi-org:types"
    keyValue="specification"/>
 </categoryBag>
</tModel>

Hopely this tModel will be a registered tModel.

Step A.2: Every time a new behavior for a certain portType instance
need to be registered in the UDDI registry a new tModel like the
following will be published. This tModel points to the actual xml file
instance. The tModel's category bag will have a keyed reference
pointing to the above Specification tModel.

<tModel tModelKey="uuid:e8cf1163-8234-4b35-865f-94a7322e40c1" >
    <name>
        Service1
    </name>
    <overviewDoc>
         <overviewURL>
            http://myservice.com/behav1.xml
         <overviewURL>
    <overviewDoc>
    <categoryBag>
         <keyedReference
            tModelKey="BEHAV-TMODEL-KEY"
            keyName="behavioral spec"
            keyValue="" />
    </categoryBag>
</tModel>

Step A.3: Now we would like to add this behavioral specification to a
Web service.
Suppose our Web service has already been published in the UDDI
registry. It consist of several tModels (at least the portType and
binding tModels) and a bindingTemplate structure. The
bindingTemplate's tModelInstanceDetails collection points to the
tModels generated for the WSDL portType and binding. The behaviour can
be associated to the Web service adding a reference to the behavior
tModel in the bindingTemplate structure.
This can be done by adding a tModelInstanceInfo structure pointing to
the tModel in the bindingTemplate. The following example shows how
look like the reference to the new tModel (registered above) that will
be added to the bindingTemplate.

<tModelInstanceInfo
    tModelKey="uuid:e8cf1163-8234-4b35-865f-94a7322e40c1">
    <description xml:lang="en">
            The behavior the bindingTemplate complies to.
    </description>
</tModelInstanceInfo>


Solution B
Step B.1: Generate a Specification tModel as in SolutionA, step A.1
Step B.2: Generate an instance tModel as in SolutionA, step A.2
Step B.3: Add a keyedReference element to the portType tmodel the
specification refers to

Suppose the portType tModel in the registry is a as follow:
<tModel tModelKey="uuid:e8cf1163-8234-4b35-865f-94a7322e40c3" >
    <name>
         StockQuotePortType
    </name>
    <overviewDoc>
         <overviewURL>
             http://location/sample.wsdl
         <overviewURL>
    <overviewDoc>
    <categoryBag>
         <keyedReference
             tModelKey="uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824"
         keyName="portType namespace"
             keyValue="http://example.com/stockquote/"; />
         <keyedReference
             tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457"
         keyName="WSDL type"
             keyValue="portType" />
    </categoryBag>
</tModel>

This tModel will be updated including a new keyedReference:

<keyedReference
             tModelKey="BEHAV-TMODEL-KEY"
             keyName="behavioral spec"
             keyValue= "uuid:e8cf1163-8234-4b35-865f-94a7322e40c1" />

In Solution B the bindingTemplate structure is leaved as is.

Can anyone suggest if these solutions are both reasonable, if others
solutions are possible  and what is the best for my purpose?

Many thanks

Federica Ciotti


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]