It looks we are getting to common grounds, this is good.
I still do not see how an interaction may be service-oriented and not
service-oriented itself.
Also, a bit of disconnection I've found between 1) and 2):
1) >> If you put, e.g., a Web Service interface on the component, you > >have
an interaction between components via that interface but it is
> >not a service-oriented interaction
>I think that it is.
2) >I agree that simply the presence of WS-*/CORBA/RMI/ et al does not
>indicate an SO architecture.
What makes an interaction service-oriented if not an interaction between
services?
I disagree that "The interaction might be service oriented with a component
that is not"
"SOA is integration" != 'SO architecture results in an integrated system' (as
one of its results but NOT the primarily one)
false true
- Michael
________________________________
From: Rob Eamon <[email protected]>
To: [email protected]
Sent: Monday, December 22, 2008 9:06:54 PM
Subject: [service-orientated-architecture] Re: Yefim Natis is sure that "SOA is
integration"
--- In service-orientated- architecture@ yahoogroups. com, Michael
Poulin <m3pou...@.. .> wrote:
>
> "The interactions between the components might be specified in an
> SO way (service wrappers around non-service capability, sort of)."
>
> After you create a service that encapsulates a component, the
> interaction happen between services, not components any more.
Not exactly. The interaction might be service oriented with a
component that is not. I agree that from an interface perspective,
the distinction is all but nil but at the architecture level, we know
that the component is not a service and thus the interface may
contain compromises in principles. Not an ideal scenario but
pragmatic.
> If you put, e.g., a Web Service interface on the component, you
> have an interaction between components via that interface but it is
> not a service-oriented interaction
I think that it is.
> - you can put any type of interface on the component and it does
> not make it a service.
Agreed. I hope I've not promoted that notion.
> This is exact the reason I argue against 'integration= SOA'
I've not argued that integration == SOA. I've argued that designing
an SO architecture results in an integrated system. One could argue
that virtually an type of architecture represents an integrated
system. That's almost the entire point of an architecture- -define
components and the relationships/ interactions between them.
> -integration via interfaces called 'service' does not convert a
> monolithic application into the service.
Agreed. Wasn't arguing for that.
> Unfortunately, many people do exactly this - wrapping monolithic
> application with Web Services - and claim they have SOA solution.
> Why then they cannot find SOA benefits from such "SOA" and saying
> us the SOA fails?
I agree that such an approach can be lacking in many ways.
> Does SOA include integration? Sure, it does.
Then we agree.
> Does integration constitute SOA? No, it does not.
I don't think anyone argued for that view. The simple presence of
integration characteristics indicates nothing about the encompassing
architecture.
> I am saying that integration with Web Services/CORBA/ RMI/etc. is
> not SOA yet; there has to be a business orientation first.
I agree that simply the presence of WS-*/CORBA/RMI/ et al does not
indicate an SO architecture.
Architecture is preferrably driven by business orientation first, but
as we all know, that's not always the case. SOA != BA. SOA != EA. SOA
does not imply any particular level of architecture.
I know many feel that SO at other levels does not constitute SOA,
that "true" SOA must be at the business and/or enterprise level. But
I disagree. The greatest benefits will be achieved when SO is applied
at the highest levels, but applying SO principles at lower levels is
not without merit.
Might the real problem be that folks apply SO to lower level
architectures and then expect higher level benefits? I suspect that
is the case.
-Rob
