I agree in that there is much Service-Oriented Design in SOA, but also quite a lot of Architecture. Without a defined architectural framework there is no real interoperability, which is the basis of the reuse, agility et al touted for SOAs. This is, besides services, to make the system work you need of some infrastructure around them, for things like discovery, communications (both synchronous and otherwise), management, etc. I.e. the gap originally addressed by SOAP, WSDL and UDDI and being now incrementally filled by WS-*. For SOAs not based on web services, similar things must exist first in order to lay the ground for reuse in practice.
I think there are three levels of architectural detail in any SOA: 1) The basic one shared by every SOA, i.e.: there are services (implementing the business/domain functionality without user interface) and applications (without business/domain functionality at all, but with user interface). I think there is a general agreement about this simple architecture, except maybe some discussion about whether applications and services can invoke other services, or whether this is allowed only to ESBs (which would then be the third element of the basic architecture, of course). 2) The level addressed by the assorted Reference Architectures used nowadays by different software vendors, involving elements like "legacy services", "service buses" or "registries". There is some degree of convergence here but by far no consensus yet. 3) The concrete architecture of a particular running SOA which details what and which are these legacy services, buses or whatever, if any. To have a running SOA you must first make a decision about the three levels, and this is architecture, because Service Models do not execute. By the way, in my humble opinion, the OASIS Reference Model is too abstract and generic to be of real use. In order to be so it before should come much close to the ground. Just my personal opinions, -- Javier Cámara ([EMAIL PROTECTED]) BCS Competence Center, Software AG España, S.A. Ronda de la Luna, 22; 28760 Tres Cantos (Spain) +34 91 807 9400, fax +34 91 807 9447 -----Mensaje original----- De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Steve Ross-Talbot Enviado el: lunes, 06 de noviembre de 2006 13:06 Para: [email protected] Asunto: Re: [service-orientated-architecture] abstraction of soa and its components Does the Zachman framework help as a way of understanding the necessary abstractions that are needed to tie requirements and business analysis to an specific architecture? We have found that we can abstract out the information models using UML and we have found that we can define the context in which the information is used by defining the dynamic model using WS- CDL. From this we can generate both specific XML schema representations of information models and their necessary state machines by auto-generating the correct UML artifacts and thence onto code generation. This approach, which is keeping with the Zachman framework, appears to work quite well as we can preserve the abstractions and use transformation functions to move between the different levels. For my own part I do not think that there is much A in SOA. It is more SOD (Service Oriented Design). It is a way of aggregating functions in a loose coupled way as services that are directly relevant to business needs. This contrasts with OOD (Object Oriented Design) which was more technically focussed (for IT) than for business. I think this is why various efforts have been and are being made to address the lack of fundamental architecture in SOA. For example the Architecture Summit in London, England, in December 2005 that was attended by luminaries such as Rod Johnson, John Davies, Mathew Rawlings, Alexis Richardson to name but a few - many others where there too. They looked at this very issue and looked into what we really mean by architecture and the Zachman framework loomed large (along with others). Cheers Steve T On 6 Nov 2006, at 11:04, shashank d. jha wrote: >> I believe many parts of the standard were under long and serious >> discussions and the search for compromises in the Committee, that is >> why they have such abstract definitions, especially the ones, >> mentioned by Shashank. >> >> I do not see a lack but too much compromises between an intention >> to make the SAO business-oriented architecture and an intention of >> IT vendors to continue making money on application tools, aka >> application-oriented approach. > >> According to Shashank, "SOA is an architectural approach that seeks >> to align business processes with service protocols and the >> underlying software components and legacy applications that >> implement them." To me, it is exactly opposite! >> > > Interesting observation. > >> > (Now we have an interesting precedent caused by the standard.) At > last, the "service protocols and the underlying software components > and legacy applications" have to be aligned with the business > process. That is, IT's got critical mass in technology and now IT has > to partner with the business minding business functions, not IT own > technology-centric interests. As you know, 'who is paying money those > order the music'... >> >> I do have found relatively clear definitions of " visibility, >> awareness, real-world effect, willingness, reachability", "those in >> needs" and "those with capabilities" in the standards. >> Probably, it worth reading it a few times because, as I said, it is >> an attempt to position technical architecture in the real business >> world. >> - Michael Poulin > > My issue is not with abstraction. but with proper abstraction. > > Look at the paper again, there is no architecture diagram for > reference model? But their is a diagram for how SOA RM relates to > other work?? Wherein in SOA implementation (not spec nor RM) seems to > be the biggest block. > > Service oriented Architecture implementation is the biggest block?? > > Reference model just guides or just a small part of Architecture > work?? > > How can you define the artifacts of the systems without having > identified artifacts and their relations with each other? > > Though the relation with Requirement, motivation and Goals has been > shown but no description for the same is mentioned in the paper? > > regards, > shashank > > > > > Yahoo! Groups Links > > > [EMAIL PROTECTED] > > > > Yahoo! Groups Links 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: mailto:[EMAIL PROTECTED] mailto:[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/
