I am afraid that beside relatively known and trivial facts, the tone of the statements is a bit orthodoxy...
For example, "We cannot achieve it [upgradeability] if we use RPC style communication but we can achieve it very easily if we use the document style" - it is really impossible to upgrade RPC? I doubt on it. This statement is almost revolutionary: "This is why it is better to design service at a fine-grained and composite them together." As I recall, the design of services always recommended to consider coarse-granular approach. Composition of service of absolutely different granularity targets not just a 'Facade' pattern ( covering fine-grande interfaces with a coarse-grande one) but creation of business functionality with new capabilities, IMO. "If we do so, we can easily achieve the immutable service and any changes will only be done on the composite services, version..etc." - I do not think we may say so because it depends on particular change in the business environment - some new industry regulations can affect the very fundamental things implemented in the lowest level of business services. There is no such thing as 'immutable' for the entities viewed and operating in the changeable external environment. "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." - to me this sounds a bit idealistic, especially when we address management. We have to remember that the clearance and concrete relationship between the elements of the technical system do not consider many other aspects that exist in management, for example. In particular, if you are the owner of the service composition and want to re-compose it, you are in full power to 'de-construct' the existing composition but you have to obtain new permissions to use the old elements /services in the new one (if you are really in the SO environment). So, for management, this re-negotiation of use of existing services in new combination may be a challenge. This is the problem of ownership and management boundaries, not technical problem. I think that the problem with IT with regard to SOA or other architectural/technological things is in that IT Management assumed it might decide what to do while this 'role' should belong to Business and Architecture exclusively. No SaaS/Cloud will help until they would follow architectural solutions dedicated to resolving concrete business problems. The major trick here is that technology vendors cannot properly guess what these problems are in many cases, and they know about this. Thus, they have to change their appeared from 'we have the hottest and cool technology available to you(IT)' to something that fist shows the business value of the product and the 'cool' part only the second. And this is not that easy and quickly to do. - Michael ________________________________ From: Ashraf Galal <[email protected]> To: [email protected] Sent: Fri, December 4, 2009 5:32:01 AM Subject: Re: [service-orientated-architecture] Miko on SOA Governance 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
