No, I wasn't referring to Todd's post, it was the fact that David Longley had promoted the same book twice in two successive emails and not necessarily seeming like it was completely germaine to the topic of the thread. I did not have any issue with Todd's email and I also will refer to my books when it seems like it might be helpful or appropriate but it was starting to seem as if David's answer to everything included a reference to a book.
----- Original Message ----
From: Gervas Douglas <[EMAIL PROTECTED]>
To: [email protected]
Sent: Friday, March 31, 2006 3:07:16 AM
Subject: [service-orientated-architecture] Re: Miko Does Not Believe in Starting Small
I think that we are in danger of getting a little over-sensitive on
this issue. I did not interpret David's quoting of that book as
billboarding. I have actually spoken to David on other matters and I
am sure he has enough on his hands without becoming a part-time
bookseller. Todd, you have absolutely no reason to apologise. Eric,
after all, quotes his products where relevant (to which there should
be no objection in principle provided it is done in the correct manner
he adopts), and I see no harm in quoting your sources. There are
sound reasons for bibliographies as any academic will tell you.
You do not have to be a commerce-hating, paranoid crypto-Marxist to
participate in this Group :). It would in any case be bad for your
blood pressure.
Gervas
Moderator
--- In [email protected], Todd Biske
<[EMAIL PROTECTED]> wrote:
>
> My apologies, as I started the trend by quoting Ron & Jason's book
> and jokingly pointing to the pages I was referencing. In my case, I
> was simply raising awareness of books that are useful, as any
> benefits to the authors isn't benefiting me in any way. I paid for
> my copy at the going price at Amazon. :)
>
> I think we've done a good job in bringing books to people's
> attention, but I did cross the line by doing more than simply
> mentioning the title. Quoting page numbers was a bit too much and
> could be misconstrued as a blatent plug.
>
> -tb
>
> On Mar 30, 2006, at 2:15 PM, Eric Newcomer wrote:
>
> > Are we promoting SOA books now on this list?
> >
> > ----- Original Message ----
> > From: david.longley <[EMAIL PROTECTED]>
> > To: [email protected]
> > Sent: Wednesday, March 29, 2006 6:39:59 AM
> > Subject: [service-orientated-architecture] Re: Miko Does Not
> > Believe in Starting Small
> >
> > Hi
> > It seems to me that its possible to categorize 'pilots' in one of 3
> > ways: (a) as a small training excerise working round business
> > issues; (b) as a a way of testing one approach against another for a
> > defined task; or (c) setting goals to assess the value of an
> > approach to 'solving' an business issue for real.
> >
> > In my view (a) is very questionable as it may not confront real
> > architecy=ure and business issues and thus its value in preparing
> > people for the 'real task' is smal at best and misleading at worst.
> > (b) is often used to compare products and/or SI companies - it is
> > thus contrived and unless performed in the guise of (c) will have
> > the inherent faults of (a).
> >
> > In (c) it should be expected that, if the pilot does meet its
> > success criteria, it will be an enterprise class and useable
> > service. So the key issues here are to do with selecting the
> > right "service" and being clear on success factors that define the
> > scope of the pilot .
> >
> > Thus there is implicit in the pilot full discovery and analysis as
> > with a full implementation. The only difference really being that
> > the size is ring fenced and there is a backout plan in the evnt of
> > disaster!
> >
> > Chapters 15 through 17 and especially 17 of "Understanding
> > Enterprise SOA" by Pulier & Taylor (http://www.soa.com/book/) offer
> > insight into best practise on this subject.
> >
> > Tx so much
> >
> >
> >
> > --- In [email protected], Todd Biske
> > <todd@> wrote:
> > >
> > > Bear in mind that the point about enterprise scale is actually
> > from
> > > ZapThink, quoted by Miko, quoted by me, so it's missing a lot of
> > > context. The context of the quote was speaking about pilots in
> > > general, not necessarily an SOA pilot. The way companies go
> > about
> > > selecting pilots and implementing them is somewhat contrary to
> > > everything SOA. There's a big risk that in selecting an SOA
> > pilot, a
> > > company may go about it like every other pilot, and miss all of
> > the
> > > non-technical things so critical to an enterprise SOA.
> > > See chapter 9, pages 169-173 in the Doomed book. :)
> > >
> > > A correctly defined SOA pilot should have the right elements to
> > be
> > > applicable when a full scale enterprise adoption is embraced.
> > >
> > > -tb
> > >
> > >
> > > On Mar 24, 2006, at 6:31 AM, JP Morgenthal wrote:
> > >
> > > > Todd,
> > > >
> > > >
> > > >
> > > > I like the way you stated your point. I tell
> > people
> > > > that no one gets it right the first time out and that, through
> > > > implementation, you will refactor your service architecture to
> > > > optimize. This is no different than database design or OO
> > design.
> > > > You "think" that it should be one way, but then as you start to
> > put
> > > > it into action, you "realize" that it would work better a
> > different
> > > > way. Hence, the design is ultimately modified by the usage.
> > > > However, I disagree with the point that what you do in a pilot
> > is
> > > > not what you would do on an enterprise scale in SOA. The goal
> > is
> > > > to abstract out the business service, period. It may need to
> > be
> > > > refactored as you begin to realize the design in
> > implementation,
> > > > but the process is the same regardless.
> > > >
> > > >
> > > >
> > > > JP
> > > >
> > > >
> > > >
> > > > From: [email protected]
> > > > [mailto:[EMAIL PROTECTED] On
> > Behalf
> > > > Of Todd Biske
> > > > Sent: Friday, March 24, 2006 12:42 AM
> > > > To: [email protected]
> > > > Subject: Re: [service-orientated-architecture] Re: Miko Does
> > Not
> > > > Believe in Starting Small
> > > >
> > > >
> > > >
> > > > Here are my thoughts, copied from my blog:
> > > >
> > > >
> > > >
> > > > Miko Matsumura recently posted about the myth of starting small
> > > > which was followed up by a response from Joe McKendrick of ZDNet.
> > > >
> > > > Miko stated that the only ones getting it right were ZapThink,
> > who
> > > > state that "the things you do in a pilot are the exact opposite
> > of
> > > > what you need to do to get to enterprise scale." For the record,
> > I
> > > > agree. This all comes down to defining the pilot properly. In
> > their
> > > > book, "Service Orient or Be Doomed!" Jason and Ron call out
> > three
> > > > SOA Pilot essentials: an architectural plan (the pilot will
> > cover
> > > > some portion of it), a specific scope, and clear acceptance
> > criteria.
> > > >
> > > > There shouldn't be much controversy over these, but yet, the
> > case
> > > > studies and whitepapers that I see presented don't have these
> > > > elements, and it's usually because the study is equating web
> > > > services usage with SOA. Taking a user-facing customer portal
> > and
> > > > extending it by allowing customers to integrate their systems
> > > > directly can be a good thing, but is it really an SOA pilot?
> > > >
> > > > One of the key things, in my opinion, in a proper SOA pilot is
> > to
> > > > pick a problem that will require the organization to see the
> > > > cultural changes that are necessary to become a service
> > provider.
> > > > In the portal case, the group maintaining the portal is already
> > a
> > > > service provider, so there's no big stretch there. Instead, we
> > need
> > > > to find a service that has potential for reuse, and has no
> > clear
> > > > owner in the current organization structure. This scenario will
> > > > give a good dose of what SOA is all about from an IT
> > perspective.
> > > > If you're using the pilot to sell SOA to the business, you've
> > got
> > > > to be even more careful in your selection, especially in
> > picking
> > > > the right service consumers. Agility is a particularly
> > difficult
> > > > thing to pilot, because it only becomes evident when something
> > > > needs to change. If a pilot is putting it in place for the
> > first
> > > > time, there's no change involved. What can help pick the right
> > > > pilot? The architectural plan. If the architectural plan isn't
> > > > already service-oriented, however, what do you do?
> > > >
> > > > My advice is to first focus on why you're doing the pilot, and
> > what
> > > > you hope to achieve/prove. If IT begins to understand what being
> > a
> > > > service-provider means (you need to have a pilot that have
> > distinct
> > > > service consumers and providers to do this), it is progress,
> > even
> > > > if the service isn't as coarse-grained as it should be or can
> > be
> > > > used as a good case for business justification. It may not be
> > SOA
> > > > yet, but it is a step in right direction. Once you understand
> > how
> > > > the IT organization needs to change, now you can pick a service
> > > > with a bit more impact that really can show the business that
> > IT
> > > > has its act together and can make a difference.
> > > >
> > > > -tb
> > > >
> > > >
> > > >
> > > > On Mar 23, 2006, at 3:47 PM, miko_68 wrote:
> > > >
> > > >
> > > >
> > > >
> > > > Just to clarify--I think Pilots and Proof-of-concept projects are
> > > >
> > > > important for some. And I also believe that some projects are
> > just
> > > >
> > > > plain inappropriate for enterprise scale SOA. So I'm certainly
> > not
> > > >
> > > > advocating a leap without thinking approach.
> > > >
> > > >
> > > >
> > > > It's *after* you do the pilot and when you get into deploying
> > services
> > > >
> > > > that impact the business and livelihood of your company where I
> > think
> > > >
> > > > you need to deal with architecture (hmm loaded word, sorry).
> > > >
> > > >
> > > >
> > > > The concern I have isnt neccesarily with people doing small SOA
> > > >
> > > > things, it's more the idea that a small mentality can govern a
> > big
> > > >
> > > > architecture...
> > > >
> > > >
> > > >
> > > > --- In [email protected], "Gervas
> > > >
> > > > Douglas" <gervas.douglas@> wrote:
> > > >
> > > >>
> > > >>
> > > >> <<Start Small. Start small. Start Small. Start Small. Oh wait, I
> > > >>
> > > >> forgot to mention that you should probably Start Small.
> > > >>
> > > >>
> > > >>
> > > >> The superplatform vendors want you to do things "iteratively".
> > > >>
> > > >> Iteratively is code word for dont build too fast so we can
> > catch
> > > >> up to
> > > >>
> > > >> the market! Platform vendors have long been hoping that SOA
> > could be
> > > >>
> > > >> defined as "all the stuff I have been selling for years, with a
> > new
> > > >>
> > > >> brand". Customers are too smart to fall for that and are
> > steaming
> > > >> aheadÂ…
> > > >>
> > > >>
> > > >>
> > > >> I think the only folks who have gotten "Start Small" correct
> > have
> > > >> been
> > > >>
> > > >> Zapthink.
> > > >>
> > > >>
> > > >>
> > > >> The piece that they get right is that the things you do in a
> > pilot
> > > >> are
> > > >>
> > > >> the exact opposite of what you need to do to get to enterprise
> > scale.
> > > >>
> > > >> The shortcuts that seemed so expedient in the small picture are
> > > >>
> > > >> impossible to avoid when you take a serious corporate asset
> > and
> > > >> put it
> > > >>
> > > >> up as a live service.
> > > >>
> > > >>
> > > >>
> > > >> If you dont have some reasonable architectureal guidance in
> > place as
> > > >>
> > > >> you go to enterprise scale, even starting small wont get you
> > there.
> > > >>
> > > >>
> > > >>
> > > >> One Response to "The myth of start small" >>
> > > >>
> > > >>
> > > >>
> > > >> You can read this at: <http://www.soacenter.com/?p=43>
> > > >>
> > > >>
> > > >>
> > > >> Gervas
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > > http://groups.yahoo.com/group/service-orientated-
> > architecture/
> > > >
> > > >
> > > >
> > > > [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > > > http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 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.
> > > >
> > > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> > 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.
> >
> >
>
----- Original Message ----
From: Gervas Douglas <[EMAIL PROTECTED]>
To: [email protected]
Sent: Friday, March 31, 2006 3:07:16 AM
Subject: [service-orientated-architecture] Re: Miko Does Not Believe in Starting Small
I think that we are in danger of getting a little over-sensitive on
this issue. I did not interpret David's quoting of that book as
billboarding. I have actually spoken to David on other matters and I
am sure he has enough on his hands without becoming a part-time
bookseller. Todd, you have absolutely no reason to apologise. Eric,
after all, quotes his products where relevant (to which there should
be no objection in principle provided it is done in the correct manner
he adopts), and I see no harm in quoting your sources. There are
sound reasons for bibliographies as any academic will tell you.
You do not have to be a commerce-hating, paranoid crypto-Marxist to
participate in this Group :). It would in any case be bad for your
blood pressure.
Gervas
Moderator
--- In [email protected], Todd Biske
<[EMAIL PROTECTED]> wrote:
>
> My apologies, as I started the trend by quoting Ron & Jason's book
> and jokingly pointing to the pages I was referencing. In my case, I
> was simply raising awareness of books that are useful, as any
> benefits to the authors isn't benefiting me in any way. I paid for
> my copy at the going price at Amazon. :)
>
> I think we've done a good job in bringing books to people's
> attention, but I did cross the line by doing more than simply
> mentioning the title. Quoting page numbers was a bit too much and
> could be misconstrued as a blatent plug.
>
> -tb
>
> On Mar 30, 2006, at 2:15 PM, Eric Newcomer wrote:
>
> > Are we promoting SOA books now on this list?
> >
> > ----- Original Message ----
> > From: david.longley <[EMAIL PROTECTED]>
> > To: [email protected]
> > Sent: Wednesday, March 29, 2006 6:39:59 AM
> > Subject: [service-orientated-architecture] Re: Miko Does Not
> > Believe in Starting Small
> >
> > Hi
> > It seems to me that its possible to categorize 'pilots' in one of 3
> > ways: (a) as a small training excerise working round business
> > issues; (b) as a a way of testing one approach against another for a
> > defined task; or (c) setting goals to assess the value of an
> > approach to 'solving' an business issue for real.
> >
> > In my view (a) is very questionable as it may not confront real
> > architecy=ure and business issues and thus its value in preparing
> > people for the 'real task' is smal at best and misleading at worst.
> > (b) is often used to compare products and/or SI companies - it is
> > thus contrived and unless performed in the guise of (c) will have
> > the inherent faults of (a).
> >
> > In (c) it should be expected that, if the pilot does meet its
> > success criteria, it will be an enterprise class and useable
> > service. So the key issues here are to do with selecting the
> > right "service" and being clear on success factors that define the
> > scope of the pilot .
> >
> > Thus there is implicit in the pilot full discovery and analysis as
> > with a full implementation. The only difference really being that
> > the size is ring fenced and there is a backout plan in the evnt of
> > disaster!
> >
> > Chapters 15 through 17 and especially 17 of "Understanding
> > Enterprise SOA" by Pulier & Taylor (http://www.soa.com/book/) offer
> > insight into best practise on this subject.
> >
> > Tx so much
> >
> >
> >
> > --- In [email protected], Todd Biske
> > <todd@> wrote:
> > >
> > > Bear in mind that the point about enterprise scale is actually
> > from
> > > ZapThink, quoted by Miko, quoted by me, so it's missing a lot of
> > > context. The context of the quote was speaking about pilots in
> > > general, not necessarily an SOA pilot. The way companies go
> > about
> > > selecting pilots and implementing them is somewhat contrary to
> > > everything SOA. There's a big risk that in selecting an SOA
> > pilot, a
> > > company may go about it like every other pilot, and miss all of
> > the
> > > non-technical things so critical to an enterprise SOA.
> > > See chapter 9, pages 169-173 in the Doomed book. :)
> > >
> > > A correctly defined SOA pilot should have the right elements to
> > be
> > > applicable when a full scale enterprise adoption is embraced.
> > >
> > > -tb
> > >
> > >
> > > On Mar 24, 2006, at 6:31 AM, JP Morgenthal wrote:
> > >
> > > > Todd,
> > > >
> > > >
> > > >
> > > > I like the way you stated your point. I tell
> > people
> > > > that no one gets it right the first time out and that, through
> > > > implementation, you will refactor your service architecture to
> > > > optimize. This is no different than database design or OO
> > design.
> > > > You "think" that it should be one way, but then as you start to
> > put
> > > > it into action, you "realize" that it would work better a
> > different
> > > > way. Hence, the design is ultimately modified by the usage.
> > > > However, I disagree with the point that what you do in a pilot
> > is
> > > > not what you would do on an enterprise scale in SOA. The goal
> > is
> > > > to abstract out the business service, period. It may need to
> > be
> > > > refactored as you begin to realize the design in
> > implementation,
> > > > but the process is the same regardless.
> > > >
> > > >
> > > >
> > > > JP
> > > >
> > > >
> > > >
> > > > From: [email protected]
> > > > [mailto:[EMAIL PROTECTED] On
> > Behalf
> > > > Of Todd Biske
> > > > Sent: Friday, March 24, 2006 12:42 AM
> > > > To: [email protected]
> > > > Subject: Re: [service-orientated-architecture] Re: Miko Does
> > Not
> > > > Believe in Starting Small
> > > >
> > > >
> > > >
> > > > Here are my thoughts, copied from my blog:
> > > >
> > > >
> > > >
> > > > Miko Matsumura recently posted about the myth of starting small
> > > > which was followed up by a response from Joe McKendrick of ZDNet.
> > > >
> > > > Miko stated that the only ones getting it right were ZapThink,
> > who
> > > > state that "the things you do in a pilot are the exact opposite
> > of
> > > > what you need to do to get to enterprise scale." For the record,
> > I
> > > > agree. This all comes down to defining the pilot properly. In
> > their
> > > > book, "Service Orient or Be Doomed!" Jason and Ron call out
> > three
> > > > SOA Pilot essentials: an architectural plan (the pilot will
> > cover
> > > > some portion of it), a specific scope, and clear acceptance
> > criteria.
> > > >
> > > > There shouldn't be much controversy over these, but yet, the
> > case
> > > > studies and whitepapers that I see presented don't have these
> > > > elements, and it's usually because the study is equating web
> > > > services usage with SOA. Taking a user-facing customer portal
> > and
> > > > extending it by allowing customers to integrate their systems
> > > > directly can be a good thing, but is it really an SOA pilot?
> > > >
> > > > One of the key things, in my opinion, in a proper SOA pilot is
> > to
> > > > pick a problem that will require the organization to see the
> > > > cultural changes that are necessary to become a service
> > provider.
> > > > In the portal case, the group maintaining the portal is already
> > a
> > > > service provider, so there's no big stretch there. Instead, we
> > need
> > > > to find a service that has potential for reuse, and has no
> > clear
> > > > owner in the current organization structure. This scenario will
> > > > give a good dose of what SOA is all about from an IT
> > perspective.
> > > > If you're using the pilot to sell SOA to the business, you've
> > got
> > > > to be even more careful in your selection, especially in
> > picking
> > > > the right service consumers. Agility is a particularly
> > difficult
> > > > thing to pilot, because it only becomes evident when something
> > > > needs to change. If a pilot is putting it in place for the
> > first
> > > > time, there's no change involved. What can help pick the right
> > > > pilot? The architectural plan. If the architectural plan isn't
> > > > already service-oriented, however, what do you do?
> > > >
> > > > My advice is to first focus on why you're doing the pilot, and
> > what
> > > > you hope to achieve/prove. If IT begins to understand what being
> > a
> > > > service-provider means (you need to have a pilot that have
> > distinct
> > > > service consumers and providers to do this), it is progress,
> > even
> > > > if the service isn't as coarse-grained as it should be or can
> > be
> > > > used as a good case for business justification. It may not be
> > SOA
> > > > yet, but it is a step in right direction. Once you understand
> > how
> > > > the IT organization needs to change, now you can pick a service
> > > > with a bit more impact that really can show the business that
> > IT
> > > > has its act together and can make a difference.
> > > >
> > > > -tb
> > > >
> > > >
> > > >
> > > > On Mar 23, 2006, at 3:47 PM, miko_68 wrote:
> > > >
> > > >
> > > >
> > > >
> > > > Just to clarify--I think Pilots and Proof-of-concept projects are
> > > >
> > > > important for some. And I also believe that some projects are
> > just
> > > >
> > > > plain inappropriate for enterprise scale SOA. So I'm certainly
> > not
> > > >
> > > > advocating a leap without thinking approach.
> > > >
> > > >
> > > >
> > > > It's *after* you do the pilot and when you get into deploying
> > services
> > > >
> > > > that impact the business and livelihood of your company where I
> > think
> > > >
> > > > you need to deal with architecture (hmm loaded word, sorry).
> > > >
> > > >
> > > >
> > > > The concern I have isnt neccesarily with people doing small SOA
> > > >
> > > > things, it's more the idea that a small mentality can govern a
> > big
> > > >
> > > > architecture...
> > > >
> > > >
> > > >
> > > > --- In [email protected], "Gervas
> > > >
> > > > Douglas" <gervas.douglas@> wrote:
> > > >
> > > >>
> > > >>
> > > >> <<Start Small. Start small. Start Small. Start Small. Oh wait, I
> > > >>
> > > >> forgot to mention that you should probably Start Small.
> > > >>
> > > >>
> > > >>
> > > >> The superplatform vendors want you to do things "iteratively".
> > > >>
> > > >> Iteratively is code word for dont build too fast so we can
> > catch
> > > >> up to
> > > >>
> > > >> the market! Platform vendors have long been hoping that SOA
> > could be
> > > >>
> > > >> defined as "all the stuff I have been selling for years, with a
> > new
> > > >>
> > > >> brand". Customers are too smart to fall for that and are
> > steaming
> > > >> aheadÂ…
> > > >>
> > > >>
> > > >>
> > > >> I think the only folks who have gotten "Start Small" correct
> > have
> > > >> been
> > > >>
> > > >> Zapthink.
> > > >>
> > > >>
> > > >>
> > > >> The piece that they get right is that the things you do in a
> > pilot
> > > >> are
> > > >>
> > > >> the exact opposite of what you need to do to get to enterprise
> > scale.
> > > >>
> > > >> The shortcuts that seemed so expedient in the small picture are
> > > >>
> > > >> impossible to avoid when you take a serious corporate asset
> > and
> > > >> put it
> > > >>
> > > >> up as a live service.
> > > >>
> > > >>
> > > >>
> > > >> If you dont have some reasonable architectureal guidance in
> > place as
> > > >>
> > > >> you go to enterprise scale, even starting small wont get you
> > there.
> > > >>
> > > >>
> > > >>
> > > >> One Response to "The myth of start small" >>
> > > >>
> > > >>
> > > >>
> > > >> You can read this at: <http://www.soacenter.com/?p=43>
> > > >>
> > > >>
> > > >>
> > > >> Gervas
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > > http://groups.yahoo.com/group/service-orientated-
> > architecture/
> > > >
> > > >
> > > >
> > > > [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > > > http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 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.
> > > >
> > > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> > 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
- 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.
