GXA ، معماری و اجزای تشکیل دهنده آن

GXA چیست؟

خاستگاه GXA را می ‏توان از مقاله‏ های با عنوان Web Services Framework از Microsoft و IBM دانست. در این مقاله کارهایی شرح داده شده بود، که باید انجام شوند، تا یک وب سرویس (وب سرویس یک قسمت از منطق برنامه است که از طریق اینترنت قابل دسترسی است) بتواند بین سازمان‏ها (با ساختارهای متفاوت و زیربناهای مختلف)، اجرا شده و قابل استفاده شود. برخی از موارد مطرح شده در این مقاله عبارتند از:

1. امنیت: مواردی که رعایت آنها در مورد خاستگاه و محتویات یک پیام تضمین کافی را بدهد.
2. تراکنش‏ها: چگونگی عملکرد، هنگامی که چند سرویس بر روی داده ‏های چند لایه، کار می‏ کنند و چگونگی اثر داده ‏ها بر هم.
3. هماهنگی: چگونگی تعامل و انتقال اطلاعات بین وب سرویس های مختلف.
4. پیام رسانی مطمئن: مطمئن شدن از اینکه کسی که پیام را دریافت می‏کند همان است که پیام برای او ارسال شده است.
5. تعیین مسیر برای پیام.
6. چگونگی الصاق داده‏ های دودویی به پیام.

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

معماری GXA

GXA یک معماری چند لایه دارد که برروی خصوصیات وب سرویس بنا شده است. لایه بالاتر از این لایه را به دو بخش می‏توان تقسیم کرد.

• لایه اول که شامل ماژولهای SOAP است. مانند WS-Security وWS-Attachment که به متن و ساختار پیام می ‏پردازند.
• لایه دوم، شامل یک ‏سری پادمان زیرساختی است. این لایه مشخص می‏کند که پیام ‏ها چطور درپیِ هم بیایند، تا پاسخ یک نیاز ما باشند. برای مثال ترتیب ارسال پیام‏ها به یک وب ‏سرویس برای به‏ روز کردن یک رکورد از پایگاه داده در این قسمت مشخص می ‏شوند.

شکل زیر معماری کلی پیاده سازی شده در GXA را نشان می دهد. در ادامه به شرح و بسط این لایه ها و موارد مهمی که در طراحی آنها درنظرگرفته شده و پیاده ‏سازی شده است، می پردازیم.

1- امنیت (WS-Security)

یکی از دغدغه ‏های مهم در استفاده از وب سرویس‏ها، امنیت است، که شامل موارد زیر است:

1. نحوه کد کردن و پنهان ‏سازی اطلاعات.
2. نحوه اعتبارسنجی.
3. امضای الکترونیکی.

WS-Security به نیازهای بالا پاسخ می گوید و به نیازهای شما در برقرار امنیت پاسخ می دهد. WS-Security یک ‏سری مشخصات و دستورالعمل است، که چگونگی پیاده ‏سازی این موارد را مشخص می‏ کند و از طریق WSDK قابل دسترسی است. WS-Security مشخص می‏ کند که چگونه نشانه ‏های امنیتی با پیام همراه می ‏شوند تا امنیت لازم در استفاده از وب سرویس ها و SOAP فراهم شود.

WS-Security دو شیوه X.509 و Kerberos را پشتیبانی می‏کند.

برای افزودن گواهی به پیام ‏ها و جلوگیری از دستکاری آنها، لازم است که پیام‏ها کد شوند و با امضای دیجیتال همراه شوند. برای این کار باید از XML-Encrypt و  XML-Signatureاستفاده کرد که نحوه استفاده از این دو ابزار، در WS-Security آورده شده است.

2- تراکنش (WS-Transaction)

با زیاد شدن تعداد وب سرویس‏ های مورد استفاده در یک برنامه، نحوه تعامل بین آنها و اطمینان حاصل کردن از اعمال شده تغییرات، به عنوان یک دغدغه مطرح می شود و ضرورت داشتن یک استاندارد، بیش از پیش ضروری به نظر می رسد. WS-Transaction یک شرح و بسط است که توسط IBM و BEA منتشر شده است که در آن نحوه هماهنگ کردن عملیات در وب سرویس ها، به طوری که از اعمال شدن درست تغییرات در پایگاه داده اطمینان حاصل شود، شرح داده شده است. WS-Transaction به تنهایی یک راه حل جامع نیست و با استفاده از WS-Security  (که قبلا توضیح داده شده) و WS-Coordination (که توضیحات آن در ادامه خواهد آمد) تکمیل می شود.

