معماری سرویس‌گرا؛ راه حلی برای یکپارچه سازی زنجیره تامین

نویسندگان: مهدی سرابی – کاظم جعفری

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

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

نتیجه گیری
معماری سرویس‌گرا می‌تواند راهکاری برای داشتن سیستم‌های چابک؛ استفاده مجدد؛ غلبه بر غیر‌یکنواختی و گستردگی سیستم‌های زنجیره تامین و کاهش هزینه توسعه برنامه‌های کاربردی باشد به گونه‌ای که زنجیره تامین را قادر می‌سازد تا به سرعت سیستم‌های خود را تغییر دهد. این چابکی به جهت کارکردهای سیستم و ارتقاء پلتفرم‌ها است. قابلیت ترکیب سرویس‌ها در معماری سرویس‌گرا امکان استفاده مجدد از سرویس‌های فرایندی و پایه را فراهم می‌سازد به عبارت دیگر امکان استفاده مجدد از کارکردها و داده‌ها فرآهم می‌گردد. می‌توان گفت یکپارچگی آسان با شرکای داخلی و خارجی یکی از نکات کلیدی است که معماری سرویس‌گرا به آن پرداخته است. توسعه معماری سرویس‌گرا مجموع هزینه صرف شده برای فناوری اطلاعات و سرویس‌های کسب و کار را به دو روش کاهش می‌دهد. اول با حذف هزینه‌های میان افزارها و فناوری‌های اختصاصی و جایگزین کردن آن با فناوری‌های استاندارد مانند وب سرویس و دوم با ترکیب کارکردهای کسب و کار در قالب سرویس‌هایی که توسط واحدهای مختلف قابل ارائه و استفاده باشند.

منابع

Iranian Information Architecture committee
httpwww.esosa.ir
Brown, Alan, Johnston, Simon, Kelly, Kevin. Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications, Rational Software Corporation, 2002.
Manes, A.T. 2003, Web Services Manager’s Guide, Addison-Wesley.
Chatterjee, Sandeep and Webber, 2004, Developing Enterprise Web Services An Architect’s Guide, Upper Saddle River, Prentice Hall.
Linthicum, D. 2004, What Level Is Your SOA Choose for what you need and maybe a little better, Available httpwebservices.sys-con.comread47277.htm

منبع: صنعت خودرو، ویژه نامه زنجیره تأمین ، نسخه شماره 16 – تاریخ 02 /10/ 1388
تهیه و تنظیم: پایگاه مقالات علمی مدیریت  www.SYSTEM.parsiblog.com