Hi Kurt
I honestly do not want to bug you with this. But the port types are
even documented properly in
http://svn.apache.org/repos/asf/webservices/juddi/branches/v3_trunk/docs/jUDDI-UserGuide.pdf
with the right names but no implemented as such.
1. UDDI_Security_PortType, defines the API to obtain a security token.
With a valid security token a
publisher can publish to the registry. A security token can be used
for the entire session.
2. UDDI_Publication_PortType, defines the API to publish business and
service information to the UDDI
registry.
3. UDDI_Inquiry_PortType, defines the API to query the UDDI registry.
Typically this API does not
require a security token.
4. UDDI_CustodyTransfer_PortType, this API can be used to transfer the
custody of a business from one
UDDI node to another.
5. UDDI_Subscription_PortType, defines the API to register for updates
on a particular business of service.
6. UDDI_SubscriptionListener_PortType, defines the API a client must
implement to recieve subscription
notifications from a UDDI node.
7. UDDI_Replication_PortType, defines the API to replicate registry
data between UDDI nodes.
8. UDDI_ValueSetValidation_PortType, by nodes to allow external
providers of value set validation. Web
services to assess whether keyedReferences or keyedReferenceGroups are
valid.
9. UDDI_ValueSetCaching_PortType, UDDI nodes may perform validation of
publisher references
themselves using the cached values obtained from such a Web service
Regards
Cedric
*From:* Kurt T Stam [mailto:[email protected]]
*Sent:* Tuesday, January 12, 2010 12:13 AM
*To:* Cedric Perrot; [email protected]
*Subject:* Re: jUDDI and SSL
Absolutely Cedric,
It may go in as soon as this week. Just add yourself to
http://issues.apache.org/jira/browse/JUDDI-336, and add yourself to
the mailing lists.
Cheers,
--Kurt
Cedric Perrot wrote:
Hello Kurt
I wondered if you could keep me posted in which release you are going
to implement the changes.
Best regards
Cedric
*From:* Cedric Perrot [mailto:[email protected]]
*Sent:* Friday, January 08, 2010 12:47 PM
*To:* 'Kurt T Stam'
*Cc:* '[email protected] <mailto:[email protected]>'
*Subject:* RE: jUDDI and SSL
Hello Kurt
I've done the changes and attached a sample project for your
convenience. For the sample to work you must change the uddi business
key in the HelloWorld.java file to an existing business key in the
UDDI registry.
@UDDIService(
//USA WORKS
businessKey="uddi:5f7a5d60-f83a-11de-8c32-783b81118c32",
serviceKey="uddi:72b4642c-4153-4e12-9d7e-c46936587f61",
description = "Hello World test service")
Furthermore I introduced another flag in the uddi.xml
<clerks registerOnStartup=/"true"/
/isRegisterJUDDIPortalOnStartup/=/"false"/>
<clerk name=/"BobCratchit"/ node=/"default"/
publisher=/"admin"/ password=/"changeit"/>
<class>_ch.pesto.services.HelloWorld_</class>
</clerk>
Injected following code into UDDIClerkManager.java
*public* *synchronized* *static* *void* start() *throws*
ConfigurationException {
*if* (/manager/!=*null*) {
/log/.warn("ClerkManager was already started. Going
to reload..");
/manager/.releaseResources();
/manager/.clientConfig.loadManager();
} *else* {
/log/.info("Starting UDDI Clerks...");
/manager/ = *new* UDDIClerkManager();
}
*if*
(/manager/.clientConfig.isRegisterJUDDIPortalOnStartup()) {
/manager/.saveClerkAndNodeInfo();
}
*if* (/manager/.clientConfig.isRegisterOnStartup()) {
/manager/.registerAnnotatedServices();
/manager/.xRegister();
}
/log/.info("Clerks started succesfully for manager " +
/manager/.clientConfig.getManagerName());
}
And last but not least I had to change the port types to fit the
oracle registry. I must say though, that based on the spec’s Oracle’s
registry is doing the right thing.
That’s what I have changed to make jUDDI UDDI v3 compliant.
In Transport.java I changed
From:
// public final static String API_V3_NAMESPACE =
"urn:uddi-org:api_v3_portType";
To:
*public* *final* *static* String /API_V3_NAMESPACE/
= "urn:uddi-org:api_v3";
this was probably a typo anyway and
From:
// public final static String INQUIRY_SERVICE =
"UDDIInquiryService";
// public final static String SECURITY_SERVICE =
"UDDISecurityService";
// public final static String PUBLISH_SERVICE =
"UDDIPublishService";
// public final static String SUBSCRIPTION_SERVICE =
"UDDISubscriptionService";
// public final static String CUSTODY_TRANSFER_SERVICE =
"UDDICustodyTransferService";
// public final static String SUBSCRIPTION_LISTENER_SERVICE =
"UDDISubscriptionListenerService";
To:
*public* *final* *static* String /INQUIRY_SERVICE/
= "UDDI_Inquiry_SoapService";
*public* *final* *static* String /SECURITY_SERVICE/
= "UDDI_Security_SoapService";
*public* *final* *static* String /PUBLISH_SERVICE/
= "UDDI_Publication_SoapService";
*public* *final* *static* String /SUBSCRIPTION_SERVICE/
= "UDDI_Subscription_Service";
*public* *final* *static* String /SUBSCRIPTION_LISTENER_SERVICE/
= "UDDI_SubscriptionListener_SoapService";
*public* *final* *static* String /CUSTODY_TRANSFER_SERVICE/
= "UDDI_Ownership_Transfer_SoapService";
UDDI API v3 specs.
http://documentation.softwareag.com/webmethods/soal8/pdf/dg-uddi/uddiapi.pdf
have a look at this spec.
e.g interface definition
http://documentation.softwareag.com/webmethods/inm8/jd/uddiv3ClientAPI/com/centrasite/uddiv3/client/UDDI_Inquiry_SoapService.html
http://documentation.softwareag.com/webmethods/inm8/jd/uddiv3ClientAPI/com/centrasite/uddiv3/client/UDDI_SubscriptionListener_SoapService.html
and all others….
Thanks again for your help and I’m glad I could contribute. If you
have any questions don’t hesitate to contact me.
Regards
Cedric
-----Original Message-----
From: Kurt T Stam [mailto:[email protected]]
Sent: Friday, January 08, 2010 5:38 AM
To: [email protected] <mailto:[email protected]>
Cc: [email protected] <mailto:[email protected]>
Subject: Re: jUDDI and SSL
Actually the flag is there and is called isRegisterOnStartup.
<clerks registerOnStartup="false">
if that is set up false it should not be using the JUDDIApi.
--K
manager.clientConfig.isRegisterOnStartup
Kurt T Stam wrote:
> Yes actually this post should have all the info you need:
>
>
http://apachejuddi.blogspot.com/2009/11/uddi-annotations-how-do-i-self-register.html
>
>
> I think we just need some flag to turn off persisting the Clerk and
> Node info to the DB. This is really only needed for Subscriptions. I'm
> pretty sure it is kept in memory anyway, so you should simply be able
> to comment out that part:
>
> public void saveClerkAndNodeInfo() in the UDDIClerkManager.
>
> for now to prove that. it still needs a clerk to publish to the
> registry (think of it as a datasource where you put your name and
> password).
>
> It would be really cool to make this work. So I'm looking forward to
> your changes. maybe you can add them as patches to
> http://issues.apache.org/jira/browse/JUDDI-336.
>
> We currently working hard towards 3.0.1, which should come out in a
> few weeks. So it'd be cool to roll it in there. Please let us know how
> else we can help you :)
>
> --Kurt
>
> Cedric Perrot wrote:
>> Hello Kurt
>>
>> Would you have a code snippet or hint on how to go about in terms of
>> integrating
>> the webservice with @UDDI* annotations and self-registration without
>> the clerks
>> and JUDDIApiImpl.
>>
>> I am happy to provide you all the changes I've made to make Oracle
>> (Systinet)
>> Registry work. In order for you to integrate it.
>>
>> Any help greatly appreciated.
>>
>> Regards
>>
>> Cedric
>>
>> On Wed 6/01/10 15:01 , Kurt T Stam [email protected]
<mailto:[email protected]> sent:
>>
>>> I finally understand what it is you're trying to :). And yes you
>>> *should* be possible to use the juddi client, but you're right you
>>> can't use the JUDDIApi as this is specific to jUDDI, which is why it
>>> is in a separate API. The other APIs are directly taken from the UDDI
>>> spec, so they should work fine. To answer your question, we have not
>>> tested it against Oracle's Registry. What you should do is compare the
>>> WSDLs of the Security and Inquiry APIs. The service names you
>>> mentioned earlier are taken directly from the WSDL. If Oracle/systinet
>>> uses different names, then I guess they deviate from the spec, but we
>>> maybe be able to make this configurable if this is the only thing
>>> needed to make it work.
>>> --Kurt
>>> Cedric Perrot wrote:
>>> Hello everyone After investigating the juddi client for almost 2
>>> days, I have to
>>> ask you. Have you ever tested a UDDI Registry other than jUDDI? Is it
>>> even possible to integrate Oracle's Registry with the
>>> org.apache.juddi.api.impl.JUDDIApiImpl dependency in the client
>>> library, which is only implemented by jUDDI?!?!? Is there a way for
>>> a slick integration of the client to connect to
>>> another UDDI Registry????? If yes, how. Any help greatly
>>> appreciated. Thanks in advance Regards Cedric FROM: Cedric Perrot
>>> [mailto:[email protected]] SENT: Wednesday, January 06, 2010 12:07 PM
>>> TO: '[email protected] <mailto:[email protected]>'
>>> CC: 'Kurt T Stam'; '[email protected] <mailto:[email protected]>';
'[email protected] <mailto:[email protected]>';
>>> '[email protected] <mailto:[email protected]>'; 'Steve Viens';
'[email protected] <mailto:[email protected]>'
>>> SUBJECT: RE: jUDDI and SSL Hello Tom I am trying to create a
>>> webservice running in glassfish app server
>>> using the juddi client libraries. I want to register the webservice
>>> with Oracle Registry 11.1 (Systinet). The error mentioned below is
>>> thrown in your code of the juddi
>>> client.
>>> Your Transport.java class file
>>>
>>>> public final static String INQUIRY_SERVICE =
>>>>
>>> "UDDIInquiryService";
>>>
>>>> public final static String SECURITY_SERVICE =
>>>>
>>> "UDDISecurityService";
>>>
>>>> public final static String PUBLISH_SERVICE =
>>>>
>>> "UDDIPublishService"; And the exception is being thrown here in the
>>> jUddi class
>>> JAXWSTransport.java public UDDISecurityPortType
>>> getUDDISecurityService(String
>>> endpointURL) throws TransportException { if (securityService==null) {
>>> try {
>>> if (endpointURL==null) endpointURL =
>>>
UDDIClerkManager.getClientConfig().getUDDINode(nodeName).getSecurityUrl();
>>>
>>>
>>>
>>> QName qName = new
>>> QName(Transport.API_V3_NAMESPACE, Transport.SECURITY_SERVICE);
>>>
>>>>> EXCEPTION THROWN HERE >>> SERVICE SERVICE = SERVICE.CREATE(NEW
>>>>>
>>> URL(ENDPOINTURL), QNAME);
>>> securityService = (UDDISecurityPortType)
>>> service.getPort(UDDISecurityPortType.class);
>>> } catch (Exception e) {
>>> throw new TransportException(e.getMessage(),
>>> e);
>>> }
>>> }
>>> return securityService;
>>> } I hope I made myself clearer this time. Thanks again for your
>>> swift replies, it is highly appreciated. Regards Cedric
>>> -----Original Message-----
>>> From: Tom Cunningham [mailto:[email protected]] Sent: Wednesday,
>>> January 06, 2010 12:13 AM
>>> To: Cedric Perrot
>>> Cc: 'Kurt T Stam'; [email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>;
>>> [email protected] <mailto:[email protected]>; 'Steve Viens';
[email protected] <mailto:[email protected]>
>>> Subject: Re: jUDDI and SSL Cedric, Back to Kurt's question- you're
>>> trying to bring jUDDI up under
>>> https? Looks like your problem below is lack of underscores
>>> (UDDISecurityService != UDDI_SecuritySoapService). Can you
>>> configure this in your webservice descriptor rather than changing
>>> code? --Tom Cedric Perrot wrote:
>>>
>>>> Hello Kurt
>>>> I found the problem with PKIX certificate error. I was
under the
>>>>
>>> assumption
>>>
>>>> that the application server would take the JAVA keystore whereas
>>>>
>>> it has its
>>>
>>>> own. I added the certificate to the application servers keystore
>>>>
>>> and it
>>>
>>>> doesn't throw the PKIX error but now a new one which I think is
>>>>
>>> about the
>>>
>>>> interfaces of the Oracle Registry.
>>>> Any hints are highly appreciated:
>>>> Error message: javax.xml.ws.WebServiceException:
>>>> {urn:uddi-org:api_v3_portType}UDDISecurityService is not a valid
>>>>
>>> service.
>>>
>>>> Valid services are:
>>>
{urn:uddi-org:api_v3}UDDI_Inquiry_SoapService,{urn:uddi-org:api_v3}UDDI_Pub
>>>
>>> l
>>>
>>>
>>>> ication_SoapService,{urn:uddi-org:api_v3}UDDI_Security_SoapService
>>>>
>>>
>>>>
>>>> do I need to change the Strings: public final
>>>> static String INQUIRY_SERVICE =
>>>> "UDDIInquiryService"; public final static String
>>>> SECURITY_SERVICE = "UDDISecurityService";
>>>> public final static String PUBLISH_SERVICE =
>>>> "UDDIPublishService"; to public final static
>>>> String INQUIRY_SERVICE =
>>>> "UDDI_Inquiry_SoapService"; public final static String
>>>> SECURITY_SERVICE = "UDDI_Security_SoapService";
>>>> public final static String PUBLISH_SERVICE
>>>> = "UDDI_Publication_SoapService";
>>>> is Oracle Registry not conforming to standards?????
>>>> Thanks for your help guys.
>>>> Regards
>>>> Cedric
>>>>
>>>> -----Original Message----- From: Kurt T Stam
>>>> [mailto:[email protected]] Sent: Tuesday, January 05, 2010
>>>> 8:33 PM To: Cedric Perrot Cc: [email protected]
<mailto:[email protected]>;
>>>> [email protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>;
>>>>
>>> Steve Viens;
>>>
>>>> [email protected] <mailto:[email protected]>
Subject: Re: jUDDI and SSL
>>>> Cedric Perrot wrote:
>>>>> Hello everyone
>>>>> I am using your jUDDI libraries as client only as I'm using
>>>>>
>>> Oracle
>>>
>>>>> Registry 11.1.
>>>>> Is there a way to connect to https publishing services? I am
>>>>>
>>> getting
>>>
>>>>> the PKIX certificate error in Java.
>>>>> Although, I have imported the certificate into the cacerts
>>>>> of my
>>>>>
>>> jdk1.6.
>>>
>>>>>
>>>>> All test client are working like a breeze. Is there anything
>>>>>
>>> which
>>>
>>>>> needs to be configured to connect to a https publishing url?
>>>>>
>>>>> Thanks in advance for your help.
>>>>> Regards
>>>>> Cedric
>>>>>
>>>> Hi Cedric,
>>>> I'm not sure what you're trying to do, bringing jUDDI up on
>>>> https
>>>>
>>> or
>>>
>>>> registering https services in jUDDI.
>>>> Thx,
>>>> --Kurt
>>>>
>>>
>>
>>
>
