معماری سرویس گرا (بخش ششم) – بزودی در این مکان کله پزی "اصغر کله پز" افتتاح خواهد شد!

در معماری سرویس گرا، هر سرویس از دو قسمت کلی تشکیل می شود: Contract و Logic

Contract یک سرویس، ساختار و رفتار قابل انتظار آن سرویس را مشخص ساخته و Logic پیاده سازی این ساختار و رفتار است. به عبارت دیگر، با مشاهده Contract یک سرویس می توان در مورد قابلیتهای ارایه شده توسط سرویس و نحوه ارایه آن قابلیتها قضاوت کرد در صورتی که پیاده سازی این قابلیتهای "ادعا شده" وظیفه بخش Logic آن سرویس است.

به پارچه نوشته سر در این مغازه توجه کنید:

به زودی در این مکان کله پزی "اصغر کله پز" افتتاح خواهد شد.

ساعت کار: همه روزه 5 صبح تا 11 صبح (به استثنای جمعه ها) – جمعه ها از 6 صبح تا 1 عصر

کله پاچه همه روزه – جمعه ها حلیم با گوشت بوقلمون

با ظرفیت پذیرایی از 50 نفر

 

اصغر آقا در این پارچه نوشته در واقع Contract First Design را رعایت کرده است!

کله پزی مزبور هنوز افتتاح نشده است (شاید حتی وسایل آن هم تهیه نشده باشد)، اما با دیدن این نوشته بسیاری از حقایق برای ما مشخص می شود:

هدف افتتاح مغازه (کله پزی)،  زمان فعالیت، غذای ارائه شده و حداکثر ظرفیت پذیرایی مشتری

 

Contract First Design در فرآیند حرکت سازمان به سوی سرویس گرایی و حتی پس از آن، هنگام ایجاد سرویس جدید برای سازمان یک رویکرد توصیه شده (Best Practice) است. به این شکل که پیش از ایجاد هر سرویس (یا مجموعه ای از سرویس ها)، ابتدا ساختار، قابلیت ها، داده های ورودی-خروجی و کیفیت آن سرویس در قالب Service Contract ارایه می شود.

Contract ایجاد شده برای یک سرویس به دو بخش Technical Contract (یا بخش قابل پروسس توسط کامپیوتر) و Non-Technical Contract (یا بخش قابل فهم برای انسان – Human Readable Contract) تقسیم می شود.

بخش اول با توجه به تکنولوژی انتخاب شده می تواند قالبهای مختلف داشته باشد (مثلا در صورتی که تکنولوژی مورد استفاده، Web Service باشد عموما فایلهای WSDL و XSD).

بخش دوم معمولا در قالب SLA – Service Level Agreement ارایه می شود که می تواند به شکل ساده، یک فایل متنی به زبان فارسی یا انگلیسی نگاشته شود. در این بخش معمولا کیفت سرویس مانند کارایی (Performance)، حداکثر تعدا کاربر، بار ترافیک پیشبینی شده، زمان قطع سرویس به منظور پشتیبانی و .. مورد توجه قرار می گیرد.

 

نکته قابل توجه اینجاست که استفاده کنندگان از سرویس (Service Consumers) می توانند تنها با در دست داشتن Service Contract برنامه خود را توسعه دهند، بدون نیاز به اینکه حتی پیاده سازی سرویس مورد نظر آغاز شده باشد.

مشتریان آینده کله پزی اصغر آقا با خواندن همین چند جمله خواهند دانست که پس از افتتاح مغازه چه انتظاری می توان از آن داشت: قابلیت های ارایه شده (کله پاچه، حلیم)، زمان ارایه قابلیت ها و ساعت های فعالیت سرویس مورد نظر و حتی تعداد کاربران همزمان!

 

<بخش قبل  بخش بعد>

معماری سرویس گرا (بخش پنجم) – تاثیر سرویس گرایی بر سازمان

