OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-blueprints message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [soa-blueprints] Anti-Blueprints - Number of services




This comes down to Deutch's fallacies on network computing
(http://today.java.net/jag/Fallacies.html)

Definitely an anti-pattern (array iteration via web services is always a
good laugh).

Steve

> -----Original Message-----
> From: John Harby [mailto:jharby@gmail.com]
> Sent: 04 November 2005 14:45
> To: soa-blueprints@lists.oasis-open.org
> Subject: Re: [soa-blueprints] Anti-Blueprints - Number of services
>
> Whether this is common sense or not it is a major failing point of
> many attempting previous distributed architectures such as CORBA and
> EJB.
>
> On 11/1/05, marchadr@wellsfargo.com <marchadr@wellsfargo.com> wrote:
> >
> > I thought this was common sense?  :)
> >
> > But definitely should be in the anti-patterns.
> >
> > - Dan
> >
> > -----Original Message-----
> > From: John Harby [mailto:jharby@gmail.com]
> > Sent: Tuesday, November 01, 2005 6:27 AM
> > To: soa-blueprints@lists.oasis-open.org
> > Subject: Re: [soa-blueprints] Anti-Blueprints - Number of services
> >
> >
> > One metric that I think is relevant is message design. The notion of
> > distributing fine grained objects has been flagged as an anti-pattern by
> > many including Fowler (
> > http://www.sdmagazine.com/documents/s=815/sdm0304a/). For
> > example, If I have one service method which returns an employee number
> and
> > another which returns the employee name then since these will both be
> > frequently required by consumers, I should provide a way for consumers
> to
> > retrieve both rather than subject them to multiple unnecessary
> invocations.
> >
> >
> > On 11/1/05, Davies Marc <Marc.Davies@uk.fujitsu.com> wrote:
> >
> > > Now you've hit the important point for me Miko - SOA isn't *just*
> services
> > > (despite our recent conversation thread), its architecture. My view is
> > that
> > > the services are the *realisation* of good architecture and a
> collective
> > > approach toward building a loosely-coupled, multi-tiered and flexible
> > > environment where its possible to gain cost synergies and re-use
> > > flexibility, avoiding the seemingly endlessly recurring scenario of
> > > large-scale enterprise with its bulky, silo-maintained and poorly
> > integrated
> > > (while being tightly coupled!) typical non-SOA environment.
> > >
> > > I think Duane's example of the Internet perfectly underscores this
> > principle
> > > - inasmuch as the Internet is a collection of millions of services -
> it is
> > > (IMHO) *not* an SOA - unless we're talking Service Oriented Anarchy :-
> )
> > >
> > > ... it doesn't conform to architectural disciplines, anyone can code
> how
> > > they want, anyone can deploy what they want, there are no checks to
> ensure
> > > services deliver on their promised capability (I could go on). Sure,
> its
> > an
> > > excellent example of how millions of services can be operating - but,
> its
> > > also an illustration of how millions can end up delivering very poor
> > > service, to analogise - if you google the 'wrong' search string - you
> end
> > up
> > > with 1 million 'hits' = meaningless
> > >
> > > Essentially, this is my rationale for finding Steve's document so very
> > > useful as a benchmark pointing us forward, as (for a change) it
> doesn't
> > seem
> > > to be the tail wagging the dog - i.e. its top-down approach assures
> the
> > kind
> > > of alignment with business goals which I think SOA is trying to
> achieve,
> > > abstraction (at all levels) is an important element of SOA and in this
> > > context defines (to me) the importance of blueprints; properly done
> they
> > > represent a model that ensures a solution is customer (i.e. business
> > > processes, goals and fundamentals) focussed, rather than technology
> > driven.
> > >
> > > Regards,
> > > Marc.
> > >
> > >
> > > -----Original Message-----
> > > From: Miko Matsumura [mailto:mmatsumura@infravio.com ]
> > > Sent: 01 November 2005 02:33
> > > To: Duane Nickull; Jones, Steve G; Beack, Theo; Davies Marc; Ken
> Laskey
> > > Cc: soa-blueprints@lists.oasis-open.org
> > > Subject: RE: [soa-blueprints] Anti-Blueprints - Number of services
> > >
> > > I deprecated the microservice antipattern because it was a "I know it
> when
> > I
> > > see it" antipattern, but hard to codify. I added a comment to the "Too
> > many
> > > cooks" antipattern to get a similar point across. I just see too many
> > people
> > > focused on the "S" part of SOA and maybe not enough on the "A".
> Present
> > > company excluded, of course.
> > >
> > >        -----Original Message-----
> > >        From: Duane Nickull [mailto: dnickull@adobe.com]
> > >        Sent: Mon 10/31/2005 4:42 PM
> > >        To: Miko Matsumura; Jones, Steve G; Beack, Theo; Davies Marc;
> Ken
> > > Laskey
> > >        Cc: soa-blueprints@lists.oasis-open.org
> > >        Subject: RE: [soa-blueprints] Anti-Blueprints - Number of
> services
> > >
> > >
> > >
> > >        All:
> > >
> > >        I still have problems with the "number of services is a
> measurement
> > > of
> > >        whether something is a pattern/anti-pattern for SOA"
> conversation.
> > >
> > >        If you agree that the internet is a large SOA, it has more than
> > >        10,000,000 services and I do not think that anyone would state
> that
> > > is
> > >        not an SOA due to the large number of services.  I would not be
> > > willing
> > >        to state that the internet is architected errantly since it has
> too
> > > many
> > >        services. Number of services has no static bearing on good vs.
> bad
> > >        design IMO.  The requirements vary specific to scenario and
> YMMV.
> > >
> > >        Some thoughts on what may not be SOA (*thoughts only)
> > >
> > >        1. A service that is orphaned and has no associated mechanism
> for
> > > being
> > >        discovered by any consumer is probably not SOA, even though it
> is a
> > >        service itself.  One of the core tenets of SOA is that concrete
> > > services
> > >        must have some mechanism to declare they exist and are
> available
> > and
> > > to
> > >        communicate such to potential consumers.
> > >
> > >        A service availability and discovery concept is in the core
> > > reference
> > >        model (*EDITORS DRAFT only).
> > >
> > >        2. A service with a set of metadata too slim to provide a
> potential
> > >        consumer with the information and/or pointers to information it
> > > requires
> > >        to make a service invocation request is not SOA.  This may
> include
> > > many
> > >        mechanisms including out of band human-to-human contact to
> figure
> > > out
> > >        more intricate details.
> > >
> > >        A service discovery concept is in the core reference model.
> > >
> > >        3. A set of multiple services that functionally duplicate each
> > other
> > > and
> > >        one of the services is not used by any active or planned future
> > > consumer
> > >        MAY be a poor practice, but is still probably SOA.
> > >
> > >        4. A service that does not have a mechanism to allow a
> potential
> > >        consumer to discover its policies may not be SOA.  Even if a
> > service
> > > has
> > >        no specific policies, that is still a conceptual policy.
> > >
> > >        5. A set of services that advertise or claim they act on a
> specific
> > >        resource but in fact do not do anything, are likely not SOA.
> > >
> > >        6. A service that has no interaction possible is likely not
> SOA.
> > >
> > >        7. An always on synchronous socket from one physical endpoint
> to
> > > another
> > >        may not be SOA.  Not sure how to qualify this or if it is
> relevant
> > > to
> > >        the price of tea in China...
> > >
> > >        So what!
> > >
> > >        While this is an interesting conversation, I also think it may
> > > detract
> > >        from the work of building the following items:
> > >
> > >        1. A metamodel for expressing architectural blueprints; and
> > >        2. A catalog of SOA blueprints and a system for locating ones
> that
> > > are
> > >        applicable to a specific scenario.
> > >
> > >        Duane
> > >
> > >
> > >
> > >
> >
> >

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]