دانلود تحقیق احداث سلف سرویس کارکنان شرکت ملی پتروشیمی ایران مستقر در عسلویه بوشهر

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

فرمت فایل : word(قابل ویرایش)

تعداد صفحات:18

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

دانلود مقاله در مورد وب سرویس چیست؟

اختصاصی از یارا فایل دانلود مقاله در مورد وب سرویس چیست؟ دانلود با لینک مستقیم و پرسرعت .

فرمت فایل :docx(قابل ویرایش)

تعداد صفحات:15

چکیده:

کسانی که با صنعت IT آشنایی دارند حتما ً نام وب سرویس را شنیده اند . برای مثال ، بیش از 66 درصد کسانی که در نظر سنجی مجله InfoWorld شرکت کرده بودند بر این توافق داشتند که وب سرویس ها مدل تجاری بعدی اینترنت خواهند بود . به علاوه گروه گارتنر پیش بینی کرده است که وب سرویس ها کارآیی پروژه های IT را تا 30 در صد بالا می برد . اما وب سرویس چیست و چگونه شکل تجارت را در اینترنت تغییر خواهد داد ؟

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

وب سرویس هر توع کاری می تواند انجام دهد . برای مثال در یک برنامه می تواند آخرین عنوان های اخبار را از وب سرویس Associated Press بگیرد یا یک برنامه مالی می تواند آخرین اخبار و اطلاعات بورس را از وب سرویس بگیرد . کاری که وب سرویس انجام می دهد می تواند به سادگی ضرب 2 عدد یا به پیچیدگی انجام کلیه امور مشترکین یک شرکت باشد .

وب سرویس دارای خواصی است که آن را از دیگر تکنولوژی و مدل های کامپیوتری جدا می کند ، Paul Flessner ، نایب رییس مایکروسافت در dot NET Enterprise Server چندین مشخصه برای وب سرویس در یکی از نوشته هایش ذکر کرده است ، یک ، وب سرویس ها قابل برنامه ریزی هستند . یک وب سرویس کاری که می کند را در خود مخفی نگه می دارد وقتی برنامه ای به آن اطلاعات داد وب سرویس آن را پردازش می کند و در جواب آن اطلاعاتی را به برنامه اصلی بر می گرداند . دوم ، وب سرویس ها بر پایه XML بنا نهاده شده اند . XML
و XML های مبتنی بر SOAP یا Simple Object Access Protocol تکنولوژی هایی هستند که به وب سرویس این امکان را می دهند که با دیگر برنامه ها ارتباط داشته باشد حتی اگر آن برنامه ها در زبانهای مختلف نوشته شده و بر روی سیستم عامل های مختلفی در حال اجرا باشند . همچین وب سرویس ها خود ، خود را توصیف می کنند . به این معنی که کاری را که انجام می دهند و نحوه استفاده از خودشان را توضیح می دهند . این توضیحات به طور کلی در WSDL یا Web Services Description Language نوشته می شود . WSDL یک استاندارد بر مبنای XML است . به علاوه وب سرویس ها قابل شناسایی هستند به این معنی که یرنامه نویس می تواند به دنبال وب سرویس مورد علاقه در دایرکتوری هایی مثل UDDI یا Universal Description , Discovery and Integration جستجو کند . UDDI یکی دیگر از استاندارد های وب سرویس است .


نکات تکنولوژی وب سرویس :
همانطور که در ابتدا توضیح داده شد یکی از دلایل اینکه وب سرویس از دیگر تکنولوژی های موجود مجزا شده است استفاده از XML و بعضی استاندارد های تکنیکی دیگر مانند SOAP ، WSDL و UDDI است . این تکنولوژی های زمینه ارتباط بین برنامه ها را ایجاد می کند به شکلی که مستقل از زبان برنامه نویسی ، سیستم عامل و سخت افزار است .
SOAP یک مکانیزم ارتباطی را بین نرم افزار و وب سرویس ایجاد می کند . WSDL
یک روش یکتا برای توصیف وب سرویس ایجاد می کند و UDDI یک دایرکتوری قابل جستجو برای وب سرویس می سازد . وقتی اینها با هم در یک جا جمع می شود این تکنولوژی ها به برنامه نویس ها اجازه می دهد که برنامه های خود را به عنوان سرویس آماده کنند و بر روی اینترنت قرار دهند .

شکل زیر نقش هر کدام از استاندارد ها را در ساختار وب سرویس نمایش می دهد . در قسمت های بعدی هر کدام از این تکنولوژی ها را بررسی می کنیم .

