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 Luc Clement,

I did not have since that you answered my email inside of the XML code. Therefore I answered of that skill. But I see that what I thought is not very different of what you suggested me. Therefore I see that I am in the right way.

I was very happy with its help and since already I am thankful for it.

Best regards!

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

 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" metadataIdRef="meta1">

    <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">

        <nmwg:parameter name="valueUnits">octets</nmwg:parameter>






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

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

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