had to run and give the kids a bath, and didn't finish my comments. Beyond the stuff on my diagram, I am actually am trying to take some time out to research WS-CDL. I honestly don't know enough about it to say whether I could incorporate its usage anytime soon. I know enough that's it's tweaked my interest.
At the same time, I can sympathize with Alex's comments. I have a graduate degree, so I understand the culture of the academic/ theoretical/research world, and I've been a practitioner in a large corporation for the last 7 years, so I understand the tactical, get it done now, culture of corporate IT. It's a big challenge for corporate IT to adopt practices from the academic world that may be very beneficial. They simply lack the maturity at the patience to be able to do so. To some extent, it's no different than the short- term, quick win thinking that Ron and Jason talk about in their book that is such a barrier to SOA adoption. That's one of the things I enjoy about this list. Keith's book is now on my amazon list (my birthday's a week from today, so I'm hoping it will show up next week...). I've registered at pi4tech.com and plan on reviewing the info there. I probably wouldn't have even looked into it were it not for the list (although Anne did suggested I take a look at WS-CDL in a side discussion that we had). -tb On Mar 22, 2006, at 3:31 PM, Steve Ross-Talbot wrote: > Okay I kinda thought this would be the response. So some more > questions: > > Do any of you sketch out algorithms at all in any sort of pseudo code > or do you do that in plain old english? > > Todd, what formal modeling tools and languages have you actually > tried? > > Todd, from your diagram and the text I could not possibly guarantee > that I could implement it because it is > ambiguous and incomplete with respect to any message exchanges between > the services. My point all along > is that we need to move on and figure out a better way of describing > the interactions because that moves > us along the path to understanding a systems behavior. Describing a > systems behavior in terms of the roles > (service definitions if you like) and the interactions between roles > and the ordering and dependencies > between those interactions (even if it is from an externally > observable > perspective) is what is needed to > ensure the thing does what is described. Diagrams and annotations just > do not cut it. > > If you have such a description you can generate diagrams of many > flavours (UML-like, BPMN or anything else) that > act as an aid for explaining to others what is going on. But more > importantly having such a description acts as > dynamic governance of an SOA that ensures the service behaviors are > correct with respect to the description. Now > that would be helpful and useful and quite frankly move the whole > issues regarding poor architectural descriptions > to another plane. > > If it is indeed the case that nobody has such a language or such tools > to create such descriptions then at least we at W3C > have created one called WS-CDL (which I bang on about all the time). > And at www.pi4soa.org we have an open source > implementation of such a beast. > > Why don't you folks try it and see if it adds value. I have a bunch of > the brightest academics working with me on putting it together > and four large enterprises actively using it in the capacity I have > mentioned above as well as a couple of vertical standard bodies > adopting it because they are fed up with just diagrams and text and > all > the errors that ensure from that approach. > > Sorry to harp on but I get a little frustrated with people lack of > interest in WS-CDL and the pretty awful press it has received. Only by > use > will you really understand. I issue the challenge ...... > > > Cheers > > Steve T > > > On 22 Mar 2006, at 19:43, Todd Biske wrote: > >> As seeing JP's response, I feel much better about my own answer. For >> me, architecture is done through Word and Visio (or if I'm using my >> Powerbook, Word and OmniGraffle). Pictures are absolutely >> mandatory. Accompanying text should be mandatory, but most of >> the s >> time, I'm explaining the picture in person, so it's less important. >> The pictures are also frequently delivered via PowerPoint or >> Keynote, >> but they start out with the drawing tool. >> >> As for formal modeling tools/languages, I personally find them >> stifling, because somewhere along the line, they aren't able to >> clearly convey the points I need to make to a particular audience. >> The use of models is no different than anything else that involves >> human interaction. You need to know your audience/end user/customer >> and tailor it appropriately. Often times, I'll need a diagram that >> has some logical aspects, some physical aspects, some conceptual >> info, some concrete info, some deployment aspects, etc. to properly >> convey a message. It's a fine art to determine when to create a new >> view, and when to add more information into a single view. >> >> As an example, look at this diagram (hopefully this comes through OK >> with the mailing list, so): >> YAHOO! GROUPS LINKS >> >> ▪ Visit your group "service-orientated-architecture" on the web. >> >> ▪ To unsubscribe from this group, send an email to: >> [EMAIL PROTECTED] >> >> ▪ Your use of Yahoo! Groups is subject to the Yahoo! Terms of >> Service. >> >> >> <pastedGraphic.jpg> >> This is a very simple, yet powerful diagram. At one point, I wanted >> to incorporate some elements of systems management into the diagram, >> such as a dashboard. What I realized was that went down a very ugly >> path that muddied the point this diagram was trying to make. As it >> turns out, Systems Management was a type of solution that could be >> mapped onto this diagram. There are user facing components of >> systems >> management that goes into the application box. There are business >> processes associated with systems management that could be >> represented >> in the orchestration engine. There are service requests and events >> flowing through the network. There are underlying services that take >> operational actions on the systems, etc. So, rather than add >> boxes to >> this diagram, I used systems management as an example of how to apply >> the logical concepts presented to an actual problem. >> >> -tb >> >> On Mar 22, 2006, at 10:04 AM, JP Morgenthal wrote: >> >>> Steve, >>> >>> I use pictures to describe a system usually. Architecture usually >>> takes the form of pictures for me. It's a description of the >>> components of a solution and the relationships between those >>> components. There is no formal definition for how those >>> relationships get implemented nor is there any formal definition for >>> how the component gets implemented. >>> >>> However, SOA is a way to design a system. It's not a style issue, >>> it's a way to think about what goes into the picture. >>> >>> JP >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[EMAIL PROTECTED] On >>> Behalf Of >>> Steve Ross-Talbot >>> Sent: Monday, March 20, 2006 4:46 PM >>> To: [email protected] >>> Subject: Re: [service-orientated-architecture] Re: Trolling for >>> flames >>> >>> Sounds to me that anything that is "a way to design" is a style. A >>> style is not an architecture. >>> Without some way of writing down the design of a distributed system >>> such a style has no meaning. >>> The design is what gives it meaning and for me that design starts >>> having validity when it fulfills the TOGAF >>> suggestion that an architecture is "a formal description of a >>> system". >>> >>> >>> I shall review what you have all said but I must admit I do not >>> recall >>> anything earth shattering but that maybe >>> because I did not read it or failed to understand it. >>> >>> I have posed a challenge as to what people use to describe a system >>> and >>> have yet to see anything back from anyone. >>> Which I find puzzling. >>> >>> JP you are pretty well travelled. What do you use? And what about >>> Gervas, Eric and Todd for that matter. Am I the only >>> one asking the direct questions? >>> >>> Cheers >>> >>> Steve T >>> >>> On 20 Mar 2006, at 12:16, JP Morgenthal wrote: >>> >>>> +1. Review the past discussion between myself, Gervas, Eric, & >>>> Todd >>>> on this >>>> issue. SOA does not have an implicit relationship with SW. As I >>>> defined in >>>> the SOA Infrastructure thread, SOA is a way to design any >>>> system, be >>>> it >>>> software or any other. >>>> >>>> JP >>>> >>>> -----Original Message----- >>>> From: [email protected] >>>> [mailto:[EMAIL PROTECTED] On Behalf >>>> Of >>>> loek_bakker >>>> Sent: Monday, March 20, 2006 4:26 AM >>>> To: [email protected] >>>> Subject: [service-orientated-architecture] Re: Trolling for flames >>>> >>>> I think SOA is about more than just SW architecture. That is where >>>> it differs from OO and CBD for instance. There is a very clear >>>> business element in SOA (or there should be!) that goes beyond SW >>>> architecture. To me SOA answers the HOW question that is >>>> related to >>>> the answer to the WHAT question that is described in Enterprise >>>> Architecture. >>>> >>>> --Loek. >>>> >>>> --- In [email protected], Jerry Zhu >>>> <[EMAIL PROTECTED]> wrote: >>>>> >>>>> SOA is sw architecture that captures the functional >>>>> requriements and also poses nonfunctional requriements >>>>> such as security, scalibility, performance etc. >>>>> Systems architeucture describes what hosts the >>>>> operation of what sw architecture describes and what >>>>> implements the nonfunctional requirements. >>>>> >>>>> Jerry Zhu >>>>> >>>>> --- loek_bakker <[EMAIL PROTECTED]> wrote: >>>>> >>>>>> 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 >>>>>> <jerryyz@> 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 <steve@> 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: >>>>>>>> >>>>>> >>>>> === message truncated === >>>>> >>>>> >>>>> __________________________________________________ >>>>> Do You Yahoo!? >>>>> Tired of spam? Yahoo! Mail has the best spam protection around >>>>> http://mail.yahoo.com >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Yahoo! Groups Links >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> SPONSORED LINKS >>>> Computer software >>>> Computer aided design software >>>> Computer job >>>> Soa >>>> Service-oriented architecture >>>> >>>> YAHOO! GROUPS LINKS >>>> >>>> ▪ Visit your group "service-orientated-architecture" on the >>>> web. >>>> >>>> ▪ To unsubscribe from this group, send an email to: >>>> [EMAIL PROTECTED] >>>> >>>> ▪ Your use of Yahoo! Groups is subject to the Yahoo! Terms of >>>> Service. >>>> >>>> >>> >>> >>> >>> >>> >>> >>> Yahoo! Groups Links >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Yahoo! Groups Links >>> >>> >>> >>> >>> >>> >> > > > > > > > > Yahoo! Groups Links > > > > > > 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/