پایان نامه برسی معماری سرویس گرا

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

فرمت:word(قابل ویرایش)

تعداد صفحات:124

فهرست مطالب :

• پیش گفتار
• چکیده
• فصل 1: معرفی معماری سرویس گرا
• 1-1 مقدمه
• 1-1-1- معماری سرویس گرا چیست؟
• 1-1-2- ویژگی های سیستم های مبتنی بر معماری سرویس گرا
• 1-1-3- آماده شدن برای معماری سرویس گرا
• 1-2 معرفی
• 1-3- ویژگیهای سرویس و محاسبات سرویس گرا
• 1-4- نرم افزار به عنوان سرویس
• 1-6- معماری سرویس گرای مقدماتی
• 1-6- 1 معماری سرویس گرای توسعه یافته
• 1-7- نیازمندیهای معماری سرویس گرا
• فصل دوم: معماری سرویس گرا (SOA)
• 2-1 مقدمه
• 2-2- محرکهای تجاری در رویکردی جدید
• 2-3- معماری سرویس گرا بعنوان یک راه حل
• 2-3-1- تجزیه و تحلیل و طراحی شی ء گرا
• 2-3-2- طراحی بر مبنای جزء
• 2-3-3 – طراحی سرویس گرا
• 2-3-4- طراحی بر مبنای واسط
• 2-3-5- معماری های برنامه های کاربردی لایه ای
• 2-4- نگاهی دقیق تر به معماری سرویس گرا
• 2-4-1- جنبه های عملکردی عبارتند از
• 2-4-2- جنبه های کیفیت خدمات عبارتند از
• 2-4-3 همکاری SOA
• 2-4-4- نقش ها در معماری سرویس گرا عبارتند از
• 2-4-5- عملیات در معماری سرویس گرا عبارتست از
• 2-4-6- سرویس ها در بافت SOA
• 2-4-7- سرویس ها در برابر اجزاء
• 2-5- مزایای معماری سرویس گرا
• 2-5-1- بالا بردن دارایی های موجود
• 2-5-2- مجتمع سازی و اداره کردن راحت تر پیچیدگی
• 2-5-3- پاسخ گویی بیشتر و خرید و فروش سریعتر
• 2-5-4- کاهش هزینه و افزایش استفاده مجدد
• 2-5-5- آمادگی در برابر حوادث
• فصل سوم: معماری سرویس وب
• 3-1 مقدمه
• 3-2- سرویس وب چیست؟
• 3-3- مدل چند لایه مبتنی بر Xml-Web Service
• 3-2-1- برخی از ویژگیهای اصلی سرویس وب عبارتند از
• 3-4- قابلیت عملکرد متقابل سرویس وب
• 3-3-2 گزارش مبنای WS-I 1.0
• فصل چهارم: انتخاب های تکنولوژی
• 4-1- انتخابهای تکنولوژی
• 4-2 مقدمه
• 4-2-1- مزایای سرویس وب
• 4-4-2- معایب سرویس وب
• 4-3- لایه های پشته معماری سرویس گرا
• 4-3-1 حمل و نقل
• 4-3-2- پروتکل تبادل سرویس
• 3-3-4 شرح سرویس
• 4-3-4 سرویس
• 4-3-5 فرآیند تجاری
• 4-3-6 بایگانی سرویس
• 4-3-7 سیاست
• 4-3-8 امنیت
• 4-3-9 معاملات
• 4-3-10 مدیریت
• خلاصه
• نتیجه گیری
• مراجع

چکیده:

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

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

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

در جهان امروز طیف مخاطبانی که بالقوه می توانند از سرویس شما استفاده کنند، کل کاربران روی شبکه اینترنت است. بنابراین باید مکانیزمی بوجود می آمد، که می توانست پاسخگوی این محیط جدید (اینترنت) و کاربران آن باشد و بنابراین معماری سرویس گرا بوجود آمد. این معماری توسط دو شرکت IBM ، Microsoft بوجود آمد، که هر دو شرکت طی سالهای اخیر از حامیان اصلی سرویسهای وب و عامل بسیاری از ابداعات جدید در حیطه سرویس های وب، مانند WSE ، UDDI بوده اند. قابل ذکر است، که در آخرین معماری در حال توسعه، در تولید نرم افزار که هنوز هم در مرحله تحقیقاتی است (MDA) ، تدابیری جهت هماهنگی با معماری سرویس گرا در نظر گرفته شده است.

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

    معماری سرویس گرا چیست؟

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

