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: RE: [uddi-dev] Mapping Service

Thanks Clement,

Its reply it reanimated my desire to continue betting in the UDDI.

I go read your suggestions but I go explain my problem better to it.

I want store additionals informations of on service. for example: I have a service that it collects messurement data of utilization of one router. And I am interested in storing the following data on this service: Which interface was measured (eth0, eth1, ...), which the capacity of this interface(10MB, 1 Gb,...), which the type of this interface (ipv4, ipv6) and etc...

Now I have some questions:

First - I must create one tModel for each additionals informations?  Thus: e.g. Create the “interface tModel” where all "instance details" of this type (interface)  reference this tModel and the value like (eth0, eth1...) are stored In the field parameters of "instance details". It is solution solve the categorização problem. And the value (eth0, eth1 ...) it must be stored in "instance detail"?

Second - For each new value of interface (eth0, eth1...) I must create new tmodel which valeu eth0 or eth1... Thus can occur the creation of many tmodel depending on the varição of value (eth0, eth1, eth2 ...)


Luc Clement <lclement@mercury.com> escreveu:
This data maps directly to UDDI. Below is a very brief set of suggestions. I would recommend that you look at Appendix F: Using Categorization ( http://uddi.org/pubs/uddi_v3.htm#_Toc85908414 ) of the specification at it gives you examples of how to apply metadata to UDDI entities.
To get you started, I’d recommend that you read section 1.6 of the spec (http://uddi.org/pubs/uddi_v3.htm#_Toc85907986) . Another good reference are sections 2 & 3 of the WSDL interface mapping to UDDI (http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-wsdl-v202-20040631.htm#_Toc76437756) which will help you understand a mapping approach for you to consider.
… and then of course, product documentation is a very good source of information.
Hope this helps.
Luc Clément | Director, Product Management | Systinet, a Mercury Division |
Co-Chair, OASIS UDDI Technical Committee
One van de Graaff Drive Burlington, MA 01803
Phone +1 781.362.1330 | Mobile +1 978.793.2162 | Fax +1 781.362.1400 |
From: Herbert Souza [mailto:herbert_monteiro@yahoo.com.br]
Sent: Friday, June 16, 2006 16:28
To: uddi-dev@lists.oasis-open.org
Cc: herbert_monteiro@yahoo.com.br
Subject: [uddi-dev] Mapping Service
Hi all,

I looked for in some places, but I did not find a document that helped me.

I have the following information (in XML document) on a service and would like mapping in uddi. Only that not yet I found no project to make.
<nmwg:message type="RegisterRequest"




  <!-- Metadata is service info that other people
 can contact you with, it will

       be listed in the LS this way. -->     


  <nmwg:metadata id="meta1">

    <perfsonar:subject id="sub1">

      <psservice:service id="UDelMA1">

        <psservice:serviceName>UDel MA-1</psservice:serviceName>
[<lc>represented in UDDI as the service uddi:name element (see http://uddi.org/pubs/uddi_v3.htm#_Toc85908017). If you need to persist the service ID, I would either categorize the service using UDelMA1 or create an identifier system to do so.  From a commercial tooling perspective, you’ll find that using categorization (rather than trying to use an identifier system) will be the easiest approach. 


[<lc> Maps to the uddi:accessPoint element of the uddi:bindingTemplate – see http://uddi.org/pubs/uddi_v3.htm#_Toc85908021

[<lc>Maps to uddi:businessService’s uddi:description element – see http://uddi.org/pubs/uddi_v3.htm#_Toc85908018 





  <!-- Data is all of the capabilities (interfaces) you are monitoring, in the

       form of metadata blocks.  It is neccessary to wrap these in data blocks

       because they are measurement metadata (not service metadata) 

[<lc> Without getting into the details of why, this would be mapped to the bindingTemplate’s uddi:categoryBag (the means by which you attach metadata in UDDI). This approach will require the use of UDDI v3 which permits a categoryBag on a bindingTemplate – the bindingTemplate in essence represents a service instance. There are a number of UDDI v3 implementations that will allow you to exploit this capability of v3.
If you intend to use UDDI v2, then you will need to use the uddi:businessService element to hold the information. The implication of this will be a 1:1 correspondence between the service as represented in the registry and the instance deployed. 
Appendix F: Using Categorization (http://uddi.org/pubs/uddi_v3.htm#_Toc85908414) provides an example of how to exploit categorization as the means to hold your information.
I would recommend that the nmwgt: interface element’s content leverage a keyedReferenceGroup (see example F2 - http://uddi.org/pubs/uddi_v3.htm#_Toc85908416 
As for  nmwg:eventType, I would propose that you use a category to hold it – see F.1
As for
 nmwg:parameters I’m not clear given that I don’t know how you plan to use it. If however, you plan on using it to describe invocation parameters of the service, then you might want to consider the use of the uddi:instanceParms element of the instance details element. The instanceDetails holds service instance-specific information that is required to … provide further parameter and settings support.

  <nmwg:data id="data1"

    <nmwg:metadata id="meta2">

      <netutil:subject id="sub2">


          <nmwgt:ipAddress type="ipv4">xxx.xxx.xxx.xxx</nmwgt:ipAddress>




          <nmwgt:ifAddress type="ipv4">xxx.xxx.xxx.xxx</nmwgt:ifAddress>





      <nmwg:parameters id="paramid1">







The problem is that this message contains many information of one service and I am not understanding as to mapping these additional information in the UDDI (Interface, ifAdress, ifName...).

Best Regards.

Herbert Monteiro Souza
E-mail alternativo: hmsouza@pop.com.br
Cel.: 55 (71) 88029549
Tel. Com.: 55 (71)3300179

Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. Registre seu aparelho agora!

Herbert Monteiro Souza
E-mail alternativo: hmsouza@pop.com.br
Cel.: 55 (71) 88029549
Tel. Com.: 55 (71)3300179

Abra sua conta no Yahoo! Mail - 1GB de espaço, alertas de e-mail no celular e anti-spam realmente eficaz.

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