Let's get back to Anne's remark: I don't think SOA Infrastructure is the right term. I would name it service-oriented infrastructure. Usually an infrastructure is part of an enterprise architecture, so to me it does not make sense to name it service-oriented architecture infrastructure. So probably I agree with Ron.
Loek. --- In [email protected], Jerry Zhu <[EMAIL PROTECTED]> wrote: > > When we talk about architecture we need to be aware of > the context. Is it about software application or > enterprise wide IT planning? Each has different kinds > of architectures. In software application, for > example, there should be three kinds of architectures: > data, software, and system. For enterprise, there > could be more architectures as defined in FEAF. > > Infrastructure could refer to technology architecture > in EA. It may also refer to application's system > architecture. When we talk about buildings, there > maybe only one architecture. Building are things or > simple systems. Business or a software system is a > complex system that needs to be viewed in > multi-perspectives, hence multiple architectures. > > Jerry Z. > > > --- Steve Ross-Talbot <[EMAIL PROTECTED]> wrote: > > > I think it is wholly unhelpful to mix these terms. > > Let me explain > > further. There is a famous building in Paris (the > > Pompideux centre). It > > is a building that has an architecture which is > > something that > > architects produced. It's infrastructure is visible > > on the outside of > > the building - unusual because most are embedded or > > on the inside. The > > architecture was the blue print by which the > > structural engineers and > > builders delivered what was required. The > > architecture simply stated > > that the infrastructure was to be put on the outside > > and gave a clear > > description of what that meant. > > > > Clearly we do not talk about the architecture > > infrastructure of the > > Pompidu Centre being on the outside. We do talk > > about the > > infrastructure being on the outside. The danger is > > that we further > > promote poor understanding as to what is meant by > > architecture and we > > confuse it with infrastructure. Only this week I > > heard a CEO confuse > > the two thinking that the infrastructure was the > > architecture. > > > > Whilst I am on the topic I would like to make sure > > we are all of one > > mind. Architecture is not something that we do. It > > is not a verb. It is > > an artifact that is produced in the course of > > building a system. > > According to TOGAF it is "A formal description of a > > system". According > > to UML it "the organizational structure of a > > system". Architecting is > > something that Architects do and the output of what > > they do is an > > Architecture. I suggested at Web Services on Wall > > Street and I have > > still to hear anyone counter this - I'd love to have > > a debate and learn > > new tricks from those more learned than I - that > > there is not A in SOA. > > There is no clear, precise way within the accepted > > tools sets that can > > be said to define the SOA space, that are being used > > or can be used to > > "formally describe a system" or to describe "the > > organizational > > structure of a system". > > > > It would be very nice if in this group of interested > > parties we could > > actually establish what we mean by architecture and > > then be clear about > > how this might differ from the prevailing wisdom of > > TOGAF, UML, OMG and > > others. And if it doesn't how one might actually > > encode an > > Architecture. Is UML sufficient? Can we describe > > all of the > > interactions that occur between a set of services > > using UML in an > > unambiguous way? Could we do with BPEL or BPMN? > > Could we do with > > WS-CDL? > > > > Why should we care? Pretty simple really. When you > > Architect in the > > world of civil engineering, electrical engineering > > and so on, you use a > > formal description of the system (not all the detail > > but enough) to > > simulate and test. This is how Architects find that > > the stress levels > > on a specific beam are too high or find that they > > have over specified > > some tolerance can reduce the cost of a component. > > Without such a > > description this cannot be done. I would content > > that we should do the > > same in software. If you cannot write down your > > Architecture then you > > do not know enough about what you are doing, and you > > will have a high > > risk of failure because of this. > > > > I believe we can do better and make the dream of SOA > > a reality in a > > lower cost and lower risk way. In effect I think we > > can put the A back > > into SOA as opposed to continual talk of SOA when we > > really only mean > > Service Orientation - which is a step higher than > > Object-Orientation. > > > > The above rantings are not just the work of a > > demented long in the > > tooth perhaps should retire too old software guy. > > Rather they are an > > extract of many discussions with many practicing > > Architects who deliver > > real systems (not software products) that deliver > > real business benefit > > to real customers. > > > > Thoughts please ......... > > > > > > Cheers > > > > Steve T > > > > On 15 Mar 2006, at 13:56, Ron Schmelzer wrote: > > > > > So, what exactly is architecture infrastructure? > > Aren't these two > > > different things... does it make sense to even > > combine these two words > > > together? > > > > > > Ron > > > > > > Anne Thomas Manes wrote:Gregg, > > >> > > >> A SOA infrastructure [sorry JP, but I think this > > term is useful] > > >> ought to support any type of communication style: > > synchronous vs > > >> asynchronous, request/response vs one-way, direct > > connection vs > > >> brokered, queued, pub/sub, Linda, etc. It's even > > better if the > > >> infrastructure is natively supported by most > > development platforms. > > >> > > >> I think this last point is the most serious > > downfall for J/JS. You > > >> had the luxury of developing your own > > communication infrastructure, > > >> and you chose to base it on J/JS. (I think this > > was a great decision > > >> for you.) Most organizations don't have that > > luxury, though. For > > >> them, software infrastructure development is not > > a core competency. > > >> So they buy it. And because a communication > > infrastructure is such a > > >> critcal component in their IT systems, they tend > > to buy it from > > >> solid, stable vendors -- IBM, Microsoft, BEA, > > Oracle, SAP, etc. None > > >> of these vendors provide native support for J/JS > > (or any Linda system > > >> for that matter). > > >> > > >> I've always been a big fan of Linda, but you > > must agree that it's a > > >> fringe technology. It's been around for ever, but > > never been a part > > >> of the mainstream. The key advantage I see for > > using SOAP as the > > >> foundation for SOA is that *everyone* provides > > native support for the > > >> technology. > > >> > > >> Anne > > >> > > >> On 3/14/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote: > > Anne Thomas Manes > > >> wrote: > > >>> > I understand that the JERI stack opens J/JS > > up to allow > > >>> integration with > > >>> > other languages and protocols, but there are > > a number of features > > >>> in J/JS > > >>> > which are available only to Java > > applications. > > >>> > > >>> There are a number of Web services features > > that are only available > > >>> to web > > >>> services applications. > > >>> > > >>> Where is the line drawn to differentiate?  I > > am not sure what > > >>> missing features > > >>> you think are problematic or which would cause > > problems.  Can you > > >>> share some > > >>> specific concerns?  This is really an > > interesting issue for me. > > >>> > > >>> At some point, the technology of choice is > > visible > === message truncated === > > > __________________________________________________ > 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/
