On 2/18/13 3:32 PM, Alex O'Ree wrote:
Full thesis is attached. I also sent out the published doc the user
group instead (replied to the wrong email). Pretty much everything
I've suggested could be offered as an addon or something to that
effect. JAXR is Java specific interface, where as uddi is a wsdl
specification. I honestly do not know a whole lot about JAXR, however
I don't think anything that I've suggested would affect compliance.
OK true; JAXR is the JAVA API to XML Registries; and a 'simpler' unified
API to interact with both ebXML and UDDI. The JAXR API is implemented in
the Scout project which is now under the umbrella of jUDDI. In some
cases I think hiding UDDI behind JAXR made it harder to debug things
since data the JAXR data structures are more tailored to ebXML, and were
then mapped back onto UDDI. If you are using JAVA the juddi-client makes
things pretty easy I think.
I've developed very complex web services on Jboss before and sadly
most version come with juddi of the v2 variety. Further more, getting
the full juddi web apps to deploy to jboss is difficult, at least from
my experience. In the past, I've usually just download the prepackaged
tomcat container and did my integration testing with that.
OK I was referring to the JBossESB product (and SOA-P for which us
offered support), which has a substantial deployment base. Every service
(not just WebServices) is registred to jUDDI there. This is just an
example, on the appserver there are examples too. My point is that UDDI
isn't going away any time soon.
Anyway thx for the article.
What area interests you first? The UI?
Cheers,
--Kurt
On Mon, Feb 18, 2013 at 3:01 PM, Kurt T Stam <kurt.s...@gmail.com> wrote:
Hi Alex,
Sounds pretty interesting. I'd love to read your thesis; do you have a pdf
version you can send us?
On 2/18/13 9:54 AM, Alex O'Ree wrote:
A few years ago, my master's thesis focused on improving UDDI. The
short short version of the thesis proposed the following changes:
- Provide a simpler web service interface that just returns endpoints
- Increase security by deprecating the security service in favor of a
SAML based STS or something similar
- Increase interop/usability by defining a rest style interface and
providing hooks for the ebxml std
How do your changes line up with JAXR?
- Advertise the location of UDDI services via a multicast
Unfortunately, due to the state of the uddi working group at oasis and
the exuberant costs of membership for participation, I feel like some
my work was in vain.
Thus, I'm writing to the jUDDI group. Is there any interest in perhaps
making some of these things a reality? I'm willing to volunteer some
time to make it happen (as well as make a more user friendly
interface)
Is it even worth it? Are there any stats on juddi deployments?
UDDI never reached its potential at the 'internet' level, but it is sort of
reborn at the company level. JBoss ships jUDDI with the SOA Platform where
it is used as the central service repository.
The trick with adding these features will be to add them in a such a way
that we can still be spec compliant; so they have to be 'on top of' the
current infrastructure or will undermine the adoption of jUDDI itself.
People like to be vendor neutral; which why there is UDDI specification to
begin with. On top of building on top of the spec if add these features we'd
have to document how other vendors can implement these enhancements.
Looking forward to discussing this some more!
--Kurt
