If any changes need to be done in the RPC style, it must affect the server and the clients. There is no doubt about that. For the document style communication, The fact that objects are serialized and deserialized to and from an XML stream, most structural changes can be introduced with zero-impact.
For example, in a document/liter wrapped style, we might have a an outcome class that has two attributes: returnMessage and returnCode. There are some consumers who bind to it. We will add a new attribute "other", to it. The server module can now assign a value to the new attribute and the clients that update to the new outcome class can receive that value. But what about the clients who do not update? Well, they will continue to work in the same way. They will obviously not be receiving the new value, but the deserialization process will not break. On the other side, we can remove an attribute (for example, returnMessage) in the server module, and have a non-updated client receive a null value in this field, though still working. When we decide to model business processes, that means we takes the business logic out of the application and invoke the applications from the business processes tool. This means refactoring the existing applications, if needed. It is now facts and practical and not theory at all, but we have to understand the pig picture and change the ways that we have got to do the job. It is not an easy task. All the best Ashraf Galal Michael Poulin wrote: > > 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 > <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 > > > (Yahoo! ID required) > > [email protected] > <mailto:[email protected]> > > > >
