Steve Ross-Talbot wrote: > Clearly you can do it that way but in so doing you may well lock out > application builders who think functionally. > Mapping operation names to topics automagically provides a level of > abstraction between the functionally defined > interface (say in WSDL) to topics and queues. The use of topics and > queues to implement the passing of messages > or indeed the use of SOAP over HTTP should not be visible to the > application builder but should be visible to the > (enterprise or indeed technical) architect. Then the problem is how > does the architect act globally and think locally (or > influence local decision making of application builders if you prefer) > and how does the application builder act locally > but within the framework laid down by an architect so that the > application builder thinks globally?
In my broker, each module merely listens for the topic trees of interest to it. The modules can publish data under other topics that other modules are interested in. Both publish and subscribe trees are administered with security controls applied to the modules. The modules are assigned a username and password when deployed into the container, and the adminstrator can specify which topics that user has access to for pub and sub. There are no queues in the 'space', only listeners. So, it feels more like a linda space than like a queue. There is a queue module that will put things into a queue if you need such. It then periodically takes things out of the queue and republishes them until someone deletes them. The Brokering is actually implemented by two modules, the DeliveryManager and the DeliveryQueue classes. The delivery manager listens for data events on the pub/sub space, and enqueues them to the DeliveryQueue object. The DeliveryQueue republishes them under another topic that the DeliveryManager listens to and the DeliveryManager then directs the flow of execution through the appropriate delivery director. Good topics hierarchies allow the module to be as specific as it wants, while allowing the listeners to be as ignorant as they want about the topics. In many cases, I have topic hierarchies which include data that multiple modules use in different ways. This provides much more control to minimize content snooping which is required if you have app.message instead of app.report.data.device.1.009321A.192.168.54.32 which tells you exactly what you need to know. You don't have to use all of that information, but it is informative. Certainly some might scream about exposing too many details. But, if there in the data already, then exposing them in the subject does really add any tighter binding for any particular application. I have a remote space browser (event browser) which streams topics and data to remote desktops so that the space can be watched easily. Having the topics have this data manifested as strings means I can do pattern matching to find specific information in filters without having to know how to open the data. Gregg Wonderly ------------------------ Yahoo! Groups Sponsor --------------------~--> Check out the new improvements in Yahoo! Groups email. http://us.click.yahoo.com/6pRQfA/fOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
