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.
------------------------ Yahoo! Groups Sponsor --------------------~-->
Yahoo! Groups gets a make over. See the new email design.
http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