۱. سرویس گرایی و مفهوم "برنامه کاربردی" (Application):

در دنیای غیر سرویس گرایی، سازمانها دارای تعدادی برنامه کاربردی (Applications) هستند. به عنوان مثال سیستم مدیریت مشتری (CRM) سازمان، سیستم حقوق و دستمزد و وب سایت سازمان به عنوان برنامه های کاربردی مستقل از یکدیگر (و یا در بهترین حالت تحت یک سیستم بزرگ ERP) وجود دارند.

این برنامه های کاربردی در واقع هر یک مانند یک سیلو و مستقل از سیلوی دیگر در سازمان وجود دارد و همانگونه که در بخش بعد شرح داده می شود، در شرایطی که سازمان نیاز به مرتبط ساختن این سیلوها با یکدیگر داشته باشد، در بیشتر موارد تنها راه حل، استفاده از یکپارچه سازی (Integration) خواهد بود.

در سازمانهای سرویس گرا اما، این مفهوم به طور کلی دستخوش تغییر می شود. کلیه قابلیت های لازم (Capabilities) به شکل سرویس های قابل استفاده مجدد و مستقل از یکدیگر ایجاد و نصب می گردد (که در پستهای آینده شرح داده خواهد شد که حوزه یا Scope این سرویس ها می تواند بخشی از سازمان یا کل سازمان باشد که در حالت اول تشکل Domain Inventory و در حالت دوم تشکیل Enterprise Inventory را می دهد).

کلیه سرویس های طراحی و تولید شده در سازمان، در ظرفی به نام Inventory قرار داده می شوند. بدین ترتیب با ترکیب دو یا چند سرویس و مرتبط ساختن آنها با هم به قابلیت های جدید دست پیدا خواهیم کرد.

به این شکل در سازمانهای سرویس گرا (یا دست کم در بخشی از سازمان که سرویس گرایی به طور موفق پیاده شده است) مفهوم برنامه کاربردی (Application) بسیار کم رنگ یا حذف می گردد.

 

۲. سرویس گرایی و مفهوم "یکپارچه سازی" (Integration):

در محیط های غیر سرویس گرا، به دلیل وجود برنامه های کاربردی متعدد، مجموعه ای از سیستم های غیر همگن و غیر همشکل از نظر تکنولوژی، ساختار، کاربرد و ساختار اطلاعاتی مواجه هستیم. سالهاست که سازمان ها برای تبادل اطلاعات میان برنامه های مختلف و پوشش نیازمندی های جدید خود، اقدام به یکپارچه سازی می کنند.

به عنوان مثال، سازمانی را در نظر بگیرید که مجهز به دو سیستم مجزا یکی برای مدیریت اطلاعات پرسنل داخلی و دیگری به منظور مدیریت اطلاعات پیمانکاران است. به عنوان نیازمندی جدید، لازم است مدیران سطح دو شرکت گزارشاتی مشتمل بر اطلاعات هر دو گروه را دریافت دارند. یک سناریوی محتمل، استفاده از تکنیک یکپارچه سازی است.

همانگونه که در بند پیشین بیان شد، سازمان سرویس گرا در حالت ایده آل، دارای Inventoryی مشتمل بر کلیه سرویس های سیستم مدیریت اطلاعات پرسنل داخلی و همچنین پیمانکاران است. در این شرایط، برای برآورده ساختن نیازمندی جدید (ایجاد گزارشی از هر دو سیستم)، تنها کار لازم ایجاد ترکیبی (Composition) از سرویس های موجود است. سرویس هایی که از پیش با فرض "قابلیت استفاده مجدد" (Reusability) طراحی شده اند و به دلیل رعایت استانداردهای تعریف شده، تا حد زیادی همگن بوده و به راحتی با یکدیگر ترکیب می شوند.

به این منظور، هنگامی که سرویسی در سازمان طراحی می شود، یکی از ویژگیهای ذاتی آن قابلیت استفاده مجدد خواهد بود، بدون اینکه نیازمندیهای احتمالی آینده لحاظ گردد.

 

