I take you point. My point is that by using a more MOM-centric approach you may run the risk of loosing the audience. Staying at a higher more abstract level where causality (and therefore correlation) are important (no one message exchange lives in isolation) makes it easier to write down what the system as whole is supposed to do and does not lock you out from what is a very good implementation technique - namely to use topics/queues and some sort of messaging system into which container may attach themselves. Security and other policy decision become attachments to such a description (e.g. in WS-CDL) which leaves control in the hands of the architect.
I think it depends which architect role you wish to play as to what your vocabulary needs to be. If you are at the "techie patterns end" then clearly it is a technical architecture role. If you are at the business architect or enterprise architect end then you may have to live higher up and also understand what the technical architect is saying. On the one hand you have to deal with users and their articulation of their requirements and at the other you need to deliver an IT system. We did a lot of this role segmentation and what each architect needs to do at the Architecture Summit last December. Cheers Steve T On 11 Jul 2006, at 22:35, Gregg Wonderly wrote: > Steve Ross-Talbot wrote: > > 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. > ... > > I think we may have collided this thread with the one of BPMN/BPM > etc > > >>Steve Ross-Talbot wrote: > ... > >> > 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. > > My point was that the architect can define the passing of data within > a system > using "types" or "topics" or "classes". Those data values originate > from > certain entities and are consumed by certain entities. By deploying a > security > based pub/sub space, the architect remains in control of data flow > design, in a > seemingly adhoc data flow world. Only the authorized uses will be > able to > happen. All other uses will not be allowed and the developers will > have to > stick to the systems architecture/model. > > 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/
