Here's wishing I already had cut & paste on my iPhone...
Q1: have you understood the definition of SOI correctly? Yes.
Q2: what if incremental gains are sufficient? I absolutely agree. You
need to have some idea of why you're doing SOA and what you hope to
achieve, and find a way to measure it so you know when you're
successful. If you have very little redundancy in your enterprise and
the more important goal is looser coupling to minimize the impact of
change, then merely plugging in some XML technologies in place of
something else could be sufficient. The key here is knowing and
defining what is sufficient. I suspect most organizations don't have a
good handle on this.
Q3: Can an integration architecture be service-oriented. I have a hard
time viewing an integration architecture as anything more than a
technology architecture, which leads me to say it can be web service
oriented, but not service oriented, at least in how I use the term. As
soon as I go toward my definition of service, it's about a functional
architecture. An integration architecture is about how we construct
the services rather than what the services are.
-tb
Todd Biske
http://www.biske.com/blog/
Sent from my iPhone
On Mar 19, 2009, at 10:26 AM, Rob Eamon <[email protected]> wrote:
With the responses from you and Anne, SOI isn't about architecture
but more about the technology used in typical integration efforts.
Have I understood correctly?
If so, I'll drop the SOI exploration and continue the SO principles
applied to IA exploration.
Two main points:
* SOA isn't only for making "significant differences." Incremental
benefits are okay too. As a style, SOA makes no assumptions about
scope.
* SOA does not require application rationalization/redundancy
reduction. Such an effort can be beneficial for an enterprise but
not doing that doesn't mean one is not "doing SOA."
"SOA must be applied at something larger than a single application
to get anything better than incremental gains."
True, but what if incremental gains are sufficient? My main purpose
of starting this thread was to raise an objection to the common
argument that SOA can only be reasonably applied at the top level
architectures. That only SO at the EA or BA levels is worthwhile.
That not only is applying SO at lower levels not advisable, but does
not constitute SOA. It's something else at best and at worst is
something sinister.
Gartner's definition of SOA started out as an application
architecture notion. Applying SO to one application, or to an
integration architecture, may not get you the benefits possible when
applying SO to everything, but it is still SO. SOA scope has grown
since then but SO applied to AA is still SOA.
Strictly speaking, reducing redundancy is not an SO principle. At
least I haven't seen that listed in the popular definitions
(Gartner, OASIS, Erl, etc.). Indeed, many describe the flexibility
gained from SOA is in part due to the (theoretical) ability to swap
out one service for another when desired/needed. This implies the
availability of redundant or overlapping services.
I don't argue that reducing redundancy cannot be a valuable thing.
At the EA level such efforts can trim a lot of dead weight. But not
doing that doesn't mean you're not doing SOA.
Can an integration architecture be SO? Can the integration
components be SO when the end-points being connected are not SO? Can
an integration effort reasonably create the service front-ends for
applications, wrapping them with discoverable services/interfaces
and treating the application as the service implementation?
Quick definition of IA: An architecture that defines components to
provide interaction between (usually existing) end-points.
Typically, the end-points cannot be modified to support the desired
interactions and are thus often wrapped with an adaptive layer that
bridges the integration environment and the end-point.
The granularity and scope of that adaptive layer can effectively
form a service.
Thoughts?
-Rob
--- In [email protected], Todd Biske
<toddbi...@...> wrote:
>
> Here's my take. SOI, service oriented integration, is probably
> best stated as WSOI- Web Services Oriented Integration. It's
> simply the act of taking the same integration points that arise in
> a project and using web services or some other XML over HTTP
> approach to integrate the systems. Could this constitute a service-
> oriented application architecture? Absolutely, but in my mind,
> there is at best incremental benefits in this approach versus some
> other integration technology. Because the scope is a single
> application, it's unlikely that any ownership domains beyond the
> application itself were identified, so there won't be anyone
> responsible for actually looking for and removing other redundant
> service implementations. Because the scope of the services
> involved didn't change, only the technologies used, it's unlikely
> that the services will have any greater potential for reuse than
> they would with another integration technology except
> that XML/HTTP will be more interoperable, than say, Java RMI, if
> that's even a concern. To me, SOA must be applied at something
> larger than a single application to get anything better than
> incremental gains. Services should be defined along ownership
> domains that create accountability for driving the redundancy out
> of the enterprise where appropriate.
>
> This is why an application rationalization effort or application/
> service portfolio management is a critical piece of being
> successful. If it's just a "gut feel" that there is a lot of waste
> in the IT systems, arbitrary use of a different integration
> technology won't make that go away. Only working to identify the
> areas of redundancy/waste, defining appropriate ownership domains,
> and then driving out the redundancy through the use of services
> will make a significant difference.
>
> -tb
p-msg p a span.yshortcuts { font-family: Verdana; font-size: 10px;
font-weight: normal; } #ygrp-msg p a { font-family: Verdana; font-
size: 10px; } #ygrp-mlmsg a { color: #1E66AE; } div.attach-table div
div a { text-decoration: none; } div.attach-table { width:
400px; } --> l>
