Although a lot of good information has come out in this debate, at a certain
point it becomes kind of silly since ultimately it depends upon what you're
doing.
If you are creating an SOA on the scale of the Web, it may well make sense to
take on the extra coding required to use a fixed interface and decode
individual documents.
On the other hand, if you are doing an SOA of reasonable size, something around
the 1500 services in production at Credit Suisse for example, it is worth the
extra productivity of using custom interfaces. At this type of level the
scalability issues do not apply.
Furthermore, both approaches are composable. Say you get into a bigger scale
SOA than a few thousand interfaces and decide to switch over to use fixed
interfaces. No problem, just add the new interface and call the old ones when
decoding the document.
At some point in the discussion it really needs to be recognized that no one
size fits all, and that a purist approach to any problem is impractical.
I suppose this should lead us into a discussion around rules of thumb for when
it's better to use one solution or another, but I worry that the religious
aspect of software, which unfortunately still seems somewhat prevalent in the
industry, may interfere with such a potential consensus.
Eric
[EMAIL PROTECTED] wrote:
On 7/6/06, Steve Jones <[EMAIL PROTECTED]> wrote:
> Now either I've been incredibly lucky or I only build mickey mouse
> apps... but I've never had this problem.
Another possibility is that you don't realize how simple things can
really be? That's how it was for me, at least.
> What form of scalability are you refering to?
Number of services. With Web services, for each new service that's
added to the system, in order for existing components to be able to
communicate with it, you have to modify them (ignoring the data issue,
which is the same with both). Not so with REST.
In technical terms, integration complexity with Web services is
typically O(NlogN) (O(N^2) worst case). With REST it's O(logN) (O(N)
worst case). There are even REST extensions where you can achieve
O(1) at scale (e.g. weblog aggregation, search). SOA is totally
heading in the wrong direction in terms of scaling.
Mark.
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/
