Someone calling himself r r left the following comment on
part IV of my
series of posts on SOA definition:
"I
keep trying to read this series on SOA unfortunately suffers from the
same disease as the rest of literature on the subject. stays general to
a comfortable level so it can't really be applied anywhere, tends to
complicate things where is not clear if it's needed, and encourages
philosophical debate on what ultimately is a business (and so concrete)
requirement. Meanwhile the serious (IMO) issues stay untouched - how
does one actually approach an integration project with functionality,
performance and security in mind. Which should be the standards used
(considering the tens of standards on WS out there). How granular
should the WS be (I'm done with answers like "not too much, but
enough", or "well, depends on your project"). "
Before
I talk a little about the "serious issues" mentioned above - I want to
point out that the point of this series of post, as stated in the first
post is to take a formal / semi-academic look at SOA. I started these
posts as a reaction to a comment that Pete Lacey
left on my blog stating that my view of SOA (as published in "
What is SOA anyway?")
does not demonstrate that SOA is an architectural style. I don't
pretense that this is some fully thought out academic dissertation or
anything but I do try to look at the architectural roots of SOA.
That
said let's take a look at the more interesting parts of this comment.
First, the thing that bothers me about this reaction is (what seems to
me as) the quest for final and concrete recipes. For instance consider
the comment on service granularity
"How granular should the WS be (I'm done with answers like "not too much, but enough", or "well, depends on your project"")
The
problems is - it does depend! and if you forgive me taking another
philosophical detour, if you try to provide a hard definition for a
service granularity you get something like the
heap paradox
- When you remove individual grains from a heap of sand is it still a
heap when one grain remains. So while it is obvious that hiding a
complete system as a single service is wrong and that exposing every
little object as a service is wrong (even though for some inexplicable
reason
Juval lowy seems to thing that the latter is good practice) it isn't really obvious when you get too granular.
Nevertheless
it is not a pure guess either. You can use some guidelines and measure
them against your specific project/system/enterprise needs. Personally
The set of guidelines I use is based on the
fallacies of distributed computing :
- The network is reliable
- Latency is zero
- Bandwidth is infinite
- The network is secure
- Topology doesn't change
- There is one administrator
- Transport cost is zero
- The network is homogeneous
Since
a service edge is boundary which may (usually is ) be accessed remotely
you need to think about the incoming and outgoing interactions of the
service within the fallacies stated above. if the proper behavior of
the service depends on one of the above there's probably something
wrong.
Regarding the other questions (how do you approach a real system),
well, if you pardon me for banging my own drum, that's exactly why I
started to write my experience on these matters as patterns. for
instance if we look at the
saga pattern
(one of the patters I published online). you'd see that it is talking
about achieving distributed consensus in a transaction-like manner. I
talk about the problems of using distributed transaction etc., offer an
architectural solution (the saga ) and then discuss relevant technology
issues (e.g. WS-BusinessActivity ) as well as its implication from
quality attributes perspectives (Integrity and reliability).
Nevertheless even these patterns aren't an end-all solution. different
circumstances require different solutions
Both my previous job and my current one involves building a scalable
solution on-top of algorithmic engines. In my previous job I managed
the construction of a biometric solution that allows using multiple
biometrics. In my current job I manage the development of a mobile
visual search solution . Again, while on the surface both needs to get
some data, run a few algorithms and produce an answer. These systems
have very different quality attributes. On the first system we had to
handle very large databases, hundreds of queries, an emphasis on
modifiability and security, the current one needs millions of queries,
almost no database, low latencies and emphasis on usability. These
differences result in radically different solutions, with different
services, different interactions , use of different patterns etc.
There's no "one right answer" (tm)