همانطور که احتمالا مستحضر می باشید، قبل از معرفی تکنولوژی WCF، از تکنولوژی های مختلفی از قبیل ASMX و Remoting و DCOM و Enterprise Serviceو MSMQ و ... جهت تبادل اطلاعات بین کلاینت و سرور استفاده می شد. هرکدام از این تکنولوژی ها دارای معایب، مزایا، ویژگی ها و محدودیت های خاص خود می باشند و جهت برنامه نویسی برای هر کدام از این ها باید API های مخصوص آن ها را فراگرفت.

اما با ظهور تکنولوژی WCF، دیگر بسیاری از این مشکلات از میان برداشته شده و یک مدل برنامه نویسی یکسان (Unified Programming Model) برای رفع محدودیت ها ارائه شد. این تکنولوژی با حمایت از پرتکل های مختلف از قبیل HTTP و TCP و ...  و قابلیت تعامل با بلتفرم های مختلف (از قبیل DotNetو J2EE و غیره)، جایگزینی مطمئن و مناسب برای سایر تکنولوژی های قدیمی تر که در بالا ذکر شدند، می باشد.

ضمنا سرویس های WCF قابلیت میزبان شدن در محیط های مختلف از جمله Windows Service و Windows Application و Console Application و IIS می باشند.

قابلیت میزبان شدن در محیط های مختلف، برای سرویس های WCF باعث شده است که برخی ویژگی های مربوط به یک پرتکل خاص مانندHTTP به طور پیشفرض غیر فعال باشند و در صورت نیاز می توان این ویژگی ها را فعال نمود.

بدین جهت می باشد که حتی اگر شما یک سرویس WCF را در IIS میزبان نموده باشید، باز هم به طور پیشفرض مقدار System.Web.HttpContext.Currentهمواره برابر null می باشد و بنابراین دسترسی به عناصر موجود در این آبجکت از قبیل Session وCache و User و Requestو Response و ... غیر ممکن می باشد.

تذکر:

با استفاده از کلاس System.ServiceModel.Web.WebOperationContext.Current می توان به برخی ویژگی های Request و Response دسترسی یافت که بررسی این موضوع خارج از بحت ما می باشد.

با اضافه نمودن یک Attribute به نام AspNetCompatibilityRequirements به کلاس سرویس WCF می توان به کلاس های موجود در System.Web.HttpContext.Current دسترسی پیدا نمود.

در قسمت زیر نحوه انجام این کار را ملاحظه می نمایید.

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

public class Service :  IService

{

    #region IService Members

    public void TestMethod(int number)

    {

        System.Web.HttpContext.Current.Session["MySesstion"] = number;

    }

    #endregion

}

خاصیت AspNetCompatibilityRequirementsMode می تواند دارای سه مقدار باشد که مقدار پیشفرض آن NotAllowed می باشد.

اکنون به معرفی این سه مقدار می پردازیم:

• NotAllowed: همانطور که قبلا ذکر شد، به طور پیشفرض مقدار AspNetCompatibilityRequirementsMode برابر NotAllowed می باشد. این مقدار معین می کند که این سرویس نیازی به اجرا شدن در حالت Asp.NetCompatibility را ندارد و هنگامی استفاده می شود که ما نیازی به دسترسی به کلاس های مخصوص ASP.NET در سرویس را نداریم و یا اینکه این سرویس در محیط هایی با پرتکل های غیر HTTP اجرا می شود.

• Allowed: این مقدار مشخص می کند که این سرویس توانایی اجرا در حالت Asp.Net Compatibility را دارد و در صورتی که HttpContext موجود باشد، می توانیم به آن دسترسی پیدا کنیم.

• Required: این مقدار مشخص می کند که سرویس حتما باید در حال Asp.Net Compatibility اجرا شود. به طور مثال این مقدار زمانی نیاز است که ما می خواهیم مطمئن شویم که این سرویس بر روی IIS میزبانی شده و نیاز است که فقط روی پرتکل HTTP استفاده شود.

تذکر:

• در صورتی که نیاز دارید این سرویس را از طریقJavaScript و یا کتابخانه های مختلف اجاکسی از قبیلMicrosoft Ajax Library و jQuery  از سمت کلاینت فراخوانی کنید نیز باید حتما خاصیت AspNetCompatibilityRequirementsMode فعال شده باشد.

• AspNetCompatibilityRequirementsMode در فضای نامی System.ServiceModel.Activation قرار دارد.

• AspNetCompatibilityRequirementsMode حتما باید به کلاس سرویس اضافه شود و نه اینترفیسی که کلاس آن را پیاده سازی نموده است.

تذکر مهم:

دقت داشته باشید که پس از اعمال نمودن AspNetCompatibilityRequirementsMode باید اطمینان حاصل کنید که این خاصیت را در پیکربندی (Configuration) سرویس در سمت سرور نیز فعال گردیده باشد. در صورتی که از Web.config جهت پیکربندی سرویس استفاده نموده اید، کافیست که عنصر serviceHostingEnvironment را در داخل system.serviceModel اضافه نموده و خاصیت aspNetCompatibilityEnabled را برابرtrue گردانید(به طور پیشفرض این مقدار برابر false است)

این عمل را در قسمت زیر ملاحظه می نمایید:

خوب، کار تمام است و اکنون می توان با خیال راحت به استفاده از کلاس های موجود در System.Web.HttpContext.Current پرداخت.