[Zohreh Gholami]

وب سرویس

1-1  مقدمه
یک وب سرویس به معنای ساده نوعی کامپوننت تحت وب است. این کامپوننت به برنامه هایی که از آن استفاده می کنند این امکان را می دهد که بتوانند از متدهای این وب سرویس استفاده کنند.

وب سرویس یک تکنولوژی است که امکان می دهد نرم افزارهای کاربردی، مستقل از نوع سیستم عامل و زبان برنامه نویسی با یکدیگر ارتباط برقرار کنند. یک وب سرویس، واسطه ای نرم افزاری است که مجموعه ای از عملیات را تعریف می نماید، که می توانند بر روی یک شبکه و از طریق پیام رسانی استاندارد شده  XML مورد دسترسی قرار گیرند.

وب سرویس ها فراخوانی اشیاء و یا نرم افزارهای کاربردی را در محیط های گوناگون آسانتر می سازند و یک تکامل تطبیقی در محاسبات توزیع شده بحساب می روند.

دو رویکرد اصلی وب سرویس ها عبارتند از وب سرویس های  .NET و وب سرویس های .Java از آنجایی که وب سرویس ها مستقل از پلاتفورم هستند، این دو نوع می توانند بدون اشکال با یکدیگر به تبادل داده ها بپردازند. چهار سرنام اصلی که در بحث از وب سرویس ها زیاد به گوش می خورند عبارتند از: UDDI، WSDL، SOAP و XML.

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



1-2  معرفی وب سرویس
1-2-1  تعریف وب سرویس
وب سرویس واسطی برای توصیف مجموعه ای از عملیات در سطح شبکه است که از طریق پیام هایی مبتنی بر XML، در دسترس می باشند. وب سرویس با استفاده از استانداردی (که بر پایه ی XML است) شرح داده شده است که توصیف سرویس (Service Description) نامیده می شود. این توصیف، شامل تمام جزییات لازم برای تعامل با سرویس، از جمله فرمت های پیام، پروتکل های انتقال و موقعیت آن می باشد. رابط، جزییات پیاده سازی سرویس را پنهان می کند و اجازه می دهد که سرویس به طور مستقل از سخت افزار و بستر نرم افزاری که روی آن پیاده شده است و همچنین مستقل از زبان برنامه نویسی که در آن نوشته شده است، مورد استفاده قرار گیرد. وب سرویس یک کار خاص و یا مجموعه ای از وظایف را انجام می دهد. آن ها می توانند به تنهایی مورد استفاده قرار گیرند و یا با وب سرویس های دیگر برای انجام مجموعه پیچیده از کارها همکاری داشته باشند.^[3]

یک برنامه، با استفاده از پیامی که مبتنی بر XML ایجاد شده است، درخواستی را به وب سرویسی که در شبکه وجود دارد ارسال می کند و پاسخی را در قالب پیام XML دریافت می کند. این فناوری می تواند در بسیاری از زمینه ها مورد استفاده قرار گیرد. وب سرویس می تواند در یکپارچه سازی B2B برای اتصال برنامه هایی که در سازمان های مختلف اجرا می شود، استفاده شود. وب سرویس می تواند مشکل توزیعی بودن EAI (Enterprise Application Integration) را با اتصال چند برنامه کاربردی که در یک سازمان در حال اجراست، به برنامه های کاربردی متعددی که در داخل یا خارج از دیواره آتش قرار دارد، حل کند. در همه این موارد، فناوری وب سرویس یک چسب استانداردی فراهم می کند که قطعه های مختلف نرم افزار را به هم وصل می کند.

همانطور که در شکل 1-1 زیر نشان داده شده است، وب سرویس وظیفه دریافت پیامی به صورت XML، تبدیل این پیام به شکل قابل فهم برای سیستم نرم افزاری خاص موجود در back-end و برگرداندن پیام پاسخ را دارد.^[2]

شکل 1-1: رابط وب سرویس با سیستم های back-end

برنامه های تحت وب، بسته های نرم افزاری هستند که از طریق مرورگر قابل دسترسی می باشند. نرم افزار و پایگاه داده ی آن به جای نصب در سیستم کاربر، در یک سرور مرکزی قرار دارد و از طریق شبکه می توان به آن دست یافت.
تفاوت بین وب سرویس و نرم افزارهای تحت وب، در جدول 1-1 زیر آمده است:

جدول 1-1: تفاوت وب سرویس با نرم افزارهای تحت وب

[Zohreh Gholami]

1-2-2  ساختار وب سرویس
معماری وب سرویس برپایه تعامل بین سه نقش قرار دارد: مهیا کننده سرویس، ثبت کننده سرویس (Service Registry) و درخواست کننده سرویس. عملیات شامل انتشار، یافتن و اتصال می باشد. این نقش ها و عملیات بر روی اشیا (Artifact) وب سرویس فعالیت می کنند (یعنی ماژول های نرم افزاری وب سرویس و توصیفات آن ها). مهیا کننده سرویس، یک توصیفی از سرویس برای وب سرویس ارائه می-کند و آن را برای درخواست کننده سرویس یا ثبت کننده سرویس انتشار می دهد. درخواست کننده سرویس، توصیف سرویس را به صورت محلی یا از طریق ثبت کننده سرویس استخراج می کند و از آن توصیف برای تعامل با وب سرویس استفاده می کند.

ثبت کننده سرویس (Service Registry)، یک ثبات قابل جستجو برای توصیفات سرویس است و مکانی است که مهیا کنندگان سرویس، توصیفات خود را در آن منتشر می کنند.

عملیات در معماری وب سرویس عبارتند از:
انتشار (Publish): برای اینکه سرویسی در دسترس باشد، توصیف آن باید طوری انتشار یابد که درخواست کننده سرویس بتواند آن را پیدا کند.
یافتن (Find): در این عملیات، درخواست کننده سرویس، توصیف سرویس مورد نظر را به طور مستقیم و یا از طریق درخواست از ثبت کننده سرویس، استخراج می کند.
اتصال (Bind): در نهایت، از یک سرویس باید استفاده کرد. در این عملیات، درخواست کننده سرویس از طریق جزییات لازم الاجرا در توصیف سرویس، شروع به ارتباط با سرویس می کند.^[3]


1-2-3  مزایا و معایب
وب سرویس ها همانند تکنولوژی های دیگر، دارای مزایا و معایبی هستند. از مزایای وب سرویس می توان به موارد زیر اشاره کرد:
قابلیت همکاری: قابلیت همکاری بین برنامه های کاربردی متفاوت که روی سیستم های عامل غیریکسان در حال اجرا می باشند.
یکپارچگی خارجی: تجمع آسان برنامه ها و سرویس ها از شرکت هایی با موقعیت جغرافیایی متفاوت برای ارائه یک سرویس یکپارچه.
استفاده مجدد از کد: شکستن منطق و ایجاد توابع ایستا که می تواند توسط برنامه های کاربردی زیادی فراخوانی شود.
استقلال: کدها می تواند توسط برنامه های کاربردی متفاوتی مورد استفاده قرار گیرد، برای مثال یک وب سرویس که با ASP.NET نوشته شده است، می تواند توسط یک صفحه JSP استفاده شود.^[4]


