سرویسهای وب فعال کننده برنامه Cold Fusion

هدف از این مقاله کمک به توسعه دهندگان Cold fusion در فعال کردن برنامه های کاربردی CFMX بوسیله سرویسهای وب آنها است و این مقاله به ذکر موضوعاتی می پردازد که شرکت Averum با آنها مواجه شده است سرویسهای وب Averum Billing را فعال می سازند و سیستم billing تنظیم صورتحساب و تهیه لایحه مالی آن برای ASPها Application Service Providers بکار می رود

۱۰موضوع شناخته و بررسی شده.

هدف از این مقاله کمک به توسعه دهندگان Cold fusion در فعال کردن برنامه‌های کاربردی CFMX بوسیله سرویسهای وب آنها است و این مقاله به ذکر موضوعاتی می‌پردازد که شرکت Averum با آنها مواجه شده است. سرویسهای وب Averum Billing را فعال می‌سازند و سیستم billing (تنظیم صورتحساب و تهیه لایحه‌ مالی) آن برای ASPها Application Service Providers بکار می‌رود. بنظر ما روش بکار رفته در Averum تنها روش یا بهترین روش برای پیاده‌سازی سرویسهای وب در برنامه‌کاربردی شما نیست و هدف اصلی از نقل این مقاله آگاه ساختن شما از موضوعات مختلفی است که ما با آنها مواجه شده‌ایم. در ارائه پاسخها و راه حل‌های ما و مذاکرات بین انجمن Cold Fusion برای کسب بهترین تجربیات در فعل سازی برنامه کاربردی خود با سرویسهای وب شرکت کنید.

برای آشنایی کسانی که با سرویسهای وب آشنایی ندارند، باید بگوئیم که سرورها می‌توانند با استفاده از استانداردهای XML به تبادل پیام با یکدیگر بپردازند. سرویس‌های وب علیرغم آنچه درباره‌اشان اغراق شده است، شما را قادر به کاری نمی‌سازند که قبلا غیرممکن بوده است. توسعه دهندگان Cold Fusion از زمانیکه اولین نسخه Cold Fusion عرضه شده، از برچسب CF HTTP برای ارسال یک در خواست HTTP به سرور دیگر استفاده می‌کردند و سپس به تحلیل پاسخ آن می‌پرداختند. ارسال (یا دریافت) یک در خواست از طریق سرویسهای وب فقط همین بود که با استفاده از استاندارد XML انجام می‌شد.

● سرویسهای وب و CFMX

ماکرومدیا با ارائه برنامه Cold Fusion MX، پیاده‌سازی سرویسهای وب را بسیار آسان ساخت. جهت دریافت یک در خواست سرویس‌های وب، فقط باید یک Cold Fusion Component (CFC) ایجاد کنید و برای تابع‌هایی که باید بعنوان یک سرویس وب در دسترس باشند، مقدار “access” را روی “remote” تنظیم کنید. یک مزیت سرویسهای وب ویژگی Self describing آنها است یعنی خود سرویس وب عمل مستندسازی را انجام داده و به سیستم‌های دیگر (یا افراد) نوع فیلد ورودی و خروجی (نوع فیلد و نام) برای تابع سرویسهای وب را اعلام می‌کند. این سند WSDL یا Web Services Definition Language نامیده می‌شود. مثلا برای ایجاد فایل WSDL برای هر تابع “access remote” در Cold fusion Component باید از طریق مرورگر خود که به “? Wsdl” ختم می‌شود، آن مولفه را فراخوانید.

http://localhost/yourcomponent.cfc?wsdl

فایل بدست آمده یک سند WSDL است که تنها یک سند UML می‌باشد. برای ارائه یک سرویس وب از طریق Cold Fusion می‌توانید از برچسب CFINVOKE استفاده کنید، درست مثل اینکه در خواستی را به یک تابع معمولی CFC ارائه می‌دهید. روشهای دیگر فراخوانی تابعهای دیگر نیز همینطور و به همین سادگی است (مثل کار با CFSCRIPT). فرقی ندارد که در خواست سرویس وب به چه سروری ارسال شده است، سروری که برنامه Cold Fusion، جاوا، .NET یا PHP را اجرا می‌کند.

چطور سرویسهای وب برنامه‌های کاربردی را فعال می‌سازند؟

▪ یک نمونه از مطالعات و بررسیهای انجام شده:

