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

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

هدف از این مقاله کمک به توسعه دهندگان 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 را تایید نمودیم سپس برای تعیین اینکه زمان یک نشست پایان یافته است زمان و تاریخ فعلی را با آخرین در خواست مقایسه و کنترل کردیم. برای حذف نشستهایی که تاریخشان منقضی شده بود یک اسکریپت جدول بندی و زمان‌بندی شده‌ای را تنظیم کردیم که تمام نشستهای سرویسهای وب، یعنی ردیفهای در پایگاه داده که در آن بیش از ۲ساعت از روی آخرین در خواست می‌گذشت را حذف می‌کند.۳. CFCهای اضافی
با وجود اینکه اکثر توسعه دهندگان ترجیع می‌دهند تمام مولفه‌ها را فقط در یک دایرکتوری ذخیره کنند ولی ما می‌خواستیم هر مولفه را در همان دایرکتوری با کارآیی مربوط به خود آن ذخیره کنیم. ولی لازمه انجام چنین کاری رجوع مشتریان به مولفه‌های سرویسهای وب در یک گروه دایرکتوری متفاوت بود. البته اگر همه مولفه‌ها از طریق سرویسهای وب موجود در همان دایرکتوری دردسترس قرار می‌گرفتند اینکار ساده‌تر بود. گرچه برخورداری از چند مولفه اضافی بنظر مضحک و بی‌فایده است ولی بهرحال اینکار واقعا لازم بود. مولفه‌های سرویسهای وب دارای یک نام مشابه ولی با یک پیشوند “.WS” می‌باشد اکثر کاربردها و توابع سرویسهای وب در Averum Billing از یک نام (روش) تابع برخوردار هستند همچون تابع سرویسهای غیر وب مربوطه.
به چند دلیل تابع CFC و نسخه سرویسهای وب آن لیست متفاوتی از شناسه‌ها را می‌پذیرند. بعدا برای پی‌بردن به علت آن به بررسی جزییاتی از قبیل IDهای اختصاصی، جستجو، روز آمد سازی و فیلدهای بولی می‌پردازیم. البته بهترین و روشن‌ترین مثال همان UUID است که وجود آن برای اعتبار بخشیدن به یک نشست الزامی است. یک دلیل ساده آن این است که Averum Billing شامل فیلدهایی است که کاربرد داخلی دارند ولی مستقیما بوسیله سرویس گیرنده مشخص نشده‌اند. بطورکلی سرویس گیرنده‌ها حتی از وجود این فیلدها بی‌خبر است. این فیلدها بعنوان شناسه در تابع CFC عمل می‌کنند، ولی نه در تابع CFC سرویسهای وب. در حالیکه در جاوا شما می‌توانید چند تابع با یک نام و چند شناسه مختلف داشته باشید ولی در Cold Fusion اینطور نیست.
۴. CFCهای در احاطه و حوزه برنامه کاربردی
وقتی اولین مولفه سرویسهای وب خود را ایجاد کردیم و آن را تست نمودیم اتفاق جالبی رخ داد. ما برای فراخوانی مولفه و سهولت کار از CFINVOKE استفاده کردیم و گمان می‌کردیم که بین فراخوانی تابع به عنوان یک مولفه در مقابل فراخوانی آن بعنوان یک سرویس وب هیچ تفاوتی وجود ندارد. بعبارت دیگر کار “<CFINVOKE Component =" را با <CFINVOKE Web service =" یکسان در نظر گرفتیم.
هر چه تا بحال حدس زده‌اید اشتباه بوده است. اکثر مولفه‌های ما به توابع موجود در مولفه‌های دیگر دسترسی دارند. در این نمونه‌ها فقط از “CFINVOKE Component =" برای دستیابی به یک مولفه دیگر استفاده می‌کردیم. وقتی مولفه‌ای را فرامی‌خوانید که در همان دایرکتوری وجود ندارد، مقدار “Component” باید از دایرکتوری عمومی ریشه سایت شما آغاز شود که به نصب برنامه طراحی و نقشه‌برداری در Cold Fusion Administrator نیاز دارد. چون این موضوع نسبتا نامطلوب است لذا ترجیع دادیم بجای اینکه CFMX را در حالت طبیعی جاوا به اجرا در آوریم آنرا هوشمندتر سازیم. این نوع فراخوانی تابع در یک مولفه دیگر در صورتی عملکرد خوبی دارد که آن مولفه از طریق <CFINVOKE Component =" فراخوانده شود ولی به دلایل نامشخص و عجیبی اگر به عنوان یک سرویس وب فراخوانده می‌شود کارآیی ندارد. بله این دقیقا همان تابعی است که فراخوانده شده است و CF نیز اگر بعنوان یک سرویس وب فراخوانده شود عجیب‌تر است. بنابراین متوجه شدیم که تنها راه دستیابی به یک تابع در مولفه دیگر با فراخوانی بوسیله یک سرویس وب، ذخیره مولفه در دامنه و حوزه Application است. این روش خوبی برای ذخیره مولفه‌های دارای کاربرد بیشتر در حوزه Application جهت عملکرد بهتر است. لذا ما این راه را حداقل برای مولفه‌هایی که کاربرد بیشتری دارند در نظر گرفتیم. ولی مقتضیات و نیازهای سرویسهای وب به ما امکان انتخاب بهتری را در این زمینه نداده است.
تنها اشکال ذخیره مولفه‌ها در حوزه برنامه این است که باید مقدار مولفه موجود در حوزه برنامه را هر وقت که فایل CFC روز آمد می‌گردد، “روز آمد” سازیم. به همین منظور یک لینک ساده را به رابط مدیر خود اضافه کردیم تا این مقادیر را در صورت لزوم از نو تنظیم نماید. این مولفه‌ها که همان سرویسهای وب نامیده می‌شوند در حوزه برنامه ذخیره نمی‌شوند چون هرگز بوسیله مولفه‌های دیگر فراخوانده نمیشوند. آنها فقط مستقیما بوسیله سرویس گیرنده‌ها و آن هم هنگام دستیابی به یک تابع سرویسهای وب فراخوانده می‌شوند. بنابراین ذخیره آنها در حوزه برنامه هیچ سودی ندارد. با کمی وقت و توجه پی‌می‌برید که اگر یک CFC سرویس وب را روز آمد نمایید، Cold Fusion نمی‌تواند تغییرات بوجود آمد. در CFC روز آمد شده را تشخیص دهد، مگراینکه آنرا از نو راه‌اندازی نمایید ولی پس از یک مدت زمان کوتاه می‌تواند تغییرات را تشخیص دهد که ما نمی‌توانیم تا آن موقع و برای مدت زیادی صبر کنیم.
همچنین از چند تابعی که در CFSCRIPT نوشته شده‌اند استفاده می‌کنیم. بیشتر آنها در مولفه‌های ذخیره شده در حافظه پنهان کارآیی خوبی ندارد. ابتدا قبل از ضمیمه کردن فایل Cold Fusion که این تابع را تعریف می‌کند باید ببینید که این تابع مثلا وجود داشته یا نه. اگر وجود داشته باشد و شما بخواهید یک تابع را با همین نام تعریف کنید (حتی اگر همان تابع باشد)، Cold Fusion یک خطا را اعلام می‌کند. کنترل فایل تعریف کننده تابع طول کشیده و با تاخیر همراه است. حتی اگر CFSCRIPT نیز در میانه CFIF می‌گوید اگر این تابع وجود ندارد فقط CFSCRIPT را اجرا کنید وجود داشته باشد، باز Cold Fusion پیام خطا می‌دهد.
نکته آخر درباره ذخیره مولفه‌ها در حوزه برنامه (یا هر حوزه پایدار دیگر) این است که هر متغیری که با استفاده از حوزه “Variables” در یک مولفه پایدار ذخیره شده باشد برای همیشه ذخیره شده و برنامه مستندسازی Cold Frsion نیز در اینباره شما هشدار می‌دهد ولی تا بحال ما با آن برخورد نکرده‌ایم. همانطور که میدانید باید از دستور “Var” در هنگام ایجاد یک متغیر موقتی در یک مولفه استفاده کنید. مخصوصا وقتی یک سرویس وب کارآیی یک ویژگی مرورگر مبتنی‌بر آنچه غیر از مولفه است را نشان می‌دهد که در آن حوزه Variableهای پایدار مشکلی را ایجاد نمی‌کند. بنابراین ابتدا فکر کردیم باید بجای کنار گذاشتن یک متغیر خارج از حوزه، از حوزه Variables استفاده کنیم در حالیکه در اصل می‌بایست بسیاری از متغیرهایی را که از طریق یک سرویس وب در دسترس بودند از حوزه دور می‌کردیم. علاوه‌براین باید در CFCهای سرویسهای وب خود برای ایجاد یک متغیر موقتی از “Var” استفاده کنیم.
۵. IDهای اختصاصی در مقابل IDهای داخلی
اکنون که به اصول اجرا و پیاده سازی سرویسهای وب پرداختیم می‌توانیم به موضوع ویژگیها و مشخصات تابع‌های سرویسهای وب واقعی و نحوه استفاده مشتریان از آنها بپردازیم. Averum Billing از یک فیلد ID اختصاصی برای هر آیتم برخوردار است که سرویس گیرنده‌های ما می‌توانند بوسیله آن مقادیر کلیدی و اولیه خود را بجای استفاده از کلیه اولیه‌های که بطور خودکار بوسیله Averum Billing اختصاص داده شده تعیین نمایند. برای مثال وقتی یک محصول جدید ایجاد می‌شود، پایگاه داده یک ID مخصوص را برای آن محصول بطور خودکار در نظر می‌گیرد. این عدد برای سرویس گیرنده ما معنا ندارد چون آنها از قبل دارای ID دیگری برای آن محصول بوده‌اند. با استفاده از یک ID اختصاصی و فیلدی که ما آن را Product ID-Custom نامیده‌ایم، آنها می‌توانند با استفاده از همان ID قابل استفاده در سیستم خود در Averum Billing به محصول دسترسی داشته باشند. در حالیکه ID محصول (Product ID) یک فیلد عدد صحیح و Product ID-Custom یک فیلد Varchar (رشته متن) دست، لذا سرویس گیرنده‌ها میتوانند هر مقداری را که می‌خواهند در آن وارد نمایند.
هنگام شناسایی Preduct ID (ID محصول) از طریق سرویسهای وب، سرویس گیرنده ما می‌تواند هم Product ID (ID محصول داخلی) و هم Product ID-Custom (ID محصول اختصاصی) را مشخص نماید. ولی تابع سرویسهای وب باید به نوع ID که آنها شناسایی می‌کنند آگاه باشد. چندین روش برای انجام اینکار وجود دارد:
▪ برخورداری از هردو فیلد ID محصول و ID محصول اختصاصی بعنوان شناسه در تابع سرویسهای وب که در آن Product ID بصورت عددی و Product ID- Custom بصورت یک رشته است. سپس اگر ID اختصاصی محصول (Product ID- Custom) خالی نباشد و مقدار Product ID نیز صفر باشد این به معنای این است که آنها از مقدار ID اختصاصی محصول استفاده می‌کنند. این روش واضح نیست و سرویس گیرنده می‌تواند بطور تصادفی مقادیر هر دو فیلد را تعیین نماید و در این روش مبهم نمی‌توان پی‌برد که کدام فیلد قابل استفاده است. علاوه‌براین در بعضی از تابعها می‌توان چند Product ID یا چند Product ID- Custom را در لیستی که به علامت کاما محدود می‌شود شناسایی کرد.
▪ برای تضمین و اطمینان از اینکه کدام نوع ID محصول را باید بکار برد (Product ID یا Product ID_Custom) باید بجای برخورداری از هردو فیلد مورد نظر از یک فیلد تنهای ID محصول (Product ID) استفاده کرد و سپس یک شناسه را به آن اضافه نمود تا سرویس گیرنده بداند کدام نسخه را بکار برد. ما نام این فیلد را “Use Custom ID Field List" گذاشتیم. در حالت پیش‌فرض نیز استفاده از Product ID آمده است. برای تعیین استفاده از Product ID- Custom کافیست “Product ID" را بجای مقدار “Use Custom ID Field List” وارد نمایید. اگر شناسه‌های دیگری نیز در این تابع وجود دارد که در آن معلوم نیست. کدام ID اختصاصی را باید بکار برد فقط باید نام فیلد را در قسمت “Use Custom ID Field List” وارد نمایید که لیست فیلدهای محدود به کاما بوده و نوع ID اختصاصی لازمه را نشان می‌دهد. این روش کارآیی فوق‌العاده‌ای دارد ولی باز معلوم نیست که در صورت وجود تنها یک فیلد کدام فیلد را باید بکار برد (Product ID یا Product ID-Custom). همچنین اگر شناسه Product ID یک رشته باشد مفهوم سرویسهای وب از تابعی که خود را تعریف می‌کند منقضی و نقض خواهد شد.
▪ روش آخر استفاده از شناسه Use Custom ID Field List و برخورداری از هر دوشناسه Product ID وProduct ID-Custom است. این بهترین و واضح‌ترین روش است و یکپارچگی فیلد را حفظ می‌کند (بجز قسمتی که در آن Product ID لیستی محدود به کاما است که در آن صورت باید بجای عدد بصورت یک رشته باشد).
۶. تمام فیلدهای مورد نیاز
یک موضوع ناخوشایند درباره سرویسهای وب این است که وجود تمام شناسه‌ها ضروری است حال چه لازم باشد که مقداری را برای شناسه تعیین کنید یا نه. برخلاف دستیابی به توابع معمولی در Cold Fusion، بند Required در برچسب CFARGUMENT در مورد سرویسهای وب نادیده گرفته شده است. در حالیکه به تمام شناسه‌ها و نقطه بعد از آن نیاز است.
گرچه بنظر ساده است ولی بسیار جای نگرانی دارد مخصوصا اگر تابع سرویسهای وب برای عمل جستجو یا روزآمدسازی بکار رود. اگر برای جستجو بکار رود دهها معیار جستجو وجود دارد که شما می‌توانید از آنها برای فیلترسازی نتایج استفاده کنید چون به همه شناسه‌ها نیاز دارید همچنین باید از یک روش برای تعیین نوع شناسه مورد نظر خود در عمل جستجو، استفاده کنید، در Averum Billing ما این مشکل را با شناسه‌ای بنام “Search Field List" حل کرده‌ایم. این یک لیست از شناسه‌های محدود به کاما است که برای جستجو قابل استفاده می‌باشد. همچنین وقتی یک آتیم را روز آمد می‌سازید برای مثال یک محصول، شاید بخواهید فقط نام محصول را روز آمد سازید نه قیمت آنرا، همینطور مجبور نیستند همه فیلدهای محصول را روز آمد سازید. فقط پایه مقدار فعلی فیلدهای محصولی که نمی‌خواهید آنها را روز آمد بسازید بدانید. ولی ما نمی‌خواهیم برای هر فیلد محصول یک تابع سرویس وب جداگانه ایجاد کنیم به همین منظور شما می‌توانید فقط فیلد مورد نظر را روز آمد بسازید. بجای اینکار ما شناسه‌ای به نام “Update Field List" را اضافه کرده‌ایم که لیست فیلدهای محدود به کامایی که باید روزآمد گردند را نشان می‌دهد.
یک عامل موثر در بروز مشکل در فیلد مربوطه، پشتیبانی Averum Billing از فیلدهای اختصاصی است.Averum Billing به سرویس گیرنده‌ها امکان می‌دهد تا فیلدهای اختصاصی خود را برای کاربران، شرکتهای، محصولات و… ایجاد نمایند. ولی نمی‌تواند شناسه‌هایی را که نامشان در لیست تابع نیامده است به سرویسهای وب ارسال نمایند.جاوا قادر است از این “بارهایی اضافی” پشتیبانی نماید ولی Cold Fusion نمی‌تواند و این مطمئنا اصل و ماهیت خود توصیفی استانداردهای سرویسهای وب را نقض می‌کند. ما برای مشتریانی که می‌خواهند فیلدهای اختصاصی را از طریق سرویسهای وب مشخص نمایند از شناسه‌ای بنام “Custom Field” استفاده کردیم که بتوانند مقادیر فیلد اختصاصی را در یک رشته XML وارد نمایند که <Custom Field> در آن برچسب اصلی بوده و برچسبهای فیلد اختصاصی نیز همان نامهای فیلد اختصاصی است که در هنگام ایجاد فیلد اختصاصی تعریف شده است.
۷. کوئری‌های گزارش شده و برگردانده شده
همچون سایر توابع موجود در CFCها، توابع سرویسهای وب نیز نوع فیلد برگشتی و گزارش شده را مشخص مینمایند. وقتی نوع گزارش حالت پرسشی داشته باشد باید بدانید که نوع این کوئریها (پرسشهای مطرح شده) در Cold Fusion و زبانهای دیگر بطور متفاوت بیان شده‌اند. آنها معمولا بصورت یک آرایه با ۲ شاخص نشان داده شده‌اند در حالیکه در Cold Fusion کوئریها بصورت ترکیبی از آرایه و ساختار مطرح شده‌اند. برای دستیابی به یک ردیف مخصوص در یک کوئری Cold Fusion می‌توانید از quergname field name [row] استفاده کنید: ولی وقتی کوئری از طریق سرویسهای وب به زبان دیگری مطرح می‌شود مثلا بجای اینکه شاخص “field name" (“نام فیلد”) باشد یک عدد است. ولی این عدد باید مطابق نام فیلد باشد. همینطور سرویس گیرنده‌ای که این کوئری را مطرح می‌کند باید بداند که کدام عدد شاخص با نام فیلد همخوانی و مطابقت دارد. خوشبختانه، Cold Fusion در نحوه نظم و ترتیب دادن به فیلدها هماهنگ عمل می‌کند و این ترتیب را براساس فیلدهای لیست شده در بند SELECT کوئری انجام می‌دهد.
در مستندسازی شما باید فیلدهای گزارش شده را به ترتیبی لیست نمایید که انتخاب شده‌اند. اگر کوئری فیلدهای داخلی را که در مستند سازی سرویسهای وب لیست نشده‌اند گزارش نماید در آنصورت شما نمی‌توانید این حقیقت را پنهان کنید که براحتی می‌توانید طول آرایه را مشخص کنید. بنابراین یا باید مشخص کنید که کوئری در هنگامیکه برای سرویسهای وب در خواست شده است این فیلدهای داخلی را گزارشی نکرده است یا برای سرگرمی به سرویس گیرنده‌تان امکان دهید حدس بزند فیلدی که در لیست نیامده کدام است.
۸. فیلدهای بولی
فیلدهای بولی معمولا بصورت عدد ۰و۱ یا درست و نادرست شناخته و تعیین شده‌اند. آنها در رابط سرویسهای وب ما چالش کوچکی را ایجاد کرده‌اند مولفه‌های ما نیز از انواع فیلد عددی برای فیلدهای Boolean (بولی) استفاده کرده‌اند که بعنوان فیلدهای بیتی در پایگاه داده ذخیره شده‌اند. ما توانستیم یک نوع فیلد عددی را برای سرویس‌های وب خود مشخص نماییم. ولی در حفظ ماهیت تعریف سرویسهای وب از خود ترجیح دادیم از نوع شناسه‌ای استفاده کنیم که دقیقا بتواند نوع داده را نشان دهد. اینکار ۲ موضوع را برای ما روشن کرد یکی اینکه چون کد و مولفه‌های داخلی ما از مقدار عددی استفاده می‌کنند لذا یک تابع ساده‌ای را برای تبدیل مقدار Boolean به عدد صفر یا ۱، ایجاد کردیم. دوم اینکه چندین نمونه وجود دارد که نشان می‌دهد مقدار Boolean در آن Null (تهی) است. مثل یک فیلد تهی که امکان تهی بودن آن وجود دارد. ظاهرا null (علامت تهی) یک مقدار Boolean در متغیر نمی‌باشد و در صورتیکه شما یک مقدار خالی را برای یک فیلد Boolean در نظر بگیرید سرویس وب اعلام خطا می‌کند.
این موضوع نگران کننده بوده و در چنین مواردی نوع داده بکار رفته در شناسه “Boolean” باید بصورت یک رشته باشد که می‌تواند خالی باشد. نکته جانبی دیگر اینکه پایگاه داده My SQL از این فیلدهای بیتی پشتیبانی نمی‌کند. بنابراین ما از یک فیلد داخلی کوچک استفاده کردیم. یا اینکه باید از یک فیلد Varchar سایز ۱ استفاده می‌کردیم ولی ترجیع دادیم به فیلد عددی اکتفا کنیم. در این مقاله، مشکل‌ترین روش را در Cold Fusion MX یاد گرفتیم، که اگر کوئری شما یک فیلد بیتی را برگرداند، Cold Fusion مقدار صفریا یک را نشان می‌دهد، همینطور اگر از تابع Valuelist در Cold Fusion برای برگرداندن و نمایش لیستی از تمام مقادیر موجود در کوئری برای یک فیلد بیتی استفاده کنید، به چند دلیل ناخوشایند Cold Fusion مقدار ۰ را به علامت False (نادرست) و مقدار عددی۱ را به علامت true (درست) تبدیل می‌کند.
۹. پیامهای خطا
وقتی که یک کاربر فرمی را ارسال می‌کند، شما مقادیر فیلد را تایید می‌کنید و اگر اشتباهی صورت گرفته باشد پیامهای خطا را نمایش داده و فرم دوباره از نو نمایش داده می‌شود. این در سرویسهای وبی که بوسیله یک سرور ارائه می‌شوند و هیچ‌کس در آنجا برای خواندن پیامهای خطا حضور ندارد، تا حدی شکل است. مهمتر از همه اینک هر تابع سرویس وب باید نوع داده مقدار برگشتی را مشخص کند. اگر تابع یک مقدار عددی یا یک کوئری را برمی‌گرداند مسلما شما نمی‌توانید پیام خطایی را بصورت یک رشته متن نمایش دهید. بنظر من در .NET می‌توان یک استثنا را ایجاد کرد که در آن مقدار برگشتی از نوع تعیین شده نمی‌باشد ولی امتحان اینکار در Cold Fusion یک خطای استثنایی را بوجود می‌آورد. (متاسفانه Cold Fusion در هنگامیکه شما یک تابع سرویس وب را بدون شناسه‌ها فرا می‌خوانید یا زمانی که مقدار شناسه با نوع فیلد سازگار نیست یک خطا را اعلام می‌کند. اینخورد نیز بعلت عدم وجود روشی برای دستیابی به این خطا از طریق CFTRY دردسر ساز است برای اطلاع از نحوه کنترل پیامهای خطا باید به این ۲موضوع توجه کرد:
چطور به سرویس گیرنده‌ای که در خواست را ارائه میدهد بگوییم که در خواستشان با اشکال مواجه شده نجوی که سرور آنها در حالت خودکار به این موضوع پی‌ببرد. وقتی سرویس گیرنده‌ها در ابتدا سرویسهای وب را روی پایانه آنها راه‌اندازی کردند چطور به آنها امکان دهیم تا به پیامهای خطا دستیابی داشته باشند و بفهمند چرا در خواستشان با شکست روبرو شده است.
اگر در خواست با مشکل و شکست مواجه شود مستندسازی ما لیستی از مقدار برگردانده شده را برای سرور تهیه می‌کند. در نوع گزارش عددی ما عدد ۱ و برای یک رشته مقدار خالی و برای یک فیلد داده اول ژانویه ۱۹۷۰ ساعت ۱۲ظهر را اعلام کردیم. برای یک کوئری، یک کوئری خالی با یک فیلد تنها بنام “error” را اعلام کردیم (اگر کاربر فاقد مجوز باشد ما یک کوئری خالی با نامهای فیلد واقعی را نشان نمی‌دهیم. در صورت تمایل آنها می‌توانند به اسناد ما دستیابی داشته باشند ولی ما باید بین خطا و یک مجموعه نتایج خالی فرقی را قابل شویم.)
حال که سرور میداند در خواست رد شده است، برنامه‌نویس علت آنرا جویا می‌شود. در متغیرهای “Session” برای هر نشست و برقراری ارتباط سرویسهای وب، Averum Billing آخرین پیام خطای ایجاد شده برای آن نشست را ذخیره می‌کند. ما نیز می‌توانستیم آخرین پیام خطای ایجاد شده برای هر تابع سرویس وب و یا حتی ۱۰پیام خطای آخر را ذخیره کنیم. ولی اینکار باعث اتلاف وقت در ذخیره سازی میشد.
انواع پیامهای خطا عبارتند از:
▪ نشست سرویسهای وب کاربر که مهلت استقرار آنها تمام شده و زمانشان منقضی گردیده است (یا هرگز وجود نداشته)
▪ کاربر فاقد مجوز تابع در خواست شده است.
▪ سرویس‌گیرنده مجوز آتیم در خواست شده را ندارد مثل محصولی که به یک سرویس‌گیرنده Averum Billing دیگر تعلق دارد.
▪ موضوعات تایید اعتبار فرم
۱۰. اشکال زدایی
بالاخره در مبحث پیامهای خطا باید شما هشدار دهیم که اشکال زدایی سرویس‌های وب بسیار پیچیده‌تر از اشکال زدایی کد معمولی Cold Fusion است. پیامهای خطای ایجاد شده بوسیله Cold Fusion معمولا بیهوده و گمراه کننده هستند. کنترل شده خطا در Cold Fusion ممکن است به این موضوع کمک کند ولی معمولا این همان پیام خطایی است که غیرقابل توصیف است. چندین روش برای اشکال زدایی کد سرویس وب شما وجود دارد که یکی از آنها فراخوانی تابع بعنوان یک مولفه معمولی بجای یک سرویس وب است ولی این روش نیز در صورتی که خطا به سرویس وب مربوطه شود بی‌فایده است. یک روش دیگر استفاده از CTTRY در کد است که در آن بند CFCATCH شامل یک تگ (برچسب) CFMAIL برای ارسال پیام خطا به شما یا یک برچسب CFFILE برای نوشتن و ضمیمه کردن پیام خطا به یک فایل متنی است. البته تجربه ما نشان می‌دهد که Cold Fusion کد CFCATCH را نادیده می‌گیرد مگراینکه این کد درون فایلی گنجانده شود که مستقیما CFC آنرا در برنگرفته است. یعنی باید حداقل ۲فایل پایین‌تر از این مولفه باشد.
در نهایت همچون سایر کدها می‌توانید کد را بررسی نموده و روی قسمتهایی که عامل ایجاد خطا هستند توضیح داده و اظهار نظر نمایید، سپس بتدریج برای یافتن اشکال کد را از حالت توضیح در آورید. وقتی اینکار را انجام می‌دهید اطمینان حاصل کنید که یک مقدار مشخص برای هر تابع در نظر گرفته شده است.اگر واقعا خسته و ناامید شده‌اید توصیه ما به شما این است که مجموعه برچسبهای CFFILE را که یک عدد یا متن را به یک فایل اضافه می‌کند وارد نمایید که هر CFFILE متوالی آن عدد را اضافه می‌نماید. این سریعترین روش برای نشان دادن واکنش در مقابل خطایی است که در حال وقوع است، متاسفانه اگر خطا در خود CFC وجود داشته باشد این روش کارآیی خوبی ندارد چون Cold Fusion هر تابع را با دستیابی از راه دور در حافظه پنهان قرار می‌دهد و فقط آنرا زمانی روز آمد می‌سازد که Cold Fusion از نو راه‌اندازی شود (که در قسمت ۴ درباره آن توضیح داده شد)
یک حقیقت جالب این است که ما اطلاعات و روش مفید درباره تابع Query Setcel آموختیم. حتی اگر مقداری را روی یک عدد صحیح تنظیم کنیم وقتی مقادیر را در یک کوئری با استفاده از Valuelist لیست می‌نماییم، Cold Frusion مقدار را تنها با یک ممیز اعشاری نشان می‌دهد. تنها راه برای حل این مسئله تعیین مقدار با استفاده از تابع Tostring با یک مقدار عدد صحیح واقعی بود. Valuelist همچنین فیلدهای بیتی را از صفر ویک به علامت True (درست) و False (نادرست) تبدیل می‌کنید، همچنین با یک کوئری که بوسیله CFLOOP Query=nu احاطه شده بود به دردسر افتادیم. متغیرهای درون کوئری با استفاده از “query name field name” بطور مناسب در حوزه قرار گرفتند ولی این کوئری داده بیهوده‌ای را نشان میداد. استفاده از Valuelist ثابت کرد که کوئری درست بود و راه حل آن حذف “query name” در CFLOOP بود. بالاخره در مورد مقادیری که بطور موقتی در تابع شما استفاده می‌شوند باید با استفاده از “<CFSET Var>" متغیری را ایجاد نمایید. این روش برای مقادیری که بوسیله برچسب CFINVOKE در هنگام دستیابی به تابع دیگر ارائه و برگردانده می‌شوند، کاربرد ندارد. مقدار “Var” در اصل اولویت را به مقدار برگردانده شده میدهد، مثل اولویت دادن به کوئریها.
▪ معرفی Steven Rubenstein
او موسس و مدیر ارشد اجرایی Averum است که روشها و راه حلهای تنظیم صورتحساب و تهیه لایحه مالی برای ASPها را توسعه می‌دهد و نیز معرف اولین محصولی است که برای تطبیق تبادلات کارت اعتباری با حساب بانکی شما بکار می‌رود. او برنامه‌نویسی را از سال۱۹۹۷ با Cold Fusion آغاز کرده و قبل از Averum یک شرکت اعتبارات تجاری الکترونیکی و Emaze Saftware را تاسیس کرده که نرم‌افزار تعیین نرخ را توسعه داده است. آدرس: http://mxdj.sys-con.com/read/۸۶۱۰۸.htm

نویسنده: Steven Ruben stein
مترجم: شراره حداد

منبع : علم الکترونیک و کامپیوتر