البته معماری های مذکور اشکالات دیگری هم داشتند که نسبت به موارد بالا از اهمیت کمتری برخوردار است که از جمله آنها می توان به عدم هماهنگی با اصول امنیتی مورد استفاده در اینترنت اشاره کرد. البته بعدها راه حل هایی هم برای این مشکل بوجود آمد (مانند Over HTTP RPC ) اما به این علت که از روز اول، در طراحی این تکنولوژی ها این امر در نظر گرفته نشده بود، از کارایی مناسبی برخوردار نبودند. مفهوم همبستگی زیاد و در عین حال با چسبندگی و اتصال کم، وقتی بخواهد در جهت ارزیابی یک سیستم نرم افزاری یا تکنولوژی، مورد استفاده قرار گیرد بسیار مبهم می شود. حتی کسی می تواند ایده های همبستگی و چسبندگی را با هم ترکیب کند! برای جلوگیری از چنین ابهاماتی، شما می توانید از ویژگی های معماری سرویس گرا به عنوان یک راه برای ارزیابی میزان همبستگی و چسبندگی و اتصال یک سیستم نرم افزاری یا یک تکنولوژی استفاده کنید. اگر چه مفاهیم مطرح شده در معماری سرویس گرا دقیقاً همان مفاهیم همبستگی زیاد و در عین حال چسبندگی کم نیستند، اما سیستمهایی که بر اساس معماری سرویس گرا طراحی و پیاده سازی شده اند، نشان داده اند که توانسته اند تا حد بسیار زیادی ویژگی های همبستگی زیاد و در عین حال چسبندگی کم را بخوبی در خود ایجاد و حفظ کنند.

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

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

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

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

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

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

 

پایان نامه شرکت خدمات سرویس های اینترنت ISP « INTERNET SERVICE PROVIDER

اختصاصی از یارا فایل پایان نامه شرکت خدمات سرویس های اینترنت ISP « INTERNET SERVICE PROVIDER دانلود با لینک مستقیم و پرسرعت .

فرمت:word(قابل ویرایش)

تعداد صفحات:48

فهرست مطالب

• آشنایی با عملکرد و کاربردهای یک ISP
• مفهوم شبکه
• مفهوم مدیا
• انواع شبکه
• LAN . 1
• CAN . 2
• MAN . 3
• WAN . 4
• تعریف ISP
• معرفی اجزای تشکیل دهنده‌ یک ISP
• ۱٫            ارتباط با شبکه های جهانی اینترنت
• ۲٫            ارتباطات داخلی سیستم های مدیریت و کنترل کاربران
• ۳٫            ارتباط کاربران با شبکه (Dial Access Networking)
• ۴٫            فیلترها
• تعریف روتر
• تعریف سوئیچ
• Access Router . 1
• Accounting Server . 2
• DHCP Server . 3
• DNS Server . 4
• Cache Server . 5
• تعریف انواع فیلتر
• ۱٫            فیلترهای سخت افزاری
• ۲٫            فیلترهای نرم افزاری
• ۳٫            Proxy Server
• اینترنت
• آرپانت (ARPANET)
• NSFNET
• کاربردهای اینترنت
• معماری اینترنت
• شبکه های اتصال گرا : ATM , Frame Relay, X.25
• Frame Relay , X.25
• حالت انتقال آسنکرون (ATM)
• مدار مجازی ATM
• مدل مرجع ATM
• سوئیچینگ
• سوئیچینگ مداری
• سوئیچینگ پیام
• سوئیچینگ بسته ای

چکیده:

