--- In [email protected], Michael Poulin <[EMAIL PROTECTED]> wrote: > > Well, Kirstan, to answer you question, I might need to write a book :-) but I will try to dry it: >
Michael, I have a couple comments below. > 1) sure project team cannot and may not wait for "a global SOA initiative" ... because it is not its business. SOA is an enterprise concept/model/paradigm/architecture, and it has to start over there. But when faced with having to build systems, the development group can choose to use SO principles or not. Not always is SOA warranted, but a lot would benefit, and the business would benefit by using SO principles. This is my basic point, that "project level" SOA does exist, and just because the scope is not enterprise, doesn't by itself disqualify it as SOA. > 2) maximum what project team can do by itself is a) designing and creating solutions as flexible and adaptable as possible; b) reserving hooks and placeholders for the extendability in the future, not necessary implementing them now; c) creating integral testing environment and challenging new/modified pieces against existing services in full w/o stubbing them out. > I agree they can do this, but I think they can do more to move towards SO as I mention above. > 3) The most important thing is to understand the nature of the service and design respectively, i.e. see a service as an application built on the SO principles and driven by business functionality and RWE. For infrastructure services, identify technical function which is not implemented already by existing drivers like databases drivers. > I agree. And I think a project with a smart architect can and will follow guidelines you mention in the creation of services. > 4) understand that reuse of services is as dangerous as reuse of API - the wider reuse as is , the more difficult and costly to change anything (i.e. such reuse may work against adaptability to the required changes). Consider mechanisms, which can be easily changed/extended w/o significant problems for already existing service consumers (http://soa.sys-con.com/node/523434). Finally, return to original meaning of reuse - reuse of existing and legacy assets, not services; business services are not reused much in the business > I will read your article with interest, sorry no time right now. My current opinion is that reuse is possible and desireable, and achievable in many situations. I see your point about the risk of brittleness, and I agree reuse it is oversold as a goal of SOA. > 5) accept the idea that SO is function-oriented approach; the function works in concrete technical and business environment defined not via function implementation but via surrounding policies and regulations. Plus, function does not own the data it works on; instead, it owns the meta-data only. The data better be organised in canonical models but functions always have their own views on the model and it is OK - the only condition here is for functions to share the same data > I'm not certain what you mean when you say that "function owns the metadata". Does this just mean a service is responsible for defining the messages on its interface? -Kirstan > Oh, I think this is OK for the moment. What do you think? > > - Michael > > > > > ----- Original Message ---- > From: Kirstan Vandersluis <[EMAIL PROTECTED]> > To: [email protected] > Sent: Friday, October 17, 2008 9:45:08 PM > Subject: [service-orientated-architecture] Re: van Hoof on EDA & SOA > > > --- In service-orientated- architecture@ yahoogroups. com, Michael > Poulin <m3poulin@ .> wrote: > > > > Yes, it was deliberate overstatement though based on OASIS SOA RM > standard. > > When I talk with people who see value in SOA Projects, I usually > one of two cases (sometimes, both): > > 1) it is just an initial first pilot project 'to taste the water', > and it is OK > > 2) Web Services are used for application integration w/o going > into real SOA value of business functionality > > > > Actually, I do not mind having SOA projects but only AFTER the > overall business functionality picture and SOA environment are in > place: think/see globally and move locally. > > Yes, thinking globally and acting locally boils it down nicely. But > the reality is there is so much project-level development going on > that the project group can't wait around for a global SOA intiative, > if one even exists. So what advice would you give them? I would > say Paul's advice, along with his 4 point clarification, is a good > start. In a nutshell, define common messages as the basis of the > interface for an endpoint, using XML Schema, with an eye towards > using or building a canonical model (e.g. a "Customer"). Without > this guidance, you'll end up with JBOWS with little or no reuse and > agility, and you'll add to the chaos that will have to be fixed > eventually. > > -Kirstan > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com >
