قابلیت rest و soap

معماری سرویس‌گرا

BPMS شبکه فردا به طور کامل از مکانیزم rest و soap برای در اختیار قراردادن سرویس و یا فراخوانی سرویس ها پشتیبانی می کند.

صفحه قابلیت سرویس ها

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

قابلیت نشانه گذاری
قابلیت نشانه گذاری به این دیدگاه بر می گردد که باید قادر باشد فعالیت سرویس ها را در بسیاری از روش ها به منظور رسیدن به نیازهای کاربردی و غیرکاربردی نشانه گذاری کند. از این نظر است که سرویس ها را به چیزی پر معناتر در SOA ارتقا می دهد. اگر شما از SOAP استفاده می کنید، یک گستره ای از ws-specification ها (مانند ws-Reliable Messaging یا ws-SecureConversation) به توانایی های سرویس شما اضافه می شود که روی هسته عملیاتی کسب و کار تاثیر گذار نیست. اما سرویس شما را برای استفاده در SOA قابل تطابق میسازد. برای مثال توانایی اضافه کردن هدرهای HTTP، یک روش از نشانه گذاری اجرای سرویس REST-based می باشد.

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

قابلیت سرویس ها

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

قابلیت معماری سرویس ها

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

 

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