مدیریت فرآیند کسب و کار و معماری سرویس گرا



بسم الله الرحمن الرحیم

موضوع:
مدیریت فرآیند کسب و کار و معماری سرویس گرا

سال 97

فهرست
مقدمه 3
سرویس چیست؟ 7
واسط مستقل از نرم افزار 9
معماری اطلاعات Information Architecture 9
مدیریت محتوا 10
مدیریت دانش 10
آیا به معماری اطلاعات نیاز داریم ؟ 10
فرهنگ جامع طراح 11
قابلیت ترکیب سرویس 14
مروری بر تحقیقات 16
معماری سرویس گرا چیست؟ SOA چیست؟ 18
سرویس ها چیستند ؟ 22
فواید SOA برای مشتریان بانکها 27
SOA و اوراق بهادار 28
تغییر معماری نرم افزاری بانک ها کافی است؟ 29
SOA در بانکداری اسلامی 30
تهدیدات مهاجرت به معماری سرویس گرا 31
معماری سرویس گرا چیست 32
● زیربنای SOA 34
نقل و انتقال (Tranport ) 41
رابطه بین BPM ، SOA و EA 47
منابع 48

مقدمه
معماری سرویس گرا سبکی از سیستم های اطلاعاتی است که بر اتصال سست، قابلیت استفاده مجدد، ترکیب پذیری، پنهان سازی پیاده سازی داخلی و .. تاکید داشته و شامل استانداردهای soap, wsdl, bpel, uddi می شود. از طرف دیگر چگونگی تغییر و تاثیر جنبه های سازمانی (فرایندها، بانک های اطلاعاتی، زیرساخت) در مواجه با معماری سرویس گرا نیاز به توجه بیشتر دارد.
چگونگی ارتباط معماری سرویس گرا با کسب و کار سازمان(خصوصا فرایندها) و تاثیر متقابل آنها جزو موضوعات جذاب و پرطرفدار سالهای اخیر بوده و دهها کتاب و تز دانشگاهی و صدها مستند فنی نیز به این موضوع پرداخته اند که هرکدام از زاویه ای قصد داشته اند ویژگیها و قالبی برای "معماری سرویس گرا سازمانی" ارائه کنند{ ‍لینک 1‍ ‍} {لینک 2‍}. تقریبا اکثر این منابع تاثیر SOA بر جنبه های دیگر سازمان(فرایندها، زیرساخت) را ناچیز دانسته و SOA را غالبا موضوعی "نرم افزاری" به حساب آورده اند. به عبارت واضح تر از دیدگاه آنان، "معماری سرویس گرا" بیشتر از حیث نتایج در لایه نرم افزاری نسبت به سبک های قبلی متفاوت بوده است. این برداشت در طول سالهای 2004 تا 2007 غالب بود و همانگونه که گفته شد اکثر کتب و مستندات معتبر منتشر شده بر این دیدگاه اعتقاد داشتند‍ .

اما در کنار دیدگاه اول، به تدریج دیدگاه جدیدتر و کامل تری نیز رشد یافت و در یکی- دو سال اخیر بالغ شد که معتقد بود "معماری سرویس گرا" بخشی از پارادایم سرویس گرائی(Service-Orientation) است و این پارادایم همانطور که در لایه نرم افزارهای کاربردی منجر به سبک "معماری سرویس گرا"(SOA) می شود، در کسب و کار سازمان نیز می تواند اثربخش بوده و "سازمان سرویس گرا" (SOE) را تعریف کند، همچنین در لایه زیرساخت منجر به "زیرساخت سرویس گرا"(SOI) شود. با این تعریف جدید، پارادایم سرویس گرائی به سه شکل خود را نشان می دهد:
جنبه سازمانی: سازمان سرویس گرا :SOE) Service Oriented Enterprise)
جنبه معماری نرم افزار: معماری سرویس گرا :SOA) Service Oriented Architecture)
جنبه زیرساخت : زیرساخت سرویس گرا : SOI) Service Oriented Infrastructure)
این دیدگاه جدید و جامع همانطور که گفته شد طی دو سال اخیر مبانی خود را ارائه نمود، اما نتوانسته بود به دیدگاه غالب بدل شود و نیز منابع و مراجع معتبر جهانی در تائید خود نداشت تا اینکه سرانجام در نیمه دوم سال 2008، شورای مدیران ارشد اطلاعاتی(CIO Council) دولت ایالات متحده آمریکا نتایج مطالعات و بررسی های چندساله خود در تائید این دیدگاه جدید را با عنوان "راهنمای کاربردی برای معماری سرویس گرا فدرال" (A Practical Guide to Federal Service Oriented Architecture) منتشر نمود. "راهنمای کاربردی برای معماری سرویس گرا فدرال" به عنوان جدیدترین مستند منتشر شده این شورا، در بردارنده مبانی جدیدی در حوزه سازمان سرویس گرا می باشد و نشان دهنده یک جهش فنی و بنیادی در این صنعت است.
معماری سرویس گرا ساخته شد تا به شرکت ها برای نیازمحاسباتی شان انعطاف بخشد. به دلیل اینکه خصوصیت اساسی SOA توزیع معماری محاسبه است، این شانس را برای شرکت ها به وجود می آورد تا میان سکوهای(Platform) مختلف، مکان های مختلف و پشتیبانی فناوری اطلاعات محلی (Local) مختلف کار کنند.
مدیریت فرایند کسب و کار)BPM و SOA(معماری سرویس گرا) می توانند با هدف نهایی بهبود فرآیندهای کسب کار و عرضه محصولات و خدمات به مشتریان نهایی، مکمل یکدیگر باشند. BPM یا مدیریت فرآیند کسب و کار، ابزاری است که می تواند محصولات و سرویس های مورد نظر را خلق نماید، در حالی که SOA یا معماری سرویس گرا به عنوان موتوری عمل می کند که BPM را به کار می اندازد و کار مورد نظر را به کاربر مشخص می رساند. این رابطه رابطه ای نمادین است که می تواند به طور کلی تمام عملیات شرکت را بهینه سازی کند. با داشتن این نوع معماری، یک مدیریت فرآیند با مرکزیت وب و معماری سرویس گرا می تواند میان یک شبکه گسترده ی ناپیوسته کار کند. این کار باعث می شود دیگری نیازی به متمرکز کردن زیر ساخت های IT به منظور اجرای BPM بر روی یک شبکه گسترده نباشد. متمرکز سازی به ناچار همراه هزینه های سرباری مانند نصب کردن محیط IT، نگهداری از پرسنل زیرساخت و نیز پشتیبانی آن می باشد. ادغام SOA و BPM نه تنها موجب منعطف شدن شرکت ها در اجرای فرآیند جریان کار می شود، بلکه می تواند این امکان را به آنها بدهد که بخش های جداگانه کسب و کارشان را به هم مرتبط و از همه مهم ترصرفه جویی زیادی در منابع مورد نیاز شرکت کنند. BPM و SOA فناوری هایی نوینی هستند که می توانند پتانسیل شرکت ها را برای رشدی چشمگیر افزایش دهند. اگر از BPM و SOA به درستی و به صورت مکمل استفاده شود می توانند موجب بهبود، بهره وری و در نتیجه بالا رفتن سود و تقویت رشد و دوام یک شرکت شوند.
امروزه ناهماهنگی یکی از مشکلات دنیای IT است، چرا که در شرکتها از برنامه های زیادی با زبانهای مختلف استفاده شده است و قطعاً این برنامه ها باید قادر به ارتباط برقرار کردن با یکدیگر باشند. و این ایجاد ارتباط موضوعی سخت و دشوار است.
سیستم های قدیمی که با زبانهایی که پشتیبان آنها پلت فرم های در حال انقراض هستند مجبور به برقراری ارتباط با نرم افزارهایی که با زبان های جدید نوشته شده اند، خواهند بود. این سیستم های قدیمی مشکلات زیادی برای ما ایجاد می کنند و گاه ترجیح می دهیم آنها را از رده خارج کنیم و جایگزین جدیدی برای آنها بیابیم؛ تضمینی نیست که سیستم های جدید به خوبی و کاملی سیستم های قدیمی کار کنند. این برنامه های کاربردی در طی زمان امتحان خود را پس داده اند، در کارهای روزانه واقعی درگیر شده و آزموده شده اند. مشکلاتی که برنامه نویسان به عنوان پراکندگی کد در این برنامه ها می بینند همان واقعیت اداره چرخه ها و حلقه ها و موارد استثنائی جهان واقعی است. در حالی که به دنبال سیستم های منظم و منسجمی هستیم.
در حالی که کدهایی وجود دارند که ارزش باقی ماندن ندارند، بسیاری از نرم افزارهای قدیمی با اصول ذهنی نوشته می شوند امروزه این اصول اساساً تغییر کرده اند. بعضی اوقات برنامه ها با اهداف خوب نوشته می شوند ولی به روشی که استفاده دوباره آنها در نرم افزارهای دیگر بسیار دشوار است. با این حال روشهایی برای مدرنیزه کردن، قابل استفاده مجدد کردن و افزودن بر قدرت برنامه هایی که قدیمی و در عین حال برای سازمان بحرانی هستند (برنامه های اساسی سازمان) وجود دارد.
با بکارگیری سیستم های قدیمی در ساختار معماری سرویس گرا می توان در زمان صرفه جویی کرد و این زمان اضافه را به خدمات جانبی اختصاص داد.
ادغام و جمع آوری منجر به مشکلات پیچیدگی نرم افزار می شود. پلت فرم ناهماهنگ اثر منفی بر چابکی، عکس العمل و توانایی انتقال سرویس می گذارد و این اثر منفی در جهان مبتنی بر وب از همیشه پر هزینه تر خواهد بود.
SOA راهی برای به چنگ آوردن فرصت های جدید ایجاد می کند و به جای انکار تفاوتها، آنها را در بر می گیرد و کسب و کاری کم هزینه از نظر زمان را به ارمغان می آورد. شاید نیازی به از رده خارج کردن برنامه ها و جایگزین جدید برای یافتن آنها نداشته باشیم، چرا که معماری سرویس گرا به شما اجازه می دهد نیازهای یکپارچگی را به روشی تکاملی حل کنید. برای رهیابی به سوی سرویس ها باید وظایفمان در زمینه IT را به طور دقیقتری با اهداف کسب و کارمان تطبیق دهیم و اطمینان حاصل کنیم که شرکت آماده کسب فرصت های جدید است.
در اینجا به بیان راهکارهایی برای شروع کار می پردازیم. بدلیل اینکه SOA در واقع نوعی معماری را نمایش می دهد بهتر است برنامه نویسان دید کلی تری به سیستم و مزیت های SOA داشته باشند تا در کدنویسی با هماهنگی بهتری با اهداف کسب و کار پیش روند. هدف از بیان این مفاهیم کد نویسی نیست، بلکه رسیدگی به چالش هایی است که در طی اجرای برنامه ها با آن مواجه ایم. این برای برنامه نویسان و معماران مفید است؛ که مانند یکدیگر فکر کنند. امروزه ناهماهنگی یکی از مشکلات دنیای IT است، چرا که در شرکتها از برنامه های زیادی با زبانهای مختلف استفاده شده است و قطعاً این برنامه ها باید قادر به ارتباط برقرار کردن با یکدیگر باشند. و این ایجاد ارتباط موضوعی سخت و دشوار است.
سیستم های قدیمی که با زبانهایی که پشتیبان آنها پلت فرم های در حال انقراض هستند مجبور به برقراری ارتباط با نرم افزارهایی که با زبان های جدید نوشته شده اند، خواهند بود. این سیستم های قدیمی مشکلات زیادی برای ما ایجاد می کنند و گاه ترجیح می دهیم آنها را از رده خارج کنیم و جایگزین جدیدی برای آنها بیابیم؛ تضمینی نیست که سیستم های جدید به خوبی و کاملی سیستم های قدیمی کار کنند. این برنامه های کاربردی در طی زمان امتحان خود را پس داده اند، در کارهای روزانه واقعی درگیر شده و آزموده شده اند. مشکلاتی که برنامه نویسان به عنوان پراکندگی کد در این برنامه ها می بینند همان واقعیت اداره چرخه ها و حلقه ها و موارد استثنائی جهان واقعی است..
در حالی که کدهایی وجود دارند که ارزش باقی ماندن ندارند، بسیاری از نرم افزارهای قدیمی با اصول ذهنی نوشته می شوند امروزه این اصول اساساً تغییر کرده اند. بعضی اوقات برنامه ها با اهداف خوب نوشته می شوند ولی به روشی که استفاده دوباره آنها در نرم افزارهای دیگر بسیار دشوار است. با این حال روشهایی برای مدرنیزه کردن، قابل استفاده مجدد کردن و افزودن بر قدرت برنامه هایی که قدیمی و در عین حال برای سازمان بحرانی هستند (برنامه های اساسی سازمان) وجود دارد.
با بکارگیری سیستم های قدیمی در ساختار معماری سرویس گرا می توان در زمان صرفه جویی کرد و این زمان اضافه را به خدمات جانبی اختصاص داد.
ادغام و جمع آوری منجر به مشکلات پیچیدگی نرم افزار می شود. پلت فرم ناهماهنگ اثر منفی بر چابکی، عکس العمل و توانایی انتقال سرویس می گذارد و این اثر منفی در جهان مبتنی بر وب از همیشه پر هزینه تر خواهد بود.
SOA راهی برای به چنگ آوردن فرصت های جدید ایجاد می کند و به جای انکار تفاوتها، آنها را در بر می گیرد و کسب و کاری کم هزینه از نظر زمان را به ارمغان می آورد. شاید نیازی به از رده خارج کردن برنامه ها و جایگزین جدید برای یافتن آنها نداشته باشیم، چرا که معماری سرویس گرا به شما اجازه می دهد نیازهای یکپارچگی را به روشی تکاملی حل کنید.
برای رهیابی به سوی سرویس ها باید وظایفمان در زمینه IT را به طور دقیقتری با اهداف کسب و کارمان تطبیق دهیم و اطمینان حاصل کنیم که شرکت آماده کسب فرصت های جدید است.
سرویس چیست؟
سرویس یکی از اجزای نرم افزاری می باشد که خصوصیات زیر را دارد:
با یک واسط مستقل از پلت فرم تعریف شده است.
از راه اینترنت قابل استفاده می باشد.
عملکرد آن به گونه ای است که business function ها را توسط business object ها اجرا می کند.
واسط و اجرای آن به گونه ای نشانه گذاری می شود که در زمان اجرا به بهبود عملکرد بیانجامد.
سرویس می تواند معانی دیگری نیز داشته باشد، گاه معنای آن وسیع تر است، برای مثال یک جز توزیع شده که واسط آن با کسب و کار طراحی شده است. گاهی معنای آن جزئی تر می باشد مانند وب سرویس مبتنی بر SOAP .
ابتدایی ترین مشکل برای پیاده سازی SOA این است که اکثریت با مفهوم اصلی ساختمان بلوکه ای، یعنی همان سرویس، موافق نیستند. بسیاری از تعارف سرویس، به مفاهیم بی ثبات و مختصر اشاره دارند، مانند قابلیت انعطاف پذیری و چابکی که برای برنامه نویسان بسیار مبهم می باشد. به جرات می توان گفت، هیچکس در انتخاب نمی خواهد یک نرم افزار غیرقابل انعطاف و کند که نیازهای عملی را برآورده نمی سازد خلق کند. اما در واقعیت برخلاف کوشش های زیاد اغلب این اتفاق رخ می دهد. دانستن اینکه SOA می تواند سازگاری و چابکی به ارمغان بیاورد ستودنی است اما این به تنهایی کمک کننده نیست.
تمامی تعاریف دیگر برای دنیای واقعی خیلی جزئی تر می باشند، برای مثال: تعیین کردن اینکه سرویس باید جزئی از نرم افزار باشد که زبانش SOAP است می تواند گمراه کننده باشد. اما این یک محدودیت ساختگی است، اشخاص زیادی هستند که از REST استفاده می کنند و فکر می کنند که در حال ارائه سرویس هستند. شاید بهتر است که تعریف ما شامل چیزهایی درباره پیام های مبتنی بر XML که تفاوت بین RESTfull webservice و SOAP-Based service را به وجود می آورند، باشد. اما باز هم یک محدودیت برای تعریف کلی ما به حساب می آید.
چگونه به یک تعریف جامع و خاص برای سرویس دست پیدا کنیم که برای اهداف متنوع سرویس در دنیای واقعی پذیرفتنی باشد؟
بهتر است تمامی جنبه های تعریف سرویس را پیش از اینکه بیشتر پیش رویم، بررسی کنیم.
واسط مستقل از نرم افزار
کاری که یک سرویس می تواند انجام دهد باید با یک واسط خارجی شرح داده شود. برخی از معماران نرم افزار اجازه می دهند که سرویس آنها فقط با یک پلت فرم خاص اجرا شود، مانند رابط جاوا که اجرا را فقط روی remote session EJB امکان پذیر می کند. سرویس ها حتماً از این روش به معنای خود نزدیکتر می شوند و نزدیک شدن به این مفهوم در میان بافت کسب و کار موردنظر محقق می شود. دستور دادن به اینکه مصرف کننده باید از یک پلت فرم مشخص مانند جاوا یا دات نت برای دریافت سرویس استفاده کند می تواند زمان و هزینه قابل توجهی را صرفه جویی نماید و به طور موثر اعمال اجرایی را ساده کند.
خیلی از کاربردهای معماری سرویس گرا در یک شرکت و در پشت یک سیستم حفاظتی و در یک محیط شناخته شده نسبتاً ایستا عمل می کنند. معماران زیادی وجود دارند که مفهوم SOA را در پلت فرم EJB که یک پلت فرم بسیار خاص می باشد پیاده سازی کرده اند. در حالی که پیاده سازی در یک پلت فرم خاص، ما را به اهداف SOA نمی رساند هر چند این عمل بسیار هوشمندانه و با تجربه صورت پذیرد.
WSDL ها از SOAP در HTTP استفاده می کنند. HTTP ممکن است یک لایه مناسب انتقال برای سرویس های تحت وب نباشد اما سادگی و قابلیت نفوذ آن باعث انتخاب آن به عنوان لایه پیش فرض می باشد. در نتیجه پشتیبانی قابل توجهی برای اجرای این نوع سرویس ها وجود دارد.
وب سرویس های RESTful از متدهای HTTP و زبان XML برای تعریف واسط های خود استفاده می کند و این رویکرد پشتیبان بسیاری دارد که از پیچیدگی و بزرگ بودن سرویس هایی تحت SOAP خیلی راضی نیستند.
سرویس فقط، یک قسمت از کارکرد اصلی نمی باشد بلکه چیزی است قابل توصیف با یک قرارداد که روی مصرف کننده ها متمرکز هستند، بنابراین این مهم است که یک واسط تعریف شده و مشخص با قرارداد خودکارسازی کار کند. بدون داشتن یک واسط مشخص، از قابلیت استفاده مجدد سرویس کاسته می شود. بدون استقلال سرویس، نارضایتی مشتریان و وابستگی بیش از حد را در پیش داریم.
معماری اطلاعات Information Architecture
۱. ترکیبی از سازمان، برچسب زدن، و طرح پیمایشی در بین یک سیستم اطلاعاتی .
۲. طراحی بنیادین یک فضای اطلاعاتی بمنظور آسان کردن تکمیل وظایف و دسترسی شهودی به محتوا .
۳. هنر و علم ساختاربندی و طبقه بندی وب سایت ها و اینترانت برای کمک به مردم تا اطلاعات را بیابند و مدیریت کنند .
۴. یک دیسیپلین ضروری و مجموعه ای از تکرار و تمرین، که بر آوردن اصول طراحی و معماری به نمای دیجیتالی متمرکز شده است .
"معماری اطلاعات پروسه ی طراحی دسترسی به اطلاعات است؛"
"بطوریکه کاربران بتوانند به دیدگاه خود در پیمایش سریع و سازنده سایت اتکا کنند."
مدیریت محتوا
مدیریت محتوا و معماری اطلاعات واقعا دو روی یک سکه هستند. IA (معماری اطلاعات) یک " تصویر لحظه ای" یا دید سه بعدی از یک سیستم اطلاعات را به نمایش می گذارد. درحالیکه CM (مدیریت محتوا) یک دید زمانی را با نشان دادن اینکه چطور اطلاعات در داخل ، اطراف و خارج از همان سیستم در طول زمان جریان می یابند را نمایش می دهد. مدیران محتوا با پیامدهای مالکیت محتوا و یکپارچگی سیاست ها، پردازش و تکنولوژی ها سر و کار دارند تا یک محیط انتشار دینامیکی را پشتیبانی کنند .
مدیریت دانش
مدیران دانش ابزار، سیاستها، و انگیزه ها را بمنظور تشویق افراد برای به اشتراک گذاشتن چیزهایی که می دانند، توسعه می دهند. بوجودآوردن همکاری محیط دانش به معنی طناب محکم احاطه کننده پیامدهاست که فرهنگها را متحد می کند مانند " انباشتن اطلاعات ".
آیا به معماری اطلاعات نیاز داریم ؟
طراحی معماری اطلاعات یک مهارت نیست ، که بتوانید با گرفتن یک نصف روز سمینار آن را بدست آورید. یک نظم عمیق واقعی وجود دارد . معماری اطلاعات به بازی های دو و شطرنج شباهت دارد . یک دقیقه آموزش برابر یک عمر ماهر شدن است. مسئولیت ما بعنوان معمار اطلاعات، ادامه این خواهد بود که بیاموزیم چگونه کارهایی که می خواهیم سریعتر و بهتر انجام شود، را انجام دهیم و سپس دانش و تجربیات خود را با اطرافیان مان به اشتراک بگذاریم . مخصوصا در سازمان های بزرگ کسانی که بعنوان معمار اطلاعات همه منظوره اغاز بکار کردنند، جذب جایگاههای خاصی که تواناییشان را با نیازهای سازمانشان تطبیق می دهد، می شوند. در اینجا تعداد کمی از عنوان هائی که امروزه وجود دارد بیان می شود :