به دلیل شباهت ها و تداخل وظایف زیادی که بین شرکت های مخابرات و شرکت های ارائه دهنده خدمات اینترنت یا همان ISP که مخفف INTERNET SERVICE PROVIDER می باشد، وجود دارد، امروزه اوضاع بسیار درهم و مغشوش است و به سختی می ‎توان گفت کی چکاره است ؟  بهترین نقطه برای شروع خانه مشتری (client) است. در اینجا فرض را بر این گذاشته ایم که مشتری با استفاده از یک مودم و خط تلفن به ISP متصل می ‎شود. مودم وسیله ایست که سیگنال های دیجیتالی کامپیوتر را به سیگنال های آنالوگ تبدیل می کند، تا این سیگنال ها بتوانند بدون اعوجاج روی خطوط تلفن منتقل شوند. این سیگنال ها در نطقه تماس ISP (که به Point Of Presence – POP معروف است) مجدداً تبدیل به سیگنال های دیجیتال شده، و وارد شبکه منطقه ای ISP می ‎شود. از این نقطه به بعد سیستم کاملاً دیجیتال است و بر مبنای سوئیچ بسته کار می کند. اگر این ISP همان شرکت مخابرات باشد POP در مرکز سوئیچینگ تلفن واقع خواهد بود، اما اگر ISP و شرکت مخابرات یکی نباشند POP یک مرکز سوئیچینگ کوچک بین راهی خواهد بود که از آنجا به شبکه تلفن وصل می ‎شود. شبکه منطقه ای ISP از چند مسیریاب که به شهرهای مختلف تحت پوشش آن ISP سرویس می دهند تشکیل می ‎شود. اگر مقصد بسته ارسال شده از مشتری یکی از کامپیوترهای واقع در همان شبکه منطقه ای ISP باشد بلافاصله به آن تحویل داده می ‎شود. ولی اگر چنین نباشد بسته به اپراتور ستون فقرات ISP داده خواهد شد.

اینترنت

اینترنت در واقع اصلا یک شبکه نیست، بلکه مجموعه ایست از شبکه های مختلف که از پروتکلهای خاصی استفاده کرده، و سرویسهای مشخصی را ارائه می‌کند. ویژگی غیرعادی اینترنت اینست که توسط فرد خاصی طراحی نشده، و هیچکس هم آنرا کنترل نمی کند. برای درک بهتر این مطلب، اجازه دهید ببینیم اینترنت از کجا شروع شد، و علت آن چه بود. یکی از جالبترین تاریخچه های اینترنت را می توانید در کتاب جان نافتون- 2000- ببینید. این کتاب نه تنها برای افراد عادی، بلکه برای مورخان نیز جالب است، برخی از مطالب ذیل از این کتاب اقتباس شده است. البته کتابهای فنی بیشماری نیز درباره اینترنت و پروتکلهای آن نوشته شده، که از آن میان می‎توان به
(Maufer, 1999) اشاره کرد.

 آرپانت (ARPANET)

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

در سال 1960 وزارت دفاع قراردادی را با شرکت راند امضاء کرد که در ان وظیفه یافتن یک راه حل به آن محول شده بود. یکی از متخصصان این شرکت، بنام پل بارن طرح یک شبکه توزیع شده (distributed) و تحمل پذیر خطا (fault- tolerant) را پیشنهاد کرد، که آنرا در شکل (ب) می بینید. از آنجائیکه در این شبکه طول مسیر بین مراکز سوئیچینگ طولانیتر از آن بود که بتوان از سیگنالهای آنالوگ استفاده کرد، بارن پیشنهاد کرد در این سیستم از تکنولوژی سوئیچینگ بسته دیجیتالی (digital packet- switching) استفاده شود. بارن گزارشات متعددی برای وزارت دفاع نوشت، و جزئیات سیستم پیشنهادی خود را تشریح کرد. مقامات رسمی پنتاگون به ایده نهفته در این سیستم علاقمند شدند و از AT&T (که در آن زمان انحصار شبکه تلفن کشوری را در دست داشت) خواستند که یک نمونه اولیه از آن بسازد. AT&T طرح بارن را رد‌ کرد. بزرگترین و ثروتمندترین شرکت دنیا تحمل نمی کرد که یک جوان تازه از راه رسیده به آنها بگوید چگونه شبکه تلفن بسازند! آنها ادعا کردند که طرح بارن قابل اجرا نیست و بدین ترتیب ایده آن را در نطفه خفه کردند.

