‫چند نکته در باب WCF

WCF هم مثل هر تکنولوژی و سکوی جدیدی با تعدادی نکته همراه است. به نکات زیر دقت کنید:

عدم دسترسی به HttpCpntext
ممکن است حین کار با WCF نیاز به HttpContext.Current.Request یا غیر داشته باشید. این نیاز وقتی که سرویس WCFتان در IIS میزبانی می‌شود بیشتر هم می‌شود. متاسفانه HttpContext.Current در داخل یک سرویس WCF همواره null است چون اصولاً یک سرویس WCF ربطی به Http ندارد. در WCF باید به جای HttpContext از OperationContext.Current استفاده کرد.

آدرس خالی
لزومی ندارد که همیشه اسم یا IP سرویس دهنده در config مربوط به سرویس دهنده مشخص شود. بیشتر وقت‌ها می‌توان بخش address مربوط به endpoint را خالی گذاشت.
امکان مشاهده پیغام خطای رخ داده در سرور WCF
برنامه‌های ASP.NET را می‌شد طوری در سرور تنظیم کرد که اگر خطایی رخ داد به کاربر هیچ چیزی از خطا نمایش داده نشود یا این که بشود. همین کار را می‌توان در config سرور WCF با استفاده از <servicedebug includeexceptiondetailinfaults=”true” > انجام داد.

مشکل در WCF RSS در سرویس‌های WCF که مثل RSS به نوعی با وب سر و کار دارند ممکن است لازم شود نوع binding به صورت webHttpBinding تعریف شود. لینک

‫تولید Feed با استفاده WCF

مطمئناً برای تولید Feedهای RSS یا ATOM در ASP.NET راه‌ها و کدهای زیادی وجود دارد. اما یکی از راه‌های جالب تولید Feed در دات‌نت، استفاده از WCF است. WCF با استفاده از چند خط کد ساده برای شما Feed می‌سازد.

سرویس‌های Feed معمولاً در برنامه‌های تحت وب که در IIS اجرا می‌شوند قرار داده می‌شوند. بنابراین باید سرویس WCF را در فایل‌های ‎.svc قرار داد. اگر سرویس در یک host با دسترسی خیلی پایین مثل سایت‌های اینترنتی قرار داشته باشد نمی‌توان از کلاس ServiceHost استفاده کرد. بنابراین باز هم باید از فایل‌های ‎.svc که توسط IIS میزبانی (host) می‌شوند استفاده کرد. خوشبختانه امکانات اصلی WCF از نسخه ۳٫۵ دات‌نت در دسترس هستند و از آنجا که دات‌نت ۳٫۵ روی runtime نسخه ۲ دات‌نت هم کار می‌کند بنابراین مشکلی در سرورهای ویندوز ۲۰۰۳ و IISهای قبل از نسخه ۷ هم وجود ندارد.

جهت کسب اطلاعات بیشتر به MSDN مراجعه کنید. در صورت استفاده از IIS بایستی از webHttpBinding به عنوان binding استفاده کرد.

‫استفاده بهینه از Lazy Loading

برای Lazy Loading در NHibernate روال زیر را انجام داده بودم. lazy را برای همه mappingها true کرده بودم. در web.config هم همینطور. سپس هر جا که lazy مشکل پیدا می‌کرد و خطای LazyInitializationException اتفاق می‌افتاد، آن association یا collection را با استفاده از کلاس NHibernateUtil.Initialize پیش load می‌کردم تا مشکل حل شود. این راه حل خیلی هم غلط نیست، اما می‌توان برای رفع مشکل از دست رفتن session از روش‌های زیر هم استفاده کرد:

۱- در associationهای مشکل دار از outer-join = true استفاده شود.
۲- در query APIهای مختلف هم می‌توان نوع outer-join را تعیین کرد.

باید دقت کرد که نوع outer-joinی که در سطح mapping یک entity تعریف می‌شود قابل override در query یا هر جای دیگر است.

‫استفاده از Authentication/Authorization استاندارد WCF یا پیاده‌سازی خودمان؟

WCF خودش مکانیزم‌های زیادی برای Authentication و Authorization دارد. یکی از سناریوهای ممکن برای Membership یک برنامه نوعی می‌تواند این باشد که Membership در سرور با استفاده از یک Windows Domain Controller تعریف شده و به ازای همه کاربران و نقش‌های ممکن، در آن domain به تعداد مورد نیاز Windows Account و Windows Group ساخته شود. سپس Role Management تمام سرویس‌ها بر اساس این Windows Groupها تعریف شده و کاربران برنامه WCF هم بر اساس Windows Accountهای تعریف شده در domain وارد سیستم شوند.

