On 23/10/2007, Rob Eamon <[EMAIL PROTECTED]> wrote: > > > > > > > --- In [email protected], "htshozawa" > <[EMAIL PROTECTED]> wrote: > > > > --- In [email protected], "Rob Eamon" > > <reamon@> wrote: > > design/solution "might" be use both of these styles. > > > > > > Some say that "request customer info" is an event. I understand > > the > > > point of view but I believe events are more along the line > > > of "customer info changed" or "order placed" or "inventory below > > > threshold" or other such activity. > > > > > I view "order part" more in line with the business event, > > while "customer info changed" is more of a technical event. > > > > Using a simple REA methodology to find events, an contracts between > > two agents would be more of "keep inventory at xxx" and a business > > event associated with the contract to fulfill that commitment would > > be "order yyy parts". "inventory below threshold" to me is more of > > a notification or information (technical) event based on the stated > > of the inventory that may be used to invoke a business event. > > "Keep inventory at xxx" seems like a policy to me, not an event. The > example events seem like they are event that the business cares > about. Why would "inventory below threshold" be a technical event? To > me that seems to be about as business related as one can get. > > > Agreed on "-oriented" and "-driven". But should SOA consider events > > or just services. > > An *architecture* should consider services, events and other > principles and approaches. Service-orientation is but one aspect--one > should not use the SOA label as an umbrella term for things that > clearly have nothing to do with service orientation, IMO.
Again this sort of depends whether viewing SOA as an RPC interaction style or if you view SOA as being about business services and the interactions that drive them. If its the later then clearly event based elements are within the scope as an event is just something that drives a services or is sent from a service with the intention of completing a goal. For me when I look at primarily event based infrastructures I still look to see what the different services are, their boundaries, their interactions and their drivers. This gives the structure needed to really create effective event infrastructures and not just get the mythical "send it and they will come" idea. This is the challenge at the moment with EDA v T-SOA v REST its arguing about which wheel is better, rather than rising above it and working out which wheel works on which car. Vendors increase this problem as do technologists as we focus on the implementation details and then turn around surprised when the business still complains that IT isn't doing what it wants and keeps talking about technology. Events are just one type of interaction model and for some cases they are the best implementation model. Some business events are best implemented by straight invocations (e.g. Stock arrived in Warehouse is an event from one perspective but the source and destination are physically linked so you might as well do it as an invocation) and some business invocations actually end up being best implemented via events (e.g. send me the sales data is implemented as a event that ships information when sales switch to closed). I know I've said this before on this thread but I'm feeling like crap today so am even more grumpy than normal. Apologies Steve > > -Rob