سالها گذشت، و وزارت دفاع همچنان به دنبال سیستم فرماندهی و کنترل ایده آل خود بود. برای درک بهتر اتفاقات بعدی،‌ باید کمی به عقب برگردیم: به اکتبر 1957، زمانی که اتحاد جماهیر شوروی (سابق) با پرتاب اولین قمر مصنوعی به نام اسپوتنیک در مسابقه فضایی از ایالات متحده پیشی گرفت. آیزنهاور، رئیس جمهور وقت ایالات متحده در جستجو برای یافتن علت عقب افتادگی کشورش با وحشت دریافت که نیروهای زمینی، دریایی و هوایی آمریکا مشغول دعوا بر سر تقسیم بودجه تحقیقاتی پنتاگون هستند. وی بلافاصله تصمیم گرفت که یک مرکز واحد برای تحقیقات نظامی بوجود آورد، مرکزی که آرپا (آژانس پروژه‌های تحقیقاتی پیشرفته Advanced Research Projects Agency- ARPA نام گرفت. آرپا هیچ دانشمند یا آزمایشگاهی نداشت در واقع آرپا چیزی نبود جز یک دفتر هماهنگی کوچک با بودجه ای ناچیز (البته با معیارهای پنتاگون). آرپا کارش را با عقد قرارداد یا واگذاری امتیاز به شرکتها یا دانشگاه هایی که ایده های جالبی داشتند، انجام می داد.

پایان نامه ارائه روشی برای طراحی مبتنی بر سرویس

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

فرمت:word(قابل ویرایش)

تعداد صفحات:243

پایان نامه جهت دریافت درجه کارشناسی ارشد “M.Sc” مهندسی کامپیوتر- نرم افزار

فهرست مطالب

چکیده    1
مقدمه    2
فصل اول: کلیات معماری سرویس گرا   
1-1) تعاریف اولیه    5
1-1-1) سبک معماری مبتنی بر سرویس    5
2-1) اهداف تحقیق    7
3-1) پیشینه تحقیق    8
4-1) روش کار و تحقیق    10
5-1) مقایسه ای بر مدلهای توسعه وابسته به معماری    11
1-5-1) توسعه مبتنی بر object    11
2-5-1) توسعه مبتنی بر مؤلفه    12
3-5-1) محاسبات توزیع یافته    13
4-5-1) معماری سرویس گرا    14
1-4-5-1) توسعه مبتنی بر سرویس    15
2-4-5-1) قابلیتهای معماری سرویس گرا    17
6-1) مؤلفه های SOA    18
7-1) اصول سرویس گرائی
21
8-1) سرویس گرائی و تشکیلات سازمانی    27
1-8-1) لایه های سرویس      29
1-1-8-1) لایه سرویس کاربردی    32
2-1-8-1) لایه سرویس تجاری    34
3-1-8-1) لایه سرویس همنوائی    34
2-8-1) سرویسهای Agnostic    37

فصل دوم : تحلیل مبتنی بر سرویس   
1-2) چرخه حیات معماری سرویس گرا    40
2-2) استراتژیهای تحویل SOA    41
1-2-2) روش پایین به بالا    41
2-2-2) روش بالا به پایین    43
3-2-2) روش Meet-In-The-Middle      45
3-2) تحلیل سرویس گرا    47
1-3-2) اهداف تحلیل سرویس گرا    47
2-3-2) پروسه تحلیل سرویس گرا    48

فصل سوم : الگوها و اصول طراحی   
1-3) نکات قابل توجه طراحی    52
1-1-3) مدیریت دانه بندی سرویس و مؤلفه    52
2-1-3) طراحی برای قابلیت استفاده مجدد    53
3-1-3) طراحی برای قابلیت ترکیب سرویس    54
1-3-1-3) اتصال و همبستگی
54
2-3) رهنمودهای عمومی    55
1-2-3) استانداردهای نامگذاری 55
2-2-3) طراحی عملیات سرویس به شکلی که ذاتا قابل توسعه باشد    56
3-2-3) تعیین متقاضیان مطرح سرویس    56
3-3) الگوهای طراحی و انواع معماری    57
1-3-3) الگوها    58
2-3-3) طراحی بنیادی    59

فصل چهارم : راهکار پیشنهادی   
1-4) مرحله 1 بازبینی لایه بندی سیستم SOA    64
1-1-4) فعالیت 1 مروری بر استراتژیهای لایه بندی    64
2-1-4) فعالیت 2 بازبینی لایه بندی فاز تحلیل    66
3-1-4) فعالیت 3 معرفی لایه های تخصصی تر    67
1-3-1-4) لایه داده    67
2-3-1-4) لایه دسترسی سرویس    70
3-3-1-4) لایه تعامل 71
2-4) مرحله 2 تحلیل تغییرپذیری    77
1-2-4) فعالیت 1 شناسایی انواع تغییرپذیری    79
2-2-4) فعالیت 2 مدلهای موجود برای تغییرپذیری    83
3-2-4) فعالیت 3 گروهبندی و مدلسازی تغییرپذیری    84
4-2-4) فعالیت 4 نگاشت نقاط تغییرپذیر    87
3-4) مرحله 3 سرویسهای فاز طراحی
89
1-3-4) فعالیت 1 تعیین سرویسها    90
2-3-4) فعالیت 2 جایگاه سرویسهای کنترلی    98
4-4) مرحله 4 مروری بر دانه بندی 99
1-4-4) فعالیت 1 تکنیک دانه بندی سرویسها و چنددانه ای بودن    102
2-4-4) فعالیت 2 متدهای چند دانه ای سرویسها    104
5-4) مرحله 5 مدلسازی فرایند 108
1-5-4) استفاده از مدلسازی فرایند برای طراحی معماری سرویس گرا 108
2-5-4) ابزار مدلسازی فرایند    109
3-5-4) فعالیت طراحی فرایند کسب و کار مبتنی بر سرویس    113

