Eric:
You make a nice point about configurable “solutions”
versus developing services. I would tend to agree with that and it seems to be
what customers are demanding as well. Possibly stems from the HUGE cost of
modifying an existing piece of code. The more adaptable a solution/application
is, the more it reduces your TCO. Policy oriented applications (the rage in our
market space) definitely seem to be part of this trend.
Mukund Balasubramanian
CTO/Infravio
Inc.
From: Eric Newcomer
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 08, 2006
3:40 PM
To:
[email protected]
Subject: Re:
[service-orientated-architecture] Re: SOA Infrastructure
Todd,
I agree with you on both points. To
underscore the
last one first, I believe open source will not
only
eventually overtake commercial products, but the
community will also become a source of innovation.
On the initial point about developers, I believe
you
are referring to configurable solutions. I
also think
this is very important, and we are definitely
working
in this direction. That is one of the
interesting
aspects of SCA, by the way.
Overall though - and although I'm not on the IT
side
right now, that is where I started my career - I
would
say that what we are heading for is a division of
labor situation in which developers will be tasked
primarily with creating services that are easy for
others to configure into applications. I see
both
roles continuing but divided, whereas today
developers
tend to work in both areas, or applications are
developed in a kind of turnkey fashion.
Eric
--- Todd Biske <[EMAIL PROTECTED]> wrote:
> I actually don't think the issue is the
> JMS-centricity of some
> products as Eric implies. It definitely
contributes
> to the
> controversy, but I wouldn't say it's the main
issue.
> As an end user
> working primarily on the infrastructure side
of
> things, I've had to
> give a lot of time and thought to this
space. I've
> actually brought
> it down to one major point. Do you want
the space
> in the middle to
> be the domain of developers or the domain of
> operations? On the one
> hand, we have flexibility. Flexibility
will require
> some more skill
> in getting the product do what you want it to
do.
> This typically
> will fall to the development staff. For
example, an
> application
> server is a very flexible product. On
the other end
> of the spectrum
> are the niche needs in the middle: routing,
> security, etc. These are
> configure-and-go black boxes that can be
completely
> handled by the
> operations staff.
>
> For at least the near term, companies will
exist
> that have needs
> across the whole spectrum. Only time
will tell what
> winds up
> defining the product space that comprises the
SOA
> infrastructure.
> Eventually, the common needs will come out,
and the
> product space
> will converge. Personally, the thing
that I find
> the most
> interesting going on in this space is the
open
> source efforts. The
> reason for this is that you now have open
source
> products competing
> against appliances (and closed source),
rather than
> against closed
> source products. I'm not sure how it
will turn out,
> but it's fun to
> watch.
>
> -tb
>
> On Mar 7, 2006, at 3:21 PM, Awel Dico wrote:
>
> > Hi Eric;
> >
> > It is a good observation as to how the
vendors are
> approaching the
> > ESB product implementation. That
diversity may be
> positive for the
> > users - choose what best fit to their
situation.
> The reality from
> > your customers (users) perspective is
different
> though. Many
> > enterprises do not just go and buy those
"ESB
> products". They look
> > at the ESB capabilities as a pattern
first - at
> least from the point
> > of view of the enterprise I work for.
With clear
> understanding of
> > the capabilities, they map those
capabilities with
> the SOA
> > infrastructure requirement. This is
important
> because you may not
> > need ESB at all (XML appliances may do
the job);
> or it is something
> > that you need right away, or it may be
something
> for the future. The
> > enterprise architecture has to come up
with the
> SOA technology
> > infrastructure reference architecture
accordingly.
> Based on the
> > understanding of the capabilities
required and
> enterprise
> > architectural guidelines, they start to
evaluate
> ESB products - may
> > take them for a test drive
(Proof-of-concept
> type). The point I am
> > trying to make here is that it is not an
issue or
> controversial from
> > the users perspective. It may be an
issue from
> vendor's perspective.
> >
> > Regards,
> > Dico
> >
> >> The result on the one hand is JMS
centric while
> on the
> >> other ours is a multi-communications
protocol,
> multi
> >> data format, brokerless, hubless
distributed
> >> architecture much better suited for
SOA
> >> infrastructure.
> >>
> >> Unfortunately it seems like most
vendors are
> adopting
> >> the JMS centric approach, and that
is what leads
> to
> >> the controversy.
> >
> >
> > --- In
>
[email protected],
> Eric
> > Newcomer <[EMAIL PROTECTED]> wrote:
> >>
> >> A lot of posts to this group, and
recent blogs by
> Joe
> >> McKendrick among others, have
brought up the
> debate
> >> again about the Enterprise Service
Bus.
> >>
> >> For the most recent, see:
> >>
>
http://blogs.zdnet.com/service-oriented/index.php?p=560
> >>
> >> Among the questions debated here is
the lifetime
> of
> >> the ESB product category. Some
suggest that it's
> a
> >> temporary product category, soon to
be subsumed
> by
> >> something else.
> >>
> >> I'm not so sure. It takes a
long time for a new
> >> product category to get
established. Just ask
> our
> >> friends at Sonic ;-).
> >>
> >> And with IBM, BEA, Oracle, Tibco,
and others
> recently
> >> announcing they would ship an ESB
the product
> category
> >> has definitely been validated and, I
believe,
> >> established.
> >>
> >> But what is an ESB? This
question does indeed
> >> continue to trouble the industry,
since it still
> seems
> >> as if every vendor has a different
definition.
> >>
> >> Several months ago I was invited to
help deliver
> a 3
> >> -hour tutorial on SOA and ESBs
together with
> David
> >> Chappell of Sonic. He ended up
injuring himself
> in a
> >> water skiing accident (which he
blogged about)
> shortly
> >> before the tutorial date, so while
the two of us
> >> collaborated on the development of
the
> presentation a
> >> colleague of Dave's ended up
physically joining
> me in
> >> Washington for the event.
> >>
> >> The way we split things up was:
> >>
> >> -- I did about 45 minutes on generic
SOA
> >> -- Dave did about 45 minutes on
generic ESB
> >> -- Each of us did about 30 minutes
on our
> >> technologies, Artix and Sonic ESB,
respectively
> >>
> >> (With breaks and Q&A that filled
the time.)
> >>
> >> The interesting thing to me was how
well the two
> of us
> >> could agree on the generic SOA and
ESB
> definitions. I
> >> would say it was like 90-95%.
Where we diverged
> was
> >> in our respective approaches to
addressing the
> >> requirements of SOA infrastructure,
aka our ESB
> >> products.
> >>
> >> I think up to this point Dave would
agree with
> >> everything I've said. Now I
will give my view.
> >>
> >> The difference is that Sonic started
with its
> >> successful JMS product and added Web
services
> support
> >> and other elements of integration
software in
> order to
> >> create an ESB that meets SOA
infrastructure
> >> requirements.
> >>
> >> We started with our patented
configurable
> microkernel,
> >> ART, and added a Web services
"personality" aka
> >> collection of plugins.
> >>
> >> The result on the one hand is JMS
centric while
> on the
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com
YAHOO! GROUPS LINKS
