Another Great post from Miko. I just have some comments about the "the central focus of SOA is missing: upgradeability." In Computer Science upgradeability means: a. To replace (a software program) with a more recently released, enhanced version. b. To replace (a hardware device) with one that provides better performance.
This is the core advantages of SOA and loosely coupled modules. This is also the one of the WS-I goals. We cannot achieve it if we use RPC style communication but we can achieve it very easily if we use the document style that encapsulates the messages and the data. With Document style, a change in the structure of a message (like, adding a new attribute) does not affect the document exchange mechanisms. On the other hand, a change in a back-end (internal) method signature has generally no effect upon the messages structure. This loose coupling, intrinsic in the Document style, leads to more robust and reliable architectures that are easier to maintain, and having a modular aspect. This is why it is better to design service at a fine-grained and composite them together. If we do so, we can easily achieve the immutable service and any changes will only be done on the composite services, version..etc. We will not have any management problems with composite services because we can discard any of them and rebuild them from scratch without even affect the underlying services. The resistance from the IT is the among one of the major problems that cause and led to SOA failure. SOA is a concept and best practice, vendors cannot do more than educating and training but the best practice and concept have to be followed by someone in the organizations, except if we have the vendor take over all the activities from the organizations. This is could be done by SaaS / cloud computing but the problem that this model will not be successful without having a good SOA infrastructure in place. IT has to recognize that we have a paradigm shift since 2002 toward assembly not development. Thank you Ashraf Galal Gervas Douglas wrote: > > You can read the following article in full at: > > http://www.infoq.com/articles/soa-governance-revitalized > > Gervas > > <<The term “SOA Governance” has been used in the industry for years > already, but it is still considered an arcane topic. Anyone who reads > this article should be able to understand the following things: > > 1. Why are people pursuing SOA, isn’t it dead? > 2. What is the relationship of SOA Governance to SOA itself? > 3. What is SOA Governance? > 4. How does it differ from Management? > 5. How does SOA differ from Integration? > > While being able to think and speak clearly about these topics may not > win you as many brownie points as it would during the time when this > was a “hot topic” for Enterprise IT, it will help you understand why > SOA and SOA Governance continue to be significant issues for the > Enterprise despite the ups and downs of market hype cycles.>> > > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> 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/
