Interesting story, that shared DLL with Microsoft, since WCF absolutely does NOT require it.
Funny how the Microsoft consultants didn't know that and shot themselves in the foot. -- Udi Dahan From: [email protected] [mailto:[email protected]] On Behalf Of Gervas Douglas Sent: Tuesday, August 03, 2010 9:13 PM To: [email protected] Subject: [service-orientated-architecture] Michael on SOA in Chmeaux <<In Chmeaux, we do everything worldwide, everything to increase our company's revenue. Recently, we heard that if we would have SOA, we were gotten even more revenue from everything we do. Our CIO, who prefers to repeat only proofed methods, asked us to do SOA in this year. What can be better proofed than SOMA - a SOA building method from IBM? We opened the books and conducted a business analysis and modelling of business processes, as SOMA directs. After a couple of months, we had a set of the catalogues of all business processes, we supported in IT, and a few additional processes that were on our waiting list for each business division. However, our CIO didn't want to read hundreds of pages in each catalogue and asked for a few brief presentations. The best thing we were able to come up to compose "a few brief presentations" and reflect all catalogues together was a collection of the contents extracted from each catalogue. This is what we gave to our CIO. The CIO called us for an urgent meeting in a short time after we submitted out catalogue contents. She said that we did a huge work. We felt appreciated. Then she also said that a week ago new strategic business plan got in force, and several businesses processes, we recorded two months ago changed. This was not a good news because we assumed we had to record new processes and who knows, maybe other processes would change when we re-describe the first group, and so on... Though, the CIO said that she noticed that many titles in multiple catalogue contents sounded very similar and asked whether the majority of the processes we recorded did the same things with different business data. We were asked to work on the catalogues more and resolve the problems. We hesitated to talk to the same business people again about the similarity of the processes but, with the CIO help, we interviewed business managers of people we worked with the first time. This took us a bit longer than one week and, indeed, we easily found that majority of business processes, we supported in IT by multiple applications, are very light deviations from the same process, which could be implemented by one or two applications instead of our dozens ones. It looks like SOA is really a good thing, but you have to work with high and mid-level business managers to find commonality in business activities that seems so different when using traditional in IT data analysis approach. Finally, we came up with one catalogue of business processes and services, which was easy to comprehend and manage. The CIO signed the implementation project based on our findings into execution. We were proud that we found a way to compose and re-compose business services and processes keeping their business core in focus all the time, i.e. we found the way to keep IT agile to Business in Chmeaux. The receipt was simple - all processes and services had to be defined and realised as self-contained complete and even independent applications designed for orchestration in any required combinations. It was time to find who would build SOA for us because in Chmeaux, we do everything but building SW applications. Excited CIO allowed us to procure potential contractors including non-cheap IBM, Oracle, Microsoft, and others. Representatives from all potential providers told us wonderful stories about how SOA could help our business and IT to reach the next level of business advantage in the market. Many of them continued saying something like "How we do SOA in [*]", where [*] stood for the name of their company or platform. For example, Java oriented companies proposed to create a layer of processes in BPEL or similar technologies and a layer of Web Services, used by those processes. When we asked where would be our services (since Web Services were only interfaces to something), we could not get a more distinct answers than the implementation behind the Web Services might be arbitrary and anything we wanted. Well, this was exactly what we asked the providers to give us - that implementation with or without Web Services. Microsoft demonstrated a special case to us. First of all, they said that we did not need BPEL because they had much better technology named WCF/WF. Moreover, though they supported BPEL, real implementation underneath was the same WCF/WF, i.e. their BPEL engine could do only what WCF/WF allowed, i.e. why bother with BPEL. Second revelation came out when they explained how they construct and use this data in the exchanges between services and consumers. Particularly, they said that data objects might be generated based on XML Schema with meticulous definition of each type of data, which we certainly needed having so many data types in everything we dealt with. That was a great news until they said that to perform data exchange using this XML Schema typed data the consumer and the service must share at least one DLL (a programming library). In response to our amazement, they said: "This is how we do SOA on Microsoft's platform". If you still have doubts about the last statement, let us explain: if a consumer and the service must share even one DLL, or interface, or object/class, they are programmatically coupled. If a service shares one DLL with all its consumers, all of them coupled under the surface of "independent" interfaces. 'To share' is not equal 'to have the same'. For example, working with Web Services (in Java), a portion of consumer and service code is generated based on the same WSDL, i.e. they share the knowledge of the WSDL but they do not share the generated code. This allows every one of them to progress and change totally independently from each other. When needed, e.g., when WSDL changes, both sides have to re-build their externalised proxies while their core code stays the same. In the contrast, if the service changes shared DLL, all consumers must change their code at once. Don't you recognise a push to the same old monolithic desktop application under this small 'dll' issue? We do. This is a sad story because in Chmeaux, we are still in the search for a provider who can give us independent consistent business-oriented services and processes that we would be able to re-compose when and how our business needs. We think about a few weeks, the most, to be spent on such re-compositions, and we do not want programmers to work much on them. Could you, please, recommend us anybody who can do SOA for us in Chmeaux?>> You can find this at: http://www.ebizq.net/blogs/service_oriented/2010/08/how_we_do_soa_in_chmeaux _tips_for_cio.php?mkt_tok=3RkMMJWWfF9wsRonua7PZKXonjHpfsX76uksWaCg38431UFwdc jKPmjr1YIDRMV0dvycMRAVFZl5nQlaE%2FqE Gervas
<<image001.jpg>>
<<image002.jpg>>
