You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@juddi.apache.org by Alex O'Ree <sp...@gmail.com> on 2013/05/01 01:46:38 UTC
AMQP based subscription notifications
I recently discovered that the subscription API has a plugin type
system that let's system owners extend jUDDI to push notifications via
other outlets. The default ones that come with jUDDI are for the UDDI
v3 subscription callback API and for email based alerts.
I wanted to make a sample projects to demonstrate out how use it and
the best use case I came up with was to use Apache Qpid. It's an AMQP
implementation, which is basically a publish and subscribe system.
The use case is that jUDDI would publish subscription updates to a
specific Qpid server for a specific Qpid exchange (such as a topic,
queue, etc).
The question is, should jUDDI be configured for a single Qpid server
and the exchange be defined as the bindingTemplate Access Point, or
should the bindingTemplate represent the URL to a Qpid server and some
how define the exchange name else where?
So to summarize, per subscription url + exchange, or per subscription
exchange only
Re: AMQP based subscription notifications
Posted by Alex O'Ree <sp...@gmail.com>.
Qpid and AMQP can be used both intra and internets. I think that this
going to be tricky for a 100% implementation, but a partial solution
is feasible, considering that AMQP urls can have credentials in it. I
just wanted to use this as a demo.
So if i use the access point for the connection url, we still need a
place to define the topic name and exchange type. Any objections to
using a tmodel instance on the binding for this?
On Wed, May 1, 2013 at 2:24 PM, Kurt T Stam <ku...@gmail.com> wrote:
> I depends if we see this as a callback on an Intranet versus the Internet.
> For RMI_JNDI transport we assume Intranet, and the callback endpoint needs
> to be in the appserver's JNDI.
>
> If we want to support this as a generic Internet protocol, then the
> accessPoint needs to contain
> the server info as well as the queue name info.
>
> my 2 cents
>
>
>
> On 5/1/13 12:48 PM, Alex O'Ree wrote:
>
> Amqp is not xml specific. Any message can be sent
>
> On May 1, 2013 9:29 AM, "Kurt T Stam" <ku...@gmail.com> wrote:
>>
>> Do you think you can post an example of the xml exchange?
>>
>> On 4/30/13 7:46 PM, Alex O'Ree wrote:
>>>
>>> I recently discovered that the subscription API has a plugin type
>>> system that let's system owners extend jUDDI to push notifications via
>>> other outlets. The default ones that come with jUDDI are for the UDDI
>>> v3 subscription callback API and for email based alerts.
>>>
>>> I wanted to make a sample projects to demonstrate out how use it and
>>> the best use case I came up with was to use Apache Qpid. It's an AMQP
>>> implementation, which is basically a publish and subscribe system.
>>>
>>> The use case is that jUDDI would publish subscription updates to a
>>> specific Qpid server for a specific Qpid exchange (such as a topic,
>>> queue, etc).
>>>
>>> The question is, should jUDDI be configured for a single Qpid server
>>> and the exchange be defined as the bindingTemplate Access Point, or
>>> should the bindingTemplate represent the URL to a Qpid server and some
>>> how define the exchange name else where?
>>>
>>> So to summarize, per subscription url + exchange, or per subscription
>>> exchange only
>>
>>
>
Re: AMQP based subscription notifications
Posted by Kurt T Stam <ku...@gmail.com>.
I depends if we see this as a callback on an Intranet versus the Internet.
For RMI_JNDI transport we assume Intranet, and the callback endpoint needs
to be in the appserver's JNDI.
If we want to support this as a generic Internet protocol, then the
accessPoint needs to contain
the server info as well as the queue name info.
my 2 cents
On 5/1/13 12:48 PM, Alex O'Ree wrote:
>
> Amqp is not xml specific. Any message can be sent
>
> On May 1, 2013 9:29 AM, "Kurt T Stam" <kurt.stam@gmail.com
> <ma...@gmail.com>> wrote:
>
> Do you think you can post an example of the xml exchange?
>
> On 4/30/13 7:46 PM, Alex O'Ree wrote:
>
> I recently discovered that the subscription API has a plugin type
> system that let's system owners extend jUDDI to push
> notifications via
> other outlets. The default ones that come with jUDDI are for
> the UDDI
> v3 subscription callback API and for email based alerts.
>
> I wanted to make a sample projects to demonstrate out how use
> it and
> the best use case I came up with was to use Apache Qpid. It's
> an AMQP
> implementation, which is basically a publish and subscribe system.
>
> The use case is that jUDDI would publish subscription updates to a
> specific Qpid server for a specific Qpid exchange (such as a
> topic,
> queue, etc).
>
> The question is, should jUDDI be configured for a single Qpid
> server
> and the exchange be defined as the bindingTemplate Access
> Point, or
> should the bindingTemplate represent the URL to a Qpid server
> and some
> how define the exchange name else where?
>
> So to summarize, per subscription url + exchange, or per
> subscription
> exchange only
>
>
Re: AMQP based subscription notifications
Posted by Alex O'Ree <sp...@gmail.com>.
Amqp is not xml specific. Any message can be sent
On May 1, 2013 9:29 AM, "Kurt T Stam" <ku...@gmail.com> wrote:
> Do you think you can post an example of the xml exchange?
>
> On 4/30/13 7:46 PM, Alex O'Ree wrote:
>
>> I recently discovered that the subscription API has a plugin type
>> system that let's system owners extend jUDDI to push notifications via
>> other outlets. The default ones that come with jUDDI are for the UDDI
>> v3 subscription callback API and for email based alerts.
>>
>> I wanted to make a sample projects to demonstrate out how use it and
>> the best use case I came up with was to use Apache Qpid. It's an AMQP
>> implementation, which is basically a publish and subscribe system.
>>
>> The use case is that jUDDI would publish subscription updates to a
>> specific Qpid server for a specific Qpid exchange (such as a topic,
>> queue, etc).
>>
>> The question is, should jUDDI be configured for a single Qpid server
>> and the exchange be defined as the bindingTemplate Access Point, or
>> should the bindingTemplate represent the URL to a Qpid server and some
>> how define the exchange name else where?
>>
>> So to summarize, per subscription url + exchange, or per subscription
>> exchange only
>>
>
>
Re: AMQP based subscription notifications
Posted by Kurt T Stam <ku...@gmail.com>.
Do you think you can post an example of the xml exchange?
On 4/30/13 7:46 PM, Alex O'Ree wrote:
> I recently discovered that the subscription API has a plugin type
> system that let's system owners extend jUDDI to push notifications via
> other outlets. The default ones that come with jUDDI are for the UDDI
> v3 subscription callback API and for email based alerts.
>
> I wanted to make a sample projects to demonstrate out how use it and
> the best use case I came up with was to use Apache Qpid. It's an AMQP
> implementation, which is basically a publish and subscribe system.
>
> The use case is that jUDDI would publish subscription updates to a
> specific Qpid server for a specific Qpid exchange (such as a topic,
> queue, etc).
>
> The question is, should jUDDI be configured for a single Qpid server
> and the exchange be defined as the bindingTemplate Access Point, or
> should the bindingTemplate represent the URL to a Qpid server and some
> how define the exchange name else where?
>
> So to summarize, per subscription url + exchange, or per subscription
> exchange only