UDDI With JAXR

[Faraz Ali]

Hi,

I am running the sample JAXR program shipped with j2ee tutorial. While running it, i am getting the exception below:

Created connection to registry
Got registry service, querymanager, and life cycle manager
Nov 12, 2008 12:09:39 PM com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection post
SEVERE: SAAJ0008: Bad Response; Not Found
javax.xml.registry.JAXRException: com.sun.xml.messaging.saaj.SOAPExceptionImpl: 
java.security.PrivilegedActionException: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Bad response: (404Not Found
at com.sun.xml.registry.uddi.RegistryServiceImpl.jaxmSend(Unknown Source)
at com.sun.xml.registry.uddi.RegistryServiceImpl.send(Unknown Source)
at com.sun.xml.registry.uddi.Processor.processRequestJAXB(Unknown Source)
at com.sun.xml.registry.uddi.UDDIMapper.getAuthorizationToken(Unknown Source)
at com.sun.xml.registry.uddi.ConnectionImpl.setCredentials(Unknown Source)
at com.web.services.register.JAXRPublish.executePublish(JAXRPublish.java:89)
at com.web.services.register.JAXRPublish.main(JAXRPublish.java:45)
Caused by: com.sun.xml.messaging.saaj.SOAPExceptionImpl: java.security.PrivilegedActionException: 
com.sun.xml.messaging.saaj.SOAPExceptionImpl: Bad response: (404Not Found
at com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection.call(HttpSOAPConnection.java:186)
... 7 more
Caused by: java.security.PrivilegedActionException: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Bad response: (404Not Found
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection.call(HttpSOAPConnection.java:180)
... 7 more
Caused by: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Bad response: (404Not Found
at com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection.post(HttpSOAPConnection.java:363)
at com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection$PriviledgedPost.run(HttpSOAPConnection.java:209)
... 9 more

Seems like it got the connection and registry service, but than it failed. Do i need to start the registry server? or need to do something else? I also add Registry entry through Sun App Server's admin console. Looks like there is a problem with security permission.

From the help window, i saw the note below

Note - The Application Server does not come with an internal registry. To publish web services to an internal registry, download and install the registry server. To publish a web service to an external registry, specify the address of the external registry.

Can you guys help me on this?

I also want to know that is UDDI or ebXML being used these days? or there is some alternate? I some posts here i read that no body is using JAXR and UDDI.

Thanks a lot,

[ UD: added linebreaks to preserve layout ]
[ November 12, 2008: Message edited by: Ulf Dittmer ]

[Ulf Dittmer]

I don't know what this error means specifically, but yes, you need a registry running somewhere in order to use JAXR/UDDI.

I agree that UDDI (and registries in general) have not taken off as people thought they would, and -IMO- are unlikely to do so any time soon.

[arulk pillai]

Originally posted by Ulf Dittmer:

I agree that UDDI (and registries in general) have not taken off as people thought they would, and -IMO- are unlikely to do so any time soon.

Very true. I have not come across one yet.

[Peer Reynders]

If you want to have a shot a your own registry for testing then look here.

Registries can still be useful internally/privately if they are used for dynamic configuration control. Provided the clients are appropriately equipped they could retrieve a service's new endpoint address from the registry if it moved; whether that is worth the effort is debatable.

Even back in 2004 Richard Monson-Haefel referred to "The Self-Organizing Myth" (p.167) - i.e.

...software applications could look up web services and integrate with them automatically, without any human intervention. ... The level of artificial intelligence required to make the heuristic decisions involved in choosing new business partners and integrating with foreign systems simply doesn't exist yet.

Nobody in their right mind would risk their business on somebody else's services unless the appropriate (legal) service level agreements (SLAs) are in place. So there is always "human intervention". Then when all the necessary SLAs are in place the WSDL/endpoint location can be exchanged via email or similar channels.

[Faraz Ali]

Hi,

This means GlassFish dont have its own registry. Yesterday i copied registryServer.war from JWSDP and deploy it into AS9.0. The program move 1 step further, but while saving the orgnization, it again threw exception.

The article you mention says that i need to setup JWSDP with tomcat (or AS8.0), and then have to start registry. Why? GlassFish itself dont support it? Its a kind of headache that to start registry i download jwsdp and tomcat.

[Ulf Dittmer]

Yes, it is a hassle. Neither JWSDP 1.6 nor 2.0 is compatible with GlassFish, so you will need to run whatever server they are compatible with in addition to GlassFish.

As mentioned above, UDDI isn't really used by anyone, so it's not too surprising that nobody bothered to make the registry compatible with recent servers. The only context in which it still pops up regularly is the SCDJWS certification.

[Peer Reynders]

Originally posted by Faraz Ali:
This means GlassFish dont have its own registry. ... Why? GlassFish itself dont support it?

Java API for XML Registries (JAXR)

The Java API for XML Registries (JAXR) gives you a uniform way to use business registries that are based on open standards (such as ebXML) or industry consortium-led specifications (such as UDDI).

JAXR is an access API - it is not an API to build registries. The Java Enterprise specification merely requires the platform to be able to access registries - the specification doesn't require that the platform itself includes a registry (though it could certainly host a vendor extension or third-party product if required).

It just so happens that the JWSDP included code for a sample registry. But the JWSDP targeted the J2EE 1.4 platform, not Java EE 5. The last JWSDP (2.0) was strange as it targeted the J2EE 1.4 platform running on the 1.5 JVM (not that strange as all JWSDPs were merely reference implementations that were not supported in production situations).
[ November 13, 2008: Message edited by: Peer Reynders ]