[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: How to model information with tModels
Is it possible to modify the "UDDI portType tModel" shown in the "Using WSDL in a UDDI Registry", Version 2.0.2, Technical Note in section 3.2.1? I would like to add a further keyedReference to this tModel. May this case interoperability problems to toolkits dealing with UDDI registries? On 4/19/07, Federica Ciotti <ciottif@gmail.com> wrote: > 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]