2008/6/10 Rob Eamon <[EMAIL PROTECTED]>: > --- In service-orientated-architecture@yahoogroups.com, "Steve Jones" > > <[EMAIL PROTECTED]> wrote: >> >> First off SOA is not a silver bullet... >> >> 2008/6/6 Dey, Santanu <[EMAIL PROTECTED]>: >> > I have struggled to define a "service" in the first place.. >> > What is a service? We all know SOA and WS are not the same... >> > Must a service be machine discoverable? > Must it follow WS*? How >> > decoupled and atomic should the services be? how important are >> > service life cycle management, service operations management >> > aspects? >> >> The same questions could be asked of any approach, and I'd argue are >> equally badly defined. Something like ITIL can be applied to an SOA >> environment, but the job of ITIL and the architecture are different. >> >> > >> > Then there are questions specific to quintessential SOA >> > characteristics.... >> >> Only for vendors IMO... > > I disagree. There are characteristics that anyone pursuing an SO path > should at least consider, vendor or otherwise.
But they are more to do with the software design and delivery (SOD) than they are with the architecture. > >> >> > What do you think at the minimum should be followed? Is service >> > registry a must? >> >> Implementation not architecture. > > That depends on which level you start. I know you always start at the > BA level, but calling out a registry component in an EA for example, > seems perfectly legit to me. The implementation would be the how and > the specific tool. But at the EA level it doesn't mean it ends up being a service registry product. Back to the SOA RM and the key is that the service can be discovered, which is what a registry helps with. Having a single online spreadsheet or even a librarian could be an effective implementation approach of an architectural registry. > >> >> > Do you need to define a Common Message Format? >> >> Ditto, and IMO a dangerous area. >> >> > Should the architecture >> > support the capability to compose and orchestrate services? is a >> > BPM layer essential? is a Service Bus needed ? how important is >> > service virtualization? Which standards to be followed? >> >> Vendors would say yes. > > I'm a vendor basher as much as the next guy, but why single them out > here? There are plenty of non-vendor folks that have the view that > many of the above characteristics are required of an SOA. A view that > you and I most definitely disagree with. :-) Ahhh the sheep of IT ;) I've yet to meet someone who pushes BPM/ESB/CEP as "central" who hasn't been subjected to some pretty heavy mind-control from a vendor. > >> Personally I'd say this is about choosing the >> right technologies to implement your sevices. >> >> > >> > without having clear answers to many questions questions such as >> > above we can not unambiguously define SOA. >> >> yes we can. > > Haven't succeeded yet! ;-) We still disagree on the relative > usefulness of the OASIS SOA RM. True enough, but that doesn't mean that we can't say that its an unambiguous definition, even if you disagree with parts of it. The key thing about the RM is that it just talks of the basic terms and the basic elements and you can map it against a solution and go "that matches the RM" or "that doesn't match the RM". > > SOA in general is still very ambiguous, IMO, with overloaded > definitions and its application to differing levels of scope. Which is also part of the maturity problem in IT. I was chatting only yesterday with someone who is struggling to get his people out of the weeds of technology and getting depressed as they flit from technology to technology like people requiring Ritalin. Most of the ambiguity in SOA stems from this all encompassing technology view and the lack of desire to change the way we think about systems. Steve > > -Rob > >
