[…] did caution against that SOA “couldn’t be bought in a box” and that got picked up by at least one blog. I stand by that. If you “buy” Indigo or IBM or Neuron or NServiceBus or whatever, you are not […]
I see you are now changing what you wrote but what leads you to constitute that I am writing a “marketing serial.” I am devoting dozens of hours to an ambitious task of trying to communicate a little about an area I know in contrast to areas I don’t where I cannot communicate so well, like ASP.NET. Where do you feel like you are being “marketed” to? The fact that I may mention, dare forebid, a product as an example and it doesn’t start with an “N?” Blasphemy!!
I don’t actually feel marketed to – I feel educated by your posts and read them carefully, but the culmination ends up here, and it almost sounds like candy bar commercial
Introduction to Neuron as WCF/SOA Enabler and “BizTalk and Neuron: Better Together”
Neuron ESB and Publish-Subscribe, Mediation, Routing, etc.
And I’m not dogmatic about N”open-source” by any stretch – I think Neuron is a top notch product, and from my very limited experience it has by far more fit and finish than any other ESB offering in the .NET space, at least from what I’ve been able to dig up.
So I wasn’t trying to be disparaging or negative, but your series of posts appears to be organized like a typical white paper where part 1 is the general educational material and part 2 is how the problem is solved by a product. I’ve learned extensively from white papers and never felt like the case study at the end detracted from the educational material within, yet promotion or evangelism of the product is still a goal. Perhaps my assumption may have been off base, but that’s how it goes sometimes. I apologize if I offended, my tone was intended to be matter of fact without any implication of a sneer.
@Pat, I agree, those tenets are important in defining, or at least implementing SOA. I would say they are probably a subset, though, the final list being different, possibly vastly so, from one school of thought to the next.
“And then there is the ubiquitous prejudice (bordering on hatred) that SOA and its practitioners seem to universally hold against the poor beleaguered “Silo”. (Oh Silo, who weeps for thee?) ”
I basically read tons of stuff on integration – and so SOA as it relates to that – and then aggregate the content for an executive IT/business audience. I think a lot of the problem may be you’re reading stuff that’s more for CIOs than people actually wanting to build SOAs. And I agree, it’s hard to get advice that moves from philosophical to implementation.
ZapThink might have more useful information for you. There’s also the Yahoo SOA group, but it tends to be very much about debating nuances.
Rob, I’m not in much of a position to disagree with you practically, because as I’ve mentioned I have very little experience in this arena. Still, I would have a hard time saying that SOA isn’t necessarily about technology – can you have a service that is purely human based, with no integration point with technology? I didn’t so much mean it is technology like web services are a certain kind of technology, but at the end of the day your architecture will be manifested in technology if it is manifested at all. You can’t apply SOA to bridges or football arenas, SOA is a technology architecture.
In my mind, the city metaphor is not just “architecture in general”, or “enterprise architecture in general” whereas SO is a particular of flavor architecture in general. The important part of the city metaphor for me is the autonomous nature of each level in the systems hierarchy and that each logical entity transacts with those around it through a globally standardized infrastructure and set of mandated conventions that permeate the whole system, and yet a particular unit of logic, be it a web service or a LOB application, is as N-tier as it cares to be on its own time. Traditional architecture or generalized EA doesn’t mandate service autonomy or a common, enterprise wide infrastructure (or protocol), or centralized governance or loose coupling, but the city metaphor does imply those things, and from what i can tell those things are a pretty important part of most accounts of SOA I have seen.
I can’t even picture what SOA could possibly be about if it isn’t about how units of business functionality as automated by software are expected to interact with one another. Loose coupling, share contract not class, all that jazz is all about defining the relationships between such units of business functionality, and it standardizes that realtionship to maximize certain qualities such as reuse or loose coupling, and a standardized method of interactions to me feels a lot like how autonomous humans are similarly enabled to transact with one another in very complicated ways via a common set of laws, conventions and standardized infrastructure that is our society.
And I haven’t really heard of SOA being applied to application architecture, except in the context of composite applications, so I can’t speak to that, but I have a hard time picturing it. In any case I don’t see SOA as just a style, if scope isn’t involved then I’m totally missing the point. If it were just a style you can apply here and not there, then you could have one application handily crafted in the SOA style and one in the N-Tier style next door, but the connection between them isn’t addressed. You could say to a visitor “Here we have our ERP system, it was built using the post-WS-* SOA style. And here we have our CRM, it was constructed in the JBOWS style. I don’t recommend using that system at night, it isn’t in the best neighborhood” But then I don’t think you would have an SOA, as I have come to understand it. As I have come to understand it, the term SOA applies to all participants in a given system if they are N-tier or anything else.
“…can you have a service that is purely human based, with no integration point with technology?”
Yes. Business do that all the time. They might use Excel to track things, for example, but it’s hard to argue that the Excel part is a “service.” It is a tool, an “implementation detail” and is but a part of the service.
“The objective of a service is to represent what the business does and place a boundary which all parties, but predominantly the business, can agree on. It is this representation of the business on which the createion of a Service Architecture must be focused, technology is very much a secondary element and many of the services will never even be realised using technology.”
Now Steve is firmly in the “SOA is a business architecture and technology SOA should be called SOD (service oriented design) or tSOA” camp. But it reinforces my point that SO can be applied at differing levels of scope and is not always about technology (though I understand that the conventional wisdom is that SOA is exactly about technology).
“Traditional architecture or generalized EA doesn’t mandate service autonomy or a common, enterprise wide infrastructure (or protocol), or centralized governance or loose coupling,…”
“Traditional architecture” or “EA” will mandate characteristics and constraints. The characteristics and constraints you’ve listed have appeared in non-SO architectures before. For example, EAI influenced architectures have touted loose coupling for a long, long time. Centralized governance is not unique to SO. The only relatively new thing SOA brings to the table, indeed, the *only* thing SOA specifies IMO, is that the major components are to be services whose implementations are separate from the interfaces.
SO principles do not, IMO, “mandate a common, enterprise wide infrastructure (or protocol).” SOA definitions, such as the OASIS Reference Model, generally do not specify how services interact/communicate. Just that they do. One may decide to define a particular architecture using a common, enterprise wide infrastructure, but that is not a necessity to be SO.
One can use direct, service-to-service communication. One could use mediation of some sort. Both approaches (and others) are equally valid and would be driven by other desirable architecture principles (such as those associated with EDA, for example).
“I can’t even picture what SOA could possibly be about if it isn’t about how units of business functionality as automated by software are expected to interact with one another.”
You’re right that typically SO efforts are focused on the things that are to be automated but not everything needs to be automated. SO principles can be applied (should be applied?) beyond just software.
Your view is that SOA starts and ends at an enterprise technology level (please correct me if I’ve mistated your view). Others have different views. My opinion is that SO can be applied at any level, with varying degrees of impact on the overall business. Clearly, SO applied to an application architecture is going to have fairly limited impact, especially compared to SO applied to business architecture, which is much broader in scope.
You touched on the higher level: it is “units of business functionality…interact[ing] with one another.” At a business scope, technology is not in the picture. As SO is applied to lower scopes that’s when the implementations get mapped to people, technology, software, etc.
“And I haven’t really heard of SOA being applied to application architecture,…”
Gartner is generally credited with formalizing the definition of SOA first:
“Service-oriented architecture (SOA) is a client/server software design approach in which an application consists of software services and software service consumers (also known as clients or service requesters).
SOA differs from the more general client/server model in its definitive emphasis on loose coupling between software components, and in its use of separately standing interfaces. SOA principles are rendered during application design, development and deployment.”
SOA initially was an application architecture notion. It has since been broadened in scope (some would say the term has been hijacked).
“I don’t see SOA as just a style, if scope isn’t involved then I’m totally missing the point. …”
That’s why we’re having this discussion. 🙂
“If it were just a style you can apply here and not there, ”
Exactly–I’d argue that 100% of the companies “doing” SOA are doing just that. They don’t apply it everywhere. It’s rather impractical, and as it happens, unnecessary.
“…then you could have one application handily crafted in the SOA style and one in the N-Tier style next door, ”
Hmmm. SO solutions are often N-tier.
“…but the connection between them isn’t addressed.”
SO solutions *must* somehow interact with non-SO components. Adaptive layers are typical.
“But then I don’t think you would have an SOA, as I have come to understand it. As I have come to understand it, the term SOA applies to all participants in a given system if they are N-tier or anything else.”
This is why I say “SOA is not a discrete level of architecture.” IMO, one should never say “we have an SOA.” Rather, saying our *business architecture*, our *enterprise architecture*, our *integration architecture* (SOA does not eliminate the need for integration), and so on, are service oriented is more appropriate.
Additionally, those architectures may be event driven, and implementations may be object oriented, etc. A meaningful, useful architecture will comprise more than just services and will employ more than just SO principles. Why refer to the architecture by just one of its characteristics?
IMO, SOA does not infer a particular scope (there are those that disagree with me, like Steve Jones, Anne Thomas Manes and others). It is the architecture levels we already had, like BA, EA, AA, IA, etc. that sets the scope. SO is applied to those.
“the city metaphor is not just “architecture in general”, or “enterprise architecture in general””
META Group, and others, long ago equated enterprise architecture with city planning. Each of the characteristics you mention, “autonomous nature,” “hierarchy,” “set of mandated conventions,” etc. describe typcial architecture aspects. The emphasis on those characteristics may vary from architecture to architecture certainly, but SO principles didn’t introduce these notions. They’ve been around a long time.