Re: [soa-blueprints] Anti-Blueprints - Number of services

[John Harby <jharby@gmail.com>]

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
> >
> >
> >
> >
>
>