Service Oriented Architectures

چندماهی است که در پروژه‏هایی همکاری می‏کنم که نگاه “معماری سرویس گرا”- Service Oriented Architecture- در آن غالب است. در این پروژه‏ها، این نگاه از سوی کارفرما به عنوان یک “الزام” مورد تأکید قرار گرفته است. هر چند باید یادمان باشد که این رویکرد، تنها رویکردی است به معماری و نه همه ارکان توسعه نرم‏افزار. صرف نظر از مثبت بودن نگاهم به این رویکرد، موضوعی که همواره در این گونه موارد مرا نگران می‏کند، آسیب‏شناسی آنهاست؛ چرا که تجربه‏ی عملی از آن در کشور وجود ندارد و از طرف دیگر به دلیل نیاز مطرح نمی‏شوند بلکه به دلیل شانتاژهای مقالات و محتوای اینترنتی این کار صورت می‏گیرد. هر چند اعتقادم این است که نداشتن روالهای مناسب برای جذب رویکردها، روشها و تکنولوژِی‏‏ها، یکی از معضلات مهم جامعه IT ماست. صرف نظر از مثبت بودن نظرم درباره این رویکرد، وقت زیادی را برای پیدا کردن پاسخ سؤالهایم (سؤالهایی که منشأ از نگرانی‏ام دارند) صرف می‏کنم. مقاله زیر از گریدی بوچ، یکی از پاسخهایی است که پیدا کرده‏ام. امیدوارم برای شما هم مفید باشد.
همچنین توصیه می‏کنم که مجله Objective View را هم مطالعه نمایید. مطالعه آن برای من همیشه مفید بوده است.

I not so long ago returned from some work with the SEI in Pittsburgh and then in Washington, DC where I conducted a number of customer visits primarily focusing on service oriented architecture.
Comments about hunting with Dick go over really, really well with the DC crowd.
My take on the whole SOA scene is a bit edgier than most that I’ve seen. Too much of the press about SOA makes it look like it’s the best thing since punched cards. SOA will apparently not only transform your organization and make you more agile and innovative, but your teenagers will start talking to you and you’ll become a better lover. Or a better shot if your name happens to be Dick. Furthermore, if you follow many of these pitches, it appears that you can do so with hardly any pain: just scrape your existing assets, plant services here, there, and younder, wire them together and suddenly you’ll be virtualized, automatized, and servicized.
What rubbish.
SOA is, first and foremost, about the A part of the acronym (architecture). Organizations who already have a solid approach to architecture will likely do reasonably well with SOA; organizations who already have a broken architecture and/or a broken architectural governance practice will likely fail with SOA and then blame SOA on all their problems.
If you follow the history of web-centric systems, services (with a small s) are a very logical progression of web mechanisms. From a technical perspective, SOA is nothing revolutionary, it’s evolutionary. BTW, in this context, the concept of an enterprise service bus can be easily explained as a very elegant and simple pattern for location independence/message translation.
There are places where SOA is suitable, and places where it is not. SOA, from my experience, is one specific architectural style appropriate for systems of systems wherein some but not necessarily all of those systems are already web-centric. This is an important point: SOA is a useful but insufficient mechanism for architectural decomposition. Some would suggest that SOA is all you need. This is seriously wrong.
To that end, services (with a small s) are best suited to relatively large grained/low frequency interactions rather than small grained/high frequency interactions. For that latter situation, other, more traditional, mechanisms of RPC and/or message passing are better suited.
A serious gap in the current state of the art of services is that we simply don’t know how to specify quality of service very well at all. It’s one thing to wire together services a la National Instrument’s LabView, it’s another if there are quality/performance/reliability/security/dependability issues for each of those channels and each of those ports.
There are also services with a big S: there is a conceptual kind of service that is not manifest as a pure WSDL service but rather something else. Think of a service as a port on a system, with that port having a well-defined interface consisting of a vocabulary of classes, a protocol, and a particular set of messages and resulting behavior. It is a good thing that you can conceptualize a system as a web of services, some of which are Services and some of which are, well, services.
Going back to the A part of SOA, the issue then is one of abstraction, separation of concerns, and all the usual fundamentals of architecture. I’ve seen some folks suggest creating an SOA from the bottom up: look at a silo, identify the potential services, and publish them, then weave a system together from them. This is in essence technology first. In my experience, this is a recipe for disaster and/or serious over-engineering. You’ve got to start with the scenarios/business needs, play those out against the existing/new systems, zero in on the points of tangency, and there plan a flag for harvesting a meaningful service. These styles, and their resulting costs/benefits, are rarely discussed.
In a couple of weeks, I’m off to a very different venue, where I’ll be giving a talk at the Game Developer’s Conference in San Jose. Developing software for games is big business, and this community is starting to discover that the fundamentals are important: you can’t build an enduring a business just by hiring bright people, throwing them in a room together, and hoping that they’ll do great things.

Refs: ObjectiveView A Magazine for the Professional Software Developer, Issue 10

گزیده:

I don’t pretend we have all the answers. But the questions are certainly worth thinking about. Arthor Clark