در پست های آتی، استاندارد سازی سرویس ها (Service Standardisation) و حتی مدل های داده ای سازمان (Data Schema) مورد توجه قرار خواهد گرفت.

<بخش قبل  بخش بعد>

دمی درنگ

An old Cherokee Indian was speaking to his grandson:

“A fight is going on inside me,” he said to the boy. “It is a terrible fight and it is between two wolves. One is evil – he is anger, envy, sorrow, regret, greet, arrogance, self-pity, guilt, resentment, inferiority, lies, false pride, superiority, and ego. The other is good – he is joy, peace, love, hope, serenity, humility, kindness, benevolence, empathy, generosity, truth, compassion, and faith.

This same fight is going on inside you, and inside every other person, too”

The grandson thought about it for a long minute, and then asked his grandfather, “Which wolf will win?”

The old Cherokee simply replied, “The one you feed.”

معماری سرویس گرا (بخش چهارم) – مزایای سرویس گرایی (ادامه)

(ادامه از پست پیشین)

 4. هم راستایی کسب و کار و فناوری (Increased Business and Technology Domain Alignment):

همواره عامل و توجیه تولید یک نرم افزار وجود مساله ای (مشکلی) در کسب و کار است.

موفقیت یا عدم موفقیت یک نرم افزار وابستگی زیادی به پوشش مساله ایجاد شده توسط راه حل نرم افزاری ارایه شده دارد. به بیان دیگر، هر چه راه حل نرم افزاری ارایه شده بهتر مساله مورد نظر را مورد پوشش قرار دهد، راه حل شانس موفقیت بیشتری دارد.

راه حل های نرم افزاری سنتی – در صورت طراحی درست – به راحتی قادر به حل مساله هستند. اما در صورتی که صورت مساله تغییر کند (که به دلیل ماهیت پویای کسب و کار، بسیار محتمل است)، به راحتی قادر به تغییر نبوده و حتی گاهی نیاز به توسعه راه حل جدیدی خواهد بود (شکل زیر را ببینید).

طراحی سرویس گرا به دلیل مجهز بودن به مفهوم Abstraction در لایه های مختلف این کمبود را کمینه می سازد. یکی از مهترین راههایی که معماری سرویس گرا برای هم راستایی و انعطاف بیشتر در مقابل تغییر در اختیار طراحان قرار می دهد وجود لایه هایی حاوی سرویس های با کاربردهای تجاری مستقل است.

در نتیجه در صورت تغییر صورت مساله تجاری، در بسیاری از اوقات می توان با تغییر پیکر بندی (Configuration) و ترکیب بندی (Combination) سرویس ها به صورت مساله جدید دست پیدا کرد (شکل زیر را ببینید).

ارزش برای شرکت کالایاب:

شرکت کالایاب (مانند بسیاری از شرکت های در حال رشد) دارای ماهیت پویایی و تغییر است. به ویژه به این علت که این شرکت نوپا و تازه تاسیس است، بسیاری از فرآیندهای آن به سرعت دچار تغییر و بروزرسانی می شوند. به همین علت، وجود یک ساختار نرم افزاری پویا و انعطاف پذیر به خوبی پاسخگوی این نیازمندی استراتژیک است.

5. افزایش بازگشت سرمایه (Increased Return on Investment):

اندازه گیری میزان بازگشت سرمایه یک سیستم نرم افزاری، عامل مهمی در توجیه موفقیت و در مواردی حتی توسعه یا عدم توسعه نرم افزار است. هرچه بازگشت سرمایه صرف شده برای توسعه یک نرم افزار بیشتر باشد، سازمان بهره بیشتری از راه حل نرم افزاری ارایه شده می برد و هر چه بازگشت سرمایه کمتر باشد، نرم افزار ارایه شده بیشتر بودجه و سود سازمان را می بلعد.