پیاده‌سازی تابعها و برنامه‌های کاربردی سرویسهای وب در برنامه Cold Fusion آسان است. ولی با سرویسهای وبی که برنامه شما را فعال می‌سازند کاملا تفاوت دارد و تنها ایجاد چند تابع CFC و تنظیم “access” روی “remote” کفایت نمی‌کند. بلکه شناسایی و تایید اعتبار کاربری که این در خواست را ارائه می‌دهد و همینطور صدور مجوز برای استفاده از این تابع و تایید هدفشان از این در خواست الزامی است. برای مثال اگر هدف روز‌آمدسازی یک محصول است ابتدا باید کاربر را شناسایی نمایید. یعنی آیا آنها به سیستم وصل شده‌اند یا نه. اگر کاربر به سیستم وصل نشده یا از زمان نشست آنها مدت طولانی می‌گذرد و اعتبار آن تمام شده است، باید مجددا به سیستم وصل شوند. پس از اینکه هویت آنها را شناسایی نمودید، باید مشخص کنید که آیا حق و اجازه روز آمد سازی محصول را دارند یا نه، که معمولا این مجوز یا براساس نقش و وظیفه یا مجوز اختصاصی صورت می‌گیرد و بالاخره باید مشخص کنید که آیا این کاربر مالک محصولی است که می‌خواهد آنرا روز آمد سازد یا خیر، یعنی این محصول باید به او تعلق داشته باشد نه کاربر دیگری (بدون ذکر اینکه این محصول خود وجود داشته است.) البته باید مقادیر روز‌آمد شده را نیز در هنگام ارائه از طریق یک فرم معمولی مبتنی‌بر مرورگر، تایید نمایید و اگر اشتباهی صورت گیرد باید در هنگام نمایش پیامهای خطا، به کاربر بگویید که در خواست جدید آنها با شکست روبرو شده است. بدنبال آن به بررسی و مطالعه سرویسهای وب فعال کننده Overrun Billing می‌پردازیم که به خوانندگان MXDJ امکان می‌دهد تا به موضوعات مختلفی که ما با آن مواجه شده‌ایم نگاهی کلی بیندازند. بعضی از این مشکلات به برنامه Cold Fusion مربوط می‌شوند و بقیه نیز مشکلاتی هستند که به پلات‌فرم توسعه یافته شما ربطی ندارند، ۱۰موضوع اصلی و اولیه‌ای که من آنها را لیست نموده و درباره آنها توضیح خواهم داد عبارتند از:

۱. محدودیت در اندازه فایل

۲. کنترل نشست

۳. CFCهای اضافه

۴. برنامه‌ای که CFC را احاطه کرده است

۵. IDهای اختصاصی در مقابل IDهای داخلی

۶. تمام فیلدهای مورد نیاز

۷. برگشت و ارائه کوئریها (پرس‌وجوها)

۸. فیلدهای Boolean (بولی)

۹. پیامهای خطا

۱۰. اشکال زدایی

۱. محدودیت در اندازه فایل

برای توسعه دهندگان که از Fusebox یا روشهای دیگری استفاده می‌کنند که در آن تمام صفحات بوسیله index.cfm یا چند فایل دیگر فراخوانده می‌شوند. بهترین راه این است که در تمام در خواستهای سرویسهای وب از همان Cold Fusion Component استفاده کرد. متاسفانه چنین انتخابی صورت نمی‌گیرد و هرگز چنین اتفاقی رخ نخواهد داد. جاوا از یک محدودیت ۶۴ کیلوبایتی در اندازه فایل برخوردار است که بسرعت با چند تابع و شناسه جای آن دردسترس قرار می‌گیرد. شما می‌توانید تمام قسمتهای خارجی یک مولفه را جابجا نمایید (همانطور که توصیه شده است) ولی باز با مشکل محدودیت در اندازه روبرو شوید.همچنین پی‌می‌برید که برچسب CFRETURN باید روی خود CFC قرار داشته باشد نه بصورت یک فایل ضمیمه، لذا به چند متغیر برای ذخیره مقادیر اعلام شده و برگشتی نیاز دارید. در پایان اینکه اگر واقعا سرویسهای وب برنامه‌کاربردی شما را فعال می‌سازد باید از رویای استفاده از همان CFC برای همه تابعها و کاربردهای سرویسهای وب صرفنظر نمایید: همچنین باید از چند CFC استفاده نمایید. بنابراین ممکن است ناچار به تفکیک چند تابع در گروههای CFC۱ و CFC۲ مناسبی باشید که intuitive (مملوس) هم نیستند.

۲. کنترل نشست

اگر در برنامه کاربردی شما ورود و اتصال کاربران به سیستم الزامی است پس آنها باید اینکار را قبل از دستیابی به داده از طریق سرویسهای وب انجام دهند. علیرغم مستندسازی برنامه Cold Fusion، کنترل نشستها در سرویسهای وب تنها به استفاده از CFAPPLICATION یا کوکی‌ها ختم نمی‌شود. نشستهای معمولی مبتنی‌بر مرورگر براساس کوکی‌ها کار نمی‌کنند و به راه‌حل ابتکاری بیشتری نیاز دارند. در هنگام فراخوانی مولفه سرویس وب می‌توان CFFD و CFTOKEN را ضمیمه URL نمود ولی ما تا بحال این کار را انجام نداده‌ایم چون این روش در سرویسهای وب مخصوص URL برای کمک به تغییر سرویس وب، استاندارد نمی‌باشد. به همین علت است که شما از چند متغیر ورودی برخوردار هستید. همچنین تنظیمات پیش‌فرض برای زمان یک نشست Cold Fusion مبتنی‌بر مرروگر ۲۰ دقیقه بود. به همین خاطر، سرویس گیرنده‌های ما تقاضای دوره زمانی بیشتری را داشتند. برای Overrun Billing ما زمان ۲ ساعت را انتخاب کردیم که در صورت ذخیره این نشستها در حافظه خطرناک بود. بهترین روش طبق معمول برای تصمیم‌گیری در مورد موضوعات جدید رویت سایتهای دیگر و نحوه برخورد آنها با این موضوعات است. پس از مرور پیاده‌سازی سرویسهای وب بوسیله سایتهای دیگر ترجیح دادیم از یک متغیر UUID بعنوان نشست ID استفاده کنیم که ظاهرا بهتر از همه بود.

