tag:blogger.com,1999:blog-4338956765494283322.post6602805251447168085..comments2024-03-29T19:35:03.327+08:00Comments on Bill Poole's Creative Abrasion: Guerilla SOABillhttp://www.blogger.com/profile/12877394913101625095noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-4338956765494283322.post-50693449119100331162008-05-04T12:37:00.000+08:002008-05-04T12:37:00.000+08:00Hi Jim,Using Atom for publish-subscribe in an ente...Hi Jim,<BR/><BR/>Using Atom for publish-subscribe in an enterprise context is an interesting idea. It does suffer from a few issues though:<BR/><BR/>1. There is no centralised configuration of topics and subscribers - which increases the configuration overhead.<BR/><BR/>2. You have to handle "wildcard subscriptions" manually - that is, you have no notion of topic hierarchies.<BR/><BR/>3. Each publisher must implement its Atom endpoint content manually - there is no shared infrastructure here.<BR/><BR/>4. The approach doesn't work very well when you need near real-time messaging as it is a pull model rather than a push model.<BR/><BR/>5. The subscribers must remember what messages they have processed was so they don't process messages twice.<BR/><BR/>6. There may be issues in high volume scenarios as publishers are not aware when all subscribers have received a message so the message can be deleted. You'd need to hold onto all messages for an extended period of time which could lead to storage issues.<BR/><BR/>7. There is no standard mechanism for securing published messages.<BR/><BR/>8. The publishing service must be available at the time a subscriber wishes to retrieve their notifications, which means we have temporal coupling.<BR/><BR/>9. You lose additional services such as run-time governance and business activity monitoring provided by middleware products.<BR/><BR/>In simple enterprise scenarios, none of these issues may present a road block. I am certainly a believer in using the right tool for the right job.<BR/><BR/>However when the above restrictions could present a problem, I would suggest enlisting the aid of an appropriate middleware solution.Billhttps://www.blogger.com/profile/12877394913101625095noreply@blogger.comtag:blogger.com,1999:blog-4338956765494283322.post-69733203193693630122008-05-02T22:29:00.000+08:002008-05-02T22:29:00.000+08:00Hi Bill,Pub/Sub on the WCF stack is best done with...Hi Bill,<BR/><BR/>Pub/Sub on the WCF stack is best done with Atom I think, rather than any of the WS-* stuff.<BR/><BR/>JimAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-4338956765494283322.post-12485072980021694132008-03-12T15:42:00.000+09:002008-03-12T15:42:00.000+09:00Good point. Although this doesn't give us knowled...Good point. Although this doesn't give us knowledge of the address of each service endpoint.<BR/><BR/>Let's say our billing service has multiple endpoints, one of which is at net.msmq://billing.service.corp/private/billing_endpoint_1<BR/><BR/>The sending service will need to be preconfigured with this URL. If we want to change the endpoint location or transport used then we would need to update the configuration of all sending services.<BR/><BR/>The billing.service.corp is only one part of the endpoint address, and the only part that DNS helps us with. <BR/><BR/>Message routing resolves more than just the name of the server on which the target service is running.Billhttps://www.blogger.com/profile/12877394913101625095noreply@blogger.comtag:blogger.com,1999:blog-4338956765494283322.post-73781684712590011732008-03-11T14:55:00.000+09:002008-03-11T14:55:00.000+09:00Re: […] that if we have a few different services r...Re: […] that if we have a few different services running on the same machine and we now wish to move just one of those services, we cannot do this via DNS.<BR/><BR/>If the services have different hostnames you can. There’s no reason why billing.service.corp and ordering.service.corp can’t be hosted on the same machine but with different hostnames. If you move one you just update your DNS, no?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4338956765494283322.post-77441204009912016022008-03-10T22:49:00.000+09:002008-03-10T22:49:00.000+09:00DNS gives us location transparency at the network ...DNS gives us location transparency at the network layer, rather than at the message layer.<BR/><BR/>What this means is that if we have a few different services running on the same machine and we now wish to move just one of those services, we cannot do this via DNS.<BR/><BR/>We would still need to update each of the collaborating services' configurations so they knew the new location of the relocated service.Billhttps://www.blogger.com/profile/12877394913101625095noreply@blogger.comtag:blogger.com,1999:blog-4338956765494283322.post-17675294031588903152008-03-10T21:21:00.000+09:002008-03-10T21:21:00.000+09:00RE: "We don't want each service to have to know th...RE: "We don't want each service to have to know the location of all other services with which it collaborates [...] We want a decentralised distribution model with centralised configuration."<BR/><BR/>DNS?flgbhttps://www.blogger.com/profile/07877437342822384440noreply@blogger.com