Comments on: SOA, REST, and Pub/Sub http://www.udidahan.com/2008/12/15/soa-rest-and-pubsub/ Enterprise Development Expert & SOA Specialist Sat, 11 Feb 2012 15:16:10 -0600 http://wordpress.org/?v=2.8.4 hourly 1 By: udidahan http://www.udidahan.com/2008/12/15/soa-rest-and-pubsub/comment-page-1/#comment-35909 udidahan Wed, 31 Dec 2008 21:10:00 +0000 http://www.udidahan.com/2008/12/15/soa-rest-and-pubsub/#comment-35909 Hamsa, Will do :) Hamsa,

Will do :)

]]> By: Hamsa http://www.udidahan.com/2008/12/15/soa-rest-and-pubsub/comment-page-1/#comment-35906 Hamsa Wed, 31 Dec 2008 03:12:45 +0000 http://www.udidahan.com/2008/12/15/soa-rest-and-pubsub/#comment-35906 I love to see more posts on this topic. I want to extend this idea to Master data (Customer, Supplier, Item etc) synchronization in a entriprise environment. In the organizations i have worked with it is implemented in pub sub model with pooling architecture. I love to see more posts on this topic. I want to extend this idea to Master data (Customer, Supplier, Item etc) synchronization in a entriprise environment. In the organizations i have worked with it is implemented in pub sub model with pooling architecture.

]]> By: udidahan http://www.udidahan.com/2008/12/15/soa-rest-and-pubsub/comment-page-1/#comment-35857 udidahan Wed, 17 Dec 2008 20:08:03 +0000 http://www.udidahan.com/2008/12/15/soa-rest-and-pubsub/#comment-35857 Mike, I guess I should have qualified my meaning of "pub/sub" in this diagram. When describing business services which publish events, I refer to the fact that they are not dependent upon the logical subscribers. Whether the actual data delivery is pub/sub at the network level, uses a subscription list, or client-polling is a separate (but not unimportant) concern. One of the advantages of using this design for data which many subscribers might need is that we can leverage the caching behaviors of the internet to save on bandwidth. All the options you outlined are also viable and technical tradeoffs need to be made between them and the design I described - a good topic for another post :) Mike,

I guess I should have qualified my meaning of “pub/sub” in this diagram.

When describing business services which publish events, I refer to the fact that they are not dependent upon the logical subscribers. Whether the actual data delivery is pub/sub at the network level, uses a subscription list, or client-polling is a separate (but not unimportant) concern.

One of the advantages of using this design for data which many subscribers might need is that we can leverage the caching behaviors of the internet to save on bandwidth.

All the options you outlined are also viable and technical tradeoffs need to be made between them and the design I described – a good topic for another post :)

]]> By: mike lorengo http://www.udidahan.com/2008/12/15/soa-rest-and-pubsub/comment-page-1/#comment-35851 mike lorengo Mon, 15 Dec 2008 15:56:16 +0000 http://www.udidahan.com/2008/12/15/soa-rest-and-pubsub/#comment-35851 How does this accomplish Pub/Sub? The client must still initiate a request, now it's a RESTful GET. Some options for this could be 1) Using Comet/Long Polling (http://delicious.com/mikelor/comet) 2) Using XMPP to Push Events (http://ajaxian.com/archives/beyond-rest-xmpp-pubsub) 3) Creating a Provider on Gnip (http://www.gnipcentral.com) 4) Something else, perhaps using Azure's ServiceBus (http://www.microsoft.com/azure/servicebus.mspx) -=mike How does this accomplish Pub/Sub? The client must still initiate a request, now it’s a RESTful GET.

Some options for this could be
1) Using Comet/Long Polling (http://delicious.com/mikelor/comet)
2) Using XMPP to Push Events (http://ajaxian.com/archives/beyond-rest-xmpp-pubsub)
3) Creating a Provider on Gnip (http://www.gnipcentral.com)
4) Something else, perhaps using Azure’s ServiceBus (http://www.microsoft.com/azure/servicebus.mspx)

-=mike

]]>