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

jUDDI TLP has new website location

Now that jUDDI has become a Top Level Project, our coordinates are changing. Most noticeably our site is now found at juddi.apache.org and Scout is found at juddi.apache.org/scout/. Our mailing lists have been migrated (along with the existing users and archives). We now have user@juddi.apache.org and dev@juddi.apache.org, for both jUDDI and Scout. Please update your bookmarks.

Cheers,

--Kurt

Short introduction to the jUDDI QA Process

We've recorded a short presentation about the jUDDI QA Process. We believe that there are three levels of testing:

Unit tests

• Functionality
  
• Regression of components

Integration tests

• System level functionality
• Regression across components

QA tests

• Long running and repetitive, simulating real user load (memory leaks, performance)

For the QA tests we use XLT, and it it's simplest form the XLT agent and reporting engine are run on the same machine as the jUDDI server. However at true performance load testing multiple agents are deployed on dedicated machines.


Deployment Architecture showing how XLT is hooked up to load jUDDI.



The slides of the presentation can be download here.

Hurray! jUDDI is now a TLP project!

I hope your summer has been good. Not too much coding went on but instead the big news is that recently a vote passed to make jUDDI a Top Level Project (TLP). The ASF Board approved that both jUDDI and Scout will be combined into one project called "jUDDI". This is quite exciting and it is another major step for the project. It does mean that we will go through a bit of a reorganization though to move from subproject of Apache WS to the new TLP status. Stay tuned!

Cheers,

--Kurt

jUDDI v3.0.3 Released

I'm proud to announce that the latest jUDDI code has been released as version 3.0.3. As always a huge thanks to all who were involved. This release addresses a number of issues reported by our users, and it adds some new functionality on XRegistration and case folding of Keys. All keys are now case folded to support databases that do not handle case sensitive comparisons. Note that this may lead to issues if you are upgrading from a previous version of jUDDI which contains non-case folded keys. It is therefore recommended to reinstall the database if possible.

For a complete overview of the Release Notes see:
http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10401&styleName=Html&version=12314518

Simple Publish Example Demo

In a previous blog post we detailed how to publish some UDDI entities to the Registry.

In the following demo it is shown how to run the simple-publish example.

jUDDI v3.0.2 Released

I'm proud to announce that the latest jUDDI code has been released as version 3.0.2. A huge thanks to all who were involved. This was the first release using the release plugin and hosting the release on Nexus. It contains a slew of bug fixes and small enhancements. One enhancement is the ability to use multiple client (managers) on the same Classloader, which was important when inVM Transport between client and server is used. Also we resolved what seemed memory leak issues with OpenJPA which turned out related to not running the enhancement phase correctly. This means that the bundles now use OpenJPA by default. Finally, we added a ton of documentation, and as our users are starting to use the new features we have already received some great addition documentation back.

For a full report see the Release Notes - jUDDI - Version 3.0.2

http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10401&styleName=Html&version=12314553