سناریوی دوم این است که از مکانیزم Authentication و Authorization داخلی WCF استفاده نکرده و به جای آن خودمان همه موارد مورد نیاز Membership را پیاده‌سازی کنیم. این طوری کنترل بیشتری روی کار داریم ولی باید زحمت بیشتری کشیده و خیلی از موارد را که قبلاً WCF پیاده‌سازی کرده، مجدداً خودمان پیاده‌سازی نماییم. هر چند که این روش توصیه شده نیست ولی وقتی که روش Authentication و Authorization انتخابی ما زیادی پیچیده و غیر معمول است چاره‌ای نیست جز این که خودمان همه چیز را انجام دهیم.

‫ایمن‌سازی انتقال اطلاعات در WCF

بعد از آن که سرور و کلاینت خودشان را به هم شناساندند، نیاز هست که کانال ارتباطی بین آنها هم ایمن‌سازی شود. یعنی هیچ کسی وسط راه نتواند این پیغام‌ها را خوانده یا دستکاری کند. ایمن بودن پیغام‌های در WCF سه جنبه دارد، integrity به معنی دست نخورده بودن پیغام، privacy به این معنی که هیچ کس وسط راه پیغام‌ها را نخوانده باشد و mutual authentication به این معنی که پیغام صادره از طرف کلاینت صرفا به دست سرور اصلی برسد نه سرورهای دیگر.

WCF پنج روش را برای ایمن‌سازی انتقال اطلاعات فراهم می‌کند. اولین روش، عدم استفاده از هیچ نوع ایمن‌سازی است. دومین روش، ایمن‌سازی لایه انتقال است. در این روش WCF از یکی از پروتکل‌های ایمن HTTPS، TCP، IPC یا MSMQ برای انتقال اطلاعات استفاده می‌کند. این روش برای وقتی که کلاینت و سرور به طور مستقیم به هم وصل نیستند مشکلاتی دارد. سومین روش، ایمن‌سازی خود پیغام‌ها است. در این روش پیغام‌ها اول رمزنگاری شده سپس انتقال داده می‌شوند. این روش هم روی پروتکل‌های ساده مثل HTTP قابل اجراست هم بر عکس روش ایمن‌سازی لایه انتقال، نیازی به ارتباط مستقیم بین کلاینت و سرور ندارد. بنابراین از این روش در فضای اینترنتی هم می‌توان استفاده کرد. تنها نکته منفی این روش، overhead اجرای آن به دلیل رمزنگاری تک تک پیغام‌هاست. روش چهارم و پنجم هم عبارتند از ترکیب روش دوم و سوم یا استفاده هم‌زمان از هر دو که ممکن است خیلی هم مورد استفاده قرار نگیرند.

منبع:
فصل ۱۰ کتاب Programming WCF Services

‫Authentication و Authorization در WCF‫

Authentication در WCF به چندین روش انجام می‌شود:

No authentication
هیچ نوع authenticationی انجام نمی‌شود.

Windows authentication
در صورت وجود domain server از Kerberos و در غیر این صورت از NTLM استفاده می‌شود.

Username و Password
user name و password می‌تواند بر اساس اکانت‌های ویندوز یا یک روش سفارشی سازی شده سنجیده شود.

X509 certificate
کلاینت خودش را با استفاده از یک certificate به سرور می‌شناساند.

Custom mechanism
برنامه‌نویسان می‌توانند روش authentication خاص خودشان را پیاده‌سازی کرده و WCF را مجبور به استفاده از آن کنند.

Issued Token
در این روش هم سرور و هم کلاینت از یک سرویس دیگر مثل Windows Card Space برای authentication استفاده می‌کنند.

WCF برای Authorization هم از دو روش آشنا استفاده می‌کند. یکی استفاده از Windows groups و دیگری استفاده از ASP.NET role provider.

منبع: فصل ۱۰ کتاب Programming WCF Services

‫امکانات انقلابی git

انقلابی‌ترین امکان git خاصیت distributed آن است. بعد از این قضیه دو دستور زیر به نظر من خیلی انقلابی می‌آیند:

