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

[<marchadr@wellsfargo.com>]

This would be great.
One problem might be some people implementing the solution might have thought it was a good use of standards.

- Dan

-----Original Message-----
From: Duane Nickull [mailto:dnickull@adobe.com]
Sent: Friday, November 04, 2005 7:46 AM
To: Jones, Steve G; John Harby; soa-blueprints@lists.oasis-open.org
Cc: carol.geyer@oasis-open.org; James Bryce Clark; Jane Harnad; Scott
McGrath
Subject: RE: [soa-blueprints] Anti-Blueprints - Number of services


This gave me a funny idea.  Maybe for the upcoming OASIS conference in
May 2006, we should ask them to hold a "worst/funniest use of standards
or technology contest".  This is a variation of the Oreilley Open Source
conference's "Obfuscated Perl contest".

I have an idea for an entry that will get you ROTFL. 

Guidelines:

Each contestant will submit an entry in writing.  5 finalists will be
chosen and will be able to demonstrate their projects during lunch in
the Banquet hall.  Judges will make decisions based on the most
convoluted use of standards to make something much more complex that it
has to be.  Extra points will be given to those using OASIS standards.

Submissions deadline: Dec 31

First round judging decisions - Jan 30.  To give contestants time to
prepare their projects.

Carol, Jane???

Duane

-----Original Message-----
From: Jones, Steve G [mailto:steve.g.jones@capgemini.com] 
Sent: Friday, November 04, 2005 7:36 AM
To: John Harby; soa-blueprints@lists.oasis-open.org
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.