از معایب وب سرویس نیز می توان موارد زیر را نام برد:
در دسترس نبودن: هر کس که با اینترنت سروکار دارد می داند که هیچ سایتی 100 درصد در دسترس نیست. وب سرویس ها نیز زیرساختی مشابه وب سایت دارند، بنابراین وب سرویس ها هم این مشکل را خواهند داشت. حتی اگر سرور نیز در حال اجرا باشد، ممکن است ISP در دسترس نباشد. به علت وجود این مشکلات، لازم است مکانیزمی وجود داشته باشد که در صورت وقوع این اتفاق، درخواست را برای بار دوم ارسال نماید. برخی از پروتکل های جدیدی که توسط وب سرویس پشتیبانی می شوند، به صورت خودکار این عمل را انجام می دهند (مانند JMS) ولی اکثریت آن هایی که بر مبنای HTTP می باشند، از این مکانیزم پشتیبانی نمی کنند.

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

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

ضمانت اجرا: کل ایده وب سرویس این است که یک برنامه کامپیوتری به جای وارد کردن دستی کدها، به نیازمان پاسخ دهد که این برنامه بدون مراقبت اجرا می شود. HTTP یک پروتکل unreliable است و هیچ تضمینی از تحویل صحیح داده ها ندارد. اگر شما به این ضمانت نیاز دارید، یا خودتان باید این مکانیزم را به صورت دستی بنویسید که تلاش مجدد را انجام دهد، و یا اینکه از طریق یک واسط (که دارای این ویژگی است) درخواست خود را ارسال نمایید.^[6]

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

[Zohreh Gholami]