فرهنگ جامع طراح
جستجوی ویرایشگر محتوای طرح
متخصص متادیتا metadata
متخصص فنی معماری اطلاعات
مدیر عیوب ، معماری اطلاعات
تعداد زیادی از گونه های ممکن و سطوح متفاوت وجود دارد، معمار اطلاعات می تواند به وسیله ی موارد زیر تخصصی گردد:
خطوط صنعتی ( مثلا سرویس های مالی، صنعت اتومبیل
حوزه وظیفه مندی ( مثلا منابع انسانی، مهندسی، بازاریابی
نوع سیستم ( مثلا اینترانت ها، وب سایتها، اکسترانت ها، مجله های انلاین، کتابخانه های دیجیتال، نرم افزار، جامعه انلاین )
مخاطبین ( مثلا دارندگان تجارت جزئی، معلمین مدرسه ابتدایی، دانشمندان موشک، نوجوانان، پدر و مادر بزرگان )
معماری اطلاعات نباید در رده بندی ها، موتورهای جستجو و یا هر چیز دیگری که به کاربر کمک می کند تا اطلاعات را در سایت پیدا کند، محصور شود. معماری اطلاعات با کاربران شروع می شود و علت اینکه برای اولین بار به سایت می آیند اینست: یافتن اطلاعاتی که نیاز دارندقابلیت استفاده در شبکه
دنیا پر از برنامه های سودمندی است که کار آنها می تواند فقط در ماشین های مجازی یکسان یا ماشین های فیزیکی یکسان درخواست شود. این برنامه ها واقعاً به عنوان سرویس ها مفید نیستند. دقیقاً مثل دنیای واقعی، مشتری های شما باید بتوانند با کار شما ارتباط برقرار کنند تا از سرویس های مختلفی که شما می دهید استفاده کنند. اگر شما تنها کسی باشید که شماره تلفن خودتان را می دانید یا اصلاً تلفنی نداشته باشید آنگاه هیچ ارتباطی وجود ندارد. اگر کار شما قابل استفاده از راه دور نباشد پس این واقعاً یک سرویس نیست.
قابلیت نشانه گذاری
قابلیت نشانه گذاری به این دیدگاه بر می گردد که باید قادر باشد فعالیت سرویس ها را در بسیاری از روش ها به منظور رسیدن به نیازهای کاربردی و غیرکاربردی نشانه گذاری کند. از این نظر است که سرویس ها را به چیزی پر معناتر در SOA ارتقا می دهد.
اگر شما از SOAP استفاده می کنید، یک گستره ای از ws-specification ها (مانند ws-Reliable Messaging یا ws-SecureConversation) به توانایی های سرویس شما اضافه می شود که روی هسته عملیاتی کسب و کار تاثیر گذار نیست. اما سرویس شما را برای استفاده در SOA قابل تطابق میسازد. برای مثال توانایی اضافه کردن هدرهای HTTP، یک روش از نشانه گذاری اجرای سرویس REST-based می باشد.
نکته این است که می خواهید قادر به فراهم کردن SOA خود و ضرورتاً سرویس های اجزای اصلی با ابزار تکنیکی حاکمیت باشید. شما می خواهید قادر به حساب آوردن سیاست های در زمان اجرا باشید که این مطلب را که چگونه سرویس می تواند استفاده شود را بیان می کند. توانایی ارتباط برقرار کردن ایمن و اجازه دادن به عملیات معامله ای و در برخی از موارد برای پذیرش نظارت بر تجهیزات نیازهای غیرکاربردی هستند که فاصله بین اجرای مطلقاً تئوری از سرویس فرایند لیست شده آن و جهان واقعی درگیر این شبکه ویژه با این محدودیت های برون سازمانی شده که باید به حساب آید، را پر می کند.
پیاده سازی تئوری خالص از فاکتور پردازش سرویس و دنیای واقعی که شامل این شبکه ویژه با محدودیت های خارجی می شود باید به حساب آید. اضافه کردن بسیاری از موارد در سرویس هایتان می تواند شدیداً امکانات خود را برای استفاده مجدد بویژه در محیط های وابسته محدود کند یا از بین ببرد. اما نیاز به مقابله با آنها باقی می ماند. در صورت امکان، این الزامات را در قالب نشانه گذاری ارائه می دهیم.
این نیاز انتخاب شما را در پلت فرم و اجرا راهنمایی می کند. این حقیقت که بسیاری از نیازهای غیرکاربردی که اغلب در انجام اجزای نرم افزاری (واین حقیقت که بسیاری از آنها توسط ws-specification ها قابل تشخیص اند) وجود دارد باعث شده بر روی سرویس های مبتنی بر SOAP تمرکز کنیم. برای داشتن چنین شرایط معمول در یک روش استاندارد با این مشخصات، تقویت قابلیت همکاری و نگهداری و این امکان برای برنامه نویسان که بتوانند بر مشکلات کاری خود متمرکز شوند پیشنهاد می شود.
یک عمل با چه ویژگی های دیگری به عنوان یک سرویس واجد شرایط در نظر گرفته می شود؟
به نظر می رسد که یک سرویس اگر دوباره استفاده شود ارزش ساخته شدن را دارد. هدف اصلی SOA آن است که اجزای آن خود شمول باشد و کاربرد تداخلی نداشته باشد. اجزای SOA باید درجه ای از قابلیت استفاده مجدد را فراهم آورند. این بدان معناست که آنها نباید به چهارچوب تعاریف محدود کسب و کار که ارتباط کمی با کسب و کار در جای دیگر دارند محدود شوند. ممکن است شما یک سرویس بنویسد که دوباره استفاده نشود. ممکن است کسب و کار به گونه ای تغییر کند یا تعاریف ضعیفی از سرویس ارائه شده باشد یا بیش از حد خرد یا بیش از حد کلی در حوزه خود تعریف شود که مناسب برای استفاده موارد دیگر نباشد. اینجاست که یک معمار نرم افزار با ارزش شمرده می شود.
برخی از معماران نرم افزار استقلال سرویس را نیاز آن در نظر می گیرند. اما این نمی تواند یک الزام برای خصوصیات سرویس باشد. گاه سرویس های وابسته، می توانند عمل کرد مناسبی در پایگاه داده یا بسیاری از مکانیزم های گذرا داشته باشند.
قابلیت ترکیب سرویس
باید به اطمینان برسیم که استفاده از سرویس در ترکیبی دیگر نیز قابل استفاده است. برای رسیدن به این هدف؛ اجرا یا واسط سرویس را به هیچ فرایند بخصوصی مقید نکنید، بلکه از همنوا سازی یا سرویس فرایندی جدید بهره گیرید.
میدانیم که یک سرویس مرکب حاصل جمع آوری تعدادی سرویس موجود است . درحالیکه استفاده مجدد یک سرویس را به معنای بکار بردن همان سرویس در برنامه دیگری می دانیم، سرویسی را ترکیب پذیر تلقی می کنیم که قابل استفاده در داخل سرویسی دیگر باشد.
در طراحی توجه کنید که واسط و اجرای سرویس نباید بر ترکیب پذیری آن اثر منفی داشته باشد .
می توان گفت ترکیب پذیری در نرم افزارتقریباً همان معنای لغوی آن را می دهد. همان طور که قطعات لُگو، به دلیل نوع طراحی اشان، می توانند شکل های متفاوتی ایجاد کنند. بدین ترتیب خوب است در همان ابتدای کار طراحی، به این مشخصه سرویس پرداخته شود. امروزه سازمان­ها برای ارائه محصولات و خدمات مناسب به مشتریان و حفظ و ارتقای جایگاه راهبردی خود باید از چالاکی و سرعت مناسبی برخوردار باشند تا در صورت بروز مسائل و مشکلات مختلف بتوانند مدل کسب­و­کار خود را تغییر داده و آن­را بهبود دهند. سازمان­هایی که برای رسیدن به اهداف سازمان از فناوری اطلاعات استفاده می­کنند، هنگامی که بخواهند تغییری را در سیستم اعمال کنند باید تمامی جنبه­های آن ازجمله فرآیندها، قوانین، کاربران، مدل داده­ای و… را تغییر دهند؛ لذا برای انعطاف در برابر تغییرات به سیستم­هایی نیاز است که علاوه بر امکان استقرار مدل کسب­و­کار فعلی، امکان بهبود مدل کسب­ وکار را نیز داشته باشد. با ظهور معماری سرویس­گرا، دریچه تازه­ای برای طراحی انعطاف­پذیر سیستم­های سازمانی به روی معماران نرم­ افزار گشوده شده ­است. در این معماری، سیستم به صورت سرویس­های کاملاً استاندارد، مستقل از پلتفرم، قابل توسعه و انعطاف­پذیر تحلیل و طراحی شده و پیاده­سازی می­شود. معماری سرویس­گرا از دو عنصر اساسی سرویس و پیام تشکیل شده است. هر سرویس شامل دو قسمت رابط­ سرویس و پیاده­سازی آن می­باشد. پیاده­سازی هر سرویس با هر فناوری و روی هر سکویی[۱] امکان­پذیر است، لذا سرویس نهایی مستقل از سکو و فناوری خواهد بود. هر سرویس، منطق کسب­و­کار و داده مخصوص به خود را دارد و سرویس­ها از یکدیگر مستقل هستند؛ در نتیجه با تغییر یک سرویس، سایر سرویس­ها دست خوش تغییر قرار نمی­گیرند. هر سرویس برای استفاده از عملکرد و یا داده­های سایر سرویس­ها به رابط آن سرویس پیام می­فرستد و پاسخ خود را در قالب یک پیام دریافت می­کند. سرویس­ها می­توانند با قرار گرفتن در کنار یکدیگر و هم­نوایی سرویس­ها با هم، کلان – فرآیندهای کسب­ و­ کار را پیاده­سازی نمایند.
با وجود آنکه نسل قبلی سیستم­های مدیریت فرآیند کسب­ و­کار از گذشته تا به حال تحت قالب سیستم­های گردش کار حضور داشته است، اما این مفهوم در حال حاضر و با فراگیر شدن معماری سرویس­گرا و فناوری­ها و استاندارهای مربوط به آن شیوع بیشتری یافته است. به عبارتی در سال­های اخیر دو مفهوم معماری سرویس­گرا و مدیریت فرآیند کسب­و­کار سبب هم­افزایی و تقویت یکدیگر شده­اند. سیستم­های مدیریت فرآیند کسب­و­کار سیستم­های مدیریتی هستند که کلیه فرآیندهای کلان و خرد سازمان را خودکار می­نمایند. این سیستم­ها امکان شناسایی، مدل­سازی، استقرار، اجرا، مدیریت وظایف، یکپارچه­ سازی با سایر سیستم­های اطلاعاتی، کنترل و بهبود فرآیندهای کسب­و­کار سازمانی را به صورت استاندارد در اختیار سازمان قرار می­دهند. با همه مزایای گفته­ شده برای معماری سرویس­گرا باید به این نکته توجه کرد که این معماری دارای نقاط ضعفی هم می­باشد چرا که قابلیت انعطاف­پذیری و ویژگی باز بودن معماری سرویس­گرا سبب بروز مشکلات امنیتی و چالش­های جدیدی در این زمینه شده است.
در سیستم­های اطلاعاتی سنتی، مدل­سازی اطلاعات را نقطه شروع تصور می­کردند و برای مدیریت فرآیندهای کسب­و­کار به یک پشتیبان سیستمی نیاز داشتند، که این موضوع را تحت عنوان مدیریت گردش کار مطرح کردند[۴]. مدیریت گردش کار شامل فعالیت­ها و فرآیندهای در حال گردش است که برای حفظ تعادل و برقراری روند ارتباطی بین فعالیت­ها به یک سامانه مدیریتی نیاز دارد. در سازمان­های تجاری نیز گردش کارها یا گردش فعالیت­ها نقش گردش فرآیندهای کسب­و­کار را دارند که در تحقق سیستم­های اطلاعاتی سازمان نقش حیاتی را ایفا می­کنند و می­توانند با یکدیگر تعامل داشته باشند؛ برای این تعامل نیاز به اداره، پیکربندی، مدیریت، مدل سازی، طراحی و تحلیل مناسب می­باشد که این اعمال تحت عنوان مدیریت فرآیند کسب­و­کار تعریف می­شود. در سیستم­های پیشین، کنترل و گردش فرآیندهای کسب­و­کار داخل سازمان اکثراً دستی بود اما امروزه تکنولوژی­های مطرح فناوری اطلاعات در این سیستم­ها مورد استفاده قرار می­گیرد [۵]. با استفاده از معماری سرویس­گرا، فرآیندهای کسب­و­کار معنای واقعی خود را پیدا کرده­اند، چرا که هدف این معماری اتصال سست در ارتباطات بین مولفه های نرم­افزاری است؛ لذا می­توان گفت اهداف مدیریت فرآیند کسب وکار و معماری سرویس­گرا با هم منطبق هستند، زیرا فرآیندها طراحی شده و پیاده­سازی آن ها به صورت اتصال سست صورت می­پذیرد. امروزه معماری سرویس­گرا برای ساخت راه­حل­های سازمانی مبتنی بر سرویس مورد استفاده قرار می­گیرد، به طوری که این سرویس­ها به عنوان یک مولفه مستقل و هم راستا با کسب­و­کار برای انجام فرآیندهای کسب­و­کار استفاده می­شوند
در این نوشتار ابتدا با مفاهیم معماری سرویس­گرا، اصطلاحات، استانداردها و چرخه­حیات این معماری آشنا می­شویم سپس به بیان مفاهیم امنیتی می­پردازیم و در ادامه وارد حوزه مدیریت فرآیند کسب­و­کار، چرخه­حیات و اصطلاح سامانه مدیریت فرآیند کسب­و­کار خواهیم شد. با توجه به اهمیت و وابستگی مطالب در حوزه­های مدیریت فرآیند کسب­و­کار و معماری سرویس­گرا در فاز پایانی زمینه­های کاری انجام شده و رویکردهای این حوزه­ها را مورد بررسی قرار می­دهیم.
مروری بر تحقیقات
با پیشرفت تکنولوژی و همچنین با توجه به نیاز روزافزون به فناوری اطلاعات، بسیاری از سازمان­ها به استفاده از فناوری اطلاعات روی آورده­اند بنابراین بر روی معماری سرویس­گرا تحقیقات فراوانی صورت گرفته است. در حالی که در زمینه مدیریت فرآیند کسب کار به دلیل نو بودن تحقیقات کمتری نسبت به معماری سرویس­گرا انجام شده است. شرکت­های بزرگی چون اوراکل، آی­بی ام بر روی سامانه­های مدیریت فرآیند کسب و کار با رویکرد معماری سرویس­گرا تحقیقاتی انجام داده­اند و کارهای با ارزشی را در این زمینه انجام داده­اند
قوانین مربوط به مدیریت فرآیند کسب و کار به رهبران سازمان کمک می­کند تا بتوانند فرآیندهای سودمند را شناسایی کنند. قوانین فوق متخصصین این حیطه را برای امتحان و مدل سازی فرآیندها درگیر می­کندمعماری سرویس­گرا نیز برای استقرار و پیاده­سازی سریع این فرآیندها به­کار برده می­شود ایجاد دیدگاهی نزدیک تر میان مدیریت فرآیند کسب و کار و معماری سرویس­گرا و بیان روند همگرایی آن ها توسط فوزی کامون صورت گرفته است
امروزه در پاسخ به چالش­های ناشی از پیچیدگی و تنوع سیستم­های اطلاعاتی که کسب و کار با آن روبرو می­باشد یینی لیو و همکارانش یک راه­حل برای ترکیب معماری سرویس­گرا و مدیریت فرآیند کسب و کار پیشنهاد داده­اندهمچنین کارهای با ارزش دیگری نیز در این زمینه انجام شده­است که ما در فصل دو به برخی از آن ها اشاره می­کنیم.
۲-۲ معماری سرویس­گرا
اوایل سال ۱۹۹۰ مطرح شد، مفاهیمی که بر روی اصولی همچون اتصال سست[۲]، توزیع­شدگی و استفاده مجدد[۳] تاکید دارند. معماری سرویس­گرا یکی از روش­هایی است که در رابطه با مباحث محاسبات توزیع­شده با ویژگی­های اتصال سست و بر اساس استانداردها و پروتکل­های مشخص مطرح شد. معماری سرویس­گرا با توجه به جایگاه معماری در مهندسی نرم­افزار در سال­های اخیر با استقبال زیادی در دنیای فناوری اطلاعات و کسب­وکار و در تولید سیستم­های نرم­افزاری روبرو شده است. آنچه باعث افزایش روند گسترش استفاده از این معماری شده­است ظهور وب سرویس ها است که در آن امکان عملیاتی کردن اکثر اصول و مشخصات معماری سرویس­گرا فراهم است. استفاده و سازماندهی منابع گسترده، اعم از برنامه و داده در این معماری به نحوی صورت می­گیرد که به­کارگیری این قابلیت­ها به شکل یکسان و با تعاریف مشخص صرف­نظر از سکو، مشخصه شیء و دامنه امکان­پذیر باشد
معماری سرویس­گرا واژه­ای­ است برای نمایش مدلی که در آن منطق توالی و هدایت به بخش­های منطقی کوچک تر تقسیم می­شوند. این بخش­ها خود شامل بخش­های منطقی کوچک تری هستند که می­توانند به صورت توزیع­پذیر باشند. معماری سرویس گرا این بخش­ها را به خودمختار بودن و دوری از انزوا سوق می­دهد و از آن­ها می­خواهد از مجموعه اصولی استاندارد و مشترک برای رشد و نمو به صورت مستقل پیروی کنند. در معماری سرویس­گرا به این بخش­ها سرویس می­گویند[۱۵]. این سرویس­ها هم توسط دیگر نرم­افزارها قابل فراخوانی هستند و هم برای ساخت سرویس­های جدید مورد استفاده قرار می­گیرند. این راهکار برای یکپارچه­سازی فناوری­ها در محیط­هایی که انواع مختلفی از سکوهای نرم­افزاری و سخت­افزاری در آن وجود دارد، ایده­آل است.
معماری سرویس گرا چیست؟ SOA چیست؟
معاری سرویس گرا (SOA) روشی جدید و در حال تکامل برای ساخت برنامه های توزیع شده با Distributed Application است. سرویس ها اجزای توزیع شده با رابط های تعریف شده و مشخص هستند که پیغام های XML را پردازش وتبادل می کنند. با رویکرد سرویس گرا می توان راه حل های را ارائه داد که به مرز دامنه های سازمان، شرکت یا دپارتمان محدود نیستند. با استفاده از SOA می توان در شرکتی که دارای سیستم ها و برنامه های کاربردی مختلف روی پلتفرم های متفاوت است، یک راه حل یک پارچه سازی با استقلال زیاد (loosly coupled) ساخت که جریان یکنواخت و ناهماهنگ کار را تضمین کند.

معاری سرویس گرا (SOA) روشی جدید و در حال تکامل برای ساخت برنامه های توزیع شده با Distributed Application است. سرویس ها اجزای توزیع شده با رابط های تعریف شده و مشخص هستند که پیغام های XML را پردازش وتبادل می کنند. با رویکرد سرویس گرا می توان راه حل های را ارائه داد که به مرز دامنه های سازمان، شرکت یا دپارتمان محدود نیستند. با استفاده از SOA می توان در شرکتی که دارای سیستم ها و برنامه های کاربردی مختلف روی پلتفرم های متفاوت است، یک راه حل یک پارچه سازی با استقلال زیاد (loosly coupled) ساخت که جریان یکنواخت و ناهماهنگ کار را تضمین کند.
هر کس که از سایت های تجارت الکترونیکی به صورت آنلاین خرید کرده باشد، با مفهوم سرویس ها آشنا است. وقتی که سفارش تا ن را دادید، باید اطلاعات کارت اعتباریتان را ارایه کنید که به طور معمول توسط یک فراهم کننده سرویس ثانویه، تایید و شارژ می شود. وقتی که سفارش پذیرفته شد، شرکت سفارش گیرنده با یک شرکت فراهم کننده سرویس حمل ونقل فراهم می کند و در نهایت کالای شما تحویلتان می شود. نیاز به معماری سرویس گرا از جنبه ای دیگر نیز به نحوه بارزی در برنامه های کاربردیeCommerce مشهود است. اگر مثلا جزء (componet) مربوط به پرداخت با کارت اعتباری offline و یا غیر فعال باشد، قرار نیست که فرایند فروش متوقف شود. بلکه سفارش ها بایستی پذیرفته شوند وعملیات پرداخت به وقت دیگری موکول شود.
مثل سایر معماری های توزیع شده، SOA ساخت برنامه های کاربردی با استفاده اجزایی که در domainهای جدا از هم را قرار دارند را ممکن می سازد. SOA از سرویس های وب به عنوان نقاط ورود برنامه کاربردی استفاده می کند که از لحاظ مفهومی معادل همان اجزای proxy و stub در سیستم های توزیع شده سنتی مبتنی بر اجزاء هستند. با این تفاوت که در اینجا ارتباط بین سرویس وب و استفاده کننده خیلی آزاداترانه ومستقل تر (loosely coupled) است. به علاوه SOA به خاطر در بر داشتن فاکتورهایی که اهمیت حیاتی در تجارت دارند، نیز منحصر به فرد است. فاکتورهایی نظیر: قابلیت اطمینان سرویس، جامعیت پیام، یکسانی تراکنش و امنیت پیام. در امور تجاری واقعی نمی توان روی سرویس هایی که یک درخواست را فقط به خاطر اینکه بتوانند بفه مند، پردازش می کنند حساب کرد. در امور تجاری به قطعیت و اطمینان بیشتری نیاز است. واضح است که سیستم های مختلف ممکن است بعضی اوقات غیر فعال باشند و یا پاسخگویی آن ها در دفعات مختلف متفاوت باشد. با وجود این هیچکدام از این موارد نباید برای کنار گذاشتن یاعدم پاسخ به یک درخواست باشند.
علاوه بر آن نباید دلیلی برای کنار گذاشتن یا عدم پاسخ به یک درخواست باشند واضح است که سیستم های مختلف ممکن است بعضی اوقات غیر فعال باشند و یا پاسخگویی آن ها در دفعات مختلف، متفاوت باشد. با وجود این، هیچ کدام ازاین موارد نباید دلیلی برای کنار گذاشتن یا عدم پاسخ به یک درخواست باشند. علاوه بر آن نباید هیچ ابهامی در نحوه فراخوانی یک سرویس وجود داشه باشد. اگر سیستمی توانایی های خود را در قالب سرویسی روی وب ارائه کند. در آن صورت نحوه فراخوانی آن سرویس باید به طور واضح مستند سازی و اعلام شود. بسیاری از مسائل دسترس پذیری و مقیاس پذیری برنامه های کاربردی امروزی در SOA حل شده است که احتمال نقض آن در هر مر حله ای از جریان کار بسیار زیاد است. در SOA فرض بر این است که خطا وجود دارد و می تواند بیفتد، بنابراین استراتژی هایی برای مثال اگر یک سرویس نتواند یک پیغام را در مرحله اول بپذیرد. این معماری طوری طراحی شده است که مجددا پیام را بفرستد. واگر یک سرویس به طور کامل قابل دسترس نباشد، (که هرگز نباید در یک سیستم SOA پایدار انفاق بیفتد) آن وقت معماری طوری طراحی شده است که روی دادن خطاهایی که ممنجر به قطع کامل در خواست سرویس می شود، امکان پذیر نباشد. SOA قابلیت اطمینان را افزایش می دهد، چون خطاهای موقت در بخشی از جریان کار نمی توانند کل فرایند تجاری را از کار بیاندازند.
به بیان کلی، SOA فرایندی تکامل یافته را ارائه می نماید و ازاین نظر می تواند ان را بلوغ سریس های وب و تکنولوژی های یکپارچه سازی به حساب آورد. در SOA به این امر توجه شده است که سیستم های با اهمیت حیاتی که بر مبنای تکنولوژی های توزیع شده ساخته می شوند. باید تضمین های خاصی را تامین نمایند. در این گونه سیستم ها باید این اطمینان وجود داشته باشد که در خواست های سرویس به طور صحیح مسیر دهی و هدایت می شوند، در زمان مناسب به آن ها پاسخ داده می شود، و این سرویس ها به طور واضح و دقیق سیاست های ارتباطی و رابط های خود را اعلام می کنند.
معاری سرویس گرا (SOA) روشی جدید و در حال تکامل برای ساخت برنامه های توزیع شده با Distributed Applicationاست. سرویس ها اجزای توزیع شده با رابط های تعریف شده و مشخص هستند که پیغام های XMIL را پردازش وتبادل می کنند. با رویکرد سرویس گرا می توان راه حل های را ارائه داد که به مرز دامنه های سازمان، شرکت یا دپارتمان محدود نیستند. با استفاده از SOA می توان در شرکتی که دارای سیستم ها و برنامه های کاربردی مختلف روی پلتفرم های متفاوت است، یک راه حل یک پارچه سازی با استقلال زیاد(loosly coupled) ساخت که جریان یکنواخت و ناهماهنگ کار را تضمین کند.
هر کس که از سایت های تجارت الکترونیکی به صورت آنلاین خرید کرده باشد، با مفهوم سرویس ها آشنا است. وقتی که سفارش تا ن را دادید، باید اطلاعات کارت اعتباری تان را ارایه کنید که به طور معمول توسط یک فراهم کننده سرویس ثانویه، تایید و شارژ می شود. وقتی که سفارش پذیرفته شد، شرکت سفارش گیرنده با یک شرکت فراهم کننده سرویس حمل ونقل فراهم می کند و در نهایت کالای شما تحویلتان می شود. نیاز به معماری سرویس گرا از جنبه ای دیگر نیز به نحوه بارزی در برنامه های کاربردیeCommerce مشهود است. اگر مثلا جزء(componet) مربوط به پرداخت با کارت اعتباری offline و یا غیر فعال باشد، قرار نیست که فرایند فروش متوقف شود. بلکه سفارش ها بایستی پذیرفته شوند وعملیات پرداخت به وقت دیگری موکول شود.
مثل سایر معماری های توزیع شده، SOA ساخت برنامه های کاربردی با استفاده اجزایی که در domainهای جدا از هم را قرار دارند را ممکن می سازد . SOA از سرویس های وب به عنوان نقاط ورود برنامه کاربردی استفاده می کند که از لحاظ مفهومی معادل همان اجزای proxy و stub در سیستم های توزیع شده سنتی مبتنی بر اجزاء هستند . با این تفاوت که در این جا ارتباط بین سرویس وب و استفاده کننده خیلی آزاداترانه ومستقل تر (loosely coupled) است .به علاوه SOA به خاطر در بر داشتن فاکتورهایی که اهمیت حیاتی در تجارت دارند ، نیز منحصر به فرد است . فاکتورهایی نظیر: قابلیت اطمینان سرویس، جامعیت پیام ، یکسانی تراکنش و امنیت پیام . در امور تجاری واقعی نمی توان روی سرویس هایی که یک درخواست را فقط به خاطر این که بتوانند بفهمند، پردازش می کنند حساب کرد . در امور تجاری به قطعیت و اطمینان بیشتری نیاز است. واضح است که سیستم های مختلف ممکن است بعضی اوقات غیر فعال باشند و یا پاسخگویی آن ها در دفعات مختلف متفاوت باشد . با وجود این هیچکدام از این موارد نباید برای کنار گذاشتن یاعدم پاسخ به یک درخواست باشند.
علاوه بر آن نباید دلیلی برای کنار گذاشتن یا عدم پاسخ به یک درخواست باشند واضح است که سیستم های مختلف ممکن است بعضی اوقات غیر فعال باشند و یا پاسخگویی آن ها در دفعات مختلف ، متفاوت باشد. با وجود این ، هیچ کدام ازاین موارد نباید دلیلی برای کنار گذاشتن یا عدم پاسخ به یک درخواست باشند. علاوه بر آن نباید هیچ ابهامی در نحوه فراخوانی یک سرویس وجود داشه باشد. اگر سیستمی توانایی های خود را در قالب سرویسی روی وب ارائه کند. در آن صورت نحوه فراخوانی آن سرویس باید به طور واضح مستند سازی و اعلام شود . بسیاری از مسائل دسترس پذیری و مقیاس پذیری برنامه های کاربردی امروزی در SOA حل شده است که احتمال نقض آن در هر مر حله ای از جریان کار بسیار زیاد است.در SOA فرض بر این است که خطا وجود دارد و می تواند بیفتد ، بنابراین استراتژی هایی برای مثال اگر یک سرویس نتواند یک پیغام را در مرحله اول بپذیرد . این معماری طوری طراحی شده است که مجددا پیام را بفرستد . واگر یک سرویس به طور کامل قابل دسترس نباشد، (که هرگز نباید در یک سیستم SOA پایدار انفاق بیفتد ) آن وقت معماری طوری طراحی شده است که روی دادن خطاهایی که ممنجر به قطع کامل در خواست سرویس می شود، امکان پذیر نباشد. SOA قابلیت اطمینان را افزایش می دهد، چون خطاهای موقت در بخشی از جریان کار نمی توانند کل فرایند تجاری را از کار بیاندازند .
به بیان کلی، SOA فرایندی تکامل یافته را ارائه می نماید و ازاین نظر می تواند ان را بلوغ سریس های وب و تکنولوژی های یکپارچه سازی به حساب آورد . در SOA به این امر توجه شده است که سیستم های با اهمیت حیاتی که بر مبنای تکنولوژی های توزیع شده ساخته می شوند. باید تضمین های خاصی را تامین نمایند . در این گونه سیستم ها باید این اطمینان وجود داشته باشد که در خواست های سرویس به طور صحیح مسیر دهی و هدایت می شوند، در زمان مناسب به آن ها پاسخ داده می شود، و این سرویس ها به طور واضح و دقیق سیاست های ارتباطی و رابط های خود را اعلام می کنند.
سرویس ها چیستند ؟
بسیاری از ما آنقدر با تکنولوژی های سرویس های وب آشنا هستیم که اغلب در باره این که خود سرویس ها واقعا چه هستند، فکر نمی کنیم. در ادامه سه تعریف می آوریم که در کنار یکدیگر ماهیت یک سرویس راشرح می دهند:
1-سرویس ها اجزاء مستقلی هستند که پیغام های XML با ساختار مشخص و خوش تعریف(Well-defined) را پردازش می کنند.
2-سرویس ها دارای رابط های خوش تعریف هستند که به وسیله یک سند مبتنی بر XML که سند Web Service Description Language (WSDL) خوانده می شود، به این سند گاهی قرارداد WSDL نیز گفته می شود. محتویات این سند، عملیات (متدهایی) که توسط سرویس ارائه می شود را شرح می دهد. از جمله اطلاعات مربوط به انواع داده، اطلاعات نحوه اتصال به سرویس، جهت یافتن و ارتباط با عملیات سرویس وب.
3-سرویس ها دارای نقاط انتهایی(Endpoint) هستند که استفاده کنندگان از و سایر سرویس ها می توانند بر اساس آدرس سرویس (معمولا URL ) به آن ها متصل شوند. این همان چیزی است که ارتباط(جفت شدن) آزادانه خوانده می شود. عبارت SOA با مبالغه و کلیات احاطه شده است. ما به تعریفی احتیاج داریم که بتوانیم با آن کار کنیم.
قبل از اقدام جهت پاسخ دادن صحیح به انتظارات می بایستی SOA را با اندکی دقت تعریف کنید. حجم زیادی از مبالغات که SOA را در سالهای اخیر احاطه کرده است، تا حدودی مسئله را سخت ساخته. اما این کار قابل انجام است. تعریف های زیادی از SOA وجود دارد. در اینجا تعریف مورد نظر به قرار زیر است:
"SOA نوعی معماری است که سرویس را برای ساده سازی فعالیت های یکپارچه سازی و استفاده از اجزا با قابلیت استفاده مجدد به روش اتصال سست به شکل بلوک ساختمانی به کار می گیرد."
SOA نوعی معماری است.
در حالی که ممکن است این مطلب اغراق آمیز کردن یک امر واضح باشد، اما یک درس کوچک در آن وجود دارد. ایجاد مجموعه ای از سرویس ها به طور خودکار یک معماری را به سادگی ارائه نمی دهند. معماری، درحالی که راهنمای ایجاد سرویس می باشد، یک موضوع مجزا از اجرای خود سرویس می باشد.
در اصطلاح SOA، سرویس گرای را به عنوان صفتی از معماری به کار می برد. یعنی SOA یک روند معماری، که قابل اجرا می باشد را توصیف می کند. این یک حالت توسعه نمی باشد. نمی توان به سادگی یک EJB را طوری تفسیر کرد که نشان دهد یک سرویس تحت شبکه است و حالا یک سرویس تحت شبکه داریم. باید یک آغاز مناسب برای SOA وجود داشته باشد. اگر با دقت به هدف نگاه کنیم، امکان دارد شروعی بسیار پرزحمت و گران قیمت داشته باشیم.
ساخت SOA نیازمند تجزیه تحلیل و یکپارچگی قابل ملاحظه ای است و نمی توان به سادگی خرید یک کالا به آن دست یافت.
SOA با سرویس ها ساخته شده است.
این سرویس بخشی از معماری سرویس گرا می باشد و با تاکید بر تعریف گفته شده پیش می رویم. اگر معماری وجود نداشته باشد یا سرویس بخش اصلی معماری نباشد SOA بی معناست. (مانند یک سیستم شئ گرا که شئ بخش اصلی آن است.)
بدون وجود سرویس ها چیزی برای ساخت، نظارت و چیزی برای اجرا وجود ندارد. از سوی دیگر، کسی که زحمت بسیار بکشد می تواند یک مجموعه ای از نمودارهای معماری تولید کند که با دنیای واقعی ارتباط دارد. اگر شما با دقت بر کار روی مجموعه ای از اجرای سرویس ها تمرکز کنید و معماری را فراموش کنید، نه تنها SOA ندارید بلکه چیزی بدتر از آن دارید. و وقت وهزینه قابل توجهی از شما را برای حل مشکل نامربوط می گیرد. این روند نادرست را دنبال نکردن الگو (anti-pattern) می گویند که باعث ایجاد مجموعه ای از وب سرویس های بی هدف می شوند. همچنین برنامه نویسان ناشی که بدون راهنمایی معماری کار می کنند ناخواسته کسب و کار را از دنبال کردن الگو منحرف می سازند، که حاصل مجموعه ای است از سرویس های بدون حاکمیت که قادر به ساخت SOA نمی باشند.
SOA یکپارچگی را آسان می سازد.
SOA یک طرز تفکر درباره سیستم های یکپارچه بیان می کند. SOA پیشنهاد کسب و کار جدید یا گسترش یافته یا فرصت هایی با اتصال سیستم های چندگانه با هم را ارائه می دهد. در ساده ترین شکل آن، این بدان معناست که شما می توانید کار B2B را سریعتر انجام دهید.
CORBA، معماری اتصال، EDI، point-to-point EAI بیش از چند دهه تلاش کردند که همه نشان دهند توانایی یکپارچه کردن سیستم های گوناگون را دارند. اما این گونه تلاش ها می تواند پرهزینه و شکننده باشد. آنها می توانند برنامه نویسان و بخشهای IT را از حل مشکلات واقعی کار منحرف سازند. به طور کلی SOA با استفاده از XML به عنوان فرم استاندارد برای پیام ما را به هدف یکپارچه سازی نزدیک می کند.
SOA استفاده مجدد را با به کارگیری اتصال سست آسان می سازد.
این ایده که SOA استفاده مجدد را با به کارگیری اتصال سست آسان می سازد یک مطلب کلیدی در بحث پشتیبانی از تلاش های یکپارچه سازی می باشد. SOA دو ایده مجزا را پیشنهاد می کند: در وهله اول استفاده مجدد را آسان می کند، و این کار را با خلق اجزای اتصال سست انجام می دهد.
در ابتدا اقدام یکپارچه سازی یا تلاش های پیشین جهت ارائه سرویس، کاملاً تمرکز خاص بر روی ایده استفاده مجدد نداشتند. اما در حال حاضر ممکن است، استانداردهای جدید و به کارگیری یک فرمت عمومی مانند XML برای تبادل پیام، برای تحقق بخشیدن سرویس های مهم در یک روش عمومی و کامل برای اینکه سرویس ها بتوانند مجدداً استفاده شوند، ارائه شود.
استفاده مجدد می تواند در فرم یک تعامل پذیری کلی نشان داده شود. اگر دو جز نرم افزار بتوانند با هم تعامل داشته باشند این دیگر معنای اتصال سست ندارد. اما اجزای اتصال سست در نهایت می توانند با یکدیگر تعامل داشته باشند.
ویژگی استفاده مجدد در کنار اتصال سست سرویس ها قابل دستیابی است، اما این یک الزام برای اهداف هر سرویس نیست. استفاده مجدد در هر سرویس خیلی ضروری نیست.
"SOA با اجزای غیر قابل استفاده مجدد یک SOA به شمار نمی رود." معماری سرویس گرا (به انگلیسی: Service-oriented Architecture (به اختصار SOA))، رهیافتی ست برای ساخت سامانه های توزیع شده که کارکردهای نرم افزاری را در قالب سرویس ارائه می کند.
از این سرویس ها هم می توان برای فراخوانی در نرم افزارهای دیگر و هم برای ساخت سرویس های جدید استفاده کرد. معماری سرویس گرا مجموعه ای انعطاف پذیر از اصول طراحی است که در مراحل توسعهٔ سامانه ها و یکپارچگی در رایانش استفاده می شود. سامانه ای که بر معماری سرویس گرا استوار است، کارکرد را به عنوان مجموعه ای از سرویس های سازگار بسته بندی می کند که می توانند در چندین سامانهٔ مجزا از دامنه های تجاری گوناگون استفاده شوند. معماری سرویس گرا" به عنوان یکی از آخرین دستآوردها در تولید نرم افزار، به نظر می رسد، در سالهای آتی معماری غالب صنعت فناوری اطلاعات و ارتباطات باشد. علت بوجود آمدن این معماری، ایده ای بود که در ذهن تعدادی از معماران آن وجود داشت و آن " نرم افزار به عنوان سرویس" بود.
برای مدتهای طولانی برنامه نویسان سعی می کردند تا، کدهای خود را بصورت modular بنویسند، تا بتوان از آن در تولید نرم افزارهای دیگر استفاده کرد. تفاوت نوشتن کد بصورت modular و بر اساس معماری سرویس گرا در حجم مخاطبان آن است.
در جهان امروز طیف مخاطبانی که بالقوه می توانند از سرویس شما استفاده کنند، کل کاربران روی شبکه اینترنت است. بنابراین باید مکانیزمی بوجود می آمد، که می توانست پاسخگوی این محیط جدید (اینترنت) و کاربران آن باشد و بنابراین معماری سرویس گرا بوجود آمد.
این معماری توسط دو شرکت IBM, Microsoft بوجود آمد، که هر دو شرکت طی سالهای اخیر از حامیان اصلی سرویسهای وب و عامل بسیاری از ابداعات جدید در حیطه سرویس های وب، مانندUDDI,WSE بوده اند.
معماری سرویس گرا ( Service-oriented Architecture)، رهیافتی ست برای ساخت سامانه های توزیع شده که کارکردهای نرم افزاری را در قالب سرویس ارائه می کند.
از این سرویس ها هم می توان برای فراخوانی در نرم افزارهای دیگر و هم برای ساخت سرویس های جدید استفاده کرد. معماری سرویس گرا مجموعه ای انعطاف پذیر از اصول طراحی است که در مراحل توسعهٔ سامانه ها و یکپارچگی در رایانش استفاده می شود. سامانه ای که بر معماری سرویس گرا استوار است، کارکرد را به عنوان مجموعه ای از سرویس های سازگار بسته بندی می کند که می توانند در چندین سامانهٔ مجزا از دامنه های تجاری گوناگون استفاده شوند.

یکی از روندهای صنعت بانکداری الکترونیک ، معماری SOA یا Service Oriented Architecture است ، به این معنا که این معماری در تعریف کسب و کار بانک ها کاربرد خواهد داشت. سرویس گرایی در واقع رهیافتی ست برای ساخت سامانه های توزیع شده که کارکردهای نرم افزاری را در قالب سرویس ارائه می کنند. بدین معنا که از این سرویس ها هم می توان برای فراخوانی در نرم افزارهای دیگر و هم برای ساخت سرویس های جدید استفاده کرد. سامانه ای که بر معماری سرویس گرا استوار است، کارکرد را به عنوان مجموعه ای از سرویس های سازگار دسته بندی می کند که می توانند در چندین سامانه مجزا استفاده شوند.اگر بخواهیم این معماری را ساده تر بگیریم، همانند این است که شما در بازی لگو تعدادی مکعب یا شکل های پایه ای یا اولیه دارید که با کمک آن ها می توانید تعداد نامحدودی شکل یا سامانه جدید بسازید و مجددا با تغییر آرایش ه مان ها به سامانه ها یا ساخته های جدیدی برسید. در معماری SOA شما تعدادی ماجول یا واحد نرم افزاری دارید که می توانند برای انجام کارهای مختلف چیدمان شوند و کارکردهای متفاوت شما را پاسخگو باشند.
حال اگر چنین سامانه نرم افزاری انعطاف پذیری را در اختیار بانکداران قرار دهید، می توانید تصور کنید که چه حجمی از نوآوری و ابتکار می تواند در ارائه سرویس و خدمت به مشتری ایجاد شود. اتفاقا همین انعطاف پذیری یکی از نقاط افتراق بانکداری اسلامی با بانکداری سنتی است. زیرا انواع عقودی که در بانکداری اسلامی بر اساس نحوه سرمایه گذاری مشتری تعریف می شود، به شدت به چنین ساختار انعطاف پذیری نیاز دارد.
ارتباط معماری SOA با عقود اسلامی
در بانکداری اسلامی هنر بازی با شکل و نوع قرارداد است. مثلا مرابحه یا صکوک یا…. آخر همه این ها به خرید و فروش و اجاره ختم می شود ولی نوع استفاده متفاوت است. بانکداری اسلامی می گوید که من باید بدانم که شما می خواهید با پولتان چه کار کنید تا بتوانم سود و زیان و نوع عقدی که برای آن مناسب است را پیشنهاد بدهم و این یعنی انواع عقود اسلامی. ضمن آنکه بانک هم با شما شریک می شود و ارتباطی سه جانبه شکل می گیرد.
در حال حاضر هر کارت اعتباری بانکی در ذات خود سه ماجول عملیاتی مختلف و در نتیجه سه عقد متفاوت دارد. حالا اگر بخواهیم این کارت را برای مصرف خرید اقساطی یک کالا بدهیم، عقد آن متفاوت می شود. اما نوع کالا و نحوه پرداخت هم نوع عقد را تغییر می دهد و همه این ها در سیستم نیاز به پیاده سازی های جداگانه و متفاوت دارد. اما در معماری SOA همه این موارد را می توان توسط ماجول هایی که قابلیت به کارگیری مجدد دارند پیاده سازی نمود. یعنی دیگر لازم نیست که هر بار نرم افزار را عوض کنید و ماجول نویسی کنید.
در SOA فقط کافی است که ماجول مربوطه را تغییر دهید و سایر قسمت های برنامه مشغول به کار عادی خود خواهند بود. ماجول هایی که مستقل بوده و حتی ساختار معماری مخصوص به خود و ارتباط سخت افزاری ویژه خود را خواهند داشت.
فواید SOA برای مشتریان بانکها
با این معماری، چه در سیستم بانکداری سنتی و چه در بانکداری اسلامی، انعطاف پذیری فراوانی در نحوه ارائه خدمت به مشتریان بانک ایجاد می شود. ارائه خدمات جدید و متنوع و متناسب با خواسته مشتری هدف اصلی انعطاف پذیرساختن ساختار معماری نرم افزاری بانک هاست. در این روش می توان بلافاصله و متناسب با نیاز واقعی و دقیق هر بازار، خدمات متناسب با آن را پیاده سازی و ارائه نمود. فرض کنید بخواهیم به یک مشتری، بر اساس یک عقد جدید تسهیلات بدهیم. می دانید که روند تصویب یک بخشنامه در بانک چندماه ممکن است طول بکشد که تازه باید برای پیاده سازی نرم افزاری آن هم حداقل چنین بازه زمانی را درنظر گرفت. ولی اکنون در دنیایی هستیم که برای انجام چنین کاری کمتر از یک روز زمان داریم. و طولانی شدن این روند زیان مستقیمی را به کل سیستم وارد می کند.
خوب اگر بتوان در داخل شعبه و براساس تشخیص رئیس شعبه، براساس یکی از عقود اسلامی تسهیلات مورد نیاز مشتری را تعریف کرد و پیاده سازی نرم افزاری آن هم با همان سرعت انجام شود، بدیهی است که چه تحول شگرفی در نحوه و کیفیت ارائه خدمات پدید خواهد آمدحالا دیگر رئیس شعبه می داند که چگونه باید منابع را جذب و توزیع کند. اگر همین را توسعه دهید به تعریف نحوه تعامل شعبه با مشتری در نوع بازپرداخت، نوع مشارکت در انواع پروژه ها، نحوه تقسیم سود و زیان بین بانک و مشتری و… می بینید که چگونه می توان منابع را بهینه جذب و بهینه توزیع نمود

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

عملا کسانی که در بورس سبدگردان های موفقی هستند، اندکند. زیرا این کار مدیریت ریسک بالایی می خواهد و فضای رقابتی بورس، فقط به چابک ترین ها امکان موفقیت می دهد. حال همین امر را در بانکداری درنظر بگیرید که چگونه می توانند سبد سپرده ها را به نحو بهینه استفاده کنند.
تغییر معماری نرم افزاری بانک ها کافی است؟
رفتن به سمت معماری SOA لایه های متفاوتی دارد که یکی از آن ها تغییر سامانه نرم افزاری است. نرم افزار رکن مهمی است اما تفکر مدیریت بانک ها هم باید تغییرکند. همه اجزای بانک که مسئول توسعه روش ها و سیستم ها هستند هم باید به این نحوه تفکر و روش مجهز شوند. ضمن آنکه مشتری هم باید بداند که در معماری سرویس گرا، باید انتظار سودآوری بیشتر و نه کسب یک سود مشخص و ثابت را داشته باشد. هم بانک و هم مشتری باید بدانند که در این روش می توان سودهای خاص به روش های خاص تعریف کرد و مشتری می تواند در نحوه سرمایه گذاری سپرده هایش تصمیم گیری نماید. چون سرویس ها قابل تعریف و قابل انعطاف هستند.
یک مشتری می تواند درخواست کند که مایل است منابعش را در صنعت پتروشیمی یا کشاورزی یا… سرمایه گذاری نماید. یا مثلا مشتری مایل است که هفتاددرصد از سپرده هایش در صنعت و مابقی در کارهای عام المنفعه یا خیریه به کار گرفته شود.
حتی مشتری می تواند در وثیقه گیری هم تعیین ریسک کند. مشتری لازم نیست حتما سند ملک را به عنوان وثیقه بگذارد. اگر وی مایل به پرداخت نرخ سود بیشتر باشد می توان از چک و سفته هم به عنوان وثیقه استفاده کرد و آن را در سیستم تعریف نمود. حتی بانک هم می تواند اعلام کند من منابع شما را با این شرایط نمی خواهم و یا حاضر نیستم در ریسک پروژه سرمایه گذاری با شما شریک باشم. حتی بانک ممکن است اعلام کند که صددرصد ریسک طرح با خودتان و من فقط حق الوکاله خود را بر می دارم. در معماری سرویس گرا می توانیم همه این ها را تعریف کنیم. یعنی من به عنوان سپرده گذار می توانم تمام شرایط خود را بگذارم و صاحب سود بیشتری شوم و سلایقم را اعمال کنم.

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

کارهایی مانند رفتن به محل شعبه و صرف هزینه هایی این چنین در دنیای مجازی از بین می رود و اوراق بهادار جایگزین آن خواهد شد و اگر من در دنیای مجازی دارای اعتبار حقیقی و حقوقی باشم، قطعا سپرده گذار اعتماد می کند و منابع را در اختیارخواهد گذاشت. کم کم به سمتی خواهیم رفت که چک و پول فیزیکی از بانک ها و مبادلات خذف خواهد شد و سرویس جای آن را خواهد گرفت.
همین حالا هم در سیستم های جدید بانک مرکزی اصلا لزومی به دادن چک نیست در واقع در قالب برگه اعتبار و تعهد یا پرداخت حواله آینده با تایید بانک خود تمام دستور حوالجات را الکترونیکی می دهید و دریافت کننده آنرا می پذیرد و بانک تایید می کند که درصورتیکه این فرد توان پرداخت پول را نداشت، من آنرا تامین می کنم. این مسیر آینده دریافت و پرداخت است و جایگزین چک خواهد شد. این نوع سرویس دهی به طور طنز آمیزی ما را برمی گرداند به دوهزار سال قبل که چک در کار نبود. همه این ها برمبنای معماری سرویس گرا اتفاق خواهد افتاد و مطمئن باشید که آینده صنعت بانکداری، خصوصا بانکداری اسلامی به این سو خواهد رفت
معماری سرویس گرا چیست
معماری سرویس گرا SOA شکل تکامل یافته محاسبه گری توزیع شده مبتنی بر فرضیه طراحی تقاضا پاسخ برای برنامه های کاربردی همگام و ناهمگام است منطق تجاری یا توابع اختصاصی یک برنامه کاربردی به صورت ماژولار در آمده اند و به عنوان سرویس هایی برای برنامه های کاربردی مصرف کننده کلاینت ارائه گردیده اند
معماری سرویس گرا (SOA) شکل تکامل یافته محاسبه گری توزیع شده مبتنی بر فرضیه طراحی تقاضا/پاسخ برای برنامه های کاربردی همگام و ناهمگام است. منطق تجاری یا توابع اختصاصی یک برنامه کاربردی به صورت ماژولار در آمده اند و به عنوان سرویس هایی برای برنامه های کاربردی مصرف کننده/کلاینت ارائه گردیده اند. مهم ترین نکته در مورد این سرویس ها طبیعت اتصال آزادانه آنهاست؛ بدین معنی که رابط سرویس، مستقل از پیاده سازی است. توسعه دهندگان برنامه های کاربردی یا گردآورندگان سیستم ها می توانند با ساختن یک یا چند سرویس بدون آگاهی از پیاده سازی های زیرین سرویس ها اقدام به ایجاد برنامه های کاربردی نمایند. برای مثال، یک سرویس می تواند در .Net یا J۲EE پیاده سازی گردد، و برنامه کاربردی استفاده کننده از سرویس می تواند بر روی یک پلات فرم یا زبان متفاوت قرار داشته باشد.
▪ معماری های سرویس گرا دارای خصوصیات اصلی زیر هستند:
– سرویس های SOA دارای رابط های خود-توصیف گر در اسناد XML مستقل از پلاتفرم هستند. زبان توصیف سرویس های وب (WSDL) استاندارد به کار برده شده برای توصیف این سرویس ها می باشد.
– سرویس های SOA با پیام هایی که رسما توسط شمای XML (که XSD نیز نامیده می شود) تعریف شده اند ارتباط برقرار می نمایند. ارتباط میان مصرف کنندگان و فراهم کنندگان یا سرویس ها معمولا در محیط های ناهمگن رخ می دهد، با دانش کم یا بدون هیچ دانشی در مورد فراهم کننده. پیام های مبادله شده میان سرویس ها را می توان به عنوان اسناد تجاری مهم پردازش شده در یک سازمان نگریست.
– سرویس های SOA توسط یک رجیستری که به عنوان یک فهرست دایرکتوری عمل می کند نگهداری می گردند. برنامه های کاربردی می توانند سرویس ها را درون رجیستری جستجو نمایند و سرویس را فراخوانی کنند. توصیف، تعریف، و یکپارچگی جهانی (UDDI) استانداردی است که برای رجیستری سرویس مورد استفاده قرار گرفته است.
هر سرویس SOA دارای یک کیفیت سرویس (QoS) مرتبط با خود است. برخی از عناصر اساسی QoS شامل نیازمندی های امنیتی، از قبیل احراز هویت و صدور مجوز، پیام رسانی قابل اطمینان، و خط مشی هایی در این زمینه که چه افرادی می توانند سرویس ها را فراخوانی نمایند، می باشد.
● چرا SOA؟
واقعیت موجود در سازمان های IT این است که زیربنا در میان سیستم های عامل، برنامه های کاربردی، نرم افزارهای سیستمی، و زیربنای کاربردی به صورت ناهمگن است. برخی برنامه های کاربردی موجود برای اجرای فرایندهای فعلی تجارت مورد استفاده قرار گرفته اند، بنابراین آغاز از صفر برای ساختن زیربنای جدید یک رویکرد قابل انتخاب محسوب نمی گردد. سازمان ها باید به شکلی سریع به تغییرات تجاری واکنش نشان دهند؛ از سرمایه های موجود در برنامه های کاربردی و زیربنای کاربردی به منظور تمرکز بر روی نیازمندی های تجاری جدیدتر استفاده نمایند؛ کانال های جدید تعامل با مشتریان، شرکا، و تامین کنندگان را پشتیبانی کنند؛ و یک معماری که تجارت ارگانیک را پشتیبانی نماید به کار گیرند. SOA با طبیعت اتصال آزادانه خود به سازمان ها امکان بهره گیری از سرویس های جدید یا ارتقای سرویس های موجود را به شیوه ای قطعه قطعه به منظور تمرکز بر نیازمندی های تجاری فراهم می آورد، امکانی را برای قابل استفاده نمودن سرویس ها در کانال های متفاوت فراهم می سازد، و سازمان موجود و برنامه های کاربردی نسل قبل را به عنوان سرویس ها ارائه می کند، در نتیجه سرمایه های زیربنای IT موجود را حراست می نماید.
یک سازمان استفاده کننده از SOA می تواند یک برنامه کاربردی مرکب زنجیره تامین را با استفاده از مجموعه ای از برنامه های کاربردی موجود که کارکرد خود را از طریق رابط های استاندارد ارائه می دهند، ایجاد نماید.
● معماری سرویس
چندین مصرف کننده سرویس می توانند با ارسال پیام اقدام به فراخوانی سرویس ها نمایند. این پیام ها معمولا توسط یک گذرگاه سرویس تغییر شکل داده شده و به سوی یک پیاده سازی سرویس مناسب هدایت می گردند. این معماری سرویس می تواند یک موتور قواعد تجاری را فراهم سازد که امکان تلفیق قواعد تجاری در یک سرویس یا چندین سرویس را عملی سازد. معماری سرویس مزبور همچنین یک زیربنای مدیریت سرویس فراهم می آورد که سرویس ها و اعمالی از قبیل بازرسی، پرداخت صورتحساب، و واقعه نگاری (logging) را مدیریت می نماید. به علاوه، این معماری انعطاف پذیری ناشی از دارا بودن فرایندهای تجاری تغییر پذیر را به سازمان ها ارزانی می دارد، فرایندهایی که نیازمندی های تنظیمی همانند Sarbanes Oxley (SOX)i را مد نظر قرار می دهند، و سرویس های اختصاصی را بدون تحت تاثیر قرار دادن سایر سرویس ها تغییر می دهند.
● زیربنای SOA
برای اجرا و مدیریت برنامه های کاربردی SOA، سازمان ها نیازمند یک زیربنای SOA هستند که بخشی از پلات فرم SOA محسوب می گردد. یک زیربنای SOA باید تمامی استانداردهای مرتبط و ظرف های (container) مورد نیاز زمان اجرا را پشتیبانی کند. یک زیربنای SOA معمولی چیزی شبیه شکل ۳ است. بخش هایی که در ادامه این مقاله مشاهده می نمایید قطعات اختصاصی این زیربنا را مورد بحث قرار می دهند.
● SOAP, WSDL, UDDI

WSDL، UDDI، و SOAP قطعات اساسی زیربنای SOA هستند. WSDL برای توصیف سرویس به کار برده شده است؛ UDDI، برای ثبت و جستجوی سرویس ها؛ و SOAP، به عنوان یک لایه نقل و انتقال جهت ارسال پیام ها میان مصرف کننده سرویس و فراهم کننده سرویس. در حالی که SOAP ساز و کار پیش فرض برای سرویس های وب است، تکنولوژی های جایگزین، انواع دیگری از انقیادها (binding) را برای یک سرویس تحقق می بخشند. یک مصرف کننده می تواند به جستجوی یک سرویس در رجیستری UDDI بپردازد، WSDL را برای سرویسی که دارای توصیف است تهیه نماید، و سرویس را از طریق SOAP فراخوانی کند.
● WS-I Basic Profile
WS-I Basic Profile، که از سوی Web services Interoperability Organization فراهم شده است، یکی دیگر از قطعات اساسی مورد نیاز برای تست و interoperability (قابلیت کار با سایر اجزای سیستم) سرویس است. فراهم کنندگان سرویس می توانند از مجموعه های تست Basic Profile برای تست نمودن interoperability سرویس در میان پلات فرم ها و تکنولوژی های متفاوت استفاده کنند.
● J۲EE و .Net
اگر چه پلات فرم های J۲EE و .Net برای برنامه های کاربردی SOA پلاتفرم های توسعه غالب به شمار می روند، اما SOA به هیچ عنوان به این پلات فرم ها محدود نیست. پلات فرم هایی از قبیل J۲EE نه تنها یک framework را برای توسعه دهندگان جهت سهیم شدن در SOA فراهم می آورند، بلکه با طبیعت ذاتی خود، یک زیربنای کامل و مورد تایید از لحاظ بسط پذیری، قابلیت اطمینان، دسترس پذیری، و کارآیی را برای دنیای SOA به ارمغان می آورند. مشخصه های جدیدی از قبیل JAXB (Java API for XML Binding)، که کاربرد آن در نگاشت اسناد XML به کلاس های جاوا است، JAXR (Java API for XML Registry)، که کاربرد آن در تعامل با رجیستری های UDDI به یک شیوه استاندارد است، و XML-RPC (Java API for XML-based Remote Procedure Call)، که کاربرد آن در فراخوانی سرویس های راه دور در J۲EE ۱.۴ است توسعه و گسترش سرویس های وبی که در میان ظرف های استاندارد J۲EE قابل انتقال هستند را تسهیل می نمایند، ضمن این که به شکل همزمان به کار با سرویس های موجود در پلات فرم های دیگری از قبیل .Net می پردازند.
● کیفیت سرویس ها
سیستم های حیاتی موجود در سازمان ها نیازمندی های پیشرفته ای از قبیل امنیت، قابلیت اطمینان، و تراکنش ها را مد نظر قرار می دهند. همچنان که سازمان ها شروع به پذیرش معماری سرویس به عنوان ابزاری برای توسعه و گسترش برنامه های کاربردی می نمایند، مشخصه های بنیادین وب از قبیل WSDL، SOAP، و UDDI قادر به برآورده ساختن این نیازمندی های پیشرفته نیستند. همچنان که قبلا گفته شد، این نیازمندی ها، همچنین تحت عنوان کیفیت سرویس ها شناخته می شوند. تعداد بیشماری از مشخصه های مرتبط با QoS در هیئت های برخی استانداردها همچون W۳C (World Wide Web Consortium) و OASIS (Organization for the Advancement of Structured Information Standards) مطرح گردیده اند. بخش هایی که در ادامه آمده است برخی از اثرات QoS و استانداردهای مرتبط را مورد بحث قرار داده اند.
● امنیت
مشخصه Web Services Security امنیت پیام را مد نظر دارد. این مشخصه بر روی تبادل اعتبارنامه، یکپارچگی پیام، و محرمانگی پیام متمرکز گردیده است. نکته جذاب در مورد این مشخصه این است که آن از استانداردهای امنیتی موجود، از قبیل SAML (Security Assertion Markup Language)، بهره می گیرد و امکان استفاده از این استانداردها را به منظور ایمن سازی پیام های سرویس های وب فراهم می سازد. Web Services Security یک تلاش مداوم و در حال رشد از سوی OASIS است.
● قابلیت اطمینان
در یک محیط SOA معمولی، اسناد متعددی میان استفاده کنندگان از سرویس و فراهم کنندگان سرویس مبادله می گردد. تحویل پیام ها با خصوصیاتی همچون تحویل یکباره و فقط یکباره، تحویل حداکثر یکباره، حذف دوباره ای پیام، تحویل تضمین شده پیام، و تصدیق در سیستم های حیاتی که از معماری سرویس استفاده می کنند از اهمیت بالایی برخوردار می گردد. WS-Reliability و WS-ReliableMessaging دو استانداردی هستند که مسائل مربوط به پیام رسانی قابل اطمینان را مد نظر قرار می دهند. هر دوی این استانداردها اکنون بخشی از OASIS می باشند.
● خط مشی
فراهم کنندگان سرویس در برخی موارد استفاده کنندگان از سرویس را ملزم به مراوده با خط مشی های معین می نمایند. به عنوان یک مثال، یک فراهم کننده سرویس ممکن است یک نشانه امنیتی Kerberos را برای دستیابی به سرویس الزامی نماید. این استلزام ها به عنوان اظهارنامه های خط مشی تعریف گردیده اند. یک خط مشی ممکن است شامل چندین اظهارنامه باشد. WS-Policy نحوه مورد مراوده قرار گرفتن خط مشی ها میان استفاده کنندگان از سرویس و فراهم کنندگان سرویس را به شکل استاندارد در می آورند.
● هماهنگ سازی
همچنان که سازمان ها به معماری سرویس روی می آورند، سرویس ها می توانند برای یکپارچه سازی مخازن داده، برنامه های کاربردی، و کامپوننت ها مورد استفاده قرار گیرند. یکپارچه سازی برنامه های کاربردی بدان معنی است که نیازمندی های پردازش، از قبیل ارتباط ناهمگام، پردازش موازی، تبدیل داده ها، و تصحیح، باید استانداردسازی گردند. BPEL۴WS یا WSBPEL (Web Services Business Process Execution Language) یک مشخصه OASIS است که هماهنگ سازی سرویس را مد نظر دارد، جایی که فرایندهای تجاری با استفاده از مجموعه ای از سرویس های گسسته ایجاد گردیده باشند. WSBPEL اکنون بخشی از OASIS می باشد.
● مدیریت
همچنان که تعداد سرویس ها و فرایندهای تجاری ارائه شده به عنوان سرویس در سازمان افزایش می یابد، یک زیربنای مدیریت که امکان مدیریت سرویس های در حال اجرا در یک محیط ناهمگن را به مدیران سیستم می دهد از اهمیت بالایی برخوردار می گردد. WSDM (Web Services for Distributed Management) بیانگر آن خواهد بود که هر سرویس پیاده سازی شده بر اساس WSDM توسط یک راهکار مدیریت سازگار با WSDM قابل مدیریت خواهد بود. سایر صفت های QoS از قبیل هماهنگی میان شرکا و تراکنش ها که در بر دارنده چندین سرویس هستند به ترتیب در مشخصه های WS-Coordination و WS-Transaction (که باز هم جزو تلاش های OASIS محسوب می گردند) مد نظر قرار گرفته اند.
● SOA سرویس وب نیست
آن گونه که به نظر می رسد در مورد ارتباط میان SOA و سرویس های وب نوعی سردرگمی عمومی وجود دارد. در یکی از گزارش های Gartner مورخ آوریل ۲۰۰۳، Yefim V. Natis این گونه تقاوت میان آنها را شرح می دهد: ”سرویس های وب راجع به مشخصه های تکنولوژی هستند، در حالی که SOA یک قاعده ی طراحی نرم افزار است. شایان ذکر است که WSDL سرویس های وب یک استاندارد تعریف رابط مناسب SOA است: این نقطه ای است که سرویس های وب و SOA اساسا به یکدیگر پیوند می خورند.“ اساسا، SOA یک الگوی معماری است، در حالی که سرویس های وب سرویس های پیاده سازی شده توسط مجموعه ای از استانداردها می باشند؛ سرویس های وب یکی از روش هایی است که شما با استفاده از آن می توانید SOA را پیاده سازی نمایید. مزیت پیاده سازی SOA با سرویس های وب این است که شما به یک رویکرد بی طرفانه نسبت به پلات فرم به منظور دستیابی به سرویس ها و interoperability بهتر دست می یابید همچنان که فروشندگان بیشتر و بیشتری مشخصه های بیشتر و بیشتری از سرویس های وب را پشتیبانی می نمایند.
● مزایای SOA
در حالی که مفهوم SOA اساسا جدید نیست، SOA با تکنولوژی های توزیع شده موجود متفاوت است به گونه ای که اغلب فروشندگان آن را پذیرفته و دارای یک مجموعه پلات فرم یا برنامه کاربردی هستند که دارای قابلیت SOA می باشند. SOA، با یک مجموعه از استانداردهایی که همه جا در دسترس هستند، قابلیت استفاده مجدد از سرمایه ها و دارایی های موجود در سازمان را بهبود می بخشد و به شما امکان ایجاد برنامه های کاربردی که می توانند بر فراز برنامه های کاربردی موجود و جدید ساخته شوند، می دهد. SOA امکان ایجاد تغییر در برنامه های کاربردی در شرایطی که کلاینت ها یا استفاده کنندگان از سرویس جدای از تغییرات صورت گرفته در پیاده سازی سرویس حفظ شوند، فراهم می آورد. SOA امکان ارتقای استفاده کنندگان از سرویس یا سرویس های اختصاصی را فراهم می سازد؛ بازنویسی کامل یک برنامه کاربردی یا حفظ یک سیستم موجود که دیگر نیازمندی های جدید تجاری را مد نظر قرار نمی دهد لازم نیست.نهایتا، SOA انعطاف پذیری بیشتری را برای سازمان ها در ساختن برنامه های کاربردی و فرایندهای تجاری به شیوه ای سریع تر با بهره گیری از زیربنای برنامه ی کاربردی موجود به منظور تولید سرویس های جدید فراهم می نماید. معاری سرویس گرا (SOA) روشی جدید و در حال تکامل برای ساخت برنامه های توزیع شده با Distributed Applicationاست. سرویس ها اجزای توزیع شده با رابط های تعریف شده و مشخص هستند که پیغام های XMIL را پردازش وتبادل می کنند. با رویکرد سرویس گرا می توان راه حل های را ارائه داد که به مرز دامنه های سازمان، شرکت یا دپارتمان محدود نیستند. با استفاده از SOA می توان در شرکتی که دارای سیستم ها و برنامه های کاربردی مختلف روی پلتفرم های متفاوت است، یک راه حل یک پارچه سازی با استقلال زیاد(loosly coupled) ساخت که جریان یکنواخت و ناهماهنگ کار را تضمین کند.
هر کس که از سایت های تجارت الکترونیکی به صورت آنلاین خرید کرده باشد، با مفهوم سرویس ها آشنا است. وقتی که سفارش تا ن را دادید، باید اطلاعات کارت اعتباری تان را ارایه کنید که به طور معمول توسط یک فراهم کننده سرویس ثانویه، تایید و شارژ می شود. وقتی که سفارش پذیرفته شد، شرکت سفارش گیرنده با یک شرکت فراهم کننده سرویس حمل ونقل فراهم می کند و در نهایت کالای شما تحویلتان می شود. نیاز به معماری سرویس گرا از جنبه ای دیگر نیز به نحوه بارزی در برنامه های کاربردیeCommerce مشهود است. اگر مثلا جزء(componet) مربوط به پرداخت با کارت اعتباری offline و یا غیر فعال باشد، قرار نیست که فرایند فروش متوقف شود. بلکه سفارش ها بایستی پذیرفته شوند وعملیات پرداخت به وقت دیگری موکول شود.
مثل سایر معماری های توزیع شده، SOA ساخت برنامه های کاربردی با استفاده اجزایی که در domainهای جدا از هم را قرار دارند را ممکن می سازد . SOA از سرویس های وب به عنوان نقاط ورود برنامه کاربردی استفاده می کند که از لحاظ مفهومی معادل همان اجزای proxy و stub در سیستم های توزیع شده سنتی مبتنی بر اجزاء هستند . با این تفاوت که در این جا ارتباط بین سرویس وب و استفاده کننده خیلی آزاداترانه ومستقل تر (loosely coupled) است .به علاوه SOA به خاطر در بر داشتن فاکتورهایی که اهمیت حیاتی در تجارت دارند ، نیز منحصر به فرد است . فاکتورهایی نظیر: قابلیت اطمینان سرویس، جامعیت پیام ، یکسانی تراکنش و امنیت پیام . در امور تجاری واقعی نمی توان روی سرویس هایی که یک درخواست را فقط به خاطر این که بتوانند بفهمند، پردازش می کنند حساب کرد . در امور تجاری به قطعیت و اطمینان بیشتری نیاز است. واضح است که سیستم های مختلف ممکن است بعضی اوقات غیر فعال باشند و یا پاسخگویی آن ها در دفعات مختلف متفاوت باشد . با وجود این هیچکدام از این موارد نباید برای کنار گذاشتن یاعدم پاسخ به یک درخواست باشند.
علاوه بر آن نباید دلیلی برای کنار گذاشتن یا عدم پاسخ به یک درخواست باشند واضح است که سیستم های مختلف ممکن است بعضی اوقات غیر فعال باشند و یا پاسخگویی آن ها در دفعات مختلف ، متفاوت باشد. با وجود این ، هیچ کدام ازاین موارد نباید دلیلی برای کنار گذاشتن یا عدم پاسخ به یک درخواست باشند. علاوه بر آن نباید هیچ ابهامی در نحوه فراخوانی یک سرویس وجود داشه باشد. اگر سیستمی توانایی های خود را در قالب سرویسی روی وب ارائه کند. در آن صورت نحوه فراخوانی آن سرویس باید به طور واضح مستند سازی و اعلام شود . بسیاری از مسائل دسترس پذیری و مقیاس پذیری برنامه های کاربردی امروزی در SOA حل شده است که احتمال نقض آن در هر مر حله ای از جریان کار بسیار زیاد است.در SOA فرض بر این است که خطا وجود دارد و می تواند بیفتد ، بنابراین استراتژی هایی برای مثال اگر یک سرویس نتواند یک پیغام را در مرحله اول بپذیرد . این معماری طوری طراحی شده است که مجددا پیام را بفرستد . واگر یک سرویس به طور کامل قابل دسترس نباشد، (که هرگز نباید در یک سیستم SOA پایدار انفاق بیفتد ) آن وقت معماری طوری طراحی شده است که روی دادن خطاهایی که ممنجر به قطع کامل در خواست سرویس می شود، امکان پذیر نباشد. SOA قابلیت اطمینان را افزایش می دهد، چون خطاهای موقت در بخشی از جریان کار نمی توانند کل فرایند تجاری را از کار بیاندازند .
به بیان کلی، SOA فرایندی تکامل یافته را ارائه می نماید و ازاین نظر می تواند ان را بلوغ سریس های وب و تکنولوژی های یکپارچه سازی به حساب آورد . در SOA به این امر توجه شده است که سیستم های با اهمیت حیاتی که بر مبنای تکنولوژی های توزیع شده ساخته می شوند. باید تضمین های خاصی را تامین نمایند . در این گونه سیستم ها باید این اطمینان وجود داشته باشد که در خواست های سرویس به طور صحیح مسیر دهی و هدایت می شوند، در زمان مناسب به آن ها پاسخ داده می شود، و این سرویس ها به طور واضح و دقیق سیاست های ارتباطی و رابط های خود را اعلام می کنند.
بسیاری از ما آنقدر با تکنولوژی های سرویس های وب آشنا هستیم که اغلب در باره این که خود سرویس ها واقعا چه هستند، فکر نمی کنیم. در ادامه سه تعریف می آوریم که در کنار یکدیگر ماهیت یک سرویس راشرح می دهند:
۱-سرویس ها اجزاء مستقلی هستند که پیغام های XML با ساختار مشخص و خوش تعریف(Well-defined) را پردازش می کنند.
۲-سرویس ها دارای رابط های خوش تعریف هستند که به وسیله یک سند مبتنی بر XML که سند Web Service Description Language (WSDL) خوانده می شود، به این سند گاهی قرارداد WSDL نیز گفته می شود. محتویات این سند، عملیات (متدهایی) که توسط سرویس ارائه می شود را شرح می دهد. از جمله اطلاعات مربوط به انواع داده، اطلاعات نحوه اتصال به سرویس، جهت یافتن و ارتباط با عملیات سرویس وب.
۳-سرویس ها دارای نقاط انتهایی(Endpoint) هستند که استفاده کنندگان از و سایر سرویس ها می توانند بر اساس آدرس سرویس (معمولا URL ) به آن ها متصل شوند. این همان چیزی است که ارتباط(جفت شدن) آزادانه خوانده می شود.
▪ مشخصه های سرویس های وب و WS-IBasic Profile
برنامه های کاربردی SOA نیاز به پشتیبانی و امکانات زیر ساختی زیادی دارند. از جمله امکانات ارسال و دریافت مختلفی ، زیر ساخت امنیتی و پشتیبانی برای پیام رسانی مطمئن. شرکت های مختلفی، از جمله IBM و مایکروسافت، برای ارائه مشخصه های استانداردی که دامنه گسترده تکنولوژی های زیر ساخت SOA را پوشش دهد، با یکدیگر همکاری می کنند.
متاسفانه مشخصه های سرویس های وب در محیطی ارایه می شوند و توسعه می یابند که شرکت های دخیل در آن بیشتر رقیب هستند تا شریک. رقابت های میان شرکت ها باعث می شود که نتواند بر سر استانداردهای صحیح و مناسب به توافق برسند. اغلب، گروههای مختلف شرکت ها، برای موارد یکسان ، استاندارهای متفاوتی را دنبال می کنند . سازمان های غیر انتفاعی مثل OASIS گرد همایی هایی برای همکاری در ارایه و توسعه استانداردها و مشخصه های سرویس های وب برگزار می کنند
▪ معرفی WS-IBasic Profile
سازمان(WS-I)Web Services Interoperability یک هدف اصلی دارد و آن را ارائه مشخصه های استانداردی است که سرویس های وب بتوانند با استفاده از آن روی پلتفرم های مختلف با هم تعامل داشته باشند. به بیان دیگر، هدف این سازمان این است که سرویس های وب بتوانند با هم کار کنند، بدون توجه به این که تحت چه سکوی کاری عمل می کنند و یا با استفاده از چه ابزارهایی ایجاد شده اند . این مشخصه های سرویس های وب زمینه های گسترده ای را پوشش می دهند، از پروتکل های نقل و انتقال داده تا امنیت که مجموعه آن ها تحت عنوان پروفایل پایه WS-I جمع آوری شده اند.مشخصه های سرویس های وب به طور عمده در گروههای زیر دسته بندی می شوند:
نقل و انتقال (Tranport )
این گروه از مشخصه ها، پروتکل های ارتباطی برای انتقال داده های خام بین سرویس های وب را تعریف می کنند و پروتکل های HTTP، HTTPS و SMTP را شامل می شوند.
▪ پیغام رسانی (Messaging)
این گروه از مشخصه ها تعیین می کنند که پیغام های XMIL که سرویس های وب تبادل می کنند. چه فرمتی باید داشته باشند. این گروه مشخصه های SOAP برای نحوه رمز گذاری پیغام و مشخصه های XMIL و XSD برای کلمات کلیدی پیغام (vocablury) . را شامل می شود. مشخصه های آدرس دهی سرویس های وب نیز در این گروه قرار دارد . این مشخصه ها اطلاعا ت مقصد پیغام را از پروتکل نقل و انتقال داده ها، مستقل می سازد . برای مثال می توان با استفاده از مشخصه های آدرس دهی سرویس های وب، چندین مقصد برای یک پیغام XMIL تعریف کرد.
▪ تشریح (Description)
این گروه شامل مشخصه هایی برای تشریح و توضیح یک سرویس وب است . مشخصه های اصلی این گروه WSDL ( برای قرارداد سرویس ) و XSD ( برای تعریف شماهای نوع داده) هستند. این گروه همچنین مشخصه سیاست گذاری سرویس وب) WS-Policy )را شامل می شود که سیاست گذاری هایی که یک سرویس وب به هنگام ارتباط با یک سرویس گیرنده( کلاینت) اعمال می کند و تشریح می کند. برای مثال یک سرویس ممکن است شرایط خاصی برای فراخوانی عملیاتش داشته باشد. مشخصه WS-Policy به سرویس وب این امکان می دهد که به سرویس گیرنده های احتمالی بگوید برای اجرای یک درخواست سرویس موفق باید از چجه قوانینی تبعیت کنند. نهایتا، در این گروه مشخصه UDDI برای یافتن ( description) سرویس های وب گنجانده شد ه است.
▪ ضمانت های سرویس (Service Assurances)
سرویس های وب نباید فقط به سادگی پیغام های XMIL را رد و بدل کنند. این سرویس ها باید تضمینی برای سرویس گیرنده داشته باشند که اولا پیغام به نحوی ایمن منتقل خواهد شد، ثانیا این که سرویس گیرنده باید حتما پاسخی دریافت کند، حتی اگر در نقطه ای از جریان کار، نقصی پیش آمده باشد. این گروه از مشخصه ها شامل مشخصه امنیت سرویس وب ( برای تضمین رسیدن پیغام ها) مشخصه پیغام رسانی مطمئن سرویس وب ( برای تضمین رسیدن پیغام ها در شبکه های ناپایدار و بدون قابلیت اطمینان) و تعداد زیادی از مشخصه های مربوط به تراکنش است.
▪ ترکیب سرویس (Service Composition)
مجموعه گسترده مشخصه های WS-I Basic Profile را نمی توان به طور کامل در هر سرویس وب پیاده کرد. به همین خاطر، توسعه دهندگان باید مشخصه هایی که برای یک سرویس خاص مهم و مناسب هستند را انتخاب و در آن سرویس پیاده کنند. برای تامین این هدف، سرویس ها دارای ویژگی ترکیب سرویس هستند . که به توسعه دهندگان اجازه می دهد مشخصه های مختلف را برای هر سرویس انتخاب کنند و آن ها را در سند WSDL گرد آوری و ثبت کنند.
در ادامه بحث ،تعدادی از مهمترین مشخصه های سرویس های وب و اهداف آن را بیان می کنیم:
WS-Seccurity (امنیت سرویس وب ): مشخصه ای جامع که مجموعه ای از تکنولوژی های متداول امنیتی را تحت پوشش دارد، از جمله امضاهای دیجیتال و رمز گذاری مبتنی بر نشانه های امنیتی،شامل گواهی های X.۵۰۹
WS-Policy (سیاستگذاری سرویس وب ): به سرویس های وب امکان می دهد نیازها، ترجیحات( preferences ) و توانایی های خود را براساس مجموعه ای از فاکتورها بیان و مستند سازی می کند کنند. البته تمرکز بیشتر با فاکتورهای امنیتی است . برای مثال سیاستگذاری یک سرویس وب می تواند شامل نیازهای امنیتی آن، نظیر رمز گذاری و امضای دیجیتال بر اساس یک گواهی X.۵۰۹ باشد.
WS-Adressing (آدرس دهی سرویس وب): نقاط انتهایی سرویس را در یک پیغام مشخص می کندو امکان update شدن این نقاط انتهایی را در مواردی که پیغام بین دو یا چند سرویس منتقل می شود، فراهم می سازد. این مشخصه به طور گسترده در حال جایگزینی مشخصه قدیمی تر WS-Routing (مسیر دهی سرویس وب )است.
WS-Messaging (پیغام رسانی سرویس وب): امکان پشتیبانی از سایر پروتکل های کانال ارتباطی، نظیر TCP ، را در کنار HTTP برای سرویس وب فراهم می سازد. این مشخصه ساخت و توسعه نرم افزارهای پیغام رسانی، از جمله برنامه های کاربردی غیر همزمان که با استفاده از SOAP روی HTTP ارتباط برقرار می کنند، را تسهیل می کند.
WS-Secure Conversation(مکالمه ایمن سرویس وب): با استفاده از نشانه های امنیتی (Security tokens) ارتباطات مورد اعتماد برای جلسات کاری فراهم می کند.
WS-Reliable Messaging (پیغام رسانی مطمئن سرویس وب): مکانیسم هایی برای تضمین اطمینان از رسیدن پیغام،حتی در صورتی که یک یا چند سرویس در زنجیره سرویس ها قابل دسترس نباشند ، را فراهم می سازد. این مشخصه شامل روش هایی برای اعلام رسیدن پیغام است، به طوری که فرستنده بتواند بفهمد که آیا گیرنده در دریافت پیغام موفق بوده است یا نه.
با معرفی و ثبت مشخصه های جدید و بهبود مشخصه های قبلی ، مشخصه های سرویس های وب دائما در حال تکامل هستند. البته، مجموعه مشخصه های پایه ای که در مقاله بیان شد، احتمالا برای مدتی به عنوان زیر بنای اصلی مشخصه های سرویس های وب باقی خواهند ماند، چرا که این مشخصه ها نیازهای اصلی و بنیادی برنامه های کاربردی سرویس گرا را پوشش می دهند.
▪ معرفی .NET Web Services Enhancements ۲.۰ for
Web Services Enhancements (WSE) ۲.۰ مجموعه ای از ابزارهای مدیریت شده تحت .NET را جهت پیاده سازی مشخصه های سرویس های وب برای توسعه دهندگان فراهم آورده است. WSE جهت فراهم آوردن پشتیبانی بیشتر زیرساختی، فراتر از آنچه که در حال حاضر به وسیله چهارچوب کاری دات نت تامین می شود، برای راه حل ها ی SOA ارایه شده است. به کمک WSE همچنین زیر ساخت پردازشی برای میزبانی سرویس های وبی که WS-Specification را پیاده سازس می کنند، فراهم می آورد. برای مثال، WSE به شما امکان می دهد که به آسانی سرویس های وبی بسازید که رمز گذاری و امضاهای دیجیتال را روی درخواست ها و پاسخ های سرویس وب اعمال می کنند. در نهایت، WSE یک ابزار بهره وری است که برای هدایت توسعه دهندگان دات نت به سمت نسخه آینده Indigo طراحی شده است .Indigo از محصولات آینده مایکروسافت است که پشتیبانی یک پارچه برای برنامه های کاربردی پیغام رسانی و سرویس گرا را هم فراهم می آورد.
WSE یک محصول در حال تکامل است و در حال حاضر تمام مشخصه های سرویس های وب را پشتیبانی نمی کند، ولی بسیاری از مشخصه های مهم نظیر WS-Seccurity و WS-Policyپشتیبانی می نماید . به خاطر داشته باشید که SOA تحت تاثیر مجموعه ای از استانداردها و مشخصه های فنی است که خودشان در حال تغییر هستند . نگارش های WSE برای هماهنگی با نسخه های جدید این استانداردها و تکنولوژی ها باید چرخه انتشار انعطاف پذیری داشته باشند. به همین خاطر مایکروسافت تصمیم گرفته است که چرخه انتشار WSE از چرخه انتشار نگارش های .NET Framework جدا کند، تا بتواند انتشار نگارش های این محصول را با انعطاف پذیری بیشتری برنامه ریزی کند.
موضوعی که هم باعث خوشحالی و هم نگرانی من شده شیوع و همه گیر شدن معماری سرویس گرا در کشور است! با هر سازمانی که جلسه داریم و پای صحبت هر مدیر فاوا که می نشینم، اولین چیزی که میگوید تمایل به استفاده از معماری سرویس گرا است و اینکه همه مشاوران و پیمانکاران نیز همین را به وی توصیه نموده اند.
در نگاه اول این موضوع موجب خوشحالی است. بیاد دارم وقتی که در سال 83 بحث سرویس گرایی را بصورت اولیه شروع کردم هنوز در حد یک تصویر کلی بود. در سال 84 جدی تر به آن پرداختم و مطالعاتم را گسترده تر کردم و سرانجام در سال 85 به نتایج خوبی رسیدیم و اولین کارگاه معماری سرویس گرا در کنفرانس انجمن کامپیوتر ایران ارائه شده (لینک فیلم کارگاه)، در سال های بعد نیز همه تلاشم بر گسترش و فهم درست این سبک معماری در ایران بود، ده ها کارگاه و دوره آموزشی برگزار و تجارب خوبی در چندین شرکت و سازمان حاصل شد. حال که بعد از 5 – 6 سال می بینم تلاشهای من و سایر صاحب نظران حوزه معماری سرویس گرا نتیجه داده و جزو الزامات هر پروژه بزرگ نرم افزاری (سازمانی) شده و همه جا صحبت آن است، قاعدتا احساس رضایت میکنم. اما …
اما متاسفانه جنبه منفی این همه گیر شدن ، ورود غیرکارشناسان و دلالان به این حوزه تخصصی است. متاسفانه همه گیرشدن و محبوب شدن یک راهکار یا فناوری، فرصتی برای سودجویان است تا بدون دانش دقیق و تجربه کافی وارد آن حوزه شده و سازمان ها را به بیراهه بکشانند. معماری سرویس گرا نه یک تکنیک طراحی و برنامه نویسی مانند OOP است، نه متدولوژی توسعه مانند RUP ، نه پلتفرم توسعه مانند Net. ، نه نماد مدلسازی مانند BPMN، نه پروتکل و استاندارد مانند SOAP، نه یک نظام مدیریت سرویس مانند ITIL ،… بلکه یک سبک معماری فناوری اطلاعات ( و بلکه سازمان) است که مانند چتری همه موارد گفته شده را در برمیگیرد. تسلط بر چنین مفهوم گسترده و چند بعدی به سالها مطالعه سنگین و تمرین و تجربه های تخصصی نیاز دارد.
شاید هر کسی به راحتی بتواند از مزایا و مطلوبیت معماری سرویس گرا (به نسبت سایر رویکردها) سخن گوید، اما مشاوره دادن و مسیر راه مشخص کردن برای سازمان ها کار هر کسی نیست! به عنوان مثال شاید هر کسی بتواند بگوید کت وشلوار لباس مناسب مجالس رسمی است، اما دوختن کت و شلوار کار هر کسی نیست! معماری سرویس گرا نیز باید متناسب با شرایط سازمان و نیاز آن دوخته و بر تن سازمان نشانده شود. بدین منظور باید 1- نوع نیاز کاری سازمان که منجر به سرویس گرایی شده 2- بلوغ و آمادگی سازمان برای سرویس گرا 3- نوع الگو و تکنیک مناسب 4 – پلتفرم و ابزار مناسب توسعه 5- استراتژی پیاده سازی و گذار 6- ریسک ها و تهدیدها 7- لایه بندی و چگونگی توزیع سرویس ها 8- نظام حاکمیت سرویس گرا و بسیاری از عوامل دیگر دقیقا تحلیل شده و سپس راهکار و مسیر مناسب به سازمان پیشنهاد شود تا منجر به موفقیت کامل معماری سرویس گرا شود.
همانطور که گفته شد، متاسفانه اکنون این حوزه دچار آسیب جدی شده بگونه ای که همه مشاوران و شرکتهای پیمانکار نرم افزاری ، یک شبه صاحب نظر حوزه سرویس گرایی شده اند! چه نسخه ها که نمی پیچند! و چه تصورات عجیبی که از معماری سرویس گرا ندارند! در این شرایط از سازمان های بزرگ و وزراتخانه ها گرفته تا شرکت های صنعتی و خدماتی، بسیاری به این توصیه های غیرکارشناسی عمل کرده و مسیر غلط(یا پردردسری) را برای رسیدن به هدف مطلوب سرویس گرایی انتخاب کرده اند، حال آنکه یا به خاطر مسیر غلط به آن نمیرسند و یا اگر هم برسند چیزی که خواهند یافت نه "معماری چابک و انعطاف پذیر سرویس گرا" بلکه تنها اسم و ظاهری از فناوری و ابزارهای آن است!. مدیران فاوا سازمان ها و شرکت ها بخاطر تعریف و تمجیدی که از سرویس گرایی شنیده و گسترش همه جانبه فناوری و ابزارهای سرویس گرا به غلط فکر میکنند مشاوره و نظر هر فرد(شرکتی) آن ها را به اهداف مطلوب سرویس گرایی خواهد رساند!
در اینجا میخواهم اعلام کنم که اگر 6 – 7 سال گذشته را صرف ترویج و گسترش مفاهیم سرویس گرایی کردم، هدف و برنامه جدیدم برای امسال و سال های آتی، شناساندن تفاوت معماری سرویس گرا واقعی از غیرواقعی و تحقق(پیاده سازی و عملیاتی شدن) درجات بلوغ بالای آن در سازمان ها است.
در همین راستا آزمایشگاه مرجع معماری سازمانی سرویس گرا، با توجه به نیاز موجود در کشور برای فراگیری و بکارگیری نظام مند رویکرد معماری سازمانی مبتنی بر سرویس با همکاری مشترک میان سازمان فناوری اطلاعات ایران و دانشگاه شهید بهشتی به عنوان قطب معماری فناوری اطلاعات کشور راه اندازی گردیده است. یکی از اهداف این آزمایشگاه، ارائه مجموعه راهنماها، استانداردها، اسناد فنی و تکنیک های پیاده سازی در حوزه معماری سازمانی سرویس گرا در قالب نهاد مرجع در کشور بوده است.
خروجی ها و اسناد بدست آمده در آزمایشگاه شامل بیش از 30 سند فنی و کاربردی است که بخشی از آنها برای استفاده اعضا در سایت قرار داده شده است، همچنین پروژه های عملی نیز بر اساس نگاه معماری با موفقیت به انجام رسیده است. ماحصل تجارب و دانش بدست آمده در قالب مجموعه ای از خدمات بر اساس تفاهم نامه منعقد شده بین سازمان فناوری اطلاعات با دانشگاه شهید بهشتی به سازمان های دولتی و شرکت های خصوصی که متقاضی فعالیت در حوزه معماری سازمانی و سرویس گرا هستند، ارائه می گردد
رابطه بین BPM ، SOA و EA
معماری سرویس گرا رابطه تنگاتنگی با رهیافتهای معماری سازمانی (EA) و مدیریت فرایندهای حرفه (BPM) دارد. بررسی ارتباط و چگونگی تعامل این رهیافت ها می تواند موضوع جالبی برای پایان نامه ها و تحقیقات علمی باشد. اخیرا نیز پایان نامه های متعددی در دنیا به این موضوع اختصاص داده شده است که نتایج تحقیقات برخی از آنها بر روی وبلاگ منتشر می شود.
در فضای کاری و پروژه های اجرائی نیز ارتباط بین این سه رهیافت مطرح بوده و هست:
در این راستا برخی سازمانها، پروژه های تلفیقی تعریف و اجرا می کنند که معماری سازمانی را با BPM همراه نموده تا بتوانند از مدل های معماری در پروژه BPM استفاده کنند.
برخی دیگر شرکت ها نیز معماری سازمانی را با SOA همراه کرده اند و می خواهند در طی فرایند معماری سازمانی، مدل های مرتبط با سرویس های حرفه شناسائی و استخراج شوند تا در مرحله بعد، این مدل ها توسط پروژه های SOA به سرویس های سیستمی تبدیل شده و سیستم های سرویس گرا طراحی شوند، جالب اینکه پروژه های تحت عنوان معماری سازمانی سرویس گرا کم کم دارند جای پروژه های کلاسیک معماری سازمانی را می گیرند.
حالت ترکیب BPM و SOA به مراتب مرسوم تر بوده و زمینه های زیادی برای یکپارچگی دارند، اکثر سیستم های مدیریت فرایندهای کسب و کار(BPMS) که در دنیا رایج هستند از فناوری های مبتنی بر معماری سرویس گرا استفاده می کنند و از طرف دیگر محیط های یکپارچه طراحی و پیاده سازی سرویس گرا (Oracle SOA Suite, Microsoft BizTalk Server, IBM WebSphere) جایگاه ویژه ای برای BPM در نظر گرفته اند.
در جمع بندی باید به این نکته اشاره کرد که دامنه کاربرد و جایگاه سه رهیافت EA، BPM و SOA دارای نقاط مشترک فراوانی است و می تواند منشاء بهبود و تکامل هر یک از این رهیافت ها باشد. شرکت ها و سازمانها نیز بصورت غیر رسمی(برنامه ریزی نشده) به تلفیق این رهیافت ها علاقه مند شده اند، لذا متخصصان این حوزه ها باید مطالعات و تمرینهای بیشتری بر روی نقاط اشتراک و چگونگی تلفیق این رهیافت ها انجام دهند.

منابع
M.J. Carey, SOA what?, Computer, 41 (2008) 92-94.
D.K. Barry, Web services and service-oriented architecture: the savvy manager's guide, Morgan Kaufmann Pub, 2003.
S. Khoshafian, Service oriented enterprises, Auerbach Publications, 2006.
Y. Vasiliev, SOA and WS-BPEL: Composing Service-Oriented Architecture Solutions with PHP and Open-Source ActiveBPEL, in, Birmingham, UK: Packet Publishing, 2007.
D.A. Chappell, Chappell & Associates, Introducing BizTalk Server 2006 R2, Microsoft,, (2007).
G.A. Lewis, E. Morris, S. Simanta, L. Wrage, Effects of service‐oriented architecture on software development lifecycle activities, Software Process: Improvement and Practice, 13 (2008) 135-144

مدیریت فرآیند کسب و کار و معماری سرویس گرا

1