[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebsoa] [Comment: Section 2, Para 1] Re: [ebsoa] Recipes for Success
David RR Webber wrote: > > Joe, > > In terms of our position statement and what we say SOA might > include in its mission profile - this stuff below fell into my > mailbox today too. I would submit we need to > position ourselves so that we do not suffer academic obsolescence > right out the gate! Clearly - whatever the aforementioned below > actually means (your guess is as good as mine!) - you can use > an ebSOA to implement it - and we need to make sure people > can make that connect. Since these > words are extremely cheap at this 70,000 ft level - we may just > want to include them in some way - so that our customers don't > mistakenly go elsewhere looking for what they really need - aka > simple, proven and robust solution sets! Thanks David - not sure how these comments relate to the definition I proposed. > Now there's a radical thought - how about: > > "ebSOA - a simple, proven and robust solution set for delivery > of network based business systems and components". I would say that this definition does not capture the essence of SOA - which are shared services, flexible architectures, and business agility. I would say that there are probably approaches other than SOA that can apply to the definition above - so IMHO the definition is not specific enough. > Less could well be more!?! I would say not in the case of defining what SOA means, which should be at the heart of our work. Joe > DW. > > <snip>How do the common "build" principles that power the Internet illumine > the > agile path from today's business process conversations to tomorrow's > business process components? How do semantic technologies lightly abstract > and assemble shared meaning to sustain quality business conversations? > What distributed enterprise design tools accommodate the multiple forms of > expertise that need to be expressed and integrated in agile business > components within each Services life-cycle? What can we learn from early > developers and early adopters? > </snip> > ----- Original Message ----- > From: "Chiusano Joseph" <chiusano_joseph@bah.com> > To: "Matthew MacKenzie" <mattm@adobe.com> > Cc: "ebsoa" <ebsoa@lists.oasis-open.org> > Sent: Tuesday, May 25, 2004 9:31 AM > Subject: [ebsoa] [Comment: Section 2, Para 1] Re: [ebsoa] Recipes for > Success > > > I would like to suggest an alternate version of the definition of SOA > > that appears in Section 2, Para 1. > > > > Current definition: > > > > "An architecture is called a Service Oriented architecture if it follows > > a general model for how components communicate or interact with each > > other." > > > > The following proposed alternate definition approaches the definition of > > SOA from a business/functional perspective: > > > > "Service-oriented architectures (SOAs) provide flexibility and agility > > for organizations through their representation of business functionality > > as implementation-neutral, standards-based shared services. They are a > > natural progression in the evolution that began with the advent of XML > > and the emergence of Web Services." > > > > I would also recommend an alternate Figure 3.1 that depicts an > > architecture with multiple functions exposed as services, many of which > > utilize shared services (i.e. each other) for their required > > functionality. > > > > Thoughts? > > > > Joe > > > > Matthew MacKenzie wrote: > > > > > > So, I've officially thrown down a first draft of this specification, > based on Duane's introduction, and an extremely perverted transliteration of > the Zachman framework into a simple pattern notation that I cooked up. Its > basically at the outline phase right now, I more or less see it having the > following structure: > > > > > > Introduction - Basic Stuff > > > Service Oriented Architecture - What it is, why we're doing it, etc. > > > Pattern Notation - How we will represent patterns, define a grammar. > > > Patterns - The actual patterns, conforming to the pattern notation. > > > > > > So, in order to facilitate the progression of this specification, I will > make the following proposals for some ground rules. > > > > > > 1. Please, don't edit the working draft unless you are part of the > editing team. > > > 2. Please, review and send comments and suggested content. One comment > per email with a subject that sets the context, e.g. s1.1, fix to para 3. If > you draft content that is complex, do it in MS Word using ONLY the default > text styles with body text at Arial/10pt. > > > 3. Please submit comments and content to the mailing list, so that they > are archived. > > > 4. Please, don't cc people who are known to be on the list when sending > to the list. > > > > > > Thanks :-) > > > ___________________________ > > > Matthew MacKenzie > > > Senior Architect > > > IDBU Server Solutions > > > Adobe Systems Canada Inc. > > > http://www.adobe.com/products/server/ > > > mattm@adobe.com > > > +1 (506) 871.5409 > > > > -- > > Kind Regards, > > Joseph Chiusano > > Associate > > Booz | Allen | Hamilton > > -- Kind Regards, Joseph Chiusano Associate Booz | Allen | Hamilton
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]