راه حل های نرم افزاری سنتی (Silo Based) معمولا برگشت سرمایه سریعتری نسبت به راه حل های سرویس گرا دارند. اما در بلند مدت، معماری سرویس گراست که برنده این میدان است.

راه حل های سرویس گرا در ابتدای فرآیند توسعه زمان و منابع بیشتری را طلب می کنند اما به تدریج که سرویس های بیشتری برای استفاده مجدد در Service Repository قرار می گیرند، هزینه تولید فرآیندهای آینده به طور قابل توجهی کاهش می یابد. به علاوه اینکه با توجه به بند 4، در صورت نیاز به تغییر، هزینه اعمال تغییرات کمتر خواهد بود.

ارزش برای شرکت کالایاب:

با وجودی که پایه گذاری معماری سرویس گرا در شرکت کالایاب در ابتدا هزینه قابل توجهی را به سازمان تحمیل می کند، در بلند مدت بازگشت سرمایه صرف شده انتخاب این معماری را توجیه می کند.

 

6. افزایش چابکی سازمان (Increased Organizational Agility)

پاسخگویی سریع به نیازمندیهای جدید برای سازمانها همواره مزیت محسوب می شود. فرآیندها و نیازمندیهای یک سازمان در طول زمان دستخوش تغییرات زیادی می شود و در بسیاری از موارد، این تغییرات باید به سرعت اعمال گردند (ارایه یک سرویس یا محصول جدید توسط رقیب که نیاز به تصمیم گیری در کوتاهترین زمان ممکن برای سازمان ایجاد می کند، پاسخگویی سریع به نیاز مشتریان در شرایط خاص و یا نیاز به عرضه یک کالا یا خدمت برای مناسبت یا زمانی خاص نمونه های متداولی از نیازمندی های یک سازمان هستند که نیاز به تصمیم گیری و اجرای سریع دارند).

سرویس گرایی به دلیل ایجاد مجموعه ای از سرویس های قابل استفاده مجدد، به سازمان این انعطاف پذیری را می دهد که در هنگام نیاز در کوتاهتری زمان ممکن از منابع موجود بهره مند شده و پاسخگوی نیاز مزبور باشد.

ارزش برای شرکت کالایاب:

واضح است که این ویژگی برای شرکت کالایاب - مانند هر سازمان دیگری – مزیت بزرگی محسوب می شود.

 

7. کاهش حجم کاری و هزینه های فناوری اطلاعات سازمان (Reduced IT Burden)

به کار گیری مداوم سرویس گرایی در سازمان باعت کاهش افزونگی و اتلاف منابع، هزینه های عملیاتی و هزینه های بالاسری مربوط به راهبری و تکامل سیستم ها می شود.

این به معنی تخصیص بودجه کمتری از سازمان برای IT بوده که در نتیجه سازمان را قادر می سازد این سرمایه صرفه جویی شده را به قسمتهای مولد سازمان تزریق نماید.

ارزش برای شرکت کالایاب:

با توجه به وابستگی زیاد شرکت کالایاب به فناوری اطلاعات، پیش بینی می شود که این واحد سهم زیادی از سرمایه اولیه و جاری شرکت را به خود اختصاص دهد. کاهش هزینه های لازم برای واحد IT سازمان تاثیر مستقیم بر دیگر واحدها و در نهایت سود و زیان سازمان خواهد داشت.

 

<بخش قبل  بخش بعد>

معماری سرویس گرا (بخش سوم) – مزایای سرویس گرایی

در این نوشتار شرکت تخیلی کالایاب به عنوان نمونه (Case Study) مورد اشاره قرار می گیرد.

 

با علم به اینکه شرکت وابستگی زیادی به IT خواهد داشت، موسسین شرکت کالایاب تصمیم می گیرند از یک شرکت مشاوره با سابقه در این رابطه کمک گیرند.

