Another issue for us vendors is that management is kind of the tail of the dog, meaning we don't know how to define the management of a feature or function until that feature or function is completed. So I think management always tends to lag...but you are right, we should pay more attention to it. It's kind of like usability, it probably needs to be designed in more than viewed as after fit and finish work.
--- Todd Biske <[EMAIL PROTECTED]> wrote: > I don't know if this what you're looking for, but > coming from the > engineering/infrastructure side of the house at my > current employer, > one of the first possible cases I presented was the > systems > management space. The standards bodies are in line > with this idea > with both the MUWS component of WSDM and > WS-Management. > > The scenario I always used was that of an > application server farm > hosting a service. A routing device in front of the > farm collects > response times. When the response time exceeds a > threshold, the > device publishes an event. A operational management > process is > kicked off in the BPM system in response to the > event. The process > fires off one or more service invocations to > provision a new > application server instance and deploy the service > that is exceeding > the response time threshold. When the application > server comes up > and the service is deployed, the application server > fires an event. > The orchestrated management process is in a state > listening for the > event. After it receives it, it issues an > administrative service > invocation to the routing device to update its > routing table. > > It's a nice picture, but unfortunately, this > scenario isn't something > that can be done today (at least out of the box) as > very few products > have an administrative/operational interface exposed > as web > services. Personally, I wish more vendors would > think about > operational integration as well as functional > integration from day > one, but unfortunately, state of the art management > capabilities does > not drive sales until many releases down the road. > > -tb > > > On Jan 23, 2006, at 5:15 PM, Gervas Douglas wrote: > > > Most of the discussions that take place on SOA > seem to be based on an > > implicit assumption that SOA only applies to > "business" applications, > > i.e. that it fits into or belongs solely in the > realm of Enterprise > > Application Architecture. I put "business" in > inverted commas in the > > sense that in ICT it is used other than in a mere > commercial sense, > > but more generally to refer to human end-user > application needs. > > > > Should SOA be necessarily restricted to this > domain if one envisages > > it essentially as an architecture for designing > systems on a flat > > peer-to-peer basis, i.e. a client-server > architecture with no fixed > > hierarchy and where an entity could be both client > and server? This > > may sound a little vague conceptually, but have > any of you come across > > examples of a SOA or a useful opportunity for > implementing a SOA below > > the application layer? > > > > Gervas > > > > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 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/