در WS-Transaction دو نوع تراکنش وجود دارد. یکی تراکنش بنیادین (Atomic Transaction) است که مبتنی بر حفاظت بسیار زیاد است و دیگری Business Activity که تراکنش هایی با عمر زیاد را پشتیبانی می‏ کند و حفاظت کمتری دارد.

3- هماهنگی (WS-Coordination)

این قسمت با WS-Transaction ارتباط تنگاتنگی دارد WS-Coordination به برنامه نویسان اجازه می‏دهد تا پردازش‏های پیچیده بین وب سرویس ‏ها تعریف کنند و نحوه تعامل وب سرویس ‏ها و گردش داده (DataFlow) بین وب سرویس‏ها را مشخص کنند. زبان‏های مختلفی برای این کار وجود دارد مانند XLANG که WSFL (Web Services Flow Language) که متعلق به مایکروسافت و آی ‏بی ‏ام هستند.(کارگزار BizTalk مایکروسافت از Xlang استفاده می‏کند) البته دو شرکت مذکور به همراه BEA یک شرح و بسط منتشر کرده‏اند و نام آن را BPEL4WS (Business Process Execution Language for Web Services) گذاشته‏اند (این نام گذاری در نوع خود جالب است). البته هیچ پیاده ‏سازی ‏ای تا کنون برای آن انجام نشده است.

Sun به همراه SAP ، نیز WSCI (Web Services Choreography Interface) را ایجاد کرده است و از آن استفاده می‏ کند.

4- فرستادن پیام های مطمئن (Reliable Messaging)

بسیاری از برنامه ‏ها به تضمینی در مورد رسیدن پیام آنها به برنامه مقصد (حتی در صورت پایین بودن سرویس در آن لحظه) احتیاج دارند. مایکروسافت از MSMQ (Microsoft Message Queuing) و آی ‏بی ‏ام ازMQ استفاده می‏کند که هر دو آنها قابلیت کارکردن با پهنه های (Platformهای) متفاوت را ندارند و با دیوارهای آتش نیز مشکلاتی دارند.

5- مسیر یابی و ارجاع (Routing and Referral)

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

راه حل مایکروسافت برای این کار WS-Routing است و WS-Referral است و راه هایی را مشخص می‏کند که کارگزارها می ‏توانند به طور پویا، واسطه‏ ها (کارگزارهای میانی که پیام ها از آنها گذر می کند تا به مقصد برسد) را شناسایی کرده و راه‏های مناسب را بین آنها انتخاب کنند. هر دو مورد در WSDK پیاده ‏سازی شده و قابل استفاده است.

6- انتقال داده‏های دودویی (Binary Attachments)

چون وب سرویس ‏ها براساس SOAP و XML بنا شده ‏اند، پس مبتنی بر متن می‏باشند. بسیاری از اطلاعات رد و بدل شده در وب‏سرویس‏ها، متنی است بنابراین مشکلی در این موارد وجود ندارد. ولی برخی از داده‏ ها مانند صدا و تصویر چنین نیستند. برای انتقال چنین داده‏ هایی که دودویی هستند باید الگوریتمی داشته باشیم که اطلاعات دودویی را به متن تبدیل کند. یکی از این الگوریتم ها Base64 Encoding نام دارد.

البته کد کردن و کدگشایی باعث بالا رفتن بار پردازشی خواهد شد و حجم اطلاعات نیز افزایش خواهد یافت. برای حل این مشکل باید راهی انتخاب شود که در آن بتوان این اطلاعات دودویی را به پیام ضمیمه کرد. مایکروسافت WS-Attachment و  DIME (Direct Internet Message Encapsulation) را در این زمینه، به عنوان راه حل ارایه می‏کند که راه ‏هایی برای ضمیمه کردن اطلاعات به پیام و Encapsulate کردن آن دارد.

هر دو این موارد در WSDK پیاده ‏سازی شده‏اند و قابل استفاده هستند. سایر شرکت‏ها مانند IBM و OASIS (Organization for the Advancement of Structured Information Systems) این دو مورد را نپذیرفته و از سایر روش‏ها استفاده می‏کنند..