شرکت مزبور پس از جلسات متعدد با مدیران شرکت تازه تاسیس کالایاب، گزارش پیشنهادی خود را ارایه می کند. در این گزارش، معماری پیشنهاد شده برای شرکت کالایاب، معماری سرویس گرا (SOA) انتخاب شده است.

مدیران شرکت کالایاب گزارشی تکمیلی در مورد علل انتخاب این معماری به عنوان معماری مرجع (Reference Architecture) درخواست می کنند. در گزارش دوم، علل انتخاب این معماری به این شرح بیان می شود:

۱. افزایش قابلیت تعامل ذاتی سیستم ها (Increased Intrinsic Interoperability):

هرچه سیستم ها بیشتر دارای قابلیت تعامل باشند، بهتر قادر خواهند بود که اطلاعات را بین خود جابجا کنند. برنامه های مختلف نرم افزاری که قابلیت تعامل (Interoperability) نداشته باشند، دیر یا زود به یکپارچه سازی (Integration) نیاز پیدا خواهند کرد. به عبارت دیگر، قابلیت تعامل ذاتی که در نتیجه اتخاذ سرویس گرایی برای سازمان است، نیاز سازمان را نسبت به یکپارچه سازی کمینه می سازد.

این ارزش به این علت حاصل می شود که سازمان در بلند مدت مجهز به سرویس هایی با کاربردهای مختلف می گردد که این سرویس ها به دلیل پیروی از اصول (Principles) یکسانی، دارای قابلیت همگذاری (Assemble) خواهند بود تا یک فرآیند جدید را ایجاد کنند.

ارزش برای شرکت کالایاب:

 شرکت کالایاب به دلیل برخورداری از سیستم ها و فرآیندهای نرم افزاری مختلف شامل ثبت سفارشات، جستجوی مناسب ترین تامین کننده، پرداخت الکترونیکی و ... در آینده نزدیک دارای سیستم های بزرگ و کوچک زیادی خواهد بود که بسیاری از آنها نیاز به تعامل و رد و بدل کردن اطلاعات با یکدیگر دارند. در نتیجه، وجود بستری که این سیستم ها و فرآیندها در آن قادر به ایجاد این تعامل، بدون نیاز به تحمل هزینه ها و محدودیت های یکپارچه سازی باشند قابلیتی مهم است.

۲. امکان انتخاب وسیع تر میان تولیدکنندگان نرم افزار (Increased Vendor Diversification Options):

این قابلیت به سازمانهایی که سرویس گرایی را به عنوان گزینه مورد نظر خود انتخاب کرده اند این امکان را می دهد که میان تولید کنندگان متعدد نرم افزارهای توسعه، قدرت انتخاب داشته باشند و حتی قادر باشند که همزمان از بیش از یک تولید کننده بهره گیرند. به عنوان مثال، سازمان قادر خواهد بود که برای توسعه همزمان از نرم افزارهای توسعه یافته توسط Microsoft، Sun Micro Systems و Oracle استفاده کند.

توجه شود که لزوما استفاده از شرکتهای مختلف توسعه نرم افزار یک مزیت به حساب نمی آید اما وجود قابلیت انتخاب میان آنها یک مزیت محسوب می شود.

این ارزش به این علت حاصل می شود که سرویس گرایی در نفس خود مستقل از Vendor و Technology است.

شکل های زیر را ببینید:

در شکل زیر سازمانی که از معماری سرویس گرا بهره نمی برد پس از یک سال تصمیم می گیرد که در تکنولوژی مورد استفاده سازمان تغییر حاصل نماید که این عمل با دشواری زیادی همراه خواهد بود.

در شکل زیر سازمانی دیده می شود که از معماری سرویس گرا بهره می برد. به دلایل گفته شده تغییر در تکنولوژی چالش کمتری به همراه خواهد داشت.

 

ارزش برای شرکت کالایاب:

