I just ran the JAXR TCK tests using Scout-1.2.5 and a jUDDI-3.1.3 instance as the Registry backend. I was pleasantly surprised:
Test results: passed: 1,340; failed: 32
32 fails.. Almost there! Back to bug fix mode.
-----------------------
Update:
It looks like I found one real bug in scout (SCOUT-129) and one issue to with being backwards compatible with UDDI v2 default settings (SCOUT-127). A full run of all the JAXR tests results now in:
Test results: passed: 1,372
no fails, Hurray :)!
Going to prepare Scout-1.2.6 and jUDDI-3.1.4.
Monday, February 27, 2012
Tuesday, February 21, 2012
Using JAXR on JBoss 7.1.1
Introduction
One of the Technologies specified in the JEE6 Specification is the Java API for XML Registries (JSR 93). Apache Scout is the implementation of this specification. This specification is a client side library to interact with an XML Registry. Examples of XML Registries are UDDI and ebXML. To make a long story short, every Application Server needs to ship with a JAXR implementation, and this is what I have been helping out on.
JBoss JAXR module
On and off over the last few months I have been working on a JAXR module for JBoss-AS-7.1. The requirement for it was such that it needed to pass the JEE6 TCK, and that it should be able to interact with both UDDI v2 and v3 registries. Previous version of JBoss-AS have always shipped with a jUDDI v2 registry but, for the time being, it was decided to ship the client libraries only this time, which is the only JEE6 required component anyway. In other words, you need to have a running instance of jUDDI for the JAXR module to connect to.
How to use it?
Your deployment will only need to depend on the JAXR API, if you are using maven add the following to the dependencies section in your pom:
What if I don't want to use the default JAXR module configuration?
The default JAXR configuration lives in the standalone/configuration/standalone.xml:
JAXR specifies the following properties:
Figure 1. The JAXR properties as specified in the JAXR specification.
and by default the following properties are set:
Additionally, when using the Scout implementation is used, the following properties are set by default
To use JAXR in the default configuration, simply use a standalone/configuration/standalone.xml with the following jaxr section:
This means that by default Scout connects to the UDDI registry using the UDDI v2 API specification, using the SaajTransport class. It is this configuration that was used for TCK compatibility testing as the JAXR specification has not been updated since the UDDI v3 specification was published.
What if I want to connect to a UDDI v3 Registry?
The Apache Scout implementation supports connecting to a UDDI v3 registry. For this it uses the jUDDI-client library, and the JBoss JAXR module supports using the following configuration in the standalone/configuration/standalone.xml:
Override the properties set in the configuration
In the first code fragment of this blog post it was shown that you can set properties before using the connection, using jaxrFactory.setProperties(properties). This will add these properties, or override the defaults. This way you can override property setting programmatically.
This concludes this post on using JAXR on JBoss-AS7.1. If you would like to add an entry on how to use Scout on another Application Server, then by all means send it to us and we will add it!
Cheers,
--Kurt
One of the Technologies specified in the JEE6 Specification is the Java API for XML Registries (JSR 93). Apache Scout is the implementation of this specification. This specification is a client side library to interact with an XML Registry. Examples of XML Registries are UDDI and ebXML. To make a long story short, every Application Server needs to ship with a JAXR implementation, and this is what I have been helping out on.
JBoss JAXR module
On and off over the last few months I have been working on a JAXR module for JBoss-AS-7.1. The requirement for it was such that it needed to pass the JEE6 TCK, and that it should be able to interact with both UDDI v2 and v3 registries. Previous version of JBoss-AS have always shipped with a jUDDI v2 registry but, for the time being, it was decided to ship the client libraries only this time, which is the only JEE6 required component anyway. In other words, you need to have a running instance of jUDDI for the JAXR module to connect to.
How to use it?
Your deployment will only need to depend on the JAXR API, if you are using maven add the following to the dependencies section in your pom:
Now you can get a handle to the JAXR ConnectionFactory simply by looking it up in JNDIjavax.xml jaxr-api 1.0_04 provided
InitialContext context = new InitialContext();
ConnectionFactory jaxrFactory = (ConnectionFactory) context.lookup("java:jboss/jaxr/ConnectionFactory");
Properties properties = new Properties();
...
//set some JAXR properties
...
jaxrFactory.setProperties(properties);
connection = jaxrFactory.createConnection();
//now you can set the credentials on this connection.
PasswordAuthentication passwdAuth = new PasswordAuthentication(userid, passwd.toCharArray());
Set creds = new HashSet();
creds.add(passwdAuth);
connection.setCredentials(creds);
at this point you should be able to execute any JAXR registry command. Make sure to add your own exception handling.What if I don't want to use the default JAXR module configuration?
The default JAXR configuration lives in the standalone/configuration/standalone.xml:
| connection-factory attribute | default value | description | required |
|---|---|---|---|
| jndi-name | - | Name used to bind into JNDI | Y |
| class | org.apache.ws.scout. registry.ConnectionFactoryImpl | Class name of the JAXR implementation the JAXR module will instantiate | N |
| property attribute | default value | description | required |
| name | - | Name of the JAXR property | Y |
| value | - | Value of the JAXR property | Y |
JAXR specifies the following properties:
and by default the following properties are set:
| JAXR property name | default value |
|---|---|
| javax.xml.registry.queryManagerURL | http://localhost:8080/juddi/inquiry |
| javax.xml.registry.lifeCycleManagerURL | http://localhost:8080/juddi/publish |
Additionally, when using the Scout implementation is used, the following properties are set by default
| Scout property name | default value |
|---|---|
| scout.proxy.uddiVersion | 2.0 |
| scout.proxy.uddiNamespace | urn:uddi-org:api_v2 |
| scout.proxy.transportClass | org.apache.ws.scout.transport.SaajTransport |
To use JAXR in the default configuration, simply use a standalone/configuration/standalone.xml with the following jaxr section:
This means that by default Scout connects to the UDDI registry using the UDDI v2 API specification, using the SaajTransport class. It is this configuration that was used for TCK compatibility testing as the JAXR specification has not been updated since the UDDI v3 specification was published.
What if I want to connect to a UDDI v3 Registry?
The Apache Scout implementation supports connecting to a UDDI v3 registry. For this it uses the jUDDI-client library, and the JBoss JAXR module supports using the following configuration in the standalone/configuration/standalone.xml:
Override the properties set in the configuration
In the first code fragment of this blog post it was shown that you can set properties before using the connection, using jaxrFactory.setProperties(properties). This will add these properties, or override the defaults. This way you can override property setting programmatically.
This concludes this post on using JAXR on JBoss-AS7.1. If you would like to add an entry on how to use Scout on another Application Server, then by all means send it to us and we will add it!
Cheers,
--Kurt
Friday, February 17, 2012
Release announcement jUDDI-3.1.3 and Scout-1.2.5
The jUDDI team is proud to announce the release of jUDDI-3.1.3 and Scout-1.2.5. Besides bug fixes, the latest release of jUDDI has seen development on the jUDDI client to make it easier to interact with the UDDI Registries. Besides using the client code to access our own Apache jUDDI Registry it has been tested to work with for example Systinet's and SAP's Registries. We added some interesting features to the client such as a clientside cache and the registration of WSDL and BPEL processes according to respectively technote Using WSDL in a UDDI Registry, Version 2.0.2 and Using BPEL4WS in a UDDI registry. More details on how to use this will follow.
On the JAXR front we made sure Scout-1.2.5 passes all tests in the JEE6 TCK. The tests were run using a jUDDI v2 registry, but we plan to make sure they also work using the latest jUDDI v3 registry.
The releases can be downloaded at:
http://juddi.apache.org/scout/releases.html and
http://juddi.apache.org/releases.html
Cheers!
--Kurt
On the JAXR front we made sure Scout-1.2.5 passes all tests in the JEE6 TCK. The tests were run using a jUDDI v2 registry, but we plan to make sure they also work using the latest jUDDI v3 registry.
The releases can be downloaded at:
http://juddi.apache.org/scout/releases.html and
http://juddi.apache.org/releases.html
Cheers!
--Kurt
Monday, May 23, 2011
Getting Started with UDDI v3
Nowadays it is very easy to get started with a UDDI v3 registry. Here are the steps to get started with jUDDI v3.
1. From the jUDDI releases page, download the latest jUDDI v3 tomcat-bundle, or if you want an additional browser then you can download the portal-bundle.
2. Unzip the bundle and start the server by running thebin/start.sh (use the start.bat on windows).
3. Since the UDDI v3 API is a WebServices API you can interact with it using tools like SoapUI. Visit http://www.soapui.org/ to download SoapUI. Unzip the SoapUI.zip and start it using/bin/soapui.sh.
4. Open your browser to http://localhost:8080/juddiv3, and save the wsdls for the security, publish and inquiry API.
5. Import these WSDLs into a SoapUI project, and you are now ready to use the API. See also the demo to publish and delete a business.
The demo is broken down into 2 parts, please scroll down for part 2 of the demo.
1. From the jUDDI releases page, download the latest jUDDI v3 tomcat-bundle, or if you want an additional browser then you can download the portal-bundle.
2. Unzip the bundle and start the server by running the
3. Since the UDDI v3 API is a WebServices API you can interact with it using tools like SoapUI. Visit http://www.soapui.org/ to download SoapUI. Unzip the SoapUI.zip and start it using
4. Open your browser to http://localhost:8080/juddiv3, and save the wsdls for the security, publish and inquiry API.
5. Import these WSDLs into a SoapUI project, and you are now ready to use the API. See also the demo to publish and delete a business.
The demo is broken down into 2 parts, please scroll down for part 2 of the demo.
Tuesday, April 19, 2011
WSDL to UDDI Mapping
I was just working on added the standard WSDL and BPEL to UDDI mappings to the the juddi-client, when I came across this article. Nice post Kasun.
Kasun's Blog: WSDL to UDDI Mapping: "Introduction Universal Description, Discovery and Integration (UDDI) is a platform independent, Extensible Markup Language (XML) based..."
--Kurt
Kasun's Blog: WSDL to UDDI Mapping: "Introduction Universal Description, Discovery and Integration (UDDI) is a platform independent, Extensible Markup Language (XML) based..."
--Kurt
Friday, March 11, 2011
How to register Java RMI services into jUDDI
The UDDI v3 specification speaks about 5 UDDI transport tModels to define the type of protocol a binding of a service is using.
11.3.3 UDDI HTTP Transport
11.3.4 UDDI SMTP Transport
11.3.5 UDDI FTP Transport
11.3.6 UDDI Fax Transport
11.3.7 UDDI Telephone Transport
The jUDDI project is adding out-of-the-box support for RMI. For an application written in Java we think it makes sense to support Java specific transports and starting at with the jUDDI-3.1 release we will support two more Transports: rmi and jndi-rmi, where the jndi-rmi transport is a special version of the rmi transport (We'll come back to that later).
Introduction
In UDDI, tModels are used to establish the existence of a variety of concepts and to point to their technical definitions. Transport tModels are referenced by service bindings to describe the type of transport used to invoke the service, either when other parts of the technical fingerprint (other tModels referenced in the same bindingTemplate) do not specify the transport used by the particular service binding, or when the service provider wants to explicitly call out the transport in the technical fingerprint so as to enable discovery. Transport tModels are frequently coupled with other tModels that describe more completely what the service does. For example, the RMI Transport tModel may be coupled with the SOAP Protocol tModel to indicate that a Web service communicates using SOAP over RMI. The RMI Transport tModel provides a means for designating that services transport messages using the RMI protocol.
Design Goals
The RMI Transport tModel is provided to enable discovery of services that transport messages using the RMI protocol. This tModel can be used alone to provide a technical fingerprint for simple services that are accessed through HTTP when they might otherwise not have a tModel to reference in their bindingTemplates, or it can be used in conjunction with other protocol tModels to indicate the applicable transport when other parts of the technical fingerprint are ambiguous or silent with respect to the transport to use.
UDDI RMI Transport tModel Definition
Name: uddi-org:rmi
Description: A Java service that uses RMI transport
UDDI Key (V3): uddi:uddi.org:transport:rmi
Evolved V1,V2 format key: N/A
Categorization: transport
UDDI RMI Transport
UDDI RMI Transport tModel Structure
UDDI RMI Transport Example of use
The following is a typical bindingTemplate for a simple service that references the RMI Transport tModel:
UDDI JNDI-RMI Transport tModel Definition
Name: uddi-org:jndi-rmi
Description: A Java service that uses JNDI-RMI transport
UDDI Key (V3): uddi:uddi.org:transport:jndi-rmi
Evolved V1,V2 format key: N/A
Categorization: transport
UDDI RMI Transport
UDDI JNDI-RMI Transport tModel Structure
UDDI JNDI-RMI Transport Example of use
The following is a typical bindingTemplate for a simple service that references the JNDI-RMI Transport tModel. Optionally an InitialContext can be provided in the instanceParms, which should be used by the client at runtime to lookup the service as registered in that JNDI (somecontext/shopService) in this case:
Other UDDI registries will also be able to store RMI based services, as long as you add the
'uddi:uddi.org:transport:rmi' and 'uddi:uddi.org:transport:jndi-rmi' tModels.
Cheers,
--Kurt
11.3.3 UDDI HTTP Transport
11.3.4 UDDI SMTP Transport
11.3.5 UDDI FTP Transport
11.3.6 UDDI Fax Transport
11.3.7 UDDI Telephone Transport
The jUDDI project is adding out-of-the-box support for RMI. For an application written in Java we think it makes sense to support Java specific transports and starting at with the jUDDI-3.1 release we will support two more Transports: rmi and jndi-rmi, where the jndi-rmi transport is a special version of the rmi transport (We'll come back to that later).
Introduction
In UDDI, tModels are used to establish the existence of a variety of concepts and to point to their technical definitions. Transport tModels are referenced by service bindings to describe the type of transport used to invoke the service, either when other parts of the technical fingerprint (other tModels referenced in the same bindingTemplate) do not specify the transport used by the particular service binding, or when the service provider wants to explicitly call out the transport in the technical fingerprint so as to enable discovery. Transport tModels are frequently coupled with other tModels that describe more completely what the service does. For example, the RMI Transport tModel may be coupled with the SOAP Protocol tModel to indicate that a Web service communicates using SOAP over RMI. The RMI Transport tModel provides a means for designating that services transport messages using the RMI protocol.
Design Goals
The RMI Transport tModel is provided to enable discovery of services that transport messages using the RMI protocol. This tModel can be used alone to provide a technical fingerprint for simple services that are accessed through HTTP when they might otherwise not have a tModel to reference in their bindingTemplates, or it can be used in conjunction with other protocol tModels to indicate the applicable transport when other parts of the technical fingerprint are ambiguous or silent with respect to the transport to use.
UDDI RMI Transport tModel Definition
Name: uddi-org:rmi
Description: A Java service that uses RMI transport
UDDI Key (V3): uddi:uddi.org:transport:rmi
Evolved V1,V2 format key: N/A
Categorization: transport
UDDI RMI Transport
UDDI RMI Transport tModel Structure
<tModel
tModelKey="uddi:uddi.org:transport:http">
<name>uddi-org:rmi</name>
<description>Java RMI based service registered to the Java Registry</description>
<overviewDoc>
<overviewURL useType="text">
http://juddi.apache.org/docs/3.0/userguide/html/chap-root_seed_data.html#sect-rmi
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference keyName="uddi-org:types:transport"
keyValue="transport"
tModelKey="uddi:uddi.org:categorization:types"/>
</categoryBag>
</tModel>
UDDI RMI Transport Example of use
The following is a typical bindingTemplate for a simple service that references the RMI Transport tModel:
<bindingTemplate bindingKey="uddi:...." serviceKey="uddi:....">
<description xml:lang="en">Buy from Bigfoot Breweries over
the Web</description>
<accessPoint useType="endpoint"
rmi://hostname:1099/shopService
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo
tModelKey="uddi:uddi.org:transport:rmi />
</tModelInstanceDetails>
</bindingTemplate>
UDDI JNDI-RMI Transport tModel Definition
Name: uddi-org:jndi-rmi
Description: A Java service that uses JNDI-RMI transport
UDDI Key (V3): uddi:uddi.org:transport:jndi-rmi
Evolved V1,V2 format key: N/A
Categorization: transport
UDDI RMI Transport
UDDI JNDI-RMI Transport tModel Structure
<tModel
tModelKey="uddi:uddi.org:transport:jndi-rmi">
<name>uddi-org:jndi-rmi</name>
<description> A Java RMI based service registered to a JNDI Registry </description>
<overviewDoc>
<overviewURL useType="text">
http://juddi.apache.org/docs/3.0/userguide/html/chap-root_seed_data.html#sect-jndi-rmi
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference keyName="uddi-org:types:transport"
keyValue="transport"
tModelKey="uddi:uddi.org:categorization:types"/>
</categoryBag>
</tModel>
UDDI JNDI-RMI Transport Example of use
The following is a typical bindingTemplate for a simple service that references the JNDI-RMI Transport tModel. Optionally an InitialContext can be provided in the instanceParms, which should be used by the client at runtime to lookup the service as registered in that JNDI (somecontext/shopService) in this case:
<bindingTemplate bindingKey="uddi:...." serviceKey="uddi:....">
<description xml:lang="en">Buy from Bigfoot Breweries over
the Web</description>
<accessPoint useType="endpoint"
jndi-rmi://somecontext/shopService
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo
tModelKey="uddi:uddi.org:transport:jndi-rmi />
<instanceParms>
<![CDATA[
<?xml version="1.0" encoding="utf-8" ?>
<initialContextInfo>
<contextProperty name="java.naming.factory.initial"
value="org.jnp.interfaces.NamingContextFactory"/>
<contextProperty name="java.naming.provider.url"
value="jnp://localhost:1099"/>
<contextProperty name="java.naming.factory.url.pkgs"
value="org.jboss.naming:org.jnp.interfaces"/>
</initialContextInfo>
]]>
</tModelInstanceDetails>
</bindingTemplate>
Other UDDI registries will also be able to store RMI based services, as long as you add the
'uddi:uddi.org:transport:rmi' and 'uddi:uddi.org:transport:jndi-rmi' tModels.
Cheers,
--Kurt
Monday, November 8, 2010
RiftSaw integrates jUDDI for auto-registration of BPEL processes.
Recently I worked on RiftSaw. RiftSaw is the Apache ODE BPEL engine deployed to JBoss. The deployment code in RiftSaw allows BPEL processes to be deployed to the appserver in jar archives. When the BPEL process is deployed both the Service and its BindingTemplate (EndPoint information) are registered, and a partnerLinkChannel is created for each partnerLink. UDDI lookup will obtain the WSDL Endpoint from the UDDI and access this URL to obtain the WSDL straight from the Service. Upon undeployment the BindingTemplate is removed from the UDDI Registry. The Service is removed with the removal of the last BindingTemplate. For more information see the RiftSaw User Guide. This functionality allows for dynamic endpoint discovery of BPEL Services.
Most of the functionality developed for RiftSaw integration is part of the jUDDI client code. If you are interested check out the functionality of the UDDIClerk. Note that the same UDDIClerk is used by the UDDI Annotations.
Cheers,
--Kurt
Most of the functionality developed for RiftSaw integration is part of the jUDDI client code. If you are interested check out the functionality of the UDDIClerk. Note that the same UDDIClerk is used by the UDDI Annotations.
Cheers,
--Kurt
Subscribe to:
Posts (Atom)
