Transcript وب سرویس - Taghi Abadi

‫نام درس ‪:‬وب سرویس‬
‫‪1‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪2‬‬
‫یک وب سرویس به معنای ساده نوعی کامپوننت تحت وب است‪ .‬این کامپوننت به برنامه‬
‫هایی که از آن استفاده می کنند این امکان را می دهد که بتوانند از متدهای این وب‬
‫سرویس استفاده کنند‪.‬‬
‫وب سرویس یک تکنولوژی است که امکان می دهد نرم افزارهای کاربردی‪ ،‬مستقل از نوع‬
‫سیستم عامل و زبان برنامه نویس ی با یکدیگر ارتباط برقرار کنند‪.‬‬
‫یک وب سرویس‪ ،‬واسطه ای نرم افزاری است که مجموعه ای از عملیات را تعریف می‬
‫نماید‪ ،‬که می توانند بر روی یک شبکه و از طریق پیام رسانی استاندارد شده ‪XML‬مورد‬
‫دسترس ی قرار گیرند‪.‬‬
‫وب سرویس با استفاده از استانداردی (که بر پایه ی ‪ XML‬است) شرح داده شده است‬
‫که توصیف سرویس (‪ )Service Description‬نامیده می شود‪ .‬این توصیف‪ ،‬شامل تمام‬
‫جزییات الزم برای تعامل با سرویس‪ ،‬از جمله فرمت های پیام‪ ،‬پروتکل های انتقال و‬
‫موقعیت آن می باشد‪.‬‬
‫‪‬‬
‫فرض کنید شما می خواهید در ‪web application‬خود وضعیت آب و هوای مناطق‬
‫جغرافیایی مختلف را داشته باشید‪ .‬برای پیاده سازی چنین کاری شما دو راه دارید‪:‬‬
‫‪ -1‬خودتان وضعیت اب و هوا را از سایت های مختلف جمع آوری کنید و آنها را در ‪web‬‬
‫‪application‬خود استفاده کنید‪.‬‬
‫‪ -2‬از یک وب سرویس که آب و هوای مناطق جغرافیایی مختلف را می دهد استفاده کنید‪.‬‬
‫‪‬‬
‫‪‬‬
‫‪3‬‬
‫در واقع این وب سرویس آب و هوا به تنهایی کاری نمی کند‪ .‬بلکه توابعی دارد که توسط ‪web‬‬
‫‪application‬های مختلف صدا زده می شوند‪ .‬که بعنوان مثال در اینجا وب سرویس‬
‫وضعیت آب و هوا را برمی گرداند‪.‬‬
‫البته وب سرویس ها استفاده های بسیار پرکاربردتر و مهمتری دارند مثل کار با دیتابیس و ‪...‬‬
‫که در اینجا فقط یک مثال برای روشن شدن موضوع ذکر شد‪.‬‬
‫‪‬‬
‫عدم نیاز به کدنویس ی مجدد‪.‬‬
‫این کار با کالس هم امکانپذیر است‪ .‬اما‪:‬‬
‫‪ -1‬در برنامه نویس ی با کالس شما باید کالستان را در هر پروژه ‪add‬کنید ولی در وب سرویس‬
‫فقط کافیست از متدها استفاده کنید‪.‬‬
‫‪ -2‬در کار با کالسها شما ممکن است در ‪application‬های مختلف به روشهای مختلف با‬
‫کالسهای متفاوت کار کنید‪ .‬یعنی به عبارتی کار شما هر بار متفاوت است و این خوانایی را پایین‬
‫می آورد و همچنین توسعه را مشکل می سازد‪ .‬اما در استفاده از وب سرویس شما هربار فقط‬
‫با یک وب سرویس خاص کار می کنید و طبق همان متدهای خاص وب سرویس کار می کنید‬
‫حاال در هر کجا و هر ‪application‬که باشید‪.‬‬
‫‪ -3‬وقتی با سرویس کار می کنید یک سری استانداردهایی در استفاده وجود دارد که تمام‬
‫‪application‬ها باید از آن تبعیت کنند و بنابراین ‪reusability‬باال می رود‪.‬‬
‫‪4‬‬
5
‫‪‬‬
‫‪‬‬
‫‪6‬‬
‫‪ )SOAP( Simple Object Access Protocol‬پروتکل مورد استفاده توسط استفاده‬
‫کنندگان برای فرستادن درخواست به و دریافت پاسخ از سرویس های وب مبتنی بر ‪XML‬‬
‫است‪.‬‬
‫‪ SAOP‬یک پروتکل سبک است که روی ‪ HTTP‬ایجاد شده است‪.‬البته می توان پیغام‬
‫های ‪ SAOP‬را از طریق پروتکل های دیگر نیز تبادل کرد‪ ،‬ولی در حال حاضر فقط مرتبط‬
‫سازی های ‪ HTTP‬برای ‪ SOAP‬تعریف شده اند‪.‬این پروتکل مجموعه قواعد مبتنی بر‬
‫‪ XML‬برای مشخص کردن اسم متدها‪ ،‬نوع پارامترها و مقادیر برگشتی که استفاده کننده‬
‫می خواهد روی یک سرویس وب مبتنی بر ‪ ، XML‬آنها را فراخوانی کند ‪ ،‬یک ‪ Client‬یک‬
‫سرویس وب مبتنی بر ‪ XML‬را فراخوانی می کند‪ ،‬باید پارامترها و متد ها را با استفاده از‬
‫این قواعد مشخص کند‪.‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪7‬‬
‫پروتکل ‪HTTP‬یا ‪Hyper Text Transfer Protocol‬اصطالحا به پروتکلی گفته می‬
‫شود که برای ایجاد ارتباط‪ ،‬دریافت‪ ،‬و ارسال داده ها بین سرور و کالینت استفاده می شود‪.‬‬
‫این پروتکل از پروتکل ‪TCP/IP‬برای بستن پلی میان سرور و کالینت استفاده می کند‪.‬‬
‫طریقه کار ارتباط کالینت با سرور‪ ،‬با استفاده از پروتکل ‪HTTP‬به این ترتیب است که‬
‫داده ها‪ ،‬از طریق بسته های اطالعاتی‪ ،‬بین سرور و کالینت رد و بدل می شود‪ .‬به این ترتیب که‬
‫برای برای ارسال داده ای به سمت مقصد‪ ،‬در ابتدا‪ ،‬داده‪ ،‬به بخش های کوچکتری شکسته‬
‫می شود و سپس از هر کدام به سمت مقصد و با ترتیب مشخص ارسال می شوند‪.‬‬
8
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫در ابتدا برنامه متقاض ی وب سرویس جهت یافتن وب سرویس مورد نیاز خود در ‪UDDI‬‬
‫‪ Registery‬جستجو می کند‪.‬و بعد از یافتن سرویس مورد نظرش‪ ،‬چگونگی ارتباط با وب سرویس را‬
‫از طریق ‪ WSDL‬مربوط به آن وب سرویس بدست می آورد‪.‬‬
‫در مرحله بعد درخواست ‪ SOAP‬خود را بر اساس مشخصات وب سرویس‪ ،‬که از ‪ WSDL‬بدست‬
‫آورده‪ ،‬ایجاد کرده و به وب سرویس می فرستد‪ ،‬در نهایت وب سرویس پاسخ خود را بصورت پیغام‬
‫‪ SOAP‬برمی گرداند‪.‬‬
‫همانطور که در شکل نشان داده شده است برای تعریف‪ ،‬جستجو و دسترس ی به وب سرویس ها‬
‫تکنولوژی های استاندارد ‪ UDDI ,WSDL ,SOAP‬وجود دارد که در ادامه در مورد آن ها بحث‬
‫می کنیم‪.‬‬
‫‪- Universal Description, Discovery and Integration‬‬
‫‪- Simple Object Access Protocol‬‬
‫‪- Web Service Definition Language‬‬
‫‪9‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪10‬‬
‫‪ UDDI‬استانداردی است که توسط شرکت های ‪ Microsoft‬و ‪ Ariba‬و ‪ IBM‬جهت پیدا‬
‫کردن وب سرویس ها بر اساس محتوایی که ارائه می کنند در سال ‪ 2000‬ایجاد شد‪.‬‬
‫‪ UDDI‬مانند یک دفترچه تلفن برای وب سرویس ها عمل می کند‪ .‬شرکت های مختلف می توانند‬
‫اطالعات عمومی خود رادر مورد وب سرویس ها در آن ثبت کنند و کاربران می توانند با جستجو در ان‬
‫سرویس مورد نظر خود را بیابند‪.‬‬
‫اطالعات ارائه شده در ‪ UDDI‬شامل سه جزء اصلی است که در شکل زیر نشان داده شده است‪.‬‬
11
White Pages
.‫در آنها اطالعات تماس شرکت ها و توضيحات متنی آنهاست‬
.‫ محل خدمت بر اساس نام ارائه دهنده‬،‫برای مثال‬
This category contains:
Basic information about the Company and its business.
Basic contact information including business name, address, contact phone
number etc.
A unique identifiers for the company tax IDs.
This information allows others to discover your web service based upon your
business identification.
12
Yellow Pages
.‫حاوی اطالعات طبقه بندی شده شرکتها و اطالعات درباره توانايی های الکترونيکی آنها می باشد‬
This category contains:
This has more details about the company, and includes descriptions of the kind
of electronic capabilities the company can offer to anyone who wants to do
business with it.
It uses commonly accepted industrial categorization schemes, industry codes,
product codes, business identification codes and the like to make it easier for
companies to search through the listings and find exactly what they want.
13
)‫( شرح چگونگی دسترس ی به وب سرویس‬
Green Pages
‫اطالعات تجاری و‬.‫حاوی اطالعات تکنيکی درباره سرويس های آنها و نحوه پردازش اطالعات شرکت آنها می باشد‬
.‫سرويس های شرکت ها کامال ً طبقه بندی شده است و اجازه می دهد که به راحتی در آنها جستجو کرد‬
‫ می توانند از اين اطالعات استفاده کرده و شرکت ها را برای خدمات بهتر به هم متصل‬IT ‫سپس متخصصان‬
‫ را ايجاد می کند و شرکتها می توانند از سرويس های‬B2B ‫ امکان پياده سازی مدل‬UDDI ‫ با اين شرط‬.‫کنند‬
.‫يکديگر استفاده کنند‬
This category contains technical information about a web service. This is what
allows someone to bind to a Web service after it's been found. This includes:
•The various interfaces
•The URL locations
•Discovery information and similar data required to find and run the Web service.
NOTE: UDDI is not restricted to describing web services based on SOAP. Rather,
UDDI can be used to describe any service, from a single web page or email address all
the way up to SOAP, CORBA, and Java RMI services.
14
‫‪RMI‬چیست؟‬
‫‪RMI‬مخفف عبارت ‪Remote Method invocation‬به معنی «فراخوانی متد از راه دور »است‪.‬‬
‫‪ RMI‬مکانیسمی در اختیار برنامه نویسان جاوا قرار می دهد که می توانند از طریق آن متد‪ ،‬اشیای گوناگون را‬
‫بر روی یک ماشین مجازی ( ‪)JVM‬راه دور اجرا کنند‪ .‬مکانیسم های فراخوانی راه دور متفاوتی در دنیای نرم‬
‫افزار ایجاد شده اند‪،‬اما ‪RMI‬برخالف بسیاری از آنها محدود به انواع داده ای اولیه یا ساختار هایی متشکل از‬
‫داده های ساده نیست و به کمک آن می توان اشیای نرم افزاری را به تمامی همانند یک پارامتر عبور داد یا باز‬
‫گرداند‪.‬‬
‫این ویژگی از ‪RMI‬یک مکانیسم منحصر به فرد می سازد‪ .‬چنین خاصیتی به این معنی است که یک برنامه‬
‫نویس جاوا می تواند به کمک ‪ ،RMI‬کدهای جدیدی را در شبکه انتقال دهد و در ماشین های مجازی راه دور‬
‫به صورت دینامیک آن ها را اجرا نماید‪.‬‬
‫بدین ترتیب برنامه نویسان جاوا در زمان برنامه نویس ی سیستم های توزیع شده‪،‬آزادی عمل زیادی به دست‬
‫خواهند آورد‪.‬در یک محیط توزیع شده‪ ،‬کالینت های ‪RMI‬می توانند به نسخه های جدید سرویس های جاوا‬
‫دسترس ی داشته باشند و نیازی به توزیع کردن برنامه به کالینت ها نخواهد بود‪ .‬این ویژگی همانطور که در‬
‫محیط های شبکه محلی اجرا می شود‪،‬در محیط وب نیز قابل اجرا است‪.‬‬
‫‪In order to support code running in a non-JVM context, a‬‬
‫‪CORBA version was later developed.‬‬
‫‪15‬‬
‫‪CORBA‬‬
‫( ‪(Common object Request Broker Architecture‬‬
‫وابسته به يك سكوي نرم افزاری و زبان برنامه نويسي مشخص معين نيست‪،‬‬
‫و به كمك آن مي توان سيستم هاي نرم افزاري گوناگون را در محيط هاي گسترده به يكديگر ارتباط داد‪.‬‬
‫سرويس ها از طريق يك رابط که به زبان ‪)interface Definition Language (IDL‬نوشته شده‬
‫است‪،‬توصيف مي شوند‪.‬‬
‫‪CORBA‬به اشياي نرم افزاري اين امكان را مي دهد كه درخواست هايي به مقصد اشياي نرم افزاري راه‬
‫دور ارسال كنند و بدين ترتيب متدهاي شي نرم افزاري راه دور را فراخواني نمايند‪.‬‬
‫‪16‬‬
stub/skeleton ‫روش‬
A typical implementation model of Java-RMI using stub and skeleton objects.
stub/skeleton ‫بعضی از پروتکلهایی که از روش‬
:‫استفاده میکنند‬
RPC- Remote Procedure Call;
CORBA- Common Object Request Broker
Architecture;
DCE- Distributed Computing Environment;
RMI- Remote Method Invocation;
......‫و‬
17
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪-2-4‬زبان تعریف سرویس های وب چیست؟‬
‫بدنه پیغام ‪، SOAP‬به فرمت ‪ XML‬است‪.‬سرور وب انتظار دارد که ‪ Client‬از یک مجموعه خاص از تگ‬
‫ها برای رمزنگاری پارامترهای متد استفاده کند‪.‬‬
‫از طرفی سرویس وب مبتنی بر ‪ XML‬باید بتواند خودش را توصیف کند‪.‬برای این کار ‪ Client‬باید با‬
‫استفاده ‪ WSDL‬که یک ‪ query string‬است‪،‬یک درخواست به سرویس وب مبتنی بر ‪ XML‬بفرستد‪:‬‬
‫‪HTTP://localhost/Northwind Services/ProductService.asmx?WSDL‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪18‬‬
‫همانطور که شرح داده شد ‪ SOAP‬زبان ارتباط با وب سرویس ها می باشد‪ WSDL .‬جزئیات ارتباط و‬
‫پیام هایی که رد و بدل می شود را توضیح می دهد‪.‬‬
‫‪‬‬
‫‪19‬‬
‫‪ WSDL‬نیز خود ساختار ‪ XML‬دارد و برنامه ها برای ایجاد پیغام ‪ SOAP‬می بایست‬
‫در ابتدا به آن رجوع کنند‪ .‬شکل زیر چگونگی ارتباط با وب سرویس ها را با استفاده از‬
‫‪ WSDL‬نشان می دهد‪.‬‬
‫ساختار وب سرویس‬
‫معماری وب سرویس برپایه تعامل بین سه نقش قرار دارد‪:‬‬
‫‪ ‬مهیاکننده سرویس‬
‫‪ ‬ثبت کننده سرویس (‪)Service Registry‬‬
‫‪ ‬درخواست کننده سرویس‬
‫عملیات شامل انتشار‪ ،‬یافتن و اتصال می باشد‪.‬‬
‫مهیاکننده سرویس‪ ،‬یک توصیفی از سرویس برای وب سرویس ارائه می کند و آن‬
‫را برای درخواست کننده سرویس یا ثبت کننده سرویس انتشار میدهد‪ .‬درخواست‬
‫کننده سرویس‪ ،‬توصیف سرویس را به صورت محلی یا از طریق ثبت کننده‬
‫سرویس استخراج می کند و از آن توصیف برای تعامل با وب سرویس استفاده می‬
‫کند‪.‬‬
‫‪20‬‬
21
‫‪‬‬
‫‪‬‬
‫‪22‬‬
‫گره ای در شبکه که مسئولیت میزبان نمودن یک سرویس وب را برعهده خواهد‬
‫داشت‬
‫زیرساخت ایجاد شده توسط ارائه دهنده سرویس ‪ ،‬امکانات الزم حمایتی و‬
‫میزبان نمودن سرویس های وب رافراهم می نماید‪ .‬قابلیت پردازش پروتکل‬
‫‪HTTP‬و سرویس اعتبار سنجی ‪ ،‬نمونه هائی از زیر ساخت ارائه شده توسط‬
‫ارائه دهنده سرویس می باشند‪ .‬درصورتیکه ارائه دهنده سرویس قادر به ارائه‬
‫چنین زیرساختی نباشد ‪ ،‬سرویس وب می بایست خود این زیر ساخت را حمایت‬
‫نماید ‪.‬وضعیت فوق‪ ،‬طراحی و پیاده سازی سرویس های وب را با مشکل بیشتر‬
‫مواجه خواهد کرد‪.‬‬
‫‪‬‬
‫‪23‬‬
‫گره ای در شبکه است که به سرويس ارائه شده توسط يک ارائه دهنده‬
‫سرويس مرتبط و از امکانات و پتانسيل های سرويس ارائه شده در جهت پياده‬
‫سازی سيستم خود استفاده می نمايد‪ .‬مصرف کننده سرويس را می توان‬
‫بمنزله يک برنامه سرويس گیرنده بر روی يک گره در نظر گرفت ‪.‬‬
‫‪‬‬
‫‪24‬‬
‫ثبت کننده سرویس یک ثبات قابل جستجو برای توصیفات سرویس است و‬
‫مکانی است که مهیاکنندگان سرویس‪ ،‬توصیفات خود را در آن منتشر میکنند‪.‬‬
‫‪‬‬
‫‪25‬‬
‫تمامی گره های فوق ‪ ،‬قادر به ارتباط با یکدیگر از طریق شبکه های مبتنی بر‬
‫پروتکل ‪TCP/IP‬می باشند ‪.‬‬
‫عملیات در معماری وب سرویس عبارتند از‪:‬‬
‫انتشار (‪:)Publish‬‬
‫برای اینکه سرویس ی در دسترس باشد‪ ،‬توصیف آن باید طوری انتشار یابد که درخواست‬
‫کننده سرویس بتواند آن را پیدا کند‪.‬‬
‫یافتن (‪:)Find‬‬
‫در این عملیات‪ ،‬درخواست کننده سرویس‪ ،‬توصیف سرویس مورد نظر را به طور‬
‫مستقیم و یا از طریق درخواست از ثبت کننده سرویس‪ ،‬استخراج می کند‪.‬‬
‫اتصال (‪:)Bind‬‬
‫در نهایت‪ ،‬از یک سرویس باید استفاده کرد‪ .‬در این عملیات‪ ،‬درخواست کننده سرویس از‬
‫طریق جزییات الزم االجرا در توصیف سرویس‪ ،‬شروع به ارتباط با سرویس می کند‪.‬‬
‫‪26‬‬
‫ري سرويس گرا و سرويس هاي وب‬
‫معموال واژه هاي معماري سرويس گرا و سرويس هاي وب اشتباها به جاي هم و به صورت معادل استفاده‬
‫مي شوند لذا الزم است اين دو مفهوم به صورت دقيق تر بررسي شوند‪.‬‬
‫سرويس هاي وب‪:‬‬
‫‪‬نرم افزارهاي كاربردي كه تحت وب منتشر شده‪ ،‬شناسائي و مورد فراخواني قرار مي گيرند‪.‬‬
‫‪‬مستقل از سكو و زبان هستند‪.‬‬
‫‪‬نوعي از پياده سازي معماري سرويس گرا مي باشند‪.‬‬
‫‪‬با منطق حرفه در تماس هستند ولي هيچ شخصي مستقيما با آنها ارتباط ندارد‪.‬‬
‫‪‬خود شمول هستند‪.‬‬
‫‪‬خود توصيف هستند‪.‬‬
‫‪‬يك رهيافت كليدي براي عينيت بخشيدن به معماري سرويس گرا هستند‪.‬‬
‫‪27‬‬
‫سرويس وب بايد داراي شرايط زير باشد‪:‬‬
‫در سطح وب در دسترس باشد‬
‫از استاندارد ‪ XML‬جهت تبادل اطالعات استفاده كند‬
‫به هيچ سكو يا سيستم عاملي وابسته نباشد ‪.‬‬
‫با سرويس هاي تحت وب تعامل دارد و نه كاربران ‪.‬‬
‫خود توصيف باشد‬
‫قابل شناسائي باشد(جهت استفاده سرويس گيرندگان ابتدا بايد شناسائي و كشف شود)‬
‫در حاليكه نرم افزار تحت وب اين ويژگيها را دارد‪:‬‬
‫از استاندارد ‪ HTML‬براي تبادل اطالعات استفاده مي كند ‪.‬‬
‫وابسته به فناوری و سكو ست‪..) ،CGI ،PHP،(ASP‬‬
‫توسط اشخاص با مرورگر وب مورد استفاده قرار مي گيرد‪.‬‬
‫‪28‬‬
‫تفاوت بین وب سرویس و نرمافزارهای تحت وب‪ ،‬در جدول زیر آمده است‪:‬‬
‫مشخصات وب سرويس‬
‫مشخصات نرم افزارهای تحت وب‬
‫از ‪ XML‬برای انتقال داده استفاده می کنند‪.‬‬
‫از‬
‫به هيچ سکو يا سيستم عاملی وابسته نيست‪.‬‬
‫وابسته به فناوری است (‪ PHP ،ASP‬و ‪)...‬‬
‫‪HTML‬‬
‫برای انتقال داده استفاده می کنند‪.‬‬
‫توسط برنامه های کاربردی فراخوانی می توسط کاربران و با استفاده از مرورگر استفاده می‪-‬‬
‫شوند‪.‬‬
‫شوند‪.‬‬
‫‪29‬‬
‫‪ ‬وب سرویس ها همانند تکنولوژی های دیگر‪ ،‬دارای مزایا و معایبی هستند‪ .‬از مزایای وب سرویس می توان به‬
‫موارد زیر اشاره کرد‪:‬‬
‫‪ ‬قابلیت همکاری‪:‬‬
‫قابلیت همکاری بین برنامه های کاربردی متفاوت که روی سیستم های عامل غیریکسان در حال اجرا می باشند‪.‬‬
‫‪ ‬یکپارچگی خارجی‪:‬‬
‫تجمع آسان برنامه ها و سرویس ها از شرکت هایی با موقعیت جغرافیایی متفاوت برای ارائه یک سرویس‬
‫یکپارچه‪.‬‬
‫‪ ‬استفاده مجدد از کد‪:‬‬
‫شکستن منطق و ایجاد توابع ایستا که می تواند توسط برنامه های کاربردی زیادی فراخوانی شود‪.‬‬
‫‪ ‬استقالل‪:‬‬
‫کدها می تواند توسط برنامه های کاربردی متفاوتی مورد استفاده قرار گیرد‪ ،‬برای مثال یک وب سرویس که با‬
‫‪ ASP.NET‬نوشته شده است‪ ،‬می تواند توسط یک صفحه ‪JSP‬استفاده شود‬
‫‪30‬‬
‫‪ ‬در دسترس نبودن ‪:‬‬
‫هر کس که با اینترنت سروکار دارد می داند که هیچ سایتی ‪ 100‬درصد در‬
‫دسترس نیست‪ .‬وب سرویس ها نیز زیرساختی مشابه وب سایت دارند‪ ،‬بنابراین‬
‫وب سرویس ها هم این مشکل را خواهند داشت‪ .‬حتی اگر سرور نیز در حال اجرا‬
‫باشد‪ ،‬ممکن است ‪ISP‬در دسترس نباشد‪ .‬به علت وجود این مشکالت‪ ،‬الزم‬
‫است مکانیزمی وجود داشته باشد که در صورت وقوع این اتفاق‪ ،‬درخواست را‬
‫برای بار دوم ارسال نماید‪ .‬برخی از پروتکل های جدیدی که توسط وب سرویس‬
‫پشتیبانی می شوند‪ ،‬به صورت خودکار این عمل را انجام می دهند (مانند ‪)JMS‬‬
‫ولی اکثریت آن هایی که بر مبنای ‪HTTP‬می باشند‪ ،‬از این مکانیزم پشتیبانی نمی‬
‫کنند‪.‬‬
‫‪31‬‬
‫‪‬‬
‫تطبیق نیازمندی ها‪:‬‬
‫زمانی که شما یک سرویس ایجاد می کنید و آن را در دسترس عموم قرار می دهید‪،‬‬
‫می تواند مورد استفاده انواع مشتریان قرار گیرد‪ ،‬ولی این سرویس الزامات‬
‫خاص ی را فراهم می کند‪ .‬ممکن است بعض ی از مشتریان سرویس ی را بخواهند که‬
‫کمی با سرویس شما متفاوت است و فقط مورد نیاز اندکی از مشتریان باشد‪ .‬وب‬
‫سرویس یک تکنولوژی از نوع "اندازه ای متناسب برای استفاده حداکثر‬
‫مشتریان" است‪ .‬اگر این سرویس جوابگوی نیاز شما نیست‪ ،‬باید راهحل دیگری‬
‫بیابید‪.‬‬
‫‪32‬‬
‫‪ ‬غیرقابل تغییر بودن‪:‬‬
‫اگر شما برای ایجاد یک وب سرویس سرمایه گذاری کنید‪ ،‬باید از هرگونه تغییر در‬
‫پارامترها و متدهای آن اجتناب کنید‪ .‬شما می توانید تغییرات را در قالب متدهای‬
‫جدید به سرویس اضافه کنید‪ ،‬اما اگر تغییری در متدهای سرویس خود بدهید‪،‬‬
‫برنامه های مشتریان را از بین خواهید برد‪ .‬اگر متوجه شوید که سرویس شما‬
‫پاسخ اشتباه به کاربران می دهد‪ ،‬شما بازهم چاره ای جز ایجاد یک سرویس‬
‫جدید ندارید‪ .‬اشتباهاتی از این قبیل در همه سیستم ها اتفاق می افتد که وب‬
‫سرویس نیز مانند بقیه سیستم ها از این قاعده مستثنی نخواهد بود‪ .‬ولی در‬
‫سایر سیستم ها‪ ،‬یک راه ارتباطی بین ارائه دهنده خدمات و مصرف کنندگان آن‬
‫وجود دارد که در صورت تغییر‪ ،‬به اطالع کاربر می رسد‪.‬‬
‫‪33‬‬
‫‪ ‬ضمانت اجرا‪:‬‬
‫کل ایده وب سرویس این است که یک برنامه کامپیوتری به جای وارد کردن دستی‬
‫کدها‪ ،‬به نیازمان پاسخ دهد که این برنامه بدون مراقبت اجرا می شود‪.‬‬
‫‪HTTP‬یک پروتکل ‪ unreliable‬است و هیچ تضمینی از تحویل صحیح داده ها ندارد‪.‬‬
‫اگر شما به این ضمانت نیاز دارید‪ ،‬یا خودتان باید این مکانیزم را به صورت‬
‫دستی بنویسید که تالش مجدد را انجام دهد‪ ،‬و یا اینکه از طریق یک واسط (که‬
‫دارای این ویژگی است) درخواست خود را ارسال نمایید‪.‬‬
‫‪34‬‬
‫اتصاالت سست یا ‪loosely coupled‬‬
‫يك ويژگي براي سيستم هاي اطالعاتي است كه در آن واسط هاي بین اجزاء(ماژولها) به گونه اي طراحي مي شوند‬
‫كه وابستگي بین اين اجزاء حداقل شود و در نتيجه ريسك اثر تغيیر يك جزء بر ساير اجزاء كاهش يابد ‪.‬‬
‫درمعماري سرويس گرا منظور از اتصال سست قابليت تعامل بین سرويس ها به صورت مستقل از كدنويس ي و‬
‫مكان سرويس ها است‪ ،‬بگونه اي كه سرويس ها در زمان اجرا مي توانند تغيیر مكان داده‪ ،‬روالهاي داخلي خود را‬
‫تغيیر دهند يا حتي از يك فناوری جديد تر استفاده كنند‪ ،‬بدون اينكه تاثیري منفي بر سرويس گیرندگان گذاشته‬
‫شود‪.‬‬
‫چند نكته در تعريف اتصال سست وجود دارد‪ :‬به وسيله واسط سيستم انجام مي شود‬
‫ارتباط از طريق ارسال پيام است‬
‫تمام طرف ها در محيط ارتباطي بايست از يك مدل داده استفاده كنند‬
‫ارتباط بايستي مستقل از سكو و فناوری پياده سازي هر جزء باشد‬
‫‪35‬‬
‫اي ميان سيستم هاي اتصال سست با اتصال سفت‪:‬‬
‫اتصال سفت‬
‫تبادالت‬
‫همگام‬
‫سبك پيام ارسالي‬
‫آدرس پيام‬
‫‪RPC‬‬
‫وابسته به كد‬
‫نا همگام‬
‫متن‬
‫مسیريابي شده‬
‫تك فناوری‬
‫چند فناوری‬
‫وابسته‬
‫غیر وابسته‬
‫فناوری‬
‫نوع داده‬
‫تعريف نحو‬
‫مقيد سازي‬
‫اصالح معنائي‬
‫منظور و هدف‬
‫نتيجه و اثر‬
‫‪36‬‬
‫اتصال سست‬
‫طبق پيمان دو طرفه‬
‫ثابت و در مراحل اوليه‬
‫با تغيیر كد‬
‫كارائي‬
‫قابل پيش بيني‬
‫انتشار نحو طبق استاندارد‬
‫با تاخیر‬
‫با تغيیر شكل‬
‫تعامل بین انواع نرم افزارها‬
‫غیر منتظره‬
Web Service Technology Stack
37
discovery layer
The discovery layer provides the mechanism for consumers to fetch the
descriptions of providers. One of the more widely recognized discovery
mechanisms available is project. the Universal Description, Discovery, and
Integration (UDDI).
38
Description layer
When a web service is implemented, it must make decisions on every level
as to which network, transport, and packaging protocols it will support.
A description of that service represents those decisions in such a way that
the Service Consumer can contact and use the service.
The Web Service Description Language (WSDL) is the de facto standard
for providing those descriptions.
Other, less popular, approaches include the use of the W3C's Resource
Description Framework (RDF) and the DARPA Agent Markup Language
(DAML), both of which provide a much richer (but far more complex)
capability of describing web services than WSDL.
39
Packaging layer
For application data to be moved around the network by the transport layer, it
must be"packaged" in a format that all parties can understand (other terms for
this process are"serialization" and "marshalling").
This encompasses the choice of data types understood, the encoding of values,
and so on.
HTML is a kind of packaging format, but it can be inconvenient to work with
because HTML is strongly tied to the presentation of the information rather than
its meaning.
XML is the basis for most of the present web services packaging formats
because it can be used to represent the meaning of the data being transferred,
and because XML parsers are now ubiquitous.
SOAP is a very common packaging format, built on XML.
40
transport layer
The transport layer includes the various technologies that enable direct
application-to-application communication on top of the network layer. Such
technologies include protocols like TCP, HTTP, SMTP, and Jabber. The
transport layer's primary role is to move data between two or more locations
on the network. Web services may be built on top of almost any transport
protocol.
The choice of transport protocol is based largely on the communication needs
of the web service being implemented. HTTP, for example, provides the most
ubiquitous firewall support but does not provide support for asynchronous
communication. Jabber, on the other hand, while not a standard, does provide
good a asynchronous communication channel.
41
Network layer
The network layer in the web services technology stack is exactly the same as the
network layer in the TCP/IP Network Model. It provides the critical basic
communication, addressing and routing capabilities.
42
SOAP
SOAP's place in the web services technology stack is as a standardized
packaging protocol for the messages shared by applications. The specification
defines nothing more than a simple XML-based envelope for the information
being transferred, and a set of rules for translating application and platform
specific data types into XML representations.
SOAP's design makes it suitable for a wide variety of application messaging and
integration patterns.
43
SOAP Messages
A SOAP message consists of an envelope containing an optional header and a
required body. The header contains blocks of information relevant to how the
message is to be processed. This includes routing and delivery settings, authentication
or authorization assertions, and transaction contexts.
The body contains the actual message to be delivered and processed.
Anything that can be expressed in XML syntax can go in the body of a message.
44
Example. A purchase order in document-style SOAP
<s:Envelope
xmlns:s="http://www.w3.org/2001/06/soap-envelope">
<s:Header>
<m:transaction xmlns:m="soap-transaction"
s:mustUnderstand="true">
<transactionID>1234</transactionID>
</m:transaction>
</s:Header>
<s:Body>
<n:purchaseOrder xmlns:n="urn:OrderService">
<from><person>Christopher Robin</person>
<dept>Accounting</dept></from>
<to><person>Pooh Bear</person>
<dept>Honey</dept></to>
<order><quantity>1</quantity>
<item>Pooh Stick</item></order>
</n:purchaseOrder>
</s:Body>
</s:Envelope>
45
RPC and EDI
XML messaging, and therefore SOAP, has two related applications: RPC and EDI.
Remote Procedure Call (RPC) is the basis of distributed computing, the way for one
program to make a procedure (or function, or method, call it what you will) call on
another, passing arguments and receiving return values.
Electronic Document Interchange (EDI) is basis of automated business transactions,
defining a standard format and interpretation of financial and commercial documents
and messages.
If you use SOAP for EDI (known as "document-style" SOAP), then the XML will be
a purchase order, tax refund, or similar document.
If you use SOAP for RPC (known as "RPC-style" SOAP) then the XML will be a
representation of parameter or return values.
46
‫پایان‬
‫‪47‬‬