این قابلیت شرکت کالایاب را قادر می سازد که بدون محدودیت، در مورد انتخاب یک یا چند Vendor تصمیم گیری کند. به عبارت دیگر، شرکت کالایاب در انتخاب Vendor ها صرفا به ارزش آنها برای شرکت خود توجه می کند و معماری سازمانی و نرم افزاری شرکت، محدودیتی در قبال استفاده از تامین کنندگان گوناگون تحمیل نمی کند.

۳. افزایش یکدستی (Increased Federation):

Federation به معنی ارایه منابع در قالبی یک دست و متحد در عین حفظ استقلال و خود گردانی آنهاست. به بیان دیگر، یک موجودیت در سیستم مانند مشتری همیشه به یک شکل و قالب و از طریق یک مرجع (Reference) قابل دسترسی خواهد بود.

استاندارد سازی یکی از مهمترین ویژگیهایی است که معماری سازمان را به سمت Federation پیش می برد.

ارزش برای شرکت کالایاب: با توجه به اینکه موجودیتهای مختلفی برای سیستمهای شرکت کالایاب در حال و آینده متصور است و نظر به اینکه نیاز است که این موجودیتها نه در یک سیستم، بلکه در سیستم های مختلف شرکت مورد استفاده قرار گیرد (Reuse شود)، افزایش Federation کمک به سزایی در رسیدن سازمان به یک دستی می کند. به عنوان مثال، موجودیت مشتری در سیستم تحت وب، سیستم مدیریت مشتری (CRM) و همچنین در سیستم مدیریت صورتحساب ها (Invoicing) وجود خواهد داشت و وجود یکدستی در استفاده از این موجودیت در سیستمهای مختلف بسیار سودمند خواهد بود.

(ادامه در پست بعدی)

پی نوشت: به منظور تکمیل این نوشتار و همچنین اطمینان از صحت مطلب، سوالی را از طریق Emailبرای Thomas Erl ارسال کردم که پاسخ آن را در زیر می خوانید (Thomas Erl موسس SOA School و SOA Systems Inc است. شاید بتوان وی را فعالترین محقق و نویسنده در زمینه Service Orientation دانست).

پرسش:

Interoperability و Federation هر دو از مزایایی به کار گیری سرویس گرایی است. با توجه به اینکه این دو ویژگی شباهتهایی با یکدیگر دارند، تفاوت آنها چیست؟

پاسخ:

Increased Federation is primarily about establishing a federated endpoint layer. Increased Interoperability is primarily about establishing inherent compatibility among services. Each goal supports and relies on the other, but each goal also represents a distinct part of the target state we look to achieve when adopting service-orientation.

 

<بخش قبل  بخش بعد>

دمی درنگ

چندی پیش ایمیل طنزی از دوستی دریافت کردم با عنوان "قوانینی که نیوتون از قلم انداخت" که البته بیشتر شباهت به قانون مورفی داشت:

قانون صف:
اگر شما از يک صف به صف ديگري رفتيد، سرعت صف قبلي بيشتر از صف فعلي خواهد شد.

قانون تلفن:
اگر شما شماره اي را اشتباه گرفتيد، آن شماره هيچگاه اشغال نخواهد بود.

قانون تعمير:
بعد از اين که دست تان حسابي گريسي شد، بيني شما شروع به خارش خواهد کرد.

قانون کارگاه:
اگر چيزي از دست تان افتاد، قطعاً به پرت ترين گوشه ممکن خواهد خزيد.

قانون معذوريت:
اگر بهانه تان پيش رئيس براي دير آمدن پنچر شدن ماشين تان باشد، روز بعد واقعاً به خاطر پنچر شدن ماشين تان، ديرتان خواهد شد. 

قانون حمام:
وقتي که خوب زير دوش خيس خورديد تلفن شما زنگ خواهد زد.

قانون روبرو شدن:
احتمال روبرو شدن با يک آشنا وقتي که با کسي هستيد که مايل نيستيد با او ديده شويد افزايش مي يابد.

