خاستگاه GXA را می توان از مقاله ای با عنوان Web Services Framework از Microsoft و IBM دانست. در این مقاله کارهایی شرح داده شده بود، که باید انجام شوند، تا یک وب سرویس (وب سرویس یک قسمت از منطق برنامه است که از طریق اینترنت قابل دسترسی است) بتواند بین سازمانها (با ساختارهای متفاوت و زیربناهای مختلف)، اجرا شده و قابل استفاده شود. برخی از موارد مطرح شده در این مقاله عبارتند از:
GXA، نسخه Microsoft برای پیاده سازی مقاله ی مطرح شده است. GXA یک سری راهبرد با هدف مرتب کردن وب سرویس ها و یکپارچه سازی برنامه ها در بستر اینترنت است. در واقع هدف GXA، استفاده از وب سرویس ها با یک استاندارد خاص است که این مهم، هماهنگ شدن برنامه هایی را به دنبال خواهد داشت که در بسترهای مختلف طراحی شده و سرویس می دهند.
معماری GXA
GXA یک معماری چند لایه دارد که برروی خصوصیات وب سرویس بنا شده است. لایه بالاتر از این لایه را به دو بخش می توان تقسیم کرد.
شکل زیر معماری کلی پیاده سازی شده در GXA را نشان می دهد. در ادامه به شرح و بسط این لایه ها و موارد مهمی که در طراحی آنها درنظرگرفته شده و پیاده سازی شده است، می پردازیم.
۱- امنیت (WS-Security) در GXA
یکی از دغدغه های مهم در استفاده از وب سرویس ها، امنیت است، که شامل موارد زیر است:
WS-Security به نیازهای بالا پاسخ می گوید و به نیازهای شما در برقرار امنیت پاسخ می دهد. WS-Security یک سری مشخصات و دستورالعمل است، که چگونگی پیاده سازی این موارد را مشخص می کند و از طریق WSDK قابل دسترسی است. WS-Security مشخص می کند که چگونه نشانه های امنیتی با پیام همراه می شوند تا امنیت لازم در استفاده از وب سرویس ها و SOAP فراهم شود.
WS-Security دو شیوه X.509 و Kerberos را پشتیبانی میکند.
برای افزودن گواهی به پیام ها و جلوگیری از دستکاری آنها، لازم است که پیامها کد شوند و با امضای دیجیتال همراه شوند. برای این کار باید از XML-Encrypt و XML-Signatureاستفاده کرد که نحوه استفاده از این دو ابزار، در WS-Security آورده شده است.
۲- تراکنش (WS-Transaction) در GXA
با زیاد شدن تعداد وب سرویس های مورد استفاده در یک برنامه، نحوه تعامل بین آنها و اطمینان حاصل کردن از اعمال شده تغییرات، به عنوان یک دغدغه مطرح می شود و ضرورت داشتن یک استاندارد، بیش از پیش ضروری به نظر می رسد. WS-Transaction یک شرح و بسط است که توسط IBM و BEA منتشر شده است که در آن نحوه هماهنگ کردن عملیات در وب سرویس ها، به طوری که از اعمال شدن درست تغییرات در پایگاه داده اطمینان حاصل شود، شرح داده شده است. WS-Transaction به تنهایی یک راه حل جامع نیست و با استفاده از WS-Security (که قبلا توضیح داده شده) و WS-Coordination (که توضیحات آن در ادامه خواهد آمد) تکمیل می شود.
در WS-Transaction دو نوع تراکنش وجود دارد. یکی تراکنش بنیادین (Atomic Transaction) است که مبتنی بر حفاظت بسیار زیاد است و دیگری Business Activity که تراکنش هایی با عمر زیاد را پشتیبانی می کند و حفاظت کمتری دارد.
۳- هماهنگی (WS-Coordination) در GXA
این قسمت با 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) را ایجاد کرده است و از آن استفاده می کند.
۴- فرستادن پیام های مطمئن (Reliable Messaging) در GXA
بسیاری از برنامه ها به تضمینی در مورد رسیدن پیام آنها به برنامه مقصد (حتی در صورت پایین بودن سرویس در آن لحظه) احتیاج دارند. مایکروسافت از MSMQ (Microsoft Message Queuing) و آی بی ام ازMQ استفاده میکند که هر دو آنها قابلیت کارکردن با پهنه های (Platformهای) متفاوت را ندارند و با دیوارهای آتش نیز مشکلاتی دارند.
۵- مسیر یابی و ارجاع (Routing and Referral) در GXA
مفهوم مسیریابی (route) این است که شما تعیین کنید که پیام شما چه مسیری را برای رسیدن به مقصد طی خواهد کرد. برای مثال، یک تراکنش مالی دارید و میخواهید نهادی را هم از این کار مطلع کنید. برای این کار، باید قبل از رسیدن پیام به مقصد از یک پایانه در بین راه عبور کند و در آنجا نیز ثبت شود تا نهاد موردنظر نیز از این تراکنش مطلع شود.
راه حل مایکروسافت برای این کار WS-Routing است و WS-Referral است و راه هایی را مشخص میکند که کارگزارها می توانند به طور پویا، واسطه ها (کارگزارهای میانی که پیام ها از آنها گذر می کند تا به مقصد برسد) را شناسایی کرده و راههای مناسب را بین آنها انتخاب کنند. هر دو مورد در WSDK پیاده سازی شده و قابل استفاده است.
۶- انتقال دادههای دودویی (Binary Attachments) در GXA
چون وب سرویس ها براساس SOAP و XML بنا شده اند، پس مبتنی بر متن میباشند. بسیاری از اطلاعات رد و بدل شده در وبسرویسها، متنی است بنابراین مشکلی در این موارد وجود ندارد. ولی برخی از داده ها مانند صدا و تصویر چنین نیستند . برای انتقال چنین داده هایی که دودویی هستند باید الگوریتمی داشته باشیم که اطلاعات دودویی را به متن تبدیل کند. یکی از این الگوریتم ها Base64 Encoding نام دارد.
البته کد کردن و کدگشایی باعث بالا رفتن بار پردازشی خواهد شد و حجم اطلاعات نیز افزایش خواهد یافت. برای حل این مشکل باید راهی انتخاب شود که در آن بتوان این اطلاعات دودویی را به پیام ضمیمه کرد. مایکروسافت WS-Attachment و DIME (Direct Internet Message Encapsulation) را در این زمینه، به عنوان راه حل ارایه میکند که راه هایی برای ضمیمه کردن اطلاعات به پیام و Encapsulate کردن آن دارد.
هر دو این موارد در WSDK پیاده سازی شده اند و قابل استفاده هستند. سایر شرکتها مانند IBM و OASIS (Organization for the Advancement of Structured Information Systems) این دو مورد را نپذیرفته و از سایر روشها استفاده میکنند..