فصل پنجم : بررسی موردی   
1-5) انتخاب بررسی موردی    115
1-5) سیستم سفارش کالا    116
3-5) تحلیلی بر راهکار پیشنهادی    134

فصل ششم : نتیجه گیری و پیشنهادات     
1-6) نتیجه گیری    136
2-6) پیشنهادات    138
مقاله    139
پیوستها    140
منابع و ماخذ   
فهرست منابع فارسی    196
فهرست منابع لاتین    197
سایتهای اطلاع رسانی    200
اختصارات    201
چکیده انگلیسی    202

فهرست شکلها

شکل 1-1) میان افزار مبتنی بر پیغام[24]    14
شکل 2-1) مدل مفهومی معماری سرویس گرا[24]    15
شکل 3-1) توسعه مبتنی بر سرویس[24]    16
شکل 4-1) یک دیدگاه اولیه از چگونگی قرار گرفتن منطق خودکارسازی در داخل واحدها توسط    SOA    20
شکل 5-1) عملیاتهایی که به سرویسهای متفاوتی تعلق دارند و بخشهای متنوعی از منطق پروسه را نمایش می دهند.    20
شکل 6-1) چگونه مؤلفه های یک معماری سرویس گرا با یکدیگر ارتباط دارند.    21
شکل 7-1) پیمانهای سرویس به طور رسمی مؤلفه های سرویس, عملیات و پیغام از یک معماری سرویس گرا را تعریف می کند.    23
شکل 8-1) سرویسها وابستگی ها را به قرارداد سرویس محدود می کنند و با این کار به  منطق سرویس دهنده زیرین و تقاضاکننده اجازه می دهند که loosely coupled باقی بمانند.    24
شکل 9-1) عملیات Update Everything یک ترکیب سرویس را بسته بندی می کند 25
شکل 10-1) مراحل statelessو stateful که یک سرویس درهنگام پردازش یک پیغام از آنها عبور می کند .    27
شکل 11-1) جایگاه سرویسها[1]    28
شکل 12-1) لایه های تخصصی سرویس[1]    32
شکل 13-1) سلسله مراتب چرخه حیات توسعه سرویسهای وب[9]    36
شکل 14-1) بخش بندی سرویسها که محیط راه حل  و پردازشهای تجاری را تفکیک کرده است[1].    38
شکل 1-2) چرخه حیات معماری سرویس گرا          40
شکل 2-2) گامهای تکنیک پائین به بالا    42
شکل 3-2) گامهای تکنیک بالا به پائین    44
شکل 4-2) گامهای تکنیک  meet in the middle [1]    46
شکل 1-3) در صورت تجزیه یک سرویس , الگوهای نظارتی به عدم تاثیرگذاری در قرارداد سرویس کمک می کنند.[27]   
59
شکل 2-3) منطق  Agnostic و [27] Non Agnostic    60
شکل 1-4) فعالیتهای فاز طراحی   
63
شکل 2-4) مدل گسترش سیستم تحت تاثیر لایه بندی [30]    65
شکل 3-4) پنهان سازی پیچیدگی توسط لایه انتزاعی داده    69
شکل 4-4) لایه دسترسی سرویس[2]    70
شکل 5-4) ساختار منطقی از سرویسهای تعاملی    73
شکل 6-4) مثالهایی از سرویس تعاملی در SOA
76
شکل 7-4) چارچوب مبتنی بر سرویس برای سرویسهای تعاملی    76
شکل 8-4) 4 نو ع تغییرپذیری    80
شکل 9-4) واسط مورد نیاز فرایند کسب و کار    81
شکل 10-4) نقاط تغییرپذیر ممکن    82
شکل 11-4) شمایی از تغییرپذیری در XML [6]    83
شکل 12-4) مدل تصمیم , مدل واسطی برای سازگاری سرویسها می باشد[6]    84
شکل 13-4) دیاگرام فعالیت و نقاط تغییر پذیر[31]    85
شکل 14-4) مدل خصیصه[31]    86
شکل 15-4) سرویسهای Gateway [2]    92
شکل 16-4) سرویسهای Façade [2]    93
شکل 17-4) جایگاه دستورات کنترلی درمقایسه دو راه حل [2]    96
شکل 18-4) سرویسهای دانه درشت[11]    101
شکل 19-4) ارتباط سرویس دانه درشت و سرویس دانه ریز[11]    103
شکل 20-4) متد جدیدی برای ارسال اطلاعات آدرس اضافه شده است.[11]    105
شکل 21-4) یک متدی که هر دو نوع اطلاعات آدرس و حساب را بر می گرداند.[11]    105
شکل 22-4) متدی که مؤلفه های درخواست داده شده را برمی گرداند[11]    107
شکل 23-4) مدلسازی سلسله مراتبی با BPMN [5]    112
شکل 24-4) مجموعه مدلهای فاز طراحی و ارتباط آنها    113
شکل 1-5) دیاگرام فعالیت 3 عامل    117
شکل 2-5) سرویسهای کاندید
120
شکل 3-5) مدل لایه بندی سیستم    121
شکل 4-5) تغییر پذیری در گردش کار    122
شکل 5-5) مدل خصیصه    123
شکل 6-5) دیاگرام فعالیت برای شناسایی وابستگیها    124
شکل 7-5) دیاگرام General Composition 125
شکل 8-5) مدل نگاشت    125
شکل 9-5) لایه تامین کننده QOS    126
شکل 10-5) سرویسهای دانه ریز    127
شکل 11-5) دیاگرام Consignee Collaboration    127
شکل 12-5) دیاگرام Consignee Sequence Diagram    128
شکل 13-5) دیاگرام Shipper Collaboration    128
شکل 14-5) دیاگرام Shipper Sequence    129
شکل 15-5) دیاگرام Partial Order Process Collaboration 129
شکل 16-5) دیاگرام Partial Order Process Sequence
130
شکل 17-5) دیاگرام تعاملات مابین سرویس فرایند و سرویسهای همکار
131
شکل 18-5) مدل BPMN    132