قانون نتيجه:
وقتي مي خواهيد به کسي ثابت کنيد که يک ماشين کار نمي کند، کار خواهد کرد.

قانون بيومکانيک:
نسبت خارش هر نقطه از بدن با ميزان دسترسي آن نقطه نسبت عکس دارد.

قانون تئاتر:
کساني که صندلي آنها از راه روها دورتر است ديرتر مي آيند.

قانون قهوه:
قبل از اولين جرعه از قهوه داغتان، رئيس تان از شما کاري خواهد خواست که تا سرد شدن قهوه طول خواهد کشيد.

دمی درنگ

شرکت هواپیمایی Qantas بزرگترین شرکت هواپیمایی استرالیا و یکی از امن ترین خطوط هوایی دنیاست.

در تعطیلات عید پاک امسال، برخی از مشتریان این شرکت به دلیل نقص فنی در شیشه کابین خلبان تاخیری طولانی را تجربه کردند و در موردی دیگر، هواپیما به دلیل نقص فنی، ناچار به بازگشت به مبدا شد که در تمامی موارد پروازها بدون سانحه انجام گردید.

اما نکته قابل توجه، عذرخواهی رسمی بالاترین مقام اجرایی این شرکت از مردم از طریق رسانه ها بود. به علاوه به کلیه مشتریان فعلی و حتی مشتریان بالقوه این شرکت نامه ی عذرخواهی به امضای شخص مدیرعامل ارسال گردید.

 

معماری سرویس گرا (بخش دوم) – سرویس چیست؟

در دنیای گرداگرد ما نمودهای سرویس (خدمت) به وفور دیده می شود. در واقع عمر ارایه سرویس توسط بشر به اندازه عمر تمدن بشر است. هر فردی که وظیفه خاصی را در راستای خدمت رسانی به افراد دیگر انجام می دهد در واقع سرویس ارایه می دهد. به عنوان مثال راننده، نقاش، پزشک و ... . به علاوه مجموعه ای از افراد که هر یک وظیفه منفک از دیگری داشته اما در یک راستا کاری را به انجام می رسانند اقدام به ارایه سرویس می کنند. مانند افراد مختلف یک شرکت هواپیمایی که مشغول ارایه سرویس پرواز به مشتریان هستند. و به همین صورت است یک سازمان یا شرکت که خدمتی ارایه می کند.

به تعریف دیگر، در صورتی که وظیفه (task) در حال ارایه به طور مشخص تعریف شده باشد و به طور نسبی از دیگر وظایف قابل تفکیک باشد، به عنوان سرویس شناخته می شود.
در دنیای سرویس گرایی اما، سرویس یک مفهوم عام نیست. سرویس در حوزه سرویس گرایی بار معنایی خاصی دارد که دارای ویژگیهای منحصر به فرد طراحی است. به عنوان مثال، یکی از این ویژگیها "قابلیت استفاده مجدد" (Reusability) است. به عبارت دیگر در این دنیا، یک سرویس باید دارای این ویژگی به علاوه دیگر ویژگیهای یک سرویس باشد تا بتوان آنرا یک سرویس نامید.

سرویس مجموعه ای است از قابلیت ها (Capabilities)
به یاد داشته باشید که یک سرویس دارای مجموعه ای از قابلیت ها است. این قابلیت ها به نوعی مرتبط با زمینه (Context) سرویس مورد نظر هستند. در مثال زیر سرویس ارایه شده توسط شرکت هواپیمایی شامل فروش بلیت، جابجایی مسافر، استخدام و غیره است. همین طور قابلیتهای ارایه شده توسط یک پزشک شامل معاینه، ارایه نسخه و .. است.

همانگونه که در مثال بالا دیده می شود، کلیه قابلیتهای ارایه شده، به شکلی مرتبط با سرویس مورد ارایه هستند.

برای تعریف دقیق سرویس اینجا را کلیک کنید.

