Re: [service-orientated-architecture] SOA and ESBs

Wed, 28 Jun 2006 01:34:31 -0700

Dennis,

You and I probably travel in different circles. My clients are the Fortune 500, so most of my recommendations are aimed at this type of client.

You said:

But I'd personally say that Java EE app servers are overkill for SOA unless a
business is already committed to J2EE,

I totally agree. In fact, I strongly discourage folks from building services using EJBs unless they have a really compelling requirement that calls for things only EJBs can do. On the other hand, most Fortune 500 companies are committed to at least one Java EE product, and this is the established development/deployment environment. But just remember -- you can deploy POJOs in a JAX-RPC or JAX-WS container.

and I also have my doubts about registries. On registries, I've yet to see a compelling use case for UDDI. The problem I see with UDDI is mainly that it's designed for use by programs - but there's nothing useful you can do automatically with the retrieved
information in a program. AFAIKS a web page-based human-readable and
searchable directory of services would be more effective than UDDI without requiring any special interfaces. I'm hoping someone can point out something I'm missing here.

Did I say UDDI? A registry should support the UDDI protocols, but it really needs to do a lot more than just implement the UDDI spec. A registry provides a central point of interoperability among the diverse runtime components with the service infrastructure. It can also act as a foundation for SOA governance. I've waxed prolific on this topic many times before, so you might want to search the archives. A small company may not need a registry, but a big company defintely does.

You can get by doing early prototypes and the first pilot or two without a registry, but from my perspective, your should establish good governance practices from the beginning, and a registry is the first component of a governance infrastructure.

Anne

On 6/27/06, Dennis Sosnoski <[EMAIL PROTECTED]> wrote:

Thanks for everyone's replies on this topic, and especially to Anne for
her detailed discussion of the issues. I've got a few comments and
questions inline.

- Dennis

Anne Thomas Manes wrote:
> ...


>
> In my book, the basic components include:
>
> * one or more service platforms (e.g., .NET, a Java EE app server,
> etc.)
> * a SOA management solution (e.g., AmberPoint, Actional, SOA Software)
> * a registry ( e.g., Systinet, Infravio)
> * an XML gateway if services will be exposed outside the firewall
> (e.g., IBM DataPower, Reactivity, Forum, Layer 7)
>
I wasn't previously aware of the SOA management solutions category of
products, and I think these do look potentially very useful for
monitoring and management (though I personally wouldn't consider them
basic components of a SOA). On gateways, I can see a solid use case for
helping to screen messages coming in from outside the firewall. But I'd
personally say that Java EE app servers are overkill for SOA unless a
business is already committed to J2EE, and I also have my doubts about
registries.

On registries, I've yet to see a compelling use case for UDDI. The
problem I see with UDDI is mainly that it's designed for use by programs
- but there's nothing useful you can do automatically with the retrieved
information in a program. AFAIKS a web page-based human-readable and
searchable directory of services would be more effective than UDDI
without requiring any special interfaces. I'm hoping someone can point
out something I'm missing here.

> ...

>
> I also definitely don't recommend using an ESB as a central hub for
> all SOA traffic. You and I had a private discussion a couple of days
> ago wherein I suggested that all important message traffic should be
> mediated -- but it should not be mediated by an ESB.
The ESB issue has been coming up a lot for me lately, in dealing with
customers who have attending marketing - oops, I mean "technical" -
presentations on SOA sponsored by certain vendors. But yes, I also had
that discussion in mind when I wrote this, and thanks for the
clarification.

> It should be mediated by XML gateways and/or SOA management agents. A
> mediation system should do ALL of the following
>
> * virtualization of endpoints (enabling dynamic location, binding,
> routing, versioning, etc)
> * transformations
> * security mediation and enforcement of security policies
> * monitoring, management, and control
>
> An ESB can only handle the first two. XML gateways and SOA management
> agents can do all four. My preference for a mediation system is an XML
> gateway because it offers the added value of hardware acceleration.
> Although I recommend XML gateways as a basic component only when
> exposing services outside the firewall, that's only when discussing
> the initial configuration. When first getting started, I think SOA
> management is a more important infrastructure component, because you
> need the monitoring and visibility features that only a SOA management
> system offers. But as the SOA initiative progresses, I recommend using
> an XML gateway for mediation between services inside the firewall.
> (You'll still need SOA management to implement endpoint-based policy
> enforcement points, but XML gateways make better mediators.)
Here again, I'm kind of caught in between. I can see the use of all this
in the context of a major enterprise with dozens of widely used
services. But for organizations that haven't reached that stage this
again seems like overkill. In particular,


* virtualization of endpoints (enabling dynamic location, binding,
routing, versioning, etc)

Dynamic location is certainly useful - our recent off-list discussion
was on the topic of why the web services stacks don't include support
for automatic redirection handling, which would allow light-weight
dynamic location support. I have a harder time seeing the usefulness of
binding/routing/versioning support in the context of smaller
organizations, though.

* transformations

I'd think transformations should ideally only be necessary when
communicating with external services. If an organization needs
transformations just as a matter of basic support it means to me that
they haven't done the work to standardize their data representations -
and they're not building a SOA, they're building a bunch of disconnected
web services without much planning and coordination.

* security mediation and enforcement of security policies

This is an interesting aspect. In smaller organizations I'd think that
services should generally set their own security policies. External
enforcement of security policies seems to me to be something that's only
appropriate when you get to large scale enterprises. I realize this
approach doesn't fit well with the widespread idea that SOA is all about
governance.

* monitoring, management, and control

Okay, even I can't argue the usefulness of this functionality. :-)
Still, smaller organizations may well be able to handle this using
direct hooks to individual services rather than a mediation system.


__._,_.___


SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to