Gregg, sorry but I am pressed for time so this is a quick response.
What is the business purpose of your example. It sounds wonderful to me but totally techie based with no preservation of business semantics. What I have been trying (probably badly) to explain is how we need to describe from a business perspective the interaction of a system without requiring or suggesting a specific technical architecture such that regardless of the technical architecture the behavior can be said to be invariant (+/- SLA's). You might say "does it do the right thing" and then you can ask "does it do it quick enough". A system that is quick but incorrect is not a lot of use. So all of my ranting are really geared at describing in an unambiguous way the fundamental interactions that make up a system so that it can be understood by Business Analysts and presented to users without having to tell them that it is based on JMS or Lina or JavaSpaces. The latter being a techie wonderland sort of thing that - of course - we techies all love. But is irrelevant to the business. I think we may have collided this thread with the one of BPMN/BPM etc etc Cheers Steve T On 11 Jul 2006, at 16:36, Gregg Wonderly wrote: > 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 --------------------~--> Something is new at Yahoo! Groups. Check out the enhanced email design. http://us.click.yahoo.com/SISQkA/gOaOAA/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/