References:
1. SOA - Principles of Service Design, Thomas Erl, Prentice Hall, 2008
2. http://www.soaglossary.com/

 <بخش قبل   بخش بعد>

معماری سرویس گرا (بخش اول) – شرکت کالایاب

چندی پیش سه فارغ التحصیل دانشگاه در حین یک گردش دوستانه در مورد تصمیم هر یک برای شغل و فعالیت آینده خود گفتگو می کردند. بحث های مختلفی بین آنها رد و بدل می شود تا اینکه یکی از آنها ایده اولیه تاسیس یک شرکت خدماتی را مطرح می کند. پس از گفتگو و بحث گرد این موضوع، تصمیم می گیرند که در روزهای آتی بیشتر در مورد آن صحبت کنند.

 پس از چندین روز گفتگو هر سه تصمیم به تاسیس یک شرکت خدماتی با شرح وظایف زیر می گیرند:

فعالیت اصلی شرکت این است که برای مشتریان خود کالاهای مورد نیاز آنها را فراهم کرده و در محل مورد درخواست آنها تحویل دهد. به این شکل که پس از دریافت سفارش مشتری، کالای مورد نظر او در میان انبوه تامین کنندگان آن کالا جستجو شده، مناسب ترین تامین کننده با توجه به فاکتورهای مختلف شناسایی گردد، کالا تامین و به محل مشتری حمل شود. یکی از مهترین فاکتورها در انتخاب تامین کننده، قیمت پایین تر تامین کننده نسبت به دیگر تامین کنندگان است.

از میان پیشنهادات مختلف برای نام شرکت، "کالایاب" مورد تایید هر سه نفر قرار می گیرد.

برای شروع، تصمیم بر این گرفته می شود که کالاهای مورد نظر محدود به گل، کیک، شیرینی و شکلات و کارت تبریک باشد.

به عنوان مثال، یک مشتری به مناسبت تولد دوست خود، درخواست ارسال گل به آدرس محل سکونت  او می کند. مشتری از میان انتخابهای گوناگون، گل مورد نظر خود را انتخاب کرده و به همراه اطلاعات لازم شامل آدرس تحویل گیرنده، درخواست خود را صادر می کند. شرکت سپس کالای مورد نظر را از تامین کنندگان مختلف استعلام کرده و بهترین شرایط را انتخاب کرده و قیمت آن را به علاوه هزینه ارایه خدمات مورد نظر به مشتری اعلام می کند. در صورت تایید مشتری، کل هزینه به صورت الکترونیکی از حساب مشتری برداشت شده و فرآیند تامین و تحویل کالا به جریان می افتد.

تصمیم بر این است که خدمات به دو صورت تلفنی و اینترنتی به مشتریان ارایه شود و کلیه تامین کنندگان به شکل الکترونیکی استعلام گردند. در نتیجه، کوتاهترین تاخیر میان درخواست مشتری و پاسخ به مشتری قابل حصول است.

 

داستان تخیلی بیان شده، در قالب مثالهای کمکی در سری نوشتارهای پیرامون معماری سرویس گرا استفاده خواهد شد.

 

توجه: نمونه ارایه شده به طور کامل زاییده ذهن نویسنده بوده و هر گونه تشابه نام یا موضوع در این نوشتار و دیگر نوشتارهای مربوط به این مجموعه با نامها و نمونه های واقعی کاملا تصادفی است.

<بخش قبل   بخش بعد>

Earth Hour

ساعت زمین!

ایده اولیه در سال ۲۰۰۷ در سیدنی استرالیا اجرا و به سرعت در سرتاسر دنیا فراگیر شد.

امروز از ساعت ۸:۳۰ شب به مدت یک ساعت مردم و سازمانها به صورت داوطلبانه در خاموشی فرو رفتند.

اقدام سایت http://www.seek.com هم جالب بود. علاوه بر پشتیبانی از این جنبش، سایت را هم بروزرسانی می کند.

برای اطلاعات بیشتر: http://www.earthhour.org