Well, Kirstan, to answer you question, I might need to write a book :-) but I will try to dry it:
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. This is why I always address my notes to the Business/Technical Architects and Business/IT decision makers, not to the project team. Those people have to obtain the global vision, not necessary an initiative and request vision-driven work from the project team 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. 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. 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 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 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 <[EMAIL PROTECTED] .> 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