1-3  (RPC (Remote Procedure Call
1-3-1  تعریف RPC
RPC یک تکنیک قوی برای شکل دادن به برنامه های مبتنی بر Client/Server و توزیع شده است. RPC یک متد است و مبتنی بر فراخوانی روال محلی (local procedure calling) است که در آن نیازی نیست روال فراخوانی شده در همان آدرس روال فراخوانی کننده، قرار گرفته باشد. دو فرآیند ممکن است روی یک سیستم یکسان ویا روی سیستم های مختلف همراه با شبکه ای که آن ها را به هم وصل می کند، قرار گرفته باشند. با استفاده از RPC، برنامه نویسان برنامه های توزیع شده از جزییات رابط با شبکه دور خواهند بود.


1-3-2  نحوه کار RPC
RPC مانند فراخوانی یک تابع است. وقتی RPC ایجاد می شود، آرگومان های فراخوانی کننده به روال دوردست ارسال می شوند و فراخوانی کننده تا بازگشت نتیجه، منتظر می ماند. شکل 1-3 جریان فعالیت را که در طول فراخوانی RPC اتفاق می افتد، نشان می دهد.

شکل 1-3: جریان فعالیت ها در طول فراخوانی RPC

Client یک فراخوانی روال را ایجاد می کند و آن را به Server می فرستد و منتظر پاسخ می ماند. Thread به حالت بلاک می رود تا زمانی که یا پاسخ دریافت شود و یا اینکه timeout اتفاق بیافتد.

زمانی که یک درخواست (به سرور) می رسد، سرور یک روال را برای اجرای سرویس درخواست شده فراخوانی می کند و پاسخ را به Client برمی گرداند. زمانی که فراخوانی RPC کامل شد، برنامه Client به اجرای خود ادامه می دهد.

در شکل بالا، روال موجود در سرور به طور خاص با این 3 پارامتر شناسایی می شود: شماره برنامه، شماره نسخه (ورژن)، شماره  روال.
شماره برنامه، گروهی از روال ها را مشخص می کند که هرکدام دارای یک شماره ی روال منحصر به فرد هستند. یک برنامه ممکن است دارای یک یا چند نسخه مختلف باشد. هر نسخه شامل مجموعه ای از روال هاست که برای فراخوانی از راه دور در دسترس می باشند. شماره نسخه، باعث می شود که چندین نسخه از یک پروتکل RPC به طور همزمان در دسترس باشند. هر روال، یک شماره دارد.^[9]
در دنیای XML دو روش برای فراخوانی روال از راه دور (Remote Procedure Call) وجود دارد.
•  XML-RPC
•  SOAP

XML-RPC یک پروتکل RPC است که در سرتاسر اینترنت کار می کند. درخواست XML-RPC یک درخواست HTTP-POST است که بدنه این درخواست از XML می باشد. روالی که روی Server در حال اجراست، پاسخ درخواست را بر اساس XML می فرستد. پارامترهای روال می تواند از نوع عددی، رشته، آرایه و ... باشد.
در شکل 1-4 یک درخواست XML-RPC نشان داده شده است.

شکل 1-4: درخواست XML-RPC



پاسخ این درخواست در شکل 1-5 آمده است.

شکل 1-5: پاسخ مبتنی بر XML-RPC



1-3-3  انواع داده ها در XML-RPC
نوع داده های متداولی که به معادل XML آن تبدیل شده است، همراه با مثالی در جدول 1-2 آمده است:^[10]

جدول 1-2: نوع داده ها در XML- RPC

[/center]
XML-RPC در سال 1998 توسط گروهی از افراد در ماکروسافت توسعه داده شد و پروتکل جدید با نام SOAP معرفی شد. SOAP مانند XML-RPC است ولی شامل ویژگی های بسیاری است که در XML-RPC ارائه نشده بود.^[7]

از تفاوت های بین SOAP و XML-RPC می توان به موارد زیر اشاره کرد:
•  XML-RPC ساده تر است.
•  بسیاری از Web Serviceها بر مبنای XML-RPC هستند.
•  SOAP انتقال اسناد پیچیده تر را ساده می کند. پس نیاز به تعریف تگ های بیشتر و پیچیده تری دارد.
•  SOAP روی پروتکل های زیادی اجرا می شود، از جمله : HTTP,SMTP,FTP و ...
•  SOAP سربار بیشتری دارد.
•  XML-RPC با استفاده از خاصیت methodName خود، متدها را فراخوانی می کند که " ممکن است شامل حروف کوچک و بزرگ A-Z، اعداد، کالن و Slash باشد" که برای بسیاری از اهداف مناسب است ولی برای زمانی که بخواهیم یک شی را به عنوان آرگمان ارسال کنیم، با مشکل مواجه خواهیم شد.
•  آرایه ها و struct ها همیشه بی نام هستند. ^[10],^[11],^[12]



1-3-4  سایر روش های RPC
XML-RPC تنها روش ایجاد RPC نیست. پروتکل های شناخته شده دیگری نیز وجود دارد از جمله CORBA، DCOM و ... . هر کدام از این پروتکل ها مزایا و معایبی نیز دارند.


1-3-4-1  CORBA
CORBA یک پروتکل معروف برای نوشتن برنامه های شی گرا به صورت توزیع شده است. این پروتکل به طور معمول در برنامه های کاربردی چندلایه استفاده می شود. CORBA توسط بسیاری از سازندگان و برنامه های کاربردی رایگان پشتیبانی شده است و با جاوا و C++ به خوبی کار می کند و نیز برای زبان های برنامه نویسی دیگر در دسترس است.

متاسفانه CORBA بسیار پیچیده است. بنابراین این پروتکل برای شرکت ها و برنامه های کاربردی کامپیوتری مناسب تر از برنامه های توزیع شده است.^[8]


1-3-4-2  DCOM
DCOM پاسخ ماکروسافت برای CORBA بود. این پروتکل زمانی که از مولفه های COM استفاده می کنید و نیز نیازی به ارتباط با سیستم های غیرماکروسافتی ندارید، بسیار مناسب خواهد بود، در غیر این صورت کمک چندانی به شما نمی کند.^[8]

لازم به ذکر است که تکنولوژی COM در خانواده سیستم عامل های ویندوز شرکت ماکروسافت، قابلیت ارتباط را برای مولفه های نرم افزاری فراهم می کند. COM توسط توسعه دهندگان برای "ایجاد مولفه های نرم افزاری با قابلیت استفاده مجدد (Re-usable)"، "پیوند مولفه های نرم افزاری برای ایجاد برنامه کاربردی" و نیز برای "بهره مندی از سرویس های ویندوز" مورد استفاده قرار می گیرد. اشیا COM را می توان با استفاده از زبان های برنامه نویسی متعددی ایجاد کرد. زبان های برنامه نویسی شی گرا، از جمله C++، دارای مکانیسم های برنامه نویسی هستند که می توان به سادگی اشیا COM را ایجاد کرد.
COM+، Distributed COM (DCOM)، و کنترل های Activex از خانواده COM هستند.^[13]

[Zohreh Gholami]

2  فصل دوم
XML

  XML (eXtensible Markup Language  2-1  و کاربردهای آن
2-1-1  تعریف XML
XML سیستم گرامری ایجاد زبان های علامت گذاری دلخواه است. یعنی می توان آن را برای انواع داده های ریاضی، شیمی، تجاری و غیره به کار می رود. این زبان در سال 1996 توسط کنسرسیوم WWW ارائه شد و به سرعت مورد استقبال قرار گرفت. ساختار زبان XML اصول و قوانین قابل فهمی دارد که کارآیی آن را افزایش می دهد. اگر یک سند را بر اساس این قوانین ایجاد کنیم به آن سند، سند خوش فرم گفته می شود.^[19]

با گسترده شدن استفاده از وب در دهه ۹۰ کم کم محدودیت های HTML مشخص شد. ضعف HTML در توسعه پذیری (قابلیت اضافه و کم کردن خواص) و ضعف آن در توصیف دیتاهایی که درون خود نگهداری می کند برنامه نویسان را از آن ناامید کرد. همچنین مبهم بودن تعاریف آن باعث شد از توسعه یافتن باز بماند.  در پاسخ به این اشکالات W3C یک سری امکانات را در جهت توسعه HTML به آن افزود که امکان تغییر ساختار متن های HTML مهم ترین آن است. این امکان را CSS یا Cascade Style Sheet می نامند. تگ های تعریف شده در HTML ثابت هستند در حالی که در XML می توان تگ های خود تعریف ایجاد کرد.

اعتبار یک سند XML را با سندهای DTD یا shema می توان سنجید. این نوع سندها مشخص می کنند در سند XML چه تگ هایی را می توان استفاده کرد، این تگ ها چه صفت هایی دارند و ساختار تودرتویی آنها چگونه است.^[2]

برای نوشتن اسناد XML می توان از ویرایشگرهای ساده متن استفاده کرد مانند notepad. اگرچه ابزارهای کامل تری نیز مانند Visual studio تولید شرکت مایکروسافت نیز وجود دارد. در اصطلاح به هر زبانی که توسط XML ایجاد می شود، XML Application می گویند که به معنی کاربرد XML است نه برنامه کاربردی.

XML نیز مانند HTML از سه جزء اصلی عناصر، ویژگی ها و مقادیر تشکیل می شود. عنصر، اصلی ترین قسمت سند XML است و هر چیزی می تواند باشد؛ ازجمله، عناصر دیگر و یا متن. هر عنصر یک برچسب شروع دارد و یک برچسب پایان(شکل 2-1).^[19]

شکل 2-1: تعریف یک عنصر

ویژگی ها در تگ شروع آورده می شوند و نشان دهنده یک صفت از آن تگ هستند. مقادیر متناظر با این ویژگی ها درون علامت کوتیشن در جلوی همان ویژگی نوشته می شود(شکل 2-2).

شکل 2-2: تعریف ویژگی

مقدار هر تگ بعد از اتمام تگ شروع و قبل از شروع تگ پایان قرار می گیرد و می تواند شامل تگ های دیگر یا یک متن ساده باشد که این ها را بر اساس shema یا DTD متناظر مشخص می کنیم.^[19]



2-1-2    قوانین نگارش در XML
ساختار زبان XML اصول و قوانین قابل فهمی دارد که کارآیی آن را افزایش می دهد و استفاده از آن را بسیار آسان می سازد که در ادامه به مهم ترین های آن اشاره می کنیم.

•  عنصر ریشه (Root element)
هر سند یا فایل XML باید یک عنصر ریشه داشته باشد که تمام عناصر سند را شامل می گردد. تنها توضیحات و دستورات پردازشی می توانند در خارج از عنصر ریشه قرار بگیرند. هر عنصر باید یک برچسب شروع و یک برچسب پایان داشته باشد.

•  عناصر تودرتو
اگر قرار است عنصر A ابتدا و عنصر  B بعد از آن بیاید، ابتدا عنصر B بسته می شود و سپس عنصر A.

•  حروف کوچک و بزرگ
XML بین حروف کوچک و بزرگ فرق می گذارد. یعنی عناصرanimal ،ANIMAL  وAnImaL  با هم متفاوت هستند و می توانند با هم ارتباطی نداشته باشند.^[19]
در شکل 2-3 نمونه ای از یک سند XML آمده است. این سند اطلاعات پزشکی یک فرد را در خود ذخیره کرده است.^[16]

شکل 2-3: نمونه ای از یک سند XML



2-2  امنیت
داشتن امنیت در قابلیت اعتماد، حریم شخصی و یکپارچگی و امانت یک مساله حیاتی در کسب و کار آنلاین است. با رشد استقبال از تکنولوژی XML در اسناد و پروتکل ها، منطقی است که باید امنیت نیز باXML  همراه شود.  استاندارد امن XML  لغت نامه و قوانین اجرایی را تعریف کرده است که نیازهای امنیت را برطرف کند. با پدیدار شدن XML، این استاندارد از نتیجه رمزنگاری و تکنولوژی های امنیت استفاده کرد تا یک راه حل انعطاف پذیر، توسعه پذیر و انجام پذیر را برای پاسخ دادن به نیازهای امنیتی ارائه دهد.^[16]

تکنولوژی های قدیمی تر امنیت یک مجموعه از الگوریتم های پایه ای امنیت را ارائه می دهند که می توانند در امنیت XML نیز استفاده شوند اما قالب های پیاده شده در آنها برای ایجاد امنیت برای بسیاری از برنامه های XML مناسب نیست. یکی از دلایل این عدم سازگاری این است که این استانداردها از شکل دودویی استفاده می کنند که نیاز به نرم افزار خاصی برای تفسیر پیغام ها است. دلیل دیگر این است که این استانداردها برای استفاده در XML طراحی نشده اند و از روش های معمول XML برای انتقال مفاهیم حمایت نمی کنند. مانند معلوم کردن محتوا با  URI ها. علاوه بر این بعضی از تکنلوژی های موجود امنیت نیاز دارند تا با برنامه کامپیوتری یک پارچه شوند تا بتونند امنیت را تامین کنند.^[16]

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

•  احراز هویت: بدین معنی که چه کسی تقاضای دسترسی را دارد. مشخصات و قوانین یک گروهی را که یک فعالیت را انجام می دهد، مشخص میکند. مانند دسترسی به منابع و یا شرکت در یک انتقال.

•  اختیارات دسترسی: مشخص میکند کسی که احراز هویت شده است چقدر حق دسترسی دارد. مانند اینکه اجازه دارد یک صفحه اینترنتی خاص را مشاهده کند یا رمز عبور را تغییر دهد یا  کمپانی را به پرداخت 10 میلیون دلار متعهد کند.

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

•  امضای دیجیتال: ایجاد و تصدیق امضای دیجیتالی بجای امضای دستی. یک چنین امضایی برای مقاصد مختلف استفاده می شود مانند تصدیق، تایید وصول، پذیرش و توافق.

•  محرمانگی: اینکه محتوا را برای افراد غیر مجاز غیر قابل خواندن کنیم. مطمئن شویم که محتوا تنها توسط فرد مجاز قابل رویت است. محرمانگی به طور کلی با تکنولوژی های رمزنگاری همراه است، این درحالی است که دیگر روش ها مانند استگانوگرافی  کمتر مورد استفاده قرار می گیرند.

•  حریم خصوصی: محدود کردن استفاده از اطلاعاتی که هویت یک شخص را معلوم می سازد. اطلاعات شخصی معمولاً برای سازمان ها و ارگان ها نیاز است تا بتواند سرویس های مورد نیاز یک فرد را فراهم کنند. مثلا اطلاعات پزشکی فرد نیاز است تا دکتر شخص بتواند نظر درستی را ارائه دهد.^[16]


2-3  XML Security
2-3-1  تعریف
امنیت XML مجموعه ای از استانداردهای تکنیکی را معرفی می کند که نیازهای امنیت را برطرف می سازند. این استانداردها به گونه ای طراحی شده اند که با XML مطابقت داشته باشند. امنیت XML استانداردهای آن را در سطحی بالاتر قرار می دهند و به ترتیب زیر به XML  کمک می کند:

1-  استاندارد های امنیت XML یک مجموعه لغات را برای ارائه امنیت با استفاده از تکنولوژی های XML مانند شِما ،معرفی می کند. مثلا عنصر <KeyInfo> که در امضای دیجیتالی برای انتقال امضا یا اطلاعات رمزشده کلید استفاده می شود.

2-  استانداردهای امنیت XML از استانداردهای دیگر XML بهر می برند تا کارایی را بالاتر ببرند. مانند XPath برای بازیابی بخشی از یک سند.

3-  استانداردهای امنیت XML به گونه ای طراحی شده اند که انعطاف پذیری و توسعه پذیری XML را در خود داشته باشند. آنها امنیت را وارد اسناد، بخشی از یک سند، یک عنصر یا محتوای یک عنصر میکنند.

4-  تکنولوژی های امنیت تقریبا به دوسر یک ارتباط وارد می شود. که این امر وقتی که پیغام های XML مسیر یابی می شوند بسیار مهم است. در طول انتقال امنیت باید همراه داده بماند. امنیت XML را می توان در ترکیب با امنیت های انتقال استفاده کرد مانند X.509 V3. الگوریتم های موجود مانند SHA1 را می توان با آدرس دادن وارد سند کرد.^[16]

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


2-3-2  ویژگی ها
امضای دیجیتالی یک مکانیزم برای حمایت از تولید و تایید انواع مختلفی از امضا ها را دارد که این قابلیت ها را به ما ارائه می دهد:
•  تصدیق همه سند، بخشی از آن، یک عنصر یا محتوای یک عنصر
•  تصدیق هر نوع سند حتی اسناد باینری
•  تصدیق خواصی که به امضا اضافه می شود
•  تصدیق اسناد مرکب
•  تصدیق امضاهای مرکب (امضاهایی که خود شامل امضاهای دیگری هستند)

به علاوه، پیشنهادات امضای XML ، از  برنامه هایی با چند امضا برای یک سند یا بخش های مختلف آن حمایت می کند.
یک عنصر <Signature> با توجه به برنامه کاربردی در چندین نقش ظاهر میشود. می تواند در سند قرار داده شود صرف نظر از اینکه چه چیزی امضا شده است. که در این حالت به آن امضای "منفصل"می گویند و این هنگامی که یک سند غیرXML را امضا می کنیم اتفق می افتد.  هنگامی که یک سند XML امضا می شود، این عنصر می تواند به سند اضافه شود. این یک راحتی را ایجاد می کند به این خاطر که می توان عنصر را درون سند هرجا که نیاز است قرار دهیم. ومی توان به راحتی آن را پیدا کرد.در این حال به این عنصر امضای "پوشیده شده" می گوییم.


مفاهیم زیر مفاهیم اصلی برای درک امضای دیجیتالی XML است:
1-  یک امضا تنها وقتی معتبر است که محتوای امضا شده تغییر نکند. برای درک این یک خلاصه کوتاه با طول ثابت از سند ایجاد می کنیم. بنابراین یک سند هنگامی معتبر است که خلاصه تولید شده در مبدا و مقصد برابر باشند.

2-  یک عنصر <signature> یک ساختار XML است که شامل یک ارزش رمزشده است. که در عنصر <signature Value>  می آید. محتوای <signedInfo> نباید تغییر کند تا سند معتبر باشد.

3-  امضا کنند یک <Reference> برای هر عنصر اضافه شده ایجاد می کند.  هر <reference> شامل یک خلاصه و یک URI برای هر آیتم است. همچنین توضیح می دهد که چگونه خلاصه را ایجاد کنیم ، الگوریتم را مشخص می کند و دیگر اطلاعات مورد نیاز. هر <reference> بخشی از ساختار <signedInfo> است.
برای اعتبار سنجی امضا، گیرنده باید هر <reference> مستقلانه اعتبار سنجی کند با تولید خلاصه مشابه از هر آیتم.باید از URI ها برای رسیدن به مکان آیتم ها استفاده کند. و اطلاعات الگوریتم برای اینکه بداند چطور خلاصه را ایجاد کند. اگر عناصر تغییر نکرده باشند باید دو خلاصه برابر باشند.

4-  یک مرجع به هر چیزی توسط URI اشاره می کند که می تواند یک سند غیر XML باشد مانند یک عکس یا یک متن. این لازم نیست که آیتم را توسط URI  بدست بیاوریم اما اغلب مفید فایده است. یک فرم خاصی از URI می تواند به یک عنصر خاص درون سند امضا شده XML اشاره کند.

5-  یک <Reference> می تواند یک یا چندین بر تغییر کند تا برای یک عنصر مفید شود قبل از خلاصه سازی. یکی از استفاده های آن امضای بخشی از یک سند است که تغییر نمیکند.
هنگامی که یک امضا ایجاد شد می تواند به عنوان بخشی از سند یا جدای از آن قرار بگیرد.فرض کنید که دکتر در مثال قبل بخواهد که سند را امضا کند و امضا بخشی از سند شود(شکل 2-4)^[16]

شکل 2-4: نمونه ای از یک سند امضا شده

[Zohreh Gholami]

محرمانگی: رمزنگاری XML
2-4-1  هدف و فواید
رمزنگاری XML یک مجموعه از عناصر XML و  قواعد پردازش را تعریف میکند که محرمانگی را ایجاد میکند و آن را انواع مختلفی از محتوا ها اضافه میکند. رمزنگاری XML محرمانگی را در انتقال و ذخیره سازی فراهم می کند. تکنولوژی های دیگر محرمانگی نظیر SSL، TLS، یا VPN تنها محرمانگی را  در سطح انتقال ایجاد می کند.

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

برای جلوگیری از این مشکل و اینکه بتوان اطلاعات محرمانه را بین افراد مختلف رد و بدل کرد، کلید متقارن یا کلید عمومی ایجاد شد. در این روش از دو کلید عمومی و خصوصی استفاده میشود که هر کدام اطلاعاتی را که دیگری رمز کرده است میگشاید.  کلید عمومی در اختیار همه قرار میگیرد درحالی که کلید خصوصی فقط در اختیار شخص است. برای ارسال یک پیام، فرستنده پیام را با کلید عمومی گیرنده رمز می کند و گیرنده با کلید خصوصی خود آن را رمزگشایی می کند. به خاطر اینکه کارایی کلید عمومی نسبت به رمزنگاری کلید متقارن کارایی کمتری دارد برای ارسال کلید متقارن از رمزنگاری  کلید عمومی استفاده می کنیم و اطلاعات را با کلید متقارن رمز می کنیم. سپس متن رمز شده و کلید متقارن رمز شده را با هم ارسال می کنیم.^[16]


2-4-2    خصوصیات
در رمزنگاری XML یک بستر و قوانین پردازش برای رمزنگاری و رمزگشایی تعریف شده است. یک مجموعه از عناصر XML را تعریف می کند که تمام اطلاعات لازم  برای پردازش داده های رمز شده مانند الگوریتم استفاده شده برای رمز نگاری را در برمی گیرد. تمام خصوصیت های قابل پشتیبانی در زیر آمده است:
•  محتواهای XML و غیر XML را می توان رمز کرد.
•  نتیجه رمز نگاری یک سند خوش تریف XML باز هم یک سند خوش تعریف است. پس می توان بخشی از یک سند XML را رمز کرد و باز هم سند قابل پردازش باشد.
•  رمزنگاری با امضای دیجیتالی در XML سازگار است و می توانند با هم استفاده شوند.
•  از تعداد زیادی از الگوریتم ها پشتیبانی می کند


2-4-3  مفاهیم کلیدی
1-  هنگامی که یک عنصر XML یا محتوای آن رمز میشود، با عنصر <EncryptedData> جایگذین می شود.
2-  وقتی یک محتوای غیر XML رمز می شود، نتیجه یک سند XML جدید است که حاوی عنصر <EncryptedData> است.
3-  یک عنصر <EncryptedData> حاوی صفت هایی است که به گیرنده کمک می کند تا بتواند متن را رمز گشایی کند. این صفت ها می تواند به عنصر یا محتوایی که رمز شده اشاره کند مثلا یک عکس. این فرآیند برای ضمیمه های ایمیل انجام می شود.
4-  <EncryptedData> الگوریتم رمز نگاری را مشخص می کند، متن رمز شده را درون خود دارد و اطلاعاتی را که لازم است تا بتوان کلید رمزگشایی را بدست آورد.
5-  کلید متقارنی که برای رمزنگاری کتن استفاده شده است در <EncryptedKey> قرار میگیرد.
6-  XML از الگوریتم های انتخابی مناسب حمایت می کند و یک مشخصه برای حالات معمولی تعریف می کند که قابل توسعه برای دیگر حالات هم هست
7-  تعریف اطلاعات کلید شاخص برپایه امضای دیجیتالی است.
8-  خصوصیت هایی که کاربر تعریف می کند می تواند با عنصر رمز شده ترکیب شود مانند.
9-  متن واقعی رمز شده، نتیجه رمزنگاری، با استفاده از <cipherData>  مشخص میشود. این عنصر حاوی عنصر دیگری است بنام <CipherValue> که مقدار رمز شده در آن است. یا حاوی یک اشاره به جایی که مقدار رمزشده در آنجا ذخیره شده است. که این مرجع درون <CipherReference> ذخیره می شود. یک مرجع هنگامی که متن رمز شده زیاد است مفید می باشد.

یکی از مسائل مهم در امنیت XML ارتباط بین امضای دیجیتالی و رمزنگاری است. فرض کنید که یک سند با امضای دیجیتالی و عنصر <EncryptedData> دریافت کرده اید مانند نمونه زیر:

شکل 2-5: ساختار یک سند امضا شده

در این نمونه، امضا بر روی کل سند اعمال شده است . برای اینکه URL درون عنصر <Reference> خالی است. در اینجا یک سوال پیش می آید: کدام یک زودتر باید بیاید، امضا یا رمزنگاری دانستن این نکته مهم است زیرا که امضا در صورتی معتبر است که متن تغییر نکند. اگر بخشی از متن بعد از امضا رمزنگاری شود، امضا دیگر معتبر نخواهد بود مگر اینکه بخش رمز شده رمزگشایی شود . دانستن ترتیب اعمال رمزنگاری و رمزگشایی مهم است زیرا که باید با تصدیق امضا تداخل ایجاد نکند. راه حل این مشکل این است که هنگامی که یک سند را امضا می کنیم، امضاکننده باید مشخص کند که چه بخشی از سند رمزنگاری شده است. این کار باعث می شود که قبل از تصدیق امضا بدانیم که چه بخشی از سند باید رمز گشایی شود.^[16]

[Zohreh Gholami]

3  فصل سوم
استانداردهای وب سرویس

3-1  WSDL
وب سرویس چهره جدید نرم افزاری از کسب و کار را نمایان کرده است که می تواند در سطح شکبه با هم تعامل کند. برای رسیدن به این تعامل باید وب سرویس به مشتریان بالقوه خود معرفی و شناسانده شود. علاوه بر این، کاربران باید بتوانند نحوه ارتباط با وب سرویس را پیدا کنند، اینکه چه داده هایی نیاز دارد و چگونه پاسخ خود را برمی گرداند و از چه پروتکل هایی استفاده می کند. برای این منظور استانداردی به نام WSDL وجود دارد. یکی از خواص وب سرویس ها توصیف خود آن هاست به این معنی که وب سرویس دارای اطلاعاتی است که نحوه استفاده از آن را توضیح می دهد. این توضیحات در WSDL نوشته می شود، متنی به صورت XML که به برنامه ها می گوید این وب سرویس چه اطلاعاتی لازم دارد و چه اطلاعاتی را برمی گرداند.^[2]

وقتی که سازندگان نرم افزار برای اولین بار SOAP و دیگر تکنولوژی های وب سرویس را ساختند دریافتند که برنامه ها قبل از اینکه شروع به استفاده از یک وب سرویس بکنند باید اطلاعاتی درباره آن را داشته باشند. اما هر کدام از آن سازندگان برای خودشان روشی برای ایجاد این توضیحات ابداع کردند و باعث شد که وب سرویس ها با هم هماهنگ نباشد. وقتی IBM و ماکروسافت تصمیم گرفتند تا استانداردهای خود را یکسان کنند WSDL بوجود آمد. در ماه مارس سال ۲۰۰۱ Microsoft،IBM  و Ariba نسخه 1.1 را به W3C ارائه کردند. گروهی از W3C بر روی این استاندارد کار کردند و آن را پذیرفتند. هم اکنون این تکنولوژی در دست ساخت است و هنوز کامل نشده. ولی اکثر سازندگان وب سرویس از آن استفاده می کنند.^[2]

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

این مهم است که بدانیم WSDL برای برنامه ها طراحی شده است نه برای خواندن آن توسط انسان. شکل فایل های WSDL پیچیده به نظر می آید ولی کامپیوترها می توانند آن را بخوانند و تجزیه و تحلیل کنند. خیلی از نرم افزارهایی که وب سرویس می سازند فایل WSDL مورد نیاز وب سرویس را نیز تولید می کنند بنابراین وقتی برنامه نویس وب سرویس خود را ساخت به شکل خودکار WSDL موردنیاز با آن نیز ساخته می شود و احتیاجی به آموزش دستورات WSDL برای ساختن و استفاده از وب سرویس نیست. WSDL مخفف زبان توصیف سرویس های وب است و یک سند معمولی XML هستند. برنامه کاربردی می تواند یک سند WSDL را بخواند تا بفهمد چه عملیاتی بر روی سرور فعال هستند.  WSDL قابلیت توسعه را دارد تا به سیستم انتهایی شبکه اجازه توصیفات و پیغام هایشان را بدهد صرف نظر از اینکه از چه ساختار پیغامی یا از چه پروتکلی برای ارتباط استفاده می کنند.^[2]



3-1-1  ساختار اسناد WSDL
یک سند را با استفاده از این عناصر کلیدی تعریف می کنیم:
<Types>: نوع داده ای که توسط وب سرویس استفاده می شود.
<messages>: پیغام هایی که توسط وب سرویس استفاده می شود.
<portType>: عملیاتی که توسط وب سرویس انجام می شود.
<binding>: پروتکل ارتباطی که توسط وب سرویس استفاده می شود.
<Port>: آدرسی را برای اتصال مشخص می کند.
<Service>: برای اجتماع مجموعه ای از پورت های مرتبط استفاده می شود.
شکل اصلی یک سند بدین صورت است (شکل3-1 ):

شکل 3-1: ساختار یک WSDL


عنصر binding دو صفت دارد: نام و نوع.
صفت نام، نام پوشش را مشخص می کند که می توان هر نامی برای آن گذاشت.
نوع، به پورت مورد استفاده برای پوشش اشاره می کند.

در این مثال glossaryTerms است. در عنصر soap:binding دو صفت داریم. صفت style می تواند rpc یا document باشد. صفت transport  نوع پروتکل انتقالی را مشخص می کند که در اینجا HTTP است.

عنصر <PortType> بیشترین اهمیت را در یک سند دارد. این عنصر وب سرویس، کاری که انجام می دهد و پیغام هایی که درگیر هستند را توصیف می کند. این عنصر نقطه اتصال به وب سرویس را مشخص می کند. می توان آن را شبیه توابع کتابخانه ای در نظر گرفت. درخواست پاسخ معمولی ترین روش عملیات است اما WSDL چند نوع عملیات را تعریف کرده است.
One-Way: عملیات می تواند پیامی را دریافت کند اما پاسخ نمی دهد.
Request-response: عملیات می تواند پیامی را دریافت کند و حتما پاسخی برگرداند.
Solicit-response: عملیات می تواند پیامی را ارسال کند و منتظر جواب بماند.
Notification: عملیات می تواند پیغامی را ارسال کند اما منتظر پاسخ نمی ماند.^[17]

شکل 3-2 یک مثال از عملیات یک طرفه است. زیرا عملیات ورودی دارد اما خروجی ندارد.

شکل 3-2: عملیات یک طرفه


شکل 3-3 نیز یک مثال از درخواست پاسخ است. زیرا عملیات هم ورودی دارد و هم خروجی

شکل 3-3: درخواست پاسخ



در اینجا نام پورت glossaryTerms و نام عملیات getTerm است. این عملیات یک ورودی و خروجی دارد که ورودی آن getTermRequest و خروجی آن getTermResponse است. message، بخش هر پیغام و نوع آن را مشخص کرده است. ^[18]

[Zohreh Gholami]

3-2  UDDI (Universal Description, Discovery and Integration
بعد از آنکه وب سرویس ایجاد و برای استفاده در سرور قرار گرفت، کاربران باید بتوانند آن را پیدا کنند. این هدف UDDI است. بایگانی UDDI اطلاعات توصیفی یک کسب و کار را دریافت و ذخیره می کند، که شامل اطلاعات وب سرویس هایی که در اختیار می گذارد نیز می شود. این بایگانی همچنین امکان جستجو برای اطلاعات خاصی را نیز در اختیار می گذارد. برای برقراری ارتباط با شرکت، باید اطلاعاتی از آن را داشته باشیم، مانند شماره تلفن، شهر و خیابان آن شرکت، وب سایت آن یا آدرس وب سرویس آن و .... .UDDI یک متن مبتنی بر XML را تعریف می کند که در آن شرکت ها توضیحاتی درباره چگونگی کار وب سرویس شرکت شان و امکانات خود می دهند. برای تعریف این اطلاعات از شکل خاصی که در UDDI توضیح داده شده استفاده می شود. شرکت ها می توانند این اطلاعات را در UDDI شرکت خود نگهداری کنند و تنها به شرکت های مورد نظرشان اجازه دست یابی به آن ها را بدهند یا آن ها را در مکان عمومی و در اینترنت قرار دهند.^[2]

بزرگ ترین و مهم ترین پایگاه UDDI پایگاه UDDI Business Registry یا UBR نام دارد و توسط کمیته UDDI طراحی و اجرا شده است. اطلاعات این پایگاه در چهار نقطه نگهداری می شود: مایکروسافت، IBM، SAP، HP. اطلاعاتی که در یکی از چهار پایگاه تغییر کند در سه تای دیگر نیز اعمال می شود.

اطلاعات درون این پایگاه ها شبیه دفترچه تلفن است که در آنها اطلاعات تماس شرکت ها و توضیحات متنی آنهاست، Yellow Pages  حاوی اطلاعات طبقه بندی شده شرکت ها و اطلاعات درباره نوع فعالیت، شماره کسب و کار، نوع تولیدات آنها و ... می باشد. Green Pages حاوی اطلاعات تکنیکی درباره سرویس های آنها و نحوه پردازش اطلاعات شرکت آنها می باشد. White Pages حاوی اطلاعاتی در مورد خود شرکت است مانند نام شرکت و آدرس آن، اطلاعات لازم برای برقراری ارتباط، آدرس وب سایت و اطلاعات دیگر شناسایی.^[2]

شکل 3-4: اطلاعات درون یک UDDI
[/center]

  SOAP(Simple Object Access Protocol)  3-3 
هدف اصلی SOAP ایجاد روشی جهت فرستادن دیتا بین سیستم هایی است که بر روی شبکه پخش شده اند. وقتی یک برنامه شروع به ارتباط با وب سرویس می کند، پیغام های SOAP وسیله ای برای ارتباط و انتقال دیتا بین آن دو هستند. یک پیغام SOAP به وب سرویس فرستاده می شود و یک تابع یا سابروتین را در آن به اجرا در می آورد به این معنی که این پیغام از وب سرویس تقاضای انجام کاری را دارد. وب سرویس نیز از محتوای پیغام SOAP استفاده کرده و عملیات خود را آغاز می کند. در انتها نیز نتایج را با یک پیغام SOAP دیگر به برنامه اصلی می فرستد.

SOAP یک راه ارتباطی بین برنامه ها متفاوت بر روی سیستم عامل های متفاوت و با تکنولوژی های متفاوت و زبان های متفاوت است. به عنوان یک پروتکل مبتنی بر XML، پروتکل SOAP تشکیل شده از یک سری الگوهای  XML است. این الگوها شکل پیغام های XML را که بر روی شبکه منتقل می شود را مشخص می کند. مانند نوع دیتاها و اطلاعاتی که برای طرف مقابل تفسیر کردن متن را آسان کند. در اصل SOAP برای انتقال دیتا بر روی اینترنت و از طریق پروتکل HTTP طراحی شده است ولی از آن در دیگر مدلها مانند LAN نیز می توان استفاده کرد. وقتی که وب سرویس ها از HTTP استفاده می کنند به راحتی می توانند از Firewall عبور کنند.

یک پیغام SOAP از سه بخش مهم تشکیل شده است: پوشش یا Envelope ، سرآیند یا Header، بدنه یا Body. قسمت پوشش برای بسته بندی کردن کل پیغام به کار می رود. این بخش محتوای پیغام را توصیف و گیرنده آن را مشخص می کند. بخش بعدی پیغام های  SOAP، Header آن است که یک بخش اختیاری می باشد و مطالبی مانند امنیت و مسیریابی را توضیح می دهد. بدنه پیغام SOAP بخشی است که دیتاهای مورد نظر در آن جای می گیرند. دیتاها بر مبنای XML هستند و از یک مدل خاص که الگوها (Schemas) آن را توضیح می دهند تبعیت می کنند. این الگوها به گیرنده کمک می کنند تا متن را به درستی تفسیر کند. پیغام های SOAP توسط سرورهای SOAP گرفته و تفسیر می شود تا در نتیجه آن، وب سرویس ها فعال شوند و کار خود را انجام دهند.^[2]
شکل 3-5 قالب پیغام SOAP را نشان می دهد:

شکل 3-5: قالب پیغام SOAP

عنصر  Envelope ریشه یک پیغام است. این عنصر سند را به عنوان یک پیغام SOAP مشخص می کند. فضای نامی Xmlns:soap همیشه باید مقدار http://www.w3.org/2001/12/soap-envelope  را داشته باشد. اگر فضای نامی دیگری استفاده شود برنامه یک پیغام خطا تولید می کند و پیغام را نادیده می گیرد.

صفت encodingStylr برای مشخص کردن نوع داده استفاده می شود. این صفت در هر عنصری می تواند ظاهر شود و می تواند به یک عنصر و تمام فرزندان آن اعمال شود. یک پیغام SOAP هیچ کدگذاری پیش فرضی ندارد.

همانگونه که در شکل 3-6 ملاحظه می شود، درخواست کننده و فراهم آورنده وب سرویس هر دو باید توانایى تولید و همچنین ترجمه پیام هاى SOAP و نیز توانایى برقرارى ارتباط از طریق شبکه را داشته باشند. معمولاً سرویس دهنده SOAP که بر روى سرویس دهنده وب اجرا می گردد این وظایف را انجام میدهد.^[18]


برقرارى این ارتباط به چهار مرحله زیر تقسیم می شود:
١ – درخواست کننده یک وب سرویس ابتدا یک پیام SOAP مبنى بر درخواست آن از ارائه دهنده وب سرویس مورد نظر تولید می نماید. ارائه دهنده خدمات SOAP (براى مثال یک اجراکننده سمت کاربر SOAP) با استفاده از این پیام SOAP در کنار آدرس شبکه ارائه دهنده سرویس با برقرارى ارتباط با پروتکل سطح شبکه (مثل HTTP) اقدام به ارسال پیام بر روى شبکه می کند.

٢- این پیام بر روى شبکه (اینترنت یا اینترانت) به ارائه-دهنده خدمات SOAP سمت ارائه دهنده سرویس (براى مثال یک سرویس-دهنده SOAP) انتقال می یابد. سرویس دهنده SOAP بعد از تبدیل پیام، آن را به سرویس دهنده وب ارسال می کند. (سرویس دهنده SOAP توانایى تبدیل پیام هاى XML به اشیاء قابل استفاده تحت یک زبان خاص براى استفاده یک برنامه کاربردى را دارا مى باشد)

٣- سرویس دهنده وب با پردازش درخواستى که توسط پیام مطرح گردیده، پاسخ را تولید می کند. قطعاً پاسخ براى انتقال باید به یک پیام SOAP تبدیل شود که این عمل نیز توسط اجرا کننده سمت سرویس دهنده SOAP انجام شده و در نهایت پیام SOAP تولیدى بر روى شبکه براى درخواست کننده ارسال می گردد.

۴- بعد از دریافت پیام SOAP توسط گره درخواست کننده سرویس در شبکه، پیام SOAP رسیده، به اشیاء قابل استفاده توسط زبان برنامه نویسى مبداء تبدیل می گردد و نهاتاً نتیجه توسط برنامه کاربردى استفاده کننده از وب سرویس نمایش داده می شود.^[2]

شکل 3-6: برقراری ارتباط در SOAP

[Zohreh Gholami]

4  فصل چهارم
معماری وب سرویس

4-1  معماری وب سرویس
ابتدا نگاهی به پشته مفهومی وب سرویس می کنیم و چزئیات آن را بررسی می کنیم. سپس به موضوع پروتکل های شبکه و انتخاب آنها می پردازیم. علاوه بر استانداردهای پایه ای که قبلاً توضیح داده شد، تکنولوژی های اضافه تری نیاز است که معماری وب سرویس را کامل کند تا از انواع مختلفی از برنامه ها را پشتیبانی کند. اگرچه استانداردهای پایه ای برای اهداف زیادی مناسب هستند، کسب وکارهای پیچیده تر نیاز به قابلیت ها و توابع اضافه تری دارند.


4-2  پشته وب سرویس
برای به جا آوردن سه عملیات منتشر کردن، پیدا کردن و پیوستن، باید یک پشته وب سرویس وجود داشته باشد که استانداردهایی را برای هر سطح در برداشته باشد. شکل 4-1 پشته وب سرویس را مشخص می کند.

شکل 4-1: پشته وب سرویس

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

لایه بعدی، پیام نگاری مبتنی بر XML، استفاده XML را به عنوان پایه پروتکل پیام نگاری معرفی می کند. SOAP برای این لایه انتخاب شده است به دلایل زیر:
•  یک روش استاندارد پوششی برای پیغام های ارتباطی و RPC است.
•  ساده است.
•  بهتر از ارسال یک متن ساده XML است زیرا دارای ساختار مشخص است.
•  SOAP از عملیات انتشار، پیدا کردن و اتصال پشتیبانی می کند.

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

چون وب سرویس توسط SOAP از  طریق شبکه در دسترس قرار می گیرد، سه لایه اول پشته نیاز است تا بتوان وب سرویس را فراهم کرد یا مورد استفاده قرار داد. در ساده ترین حالت پشته پورتکل HTTP برای لایه شبکه، SOAP برای لایه پیام نگاری مبتنی بر XML، و WSDL برای لایه توصیف سرویس نیاز است. در پشته وب سرویس بنا بر نیاز می توان از پورتکل های دیگر نیز استفاده کرد.^[2]


4-2-1  لایه شبکه
در پایین ترین قسمت پشته وب سرویس لایه شبکه قرار دارد. این لایه همه پروتکل های لایه شبکه معرفی می کند: HTTP، SMTP، FTP، MQ، RMI، IIOP، e-mail و نظایر این ها. پروتکل های شبکه بسته به برنامه هایی که نوشته می شوند مورد استفاده قرار می گیرند.
برای وب سرویس، پروتکلی که در همه جا موجود است، استفاده می شود: HTTP


  XML Messaging-Based Distributed Computing 4-2-2
پایه اصلی معماری وب سرویس پیام نگاری XML است. در حال حاضر استاندارد مورد استفاده در SOAP است. SOAP یک روش پیام نگاری ساده و سبک برای مبادله ساخت یافته پیام ها است. از سه بخش تشکیل شده است که در فصل گذشته به آن پرداخته شد. SOAP با همه پروتکل های شبکه سازگاری دارد و می تواند از طریق آنها ارسال شود. در اکثر مواقع با این بخش¬ها مستقیما سر و کار نداریم.^[2]




5  مراجع

[1] -    D. Tidwell, J. Snell, P. Kulchenko, Programming Web Services with SOAP
[2] -    E. Newcomer, Understanding Web Service XML, WSDL, SOAP, and UDDI
[3] -    H. Kreger, Web Services Conceptual Architecture (WSCA 1.0), IBM Software Group
[4] -    A. Marchant, K. Adlam, P. Bell, T. Duffy, N. A. Smith, 3DG Systems Research and Development: Research into Emerging Spatial Technologies, British Geological Survey (2006)
[5] -    D. Jorgensen, Developing .NET Web Services with XML
[6] -    S. Potts, M. Kopack, Sams Teach Yourself Web Services in 24 Hours, Indianapolis, Indiana, USA
[7] -    Dan W. Randolph, XML-RPC Transport Layer Protocol
[8] -    E. Kidd, XML−RPC HOWTO
[9] -    D. Marshal, Remote Procedure Calls, Available http://www.cs.cf.ac.uk/Dave/
[10] -    D. Winer (1999, Jan.). XML-RPC Specification. UserLand Software, Available: http://www.xmlrpc.com/spec
[11] -    A. latteier, Internet Scripting: Zone and XML-RPC, Available in http://www.xml.com/pub/a/2000/01/xmlrpc/
[12] -    SOAP Description, Available in: http://www.w3.org/TR/soap/
[13] -    http://www.microsoft.com/com/
[14] -    Extensible Markup Language (XML) 1.0, in: http://www.w3.org/TR/REC-xml
[15] -    Getting Started with XML Security, in: http://www.sitepoint.com/
[16] -    http://www.fjhirsch.com/xml/xmlsec/starting-xml-security.html
[17] -    http://www.w3.org/TR/wsdl
[18] -    www.w3schools.com
[19]- E. Kestro, XML for the World Wide Web: Visual QuickStart Guide,  ISBN 0-201-71098-6.