فهرست جداول

جدول 1-1) مقایسه مدلهای توسعه وابسته به معماری 17
جدول 1-6) راهکار پیشنهادی در تامین اصول طراحی    137

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

کلمات کلیدی : SOA , Layer, Service Type , Process ,Variation , Granularity .Composition

مقدمه
در طول چهار دهه اخیر، میزان پیچیدگی نرم افزارها بصورت صعودی افزایش یافته و تقاضا برای نرم افزارهای قدرتمندتر بیشتر شده است. در این میان، به نظر می رسد که روشهای قدیمی جوابگوی نیازهای در حال رشد کنونی نیستند و نیاز به ایجاد و بکارگیری روشهائی است که بوسیله آنها بتوان بر این پیچیدگیها بصورت کاراتر و در زمانی کوتاهتر غلبه کرد. از سوی دیگر امکان کنار گذاشتن یکباره سیستمهای نرم افزاری موجود که تا به حال مشغول سرویس دهی به مشتریان بوده اند، وجود ندارد و می بایست سیستمهای جدید را بصورت یکپارچه و در کنار همین سیستمهای فعلی بوجود آورد. معماری سرویس گرا، با تکیه بر اصول سرویس گرائی و محاسبات و سرویس های توزیع شده و بر پایه پروتکلهای شبکه و لایه های منطقی سرویس و همچنین زبانهایی که تولید نرم افزارهای توزیع شده را فراهم می کنند، به عنوان راه حلی مناسب جهت از میان برداشتن مشکلات و مسائل مذکور مطرح گردیده است[20,21].
SOA مجموعه ای از اصول , نظریه ها و تکنیکهایی را فراهم می کند که فرایندهای کسب و کار , اطلاعات و دارایی های تشکیلات بتوانند به شیوه مؤ ثری سازماندهی شوند و این فرایندها می توانند برای پشتیبانی از طرحهای استراتژیک و سطوح بهره وری که در محیطهای رقابتی کسب و کار مورد نیاز هستند,  گسترش داده شوند .  بسیاری از تشکیلات اقتصادی در استفاده اولیه شان از SOA چنین پنداشتند که از مولفه های موجود به عنوان سرویس وب می توانند استفاده کنند و عنوان کردند تنها با ایجاد سرویسهای پوشاننده  و رها کردن مولفه های زیرین غیر قابل دسترس, این کار عملی خواهد بود . در نتیجه پیاده سازی  لایه نازکی از SOAP/WSDL/UDDI  بالای برنامه کاربردی موجود یا مولفه هایی که سرویسهای وب را تحقق می بخشند , تا حد گسترده ای در صنعت نرم افزار تجربه شد . اما تا به حال روش مناسبی برای ایجاد برنامه های کاربردی تجاری قدرتمند وجود ندارد . اگرچه طبیعت مولفه ها مناسب استفاده از آنها به عنوان سرویس وب  می باشد , در بیشتر موارد اینطور نیست و برای طراحی مجدد و ارائه کارکرد مولفه ها به شیوه صحیح و از طریق سرویس وب نیازمند تلاش مضاعفی می باشیم[9] .
پیاده سازی موفق SOA  مستلزم این است که به مفاهیم و استراتژیهای پیاده سازی که خصوصیات و ویژگیهای اساسی SOA را فرموله می کنند , توجه شود . به مجرد پیاد ه سازی موفق SOA , مزایایی در جهت کاهش زمان توسعه و ایجاد محصول , بهره برداری از کاربردهای انعطاف پذیر با پاسخ دهی سریع و امکان اتصال پویای استدلالهای کاربردی شرکای تجاری , حاصل می شود . یک پیاده سازی کامل SOA نه تنها در ارتباط با گسترش و صف آرایی سرویسها می باشد بلکه امکان استفاده از سرویسها درجهت اجتماع برنامه های کاربردی متمایز و ایجاد کاربرد مرکب را منعکس می سازد.

فصل اول:
کلیات معماری سرویس گرا
1-1  تعاریف اولیه
1-1-1  معماری  سرویس گرا (SOA)
SOA مجموعه قوانین ، سیاستها و چارچوبهایی است که نرم افزارها را قادر می سازد تا عملکرد خود را از طریق مجموعه سرویسهای مجزا و مستقل و در عین حال مرتبط با هم در اختیار سایر درخواست کنندگان قرار دهند تا بتوانند بدون اطلاع از نحوه پیاده سازی سرویس و تنها از طریق رابطهای استاندارد و تعریف شده، این سرویسها را یافته و فراخوانی نمایند و یا در تعریف دیگر می توان گفت معماری سرویس گرا روشی برای ساخت سیستمهای توزیع شده ای است که در آنها عملکرد سیستم بصورت سرویس در اختیار کاربران و یا سایر سرویسها قرار می گیرد. از دیگرتعاریف ارائه شده مرتبط با معماری های سرویس گرا می توان به واحدهای نرم افزاری آماده در شبکه  یا سرویسهای سطح حرفه ای   اشاره کرد. در حال حاضر، تکنولوژی سرویسهای وب  و پیاده سازی نمونه های موفق از آن، نشان داده است که SOA می تواند به عنوان راه حلی عملی و دست یافتنی در طراحی سیستمهای توزیع شده جدید و یکپارچه سازی سیستمهای بزرگ موجود مطرح گردد[3].  در این معماری، همه توابع به عنوان سرویس تعریف می گردند. این توابع شامل توابع تجاری و تراکنشهای تجاری می باشند که تراکنشهای تجاری خود شامل توابع سطح پایین و توابع سیستمی سرویسها هستند. سرویسها بصورت مستقل طراحی و پیاده سازی شده و به عنوان جعبه سیاه عمل می نمایند. قطعات دیگر در خارج از این قطعه,  نیازی به دانستن نحوه انجام کار در این سرویس را ندارند و تنها به نتیجه آن نیازمندند. قطعات، سرویسهای خود را از طریق رابطهای تعریف شده در اختیار قطعات دیگر قرار میدهند که این رابطها قابل دستیابی و فراخوانی هستند، بدون اینکه محل قرار گیری آنها اهمیت داشته باشد (رابطهای محلی یا دور ). در ضمن، این رابطها می توانند به همان نرم افزار کاربردی  یا به آدرسی در محل دیگری از شبکه مرتبط باشند. رابطها به عنوان کلیدی در برقراری این ارتباطها هستند و از طریق آنها نوع پارامترهای ورودی و نتایج (خروجی) مشخص می گردد[1,34,26]...