juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex O'Ree" <spyhunte...@gmail.com>
Subject Re: Potential Uddi/juddi enhancements
Date Mon, 18 Feb 2013 21:36:47 GMT
Probably the user interface, as it is easy to integrate without
affecting anything down stream. I'm on irc if you want to discuss this
outside of the distro list

On Mon, Feb 18, 2013 at 4:29 PM, Kurt T Stam <kurt.stam@gmail.com> wrote:
> 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.stam@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
>>>
>

Mime
View raw message