SOA as a SW architecture, is platform independent. Computer languages are not technologies, they are technology platforms. C++, Java, Smalltalk are platforms of object technology.
SOA is not bounded to any languages but it bounds to technologies. The use of particular langugaes has nothing to do with SOA but the decision of the designers who implement a SOA. What technologies to be bounded to SOA depends on the basic beliefs of the architects that in turn determine the capabilities of architecture. As i said before SW architecture is not designed but defined. There are no right or wrong designs only good or bad ones. Architecture, as the product of being defined, is based on basic beliefs. Basic beliefs are either accepted or rejected. There is no right or wrong, good or bad basic beliefs. To change someone's basic beliefs is as hard as moving a mountain. Therefore there is no objective unchanging definition of SW architecture out there. SW architecture can not be separated from the architects. If someone define a SOA for a project using function technolgy (using only producedural languages for implementation), it is right for him/her. There maybe minimum technologies SOA must have and having these miniumals only is not qaulified as SOA. Jerry --- Howard Kapustein <[EMAIL PROTECTED]> wrote: > * Saying that SOA is not bound to a technology makes > no sense > > Ahhh. Terminology. > > SOA, the conceptual model, is not bound to a > technology. Java, C#, > COBOL, HTTP, DECnet, CORBA, and other technologies > can all be used to > express an SOA design. > > SOA, *an implementation*, is very much bound to a > technology (it's code, > after all). This is the case where the particular > middleware and > architectural tools used for the implementation can > affect how you > express an SOA design, including potential > constraints and aids. Not all > tools do all things well; some will be better at > some aspects than > others. > > But specific technology only enters the picture when > you talk about an > implementation. > The ideas and style (the 'flavor' if you will) of > SOA designs can very > well be technology agnostic, it's only as you sink > down towards a > concrete implementation that all the real world > details start to color > the design. > > This is why many people at first may say CICS/COBOL > systems are not SOA, > but as you peel back the superficialities and > devil-in-the-details > caveats, the broader designs can become more > obvious. > > Not to say all 'old' apps are SOA, hell I've seen > Java code that was > about as far from OO as you could imagine (which is > a neat trick > considering the language jams it in your face at > every level starting at > day 1). Just that SOA, the architectural concept, is > a new term for > something that's been in practice for a very long > time. It's just more > commonly recognized nowadays, and there's more and > better tooling to > facilitate it. > > - Howard > > "Your training is nothing! The will is everything! > The will to act." > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> 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/