۱- دستور git stash
فرض کنید در حال اعمال یک سری تغییرات دامنه دار در سورس برنامه هستید. فرض کنید تعداد زیادی فایل را modify کرده و تعدادی را هم اضافه یا حذف کرده‌اید. حالا وسط کار متوجه باگ یا ایرادی در سورس می‌شوید که ارتباطی با تغییرات اخیرتان ندارد ولی به هر صورت می‌خواهید هم این اشکال را حل کنید و هم این که commit این رفع باگ با commit تغییرات مورد ذکر یکی نباشد. حالا باید چه کار کرد؟ راه معمول این است که باگ مشاهده شده را در جایی یادداشت کرد و بعداً آن را اصلاح کرد، البته اگر تغییرات اخیرتان به آن وابسته نباشد. راه دیگر آن است که تغییرات اخیر را un-do کرده، باگ مورد نظر را رفع کرده و تغییرات اصلی را مجددا از نو شروع کنید.

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

۲- دستور git grep
دستور grep دستور ساده‌ای است که می‌تواند عبارت خاصی را در فایل‌های موجود در source control گیت مورد جستجو قرار دهد. آنها که به search سورس در Visual Studio عادت دارند مطمئناً از git grep خیلی خوششان خواهد آمد.

‫بعضی از دستورات ضروری git

مشاهده تغییرات قبل از commit
git diff –cached

ایجاد یک branch به اسم mybranch
git branch mybranch

سویچ کردن بین branchهای مختلف
git checkout mybrabch

نمایش branchهای موجود و branch جاری
git branch

merge برنچ mybranch با branch جاری
git merge

حذف یک branch
git branch -d mybranch

تهیه branch از یک remote branch
git branch –track experimental origin/experimental

خالی کردن موقتی working diretory
git stash

جستجو در فایل‌ها
git grep search_phrase

undo کردن تغییرات سورسی که هنوز commit نشده است
git reset –hard HEAD

Undo کردن تغییرات یک تک فایل
git checkout HEAD hello.rb

بررسی سالم بودن فایل‌های git
git fsck

بررسی این که چه کسی چه قسمتی از یک فایل را تغییر داده است
git blame sha1_file.c

درست کردن shortcut و خلاصه برای دستورات طولانی git
git config –global alias.last ‘cat-file commit HEAD’‎

منبع:
کتاب git community

‫بعضی اصطلاحات مهم git

git directory
همان فولدر ‎.git است که خود سورس کنترل هم محسوب می‌شود.

working directory
فضای معمولی انجام کار با سورس برنامه است.

INDEX
فضای موقتی که نشانگر فایل‌های تغییر یافته یا جدیدی هستند که قرار است با commit بعدی به مخزن بروند. INDEX نقش واسطه بین working directory و git directory را بازی می‌کند. دستور git status برای نمایش اطلاعاتش از INDEX استفاده می‌کند.

HEAD
اشاره می‌کند به آخرین commit برنچ جاری.   

origin
آدرس URLی است که clone از آنجا انجام شده.

‫کتاب Programming WCF Services

این روزها WCF رواج زیادی در شرکت‌های ایرانی پیدا کرده است. برای من هم یکی دو موقعیت پیش آمده که مجبور شوم با WCF کار کنم. به اولین منبعی که برای یادگیری مراجعه کردم فصل ۲۵ کتاب Pro C# 2010 بود. این فصل خلاصه و مقدمه‌ای از WCF است و به هیچ وجه قصد وارد شدن به جزییات را ندارد. خواندن این فصل توانست دستم را به طور کامل در WCF راه بیندازد اما خودم فکر می‌کردم برای یادگیری بهتر WCF بهتر است یک کتاب اختصاصی راجع به WCF بخوانم. به همین خاطر کتاب Programming WCF Services را انتخاب کردم.

سه فصل اول این کتاب اختصاص دارد به مقدمات WCF یعنی همان‌هایی که در فصل ۲۵ کتاب قبلی پوشش داده شده بود. بنابراین آنها را بی‌خیال شدم و مستقیماً از فصل ۴ که راجع به Instance Management بود شروع کردم. این فصل و تا اندازه‌ای هم فصل بعدی چیزهای جالبی برای یاد گرفتن داشت. اما از فصل ۶ تا آخر کتاب را هر چقدر که بیشتر نگاه کردم متوجه شدم که هیچ کدامشان برای نیاز فعلی من ضروری نیستند و بعداً هم می‌توانم در صورت ضرورت به آنها مراجعه کنم. این فصول راجع به کنترل خطا، تراکنش، مدیریت همزمانی، صف، امنیت و سرویس‌های خاص Windows Azure صحبت می‌کنند.