SOA is an architecture that bridging the gap between business and IT through a
set of business-aligned IT services using a set of design principles, patterns
and techniques.
Architecture helps us to communicate and see the big picture, look beyond
immediate requirements to design flexible system that will adapt with the
changing needs of a business.
I do believe that SOA is architecture.
Comparing SO to OO paradigm might led to the conclusion that it is not an
architecture because SOA modeling requires additional activities and artifacts
that are not found in traditional OO.
So we need to make new higher abstractions than the abstraction of object
does.
We need to be able to explicitly address the techniques and processes
required for the identification, specification and realization of services,
their flows and composition, as well as ensure the quality of service required.
A paradigm shift is needs to occur, in order to appreciate the distinct
requirements of the two key roles in SOA: service provider and service
consumer.
Finally, applications that were built for one business must now aspire to be
used in a higher abstraction such as supply chain and be exposed to business
partners who might compose, combine and encapsulate them into new applications.
This is the notation of the service ecosystem.
This is a slight step up from just distributed objects.
Jan Algermissen <[EMAIL PROTECTED]> wrote:
On 08.02.2007, at 19:48, Eric Newcomer wrote:
Hi Mark,
I didn't think I was talking about architecture here ;-)
I was talking about SO as a paradigm as it compares to OO as a paradigm, and
especially as it relates to modeling business artifacts as IT artifacts.
SOA is a modeling approach - yes, definitely.
Does everyone agree that SOA has nothing to do with architecture (despite the
name)?
Jan
Todd has sent a nice post on this so I won't go into it more - the thrust of
it seems to be that the world is a mixture of functions and things so it's not
important to figure out whether either is right. I guess that makes sense - to
me the exercise of trying to "thingify" everything seems overly complex for the
purposes of application analysis and design.
Eric
----- Original Message ----
From: Mark Baker <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, February 8, 2007 10:45:44 AM
Subject: Re: [service-orientated-architecture] Booch on SOA & Architectur
Hi Eric,
On 2/8/07, Eric Newcomer <[EMAIL PROTECTED] com> wrote:
>
>
>
> I think what Steve said in the previous post is very important. To gain the
> benefit of service orientation it's important to design and model software
> systems in terms of functions (services) rather than things (objects) since
> functions are more naturally aligned with "what we do" as people and
> businesses.
I used to use that argument in favour of objects! Anyhow, I think
it's pretty specious; what matters is the architecture and its
properties; how it relates to what we do is a distant second.
> Given the service abstraction, implementation is a separate issue. As we have
> heard many times on this list a wide variety of technologies can be used for
> implementation. The most important thing is to get the design right - meaning
> to meet the business requirements, to align with the services that the
> business provides for its customers, or other departments.
Agreed; as I say above, the properties of the architecture (induced by
constraints) .
I'd like to hear about how services are better than objects from a
technical POV though; what constraints and properties do services
provide that objects don't? I've heard that services are supposed to
be stateless, but I'm unclear a) what that means (i.e. what kind of
state is absent), and b) whether they are in practice or not.
Mark.
--
Mark Baker. Ottawa, Ontario, CANADA. http://www.markbake r.ca
Coactus; Web-inspired integration strategies http://www.coactus. com
---------------------------------
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel
bargains.