پس از ورود با یک نام‌کاربر و رمز به سیستم (در مورد ما، نام شرکت)، تابع ورود به سیستم سرویسهای وب در Overrun Billing یک UUID را گزارش می‌دهد که باید بدنبال هر در خواست پیاپی سرویسهای وب ارائه شود. اینکار نام کاربر را تایید می‌نماید بطوریکه دیگر برای هر در خواست نیازی به تعریف نام کاربر و رمز وی نمی‌باشد. جهت امنیت بیشتر، Overrun Billing آدرس IP بکار رفته را در هنگام اتصال به سیستم ردیابی می‌کند. تمام در خواستهای پیاپی سرویسهای وب برای UUID باید از همان آدرس IP نشات بگیرند و گرنه در خواست بعلت عدم ورود و اتصال کاربر به سیستم، رد خواهد شد.

همچون هر نشست دیگر، باید متغیرهای “Session” را ذخیره نمود. چون ما نمی‌توانیم متغیرهای معمولی نشست را ذخیره نماییم (بین در خواستها)، بنابراین نشستی نداریم و نمی‌توانیم متغیرهای در حوزه و حیطه Session را ذخیره کنیم بلکه بجای آن برای شبیه سازی متغیرهای این نشست باید یک جدول Web Service Session را به پایگاه داده خود که اطلاعات ضروری هر نشست را ردیابی می‌کند، اضافه نماییم.

گرچه این عمل تعداد و نوع متغیرهای نشست قابل ذخیره ما را محدود می‌کند ولی تنها راه‌حل مناسب برای این کار است. ابتدا با استفاده از یک ساختار در حوزه برنامه که شاخص آن ساختار UUID نشست سرویسهای وب بود، به پیاده‌سازی هر نشست پرداختیم مقدار بدست آمده نیز ساختاری است که متغیرهای لازم برای هر نشست را ذخیره می‌کند. مثل: CFSET Application Web Service Session [the UUID].user=۱ ID این روش دارای یک اشکال اصلی از نظر مقیاس پذیری است. افزودن یک نشست جدید یا روز آمد سازی نشست موجود، به روز آمد سازی یک متغیر در قلمرو حوزه برنامه نیاز داشت و برای تضمین اینکه تنها یک فرآیند در حال روز آمد سازی متغیر می‌باشد باید از یک CFLOCK استفاده نمود. اگر می‌خواهید بطور همزمان مشتریان بیشتری به رابط سرویسهای وب دسترسی داشته باشند قفل کردن دائم یک متغیر تحت حوزه برنامه برایتان دردسر می‌شود و باید از این کار پرهیز نمایید.

بالاخره همچون سایر نشستها، این مورد نیز با خروج از سیستم یا اتمام زمان مورد نظر خاتمه می‌یابد. گرچه ما نمی‌خواستیم تابع “logout” سرویسهای وب را ایجاد کنیم ولی زمان نشست سرویسهای وب بعلت عدم فعالیت پایان می‌یابد (درست مثل نشست مرورگر) علاوه‌براین CFAPPLICATION اینکار را بطور خودکار برایتان انجام میدهد و تنها کاری که ما باید انجام دهیم این است که این قابلیت را خودمان فعال کرده و به اجرا در آوریم. به همین منظور، یک متغیر “Session” را که ذخیره کننده آخرین زمان و تاریخی است که یک “کاربر” در خواست سرویسهای وب را ارائه نموده، ایجاد کردیم تا ببینیم آیا زمان نشست سرویسهای وب باید براساس عدم فعالیت آنها پایان یابد یا خیر، که آنرا با هر در خواست کنترل کردیم. ما پایان مهلت زمانی هر نشست را ۲ساعت بعد از پایان فعالیت آن قرار دادیم. ابتدا برای تضمین اینکه این نشست فعال است یا نه با هر در خواست سرویس وب اعتبار UUID را تایید نمودیم سپس برای تعیین اینکه زمان یک نشست پایان یافته است زمان و تاریخ فعلی را با آخرین در خواست مقایسه و کنترل کردیم. برای حذف نشستهایی که تاریخشان منقضی شده بود یک اسکریپت جدول بندی و زمان‌بندی شده‌ای را تنظیم کردیم که تمام نشستهای سرویسهای وب، یعنی ردیفهای در پایگاه داده که در آن بیش از ۲ساعت از روی آخرین در خواست می‌گذشت را حذف می‌کند.

---