Skip to Content

آرشیو

مقایسه دو نرم افزار ایمیل مارکتینگ تحت وب ایرانی: آونگ ایمیل و میل چی

مقایسه دو نرم افزار ایمیل مارکتینگ تحت وب ایرانی: آونگ ایمیل و میل چی

در این مقاله دو نرم افزار ایمیل مارکتینگ تحت وب ایرانی (آونگ ایمیل و میل چی) رو به شما معرفی، و با هم مقایسه می‌کنم. مقایسه پلن‌ها، امکانات، طراحی وب‌سایت، سرعت تغییرات و میزان اهمیت به بازخوردها و تحقیقات صورت گرفته در خصوص نیازهای مشتریان و نزدیک شدن به استانداردهای سرویس‌های ایمیل مارکتینگ دنیا.

اینبار می‌خوام سریع‌تر از مقدمه عبور بکنم و برم سراغ مقایسه سرویس آونگ ایمیل و سرویس میل چی.

تنها موردی که در مقایسه این دو سرویس به اون پرداخت نشده کیفیت هست که نیاز به بررسی بلندمدت داره.

کوششم این بود که این مقایسه درست و از روی عدل و انصاف انجام بشه. هیچ جهت گیری و جانب داری ای از هیچکدام از سیستم‌ها نمی‌کنم و همه چیز رو به عنوان یک شخص ثالث و بی‌طرف گفتم.

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

معرفی دو نرم افزار ایمیل مارکتینگ تحت وب ایرانی: آونگ ایمیل و میل چی

بذارین قبل از مقایسه یک معرفی کوتاه انجام بدم تا اگر هنوز با این دو سرویس آشنایی ندارین، با اونها آشنا بشین.

آونگ ایمیل:

آونگ ایمیل

وب سایت آونگ ایمیل با آدرس avangemail.com در دسترسه. آونگ ایمیل به نظر می‌رسه که رسما از سال ۱۳۹۷ آغاز به کار کرده، اما دامنه avangemail حدود سه سال قدمت داره.

البته مدیران و بنیانگذارانش، پیش از آونگ ایمیل، یک سرویس دیگر رو در ایران راه اندازی کرده بودن (emailmarketingpanel.ir) که این نشان دهنده سابقه و تجربه بیشتر فعالیت شون در این زمینه هست و فقط نباید در سابقه، آونگ ایمیل در نظر گرفته بشه. بنابراین آغاز فعالیت در این زمینه، تنها مختص به آونگ ایمیل نمی‌شه.

هدف آونگ ایمیل ارائه امکانات و راهکارهای اصولی برای انجام ایمیل مارکتینگ در حد کلاس جهانی هست.

میل چی:

میل چی

وب سایت میل چی با آدرس mailchi.in در دسترسه. میل چی خودش رو به عنوان اولین سرویس ایمیل مارکتینگ یا نرم افزار ایمیل مارکتینگ تحت وب ایرانی معرفی کرده که امکانات و راهکارهای اصولی برای انجام ایمیل مارکتینگ یابازاریابی ایمیلی رو در اختیار کاربران ایرانی قرار داده.

در قسمت درباره ما وب‌سایت میل چی نوشته شده (میل چی متعلق به شرکت عصر فرا ارتباط می‌باشد، این شرکت تاسیس سال ۱۳۸۵ است…) بنابراین زمان دقیق تولد و آغاز به کار میل چی مشخص نیست، اما با توجه به زمان ثبت دامنه mailchi، احتمالا پنج سال قدمت داره. میل چی اولین سرویس ایمیل مارکتینگ ایرانیه.

مقایسه پلن‌های رایگان و پولی آونگ ایمیل و میل جی

در این بخش پلن‌های رایگان و پولی آونگ ایمیل و میل چی رو با هم مقایسه می‌کنم.

پلن رایگان آونگ ایمیل و میل چی

آونگ ایمیل – شما می‌تونین یک حساب کاربری رایگان ایجاد بکنین، ۱۲۰۰ ایمیل به اون اضافه کنین و به این ۱۲۰۰ عضو یا مشترک خودتون به صورت نامحدود ایمیل ارسال کنین.

پلن رایگان آونگ ایمیل و میل چی

میل چی –  می‌تونین یک حساب کاربری رایگان ایجاد بکنین، ۱۰۰۰ مشترک یا عضو به اون اضافه بکنین و ماهیانه به تعداد ۱۰۰۰ عدد ایمیل به صورت رایگان به اونها ارسال بکنین.

پلن رایگان آونگ ایمیل و میل چی

برنده: آونگ ایمیل در این بخش برنده می‌شه. به خاطر اینکه هم می‌شه تعداد ۲۰۰ مشترک بیشتر از میل چی در اون ذخیره کرد، و هم می‌شه به‌صورت نامحدود ایمیل ارسال کرد.

توجه: اشتراک‌های میل چی فقط در پلن رایگان محدودیت ارسال دارن، در پلن‌های پولی از لحاظ ارسال نامحدود هستن.

پلن‌های پولی آونگ ایمیل و میل چی

قیمت پلن ۵۰۰۰ مخاطب یکساله نامحدود آونگ ایمیل: ۸۴۰,۰۰۰ تومان

پلن‌های پولی آونگ ایمیل و میل چی
قیمت پلن ۵۰۰۰ مخاطب یکساله نامحدود میل چی: ۲۷۲,۵۰۰ تومان

پلن‌های پولی آونگ ایمیل و میل چی

قیمت پلن ۳۰۰۰۰ مخاطب یکساله نامحدود آونگ ایمیل: ۴,۶۲۰,۰۰۰ تومان

پلن‌های پولی آونگ ایمیل و میل چی

قیمت پلن ۳۰۰۰۰ مخاطب یکساله نامحدود میل چی: ۱,۶۳۵,۰۰۰ تومان

پلن‌های پولی آونگ ایمیل و میل چی

برنده: با اختلاف زیاد، میل چی از لحاظ قیمت و پلن‌های پولی در این بخش برنده می‌شه. در آونگ ایمیل بالاترین پلنی که فعلا ارائه شده ۳۰۰۰۰ مخاطب هست، اما در میل چی پلن ۵۰۰۰۰ عضوی با قیمت ۲,۷۲۵,۰۰۰ تومان موجوده.

پلن‌های پولی آونگ ایمیل و میل چی

تمامی پلن‌های پولی میل چی هم نامحدود هستن، محدودیت تنها در پلن رایگان وجود داره. البته احتمالا پلن‌های بالاتر مثلا تا صد هزار تا در میل چی و همچنین پلن‌های بالاتر در آونگ ایمیل، از طریق مکاتبه با بخش فروش این سرویس‌ها ارائه می‌شه.

طراحی وب‌سایت آونگ ایمیل و میل چی

آونگ ایمیل:

صفحه اصلی و سایر صفحات قابل مشاهده توسط میهمانان در وب‌سایت آونگ ایمیل توسط HTML, CSS, Bootstrap و jQuery به صورت اختصاصی طراحی شده. و برای قسمت پنل کاربری و اصلی، از اسکریپت تجاری MailWizz استفاده شده و این اسکریپت توسط برادران فتحی برای اونگ ایمیل تغییر و توسعه داده شده.

MailWizz یک اسکریپت تجاری، اوپن سورس، و ساخته شده با زبان PHP و فریمورک Yii هست. برای پیاده‌سازی و اجرای میل ویز از Knockout, JavaScript, jQuery و Bootstrap هم استفاده شده. MailWizz با بانک اطلاعاتی MySQL کار می‌کنه.

میل چی:

در طراحی وب‌سایت میل چی از تکنولوژی و فریمورک NET. و زبان ASP.NET شرکت مایکروسافت و دیتابیس SQL Server استفاده شده. میل چی با IIS و ویندوز سرور کار می‌کنه. در کنار اینها از کتابخانه و زبان‌های JAVA Script, Bootstrap, jQuery, jQuery UI, FancyBox, D3, HTML و CSS هم در طراحی میل چی استفاده شده.

طراحی وب‌سایت میل چی نمره قابل قبولی می‌گیره. در حالت ریسپانسیو فقط به غیر از ویدیو پلیر موجود در صفحه اصلی وب‌سایت (که ظاهرا از قلم افتاده)، باقی موارد ریسپانسیو هستن.

به گفته مدیر و سازندگانش، میل چی، هم در قسمت پنل کاربران و هم در قسمت‌های بیرونی، به‌صورت کاملا اختصاصی برنامه نویسی و طراحی شده.

برنده: این بخش بیشتر حالت معرفی داشته و بنده از لحاظ فنی نمی‌خوام در این خصوص نظر دقیقی بدم، بنابراین هیچ‌کدام به عنوان برنده انتخاب نمی‌شن! می‌شه گفت که هر دو وب‌سایت نمره قابل قبولی از لحاظ طراحی دریافت می‌کنن (منظور امکانات نیست!) بیشتر از لحاظ ظاهر منظورم هست! امکانات رو پایین‌تر بررسی می‌کنیم.

اما طبیعیه که برای طراحی وب‌سایت میل چی هم وقت بیشتر، هم انرژی بیشتر و هم سرمایه و نیروی انسانی بیشتری قرار داده شده تا به صورت کاملا بومی تولید بشه. ولی خروجی کار از نظر ظاهری تفاوت فاحشی نداره.

تجربه کاربری:

میل چی در تجربه کاربری برنده می‌شه و کار با میل چی هم به دلیل کاملا فارسی بودن، هم به دلیل سادگی زیاد و رابط کاربری بهتر اون، ساده‌ و روان‌تر هست.

توضیحات تکمیلی:

البته اینها فقط بخش بیرونی کار هست و اون چیزی که ما می‌بینیم و باهاش کار می‌کنیم، یک بخش بک-اند هم دارن که به دلیل عدم دسترسی به اون بخش نمی‌تونم نظری دربارش بدم.

جدای از این موضوع، تمامی سرویس‌های ایمیل مارکتینگ (نرم افزارهای ایمیل مارکتینگ تحت وب) به دو بخش سمت کاربر و سرور تقسیم می‌شن! وب‌سایت هاشون تازه به یک (نرم افزار ایمیل مارکتینگ دیگر) متصل هستن! (پس این وب‌سایت ها فقط فرمان‌ها رو می‌فرستن برای اون نرم افزار، اون با امکانات و سرورهای قدرتمندش ایمیل‌ها رو ارسال می‌کنه و گزارشات رو دریافت می‌کنه، گزارشات هم به یک سیستم دیگر متصل هست!، بعدا اطلاعات نهایی رو ارسال می‌کنه برای وب‌سایتی که ما باهاش کار می‌کنیم، تا ببینیمش! می‌دونم که به نظر خیلی پیچیده میاد! 🙄 )

مثلا از برترین ارائه دهندگان نرم افزارهای ایمیل مارکتینگ (MTA) دنیا، شرکت sendgrid هست. (احتمالا میل چی ایرانی، قبل از تحریم‌ها از این نرم افزار استفاده می‌کرد) ظاهرا چند مدتیه که سند گرید ایران رو تحریم کرده و میل چی هم MTA خودش رو تغییر داده.

شرکتی مثل دیجی کالا، به دلیل توانایی مالی بسیار بالا و مشتریان و ارسال‌های بسیار زیادی که داره، خودش رفته مستقیما این نرم افزارها رو خرید کرده (عواملش!) و از هیچ‌کدام از سرویس‌های رایج ایمیل مارکتینگ مانند میل چیمپ، مد می‌می، میلرلایت و … استفاده نمی‌کنه و راهکارهای اختصاصی خودش رو داره.

برادران فتحی گفتن که برای سرویس ایمیل مارکتینگ خودشون، چند نرم افزار تجاری آماده رو با هم ترکیب کردن و سیستم جدیدی ساختن! مثلا شرکت‌هایی مانند میل چی و میلرلایت از نرم افزارهای آماده استفاده می‌کنن. نظیر PostFix رایگان توسط (میلرلایت) و PowerMTA تجاری (میل چیمپ) البته تقریبا تمام سرویس‌های ایمیل مارکتینگ دنیا، از یک نرم افزار که MTA نام داره استفاده می‌کنن. این بخش وظیفه ارسال ایمیل‌ها رو بر عهده داره و به هیچ وجه توسط کاربران دیده نمی‌شه. تمام سرویس‌های ایمیل مارکتینگی که ما می‌شناسیم علاقه ای ندارن که درباره اینکه از کدام نرم افزار استفاده می‌کنن صحبتی بکنن و البته این مورد اهمیتی هم برای کاربران و بازاریابان ایمیلی نداره.)

اما با توجه به توضیحاتی که الان ارائه کردم، می‌تونین پی ببرین که چرا مثلا قیمت‌های پلن‌ها و خدمات میلرلایت، ارزان‌تر از سرویسی مانند میل چیمپ هست. به خاطر اینکه میلرلایت از یک نرم افزار رایگان استفاده می‌کنه که هیچ هزینه ای بابتش پرداخت نمی‌کنه، ولی میل چیمپ هزینه زیادی بابت نرم افزارش پرداخت می‌کنه.

البته این به معنی بد بودن میلرلایت نیست، هر شرکتی سیاست‌ و راهکارهای خودش رو داره و به نحوی اینها رو مدیریت می‌کنه. درباره سایر سیستم‌ها در دنیا هم به همین صورته و دیگه نیاز به توضیح نداره. من از مفصل این نکته مجملی گفتم. تو خود حدیث مفصل بخوان ازین مجمل! البته MTA که مخفف Mail transfer agent هست، فقط بخشی از کاره و بسیاری از موارد دیگر هم مهم هستن، مانند مواردی که پایین‌تر درباره اونها توضیح می‌دم.

مقایسه امکانات سرویس آونگ ایمیل و میل چی

کمپین:

آونگ ایمیل – امکان ایجاد دو نوع کمپین وجود داره. regular campaign و autoresponder campaign – کاربرد کمپین Regular اینطوریه که شما یک لیست دارین و می‌خواین به اون لیست ایمیل انبوه یا گروهی ارسال کنین. و Autoresponder هم به معنی پاسخگوی خودکار یا اتوماسیونه. مثلا برای ایجاد یک دوره آموزشی ایمیلی و برای ایجاد ایمیل‌های زمان‌بندی و برنامه‌ریزی شده استفاده می‌شه.

مقایسه امکانات سرویس آونگ ایمیل و میل چی

میل چی – فقط امکان ایجاد یک نوع کمپین وجود داره، چیزی مشابه همون Regular در آونگ ایمیل، و جای خالی Autoresponder در میل چی احساس می‌شه.

مقایسه امکانات سرویس آونگ ایمیل و میل چی

امکان ارسال ایمیل آزمایشی در هر دو سیستم وجود داره. امکان زمان‌بندی ارسال در هر دو سیستم وجود داره. در هر دو سیستم امکان ایجاد گروه حذفی وجود داره.

برنده: آونگ ایمیل. به دلیل داشتن دو نوع کمپین (اتوماسیون، به‌صورت اضافه‌تر) و آپشن‌های بیشتر در ایجاد کمپین.

لیست (گروه):

آونگ ایمیل – امکان ایجاد لیست‌های مختلف وجود داره. مثلا یک لیست برای کاربران عادی عضو خبرنامه، یک لیست برای مشتریان و …

آونگ ایمیل

میل چی – امکان ایجاد لیست‌های مختلف وجود داره. مثلا یک لیست برای کاربران عادی عضو خبرنامه، یک لیست‌برای مشتریان و …

میل چی

نتیجه: مساوی.

سگمنت (بخش بندی):

سگمنت‌ها یکی از اجزای جدا نشدنی در بازاریابی ایمیلی هستن، هرچند شاید در لیست‌های کوچک چندان استفاده از اون مهم به نظر نرسه، اما وقتی که لیست‌ها بزرگتر می‌شن رفته رفته اهمیت سگمنت‌ها هم بیشتر و بیشتر می‌شه. البته به نظر من حتی در کوچک‌ترین لیست‌ها هم بسیار مهم هستن. توضیح درباره این موضوع از حوصله این بحث خارجه و یکی از بحث‌های گسترده و البته کمی پیچیده ایمیل مارکتینگ همین هست.

آونگ ایمیل – امکان ایجاد سگمنت یا بخش‌های مختلف وجود داره. البته باید اعتراف کنم که متاسفانه این بخش در آونگ ایمیل کمی پیچیده و مبهم‌تر از اون چیزی که باید باشه طراحی شده و بهتره این قسمت کمی ساده‌تر بشه. مانند میلرلایت که واقعا بخش سگمت رو تا حد امکان ساده سازی کردن.

سگمنت (بخش بندی)

البته این مورد باعث ترس شما از مبحث سگمنت نشه! اونقدرها هم پیچیده و سخت نیست، فقط فهم این بخش و نحوه به کار بردن صحیح اون، از سایر بخش‌های ایمیل مارکتنیگ کمی مشکل‌تره و نیاز به دقت، فکر و سعی و خطای بیشتری داره.

میل چی – متاسفانه به قضیه سگمنت، در میل چی فعلا اهمتی داده نشده و به نظر می‌رسه که کلا کاری برای این قسمت در حال حاضر انجام نشده. البته امکان ایجاد گروه حذفی وجود داره، ولی اون بحثش از سگمنت جداست.

برنده: هرچند بخش سگمنت در آونگ ایمیل آپشن‌های زیادی داره و بسیاری از امکانات رو داراست، ولی فعلا به دلیل کاربری نامناسب چندان چنگی به دل نمی‌زنه، و البته این به معنی این نیست که بد هست، بلکه باید کمی ساده‌سازی و بهتر بشه. به هر جهت به دلیل وجود نداشتن این بخش در میل چی. آونگ ایمیل در این بخش برنده می‌شه.

فیلدهای سفارشی:

برچسب‌های سفارشی یا tag ها هم در بازاریابی ایمیلی بعضا بسیار مهم و ضروری هستن. یک تعریف ساده درباره این موضوع یعنی ارسال ایمیل‌های سفارشی سازی شده. مثلا شما یک ایمیل ارسال می‌کنین برای علی، سمیه و طلا. وقتی که ایمیل رو ارسال می‌کنین می‌تونین در هر کجا از ایمیل‌تون این نام‌های افراد رو صدا بزنین، در عنوان ایمیل، در متن ایمیل و …

آونگ ایمیل – برچسب‌های زیادی مانند، نام، نام خانوادگی، دامنه، تاریخ عضویت، شماره و … وجود داره. همچنین امکان ایجاد انواع برچسب‌های سفارشی مانند جنسیت (زن یا مرد) و … هم وجود داره.

آونگ ایمیل

میل چی – برچسب‌های زیادی مانند ایمیل، نام، نام خانوادگی، موبایل، نام شرکت، تاریخ تولد وجود داره. همچنین امکان ایجاد انواع برچسب‌های سفارشی مانند جنسیت (زن یا مرد) و … هم وجود داره.

میل چی

برنده: میل چی. به دلیل اینکه هر دو سیستم این امکانات رو تقریبا به‌صورت یکسان دارا هستن، اما در میل چی هم نحوه استفاده، هم نحوه ایجاد تگ‌های سفارشی تازه (اضافی)، آسان‌تر هست. بنابراین میل چی برنده این بخش هست.

وب فرم و لندینگ پیج (صفحه فرود):

لندینگ پیج یا صفحه فرود ، یکی از اجزای احتمالا جدایی ناپذیر بازاریابی ایمیلی در دوره حاضر محسوب می‌شه. نحوه ساخت opt-in page (نوعی از وب‌فرم ها) رو قبلا در وبسایت به صورت رایگان آموزش دادم. البته این مورد در محصول آموزش جامع بازاریابی ایمیلی (ایمیل مارکتینگ) به‌صورت بسیار کامل‌تر و با جزئیات بسیار بیشتری آموزش داده شده.

آونگ ایمیل – هیچ بخشی با عنوان و کاربرد طراحی لندینگ پیج یا صفحه فرود در حال حاضر در این سیستم موجود نیست. اما امکان ایجاد opt-in form یا opt-in page یا embed form و نمایش با درج یا ارجا URL ، یا افزودن کد جاوا اسکریپت اون در وبسایت شما، وجود داره.

وب فرم و لندینگ پیج (صفحه فرود)

میل چی – برخلاف آونگ ایمیل، در میل چی یک لندینگ پیج بیلدر یا طرحی کننده و سازنده صفحه فرود وجود داره که ۴ تمپلیت رایگان و آماده هم به‌صورت پیشفرض در اون قرار دادن. البته این قسمت هنوز امکانات خیلی زیادی نداره و چندان با استانداردهای جدید طراحی وب و لندینگ پیج سازگار نشده و انگار به حال خودش رها شده. اما علاوه بر امکان ایجاد صفحه فرود یا لندینگ پیج، امکان ایجاد opt-in form یا opt-in page یا embed form و نمایش با درج کد جاوا اسکریپت اون در وبسایت شما، وجود داره.

وب فرم و لندینگ پیج (صفحه فرود)

وب فرم و لندینگ پیج (صفحه فرود)

وب فرم و لندینگ پیج (صفحه فرود)

برنده: میل چی.

پلاگین (افزونه):

نوبت می‌رسه به یکی از مهمترین قسمت‌ها در ایمیل مارکتینگ یعنی integration یا ادغام و یکپارچگی.

آونگ ایمیل – سرویس آونگ ایمیل به این زمینه توجه زیادی نشون داده. امکان همگام‌سازی با سرویس crispchat وجود داره، امکان همگام‌سازی با سرویس ایرانی raychat وجود داره. یک پلاگین اختصاصی با نام AvangPress که تغییر داده شده افزونه بسیار کامل و حرفه ای MailChimp هست برای وردپرس ارائه کردن، و در پلاگین Layered Popups (پاپ آپ لایه ای وردپرس و همچنین نسخه stand-alone این پلاگین) امکان همگام‌سازی با آونگ ایمیل وجود داره (از پایه در این پلاگین قرار داده شده)

پلاگین (افزونه)

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

پلاگین (افزونه)

برنده: فعلا آونگ ایمیل در این بخش چندین قدم از میل چی جلوتر هست. بنابراین برنده این قسمت آونگ ایمیله.

ویرایشگر (طراحی ایمیل):

اگر از نظر امکانات رایج بررسی بکنیم، به نظر می‌رسه که تفاوت فاحشی با هم در این قسمت ندارن. ولی اگر از لحاظ طراحی و راحتی کارکرد بخوایم حساب بکنیم، ویرایشگر درگ ان دراپ میل چی کمی روان‌تر و بهتر به نظر می‌رسه. البته در هر دو ادیتور باگ‌هایی وجود داره. (منظور از بحث امنیت نیست، از بحث کارکرده)

آونگ ایمیل

ویرایشگر (طراحی ایمیل)

میل چی

ویرایشگر (طراحی ایمیل)

برنده: احساس می‌کنم نتیجه منصفانه فعلا رای مساوی هست. البته قطعا اگر بخوایم به‌صورت دقیق ادیتورها رو با هم مقایسه بکنیم و تک تک امکانات مثل دکمه، تصویر، ویدیو و آپشن‌های اون رو بخوایم در نظر بگیریم، شاید تفاوت‌های محسوسی وجود داشته باشه. به هر حال فقط یک امکان اضافی ایجاد دکمه full width در آونگ ایمیل وجود داره که شاید به همین دلیل کفه ترازو کمی به سمت آونگ ایمیل سنگینی بکنه! ظاهرا برای هر آیتم، در آونگ ایمیل کمی آپشن‌های بیشتری وجود داره.

تمپلیت های ایمیل:

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

تمپلیت های ایمیل

میل چی – تمپلیت آماده ای نداره و باید خودتون در هنگام ارسال ایمیل، اون رو طراحی بکنین.

برنده: آونگ ایمیل برنده این بخشه. به خاطر اینکه ویرایشگر و دراگ اند راپ رو آونگ ایمیل هم داراست. بحث تمپلیت‌ها جدای از بحث ادیتوره که در تمامی سرویس‌های دنیا تعداد زیادی تمپلیت آماده رایگان، استاندارد و زیبا برای استفاده وجود داره.

امکانات دامین:

آونگ ایمیل – امکان تنظیم spf و dkim در تمامی پلن‌های رایگان و پولی وجود داره. DMARC رو هم به‌صورت اضافه‌تر داراست!

امکانات دامین

میل چی – امکان تنظیم spf, dkim تنها در حساب‌های بالای صد هزار مخاطب وجود داره!

برنده: برنده آونگ ایمیل هست. در خصوص میل چی، بهتره که این امکان حتی برای تمامی حساب‌های رایگان هم فعال بشه. در تمامی سرویس‌های استاندارد دنیا به همین صورت هست و به راحتی توسط کاربرانش قابل تنظیمه.

فونت‌های فارسی:

آونگ ایمیل – در بخش طراحی ایمیل، سه فونت فارسی یکان، نازنین و میترا قرار داده شده.

فونت‌های فارسی

میل چی – در بخش طراحی ایمیل، شش فونت فارسی با نام‌های یکان، رویا، زر، میترا، ترافیک و نازنین قرار داده شده.

فونت‌های فارسی

برنده: میل چی. چون سه عدد فونت فارسی بیشتر در حال حاضر در میل چی قرار داده شده.

البته از بُعد فنی در مسائل اسپم و … نمی‌دونم این موردی که جلوتر می‌خوام بگم چقدر بر روی کیفیت ارسال تاثیرگذار هست، ولی خوبه که در هر دو سیستم یه مقدار بر روی smooth و anti-aliasing این فونت‌های فارسی هم کار بشه، البته اگر باعث نمی‌شه که به کیفیت ارسال‌ها ضربه ای وارد بشه که فکر نمی‌کنم چنین اتفاقی بیوفته. پیشنهاد بهتر استفاده از فونت تجاری ایران سنس هست.

ارسال ایمیل فعال‌سازی پس از پیوستن به یک لیست (تایید دو مرحله ای):

در میل چی در برخی از قسمت‌ها این امکان وجود داره، مثلا هنگام ایجاد وب فرم، اما در آونگ ایمیل در تمامی بخش‌ها وجود داره.

چون شرط ارسال ایمیل فعال‌سازی، وابسته به زمانی شده که یک کاربر جدید به یک لیست افزوده می‌شه.

پس برنده این بخش آونگ ایمیل هست.

امکان کپی کمپین قبلی:

در هر دو سرویس این امکان وجود داره. نتیجه مساویه.

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

اس ام تی پی سرور (SMTP Server):

هر دو سیستم فعلا به‌صورت رسمی خدماتی در این زمینه ارائه نمی‌کنن. اما ظاهرا آونگ ایمیل برنامه ای برای ارائه این خدمت هم داره.

امنیت:

امنیت فاکتورهای بسیار مهمی داره که بررسی برخی از اونها از تخصص من خارجه.

ولی جای خالی یک فرم ورود دو مرحله ای و همچنین ریکپچا در قسمت پنل هر دو سیستم احساس می‌شه. هر دو سرویس از SSL و پروتکل HTTPS برخوردارن. بنابراین در این قسمت هم مساوی هستن.

پشتیبانی:

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

گزارشات:

گزارشات یکی از بخش‌های مهم (اصلی‌ترین بخش‌ها در ایمیل مارکتینگ هست.) هر دو سیستم، در بحث گزارش‌گیری و ارائه گزارشات و آمارها، امکانات استاندارد، تقریبا یکسان و کافی رو به ما ارائه می‌کنن. مانند اوپن ریت، کلیک ریت، بانس ریت و … بنابراین در این بخش هم مساوی هستن.

آونگ ایمیل

گزارشات

میل چی

گزارشات

سرعت تغییرات، میزان اهمیت به بازخوردها و تحقیقات صورت گرفته

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

البته این به معنی این نیست که میل چی توجه نمی‌کنه، چرا که در مقاله حاضر دیدیم که بسیاری از امکانات استاندارد مورد نیاز در این سیستم هم قرار داده شده و این قطعا با تحقیق، اهمیت به بازخوردها و صرف انرژی و پول ایجاد شده. ولی به هر حال متاسفانه سرعت تغییرات میل چی، پایینه. و با توجه به پیشنهاداتی که چند سال هست دارم به عوامل میل چی ارائه می‌کنم، همچنین سایر همکارانم ارائه کردن، تاکنون سرعت تغییر پایینی داشته.

لازم به ذکره که مدیرعامل هردو سیستم اخیرا قول‌های بیشتری دادن برای اینکه سریعتر و بیشتر سیستم‌های خودشون رو با نیازهای روز هماهنگ بکنن. مانند سازگاری با پلاگین‌های بیشتر و افزودن برخی امکانات که در تمام سرویس‌های ایمیل مارکتینگ دنیا وجود داره. زمان خودش ثابت می‌کنه که در آینده چه اتفاقاتی میوفته و تغییراتی که در آینده نزدیک یا دور برای این سیستم‌ها به وجود میاد، می‌تونه با مقاله حاضر و وعده‌ها و ادعاها مقایسه بشه.

کلام آخر:

هیچ‌کدام از این سرویس‌ها رو هنوز از لحاظ کیفیت و مثلا صحت کارکرد ابزارها مانند پلاگین‌ها، وب فرم‌ها و … به‌طور کامل تست نکردم. تا جایی که وقت کردم تست انجام دادم و فعلا مشکلی در اونها مشاهده نکردم و در یک لیست یکی دو ایمیلی، ایمیل‌ها سریعا ارسال و به اینباکس رسید.

ولی از لحاظ کیفیت نمی‌تونم هیچ‌کدام رو برنده اعلام بکنم. چون هنوز تست دقیقی صورت نگرفته. البته جای هیچ ترس و شک و شبهه ای وجود نداره، امتحانش کاملا مجانیه! هر دو سیستم پلن رایگان دارن. در ابتدای همین مقاله لینک وب‌سایت هاشون رو برای شما دوستان عزیزم قرار دادم، کلیک کنین و ثبت‌نام کنین.

 

ادامه مطلب

آزمایش تأثیر سرعت جوملا 3.5 و PHP 7 ؟

Joomla 3.5 که به تازگی منتشر شده است پر از ویژگی های سودمند است اما شاید بزرگترین تغییر ، تغییری باشد که کاربران نهایی متوسط به آن فورا توجهی نمیکند ؛ پشتیبانی از PHP7 . البته ویژگی های محسوس تری مانند کشیدن و انداختن عکس ها در ویرایشگر اول یا چیزهای اضافه شده ی UI به جریان کار و مدیریت موضوع کمک میکنند اما PHP7 چیزی مفید تر ارائه میکند ، برای توسعه ی تجربیات کاربر و کاهش میزان چیزهای اضافی که باعث بارگذاری سریع تر صفحات میشود . اگر در مورد PHP7 چیزی خوانده باشید از این تغییرات خبر دارید اما این تغییرات چه تاثیری بر روی Joomla دارند ؟ در این مقاله این مسئله بررسی میشود.

آزمایش تأثیر سرعت جوملا 3.5 و PHP 7 ؟
تغییرات چشمگیر در PHP

به روز رسانی PHP7 به عنوان مهم ترین تغییر برای PHP از زمان بیرون آمدن PHP5 در سال 2004 اعلام شد ، که ادعای کمی نیست . در واقع تیم PHP بیان میکند که عملکرد کلی اش دو برابر شده و مصرف حافظه اش را تا 50 درصد میتواند کاهش دهد . آخرین نسخه ی PHP همچنین چند ویژگی جدید مانند نوشتن بیانیه ، اپراتور کلاس یا سفینه ی فضایی ناشناس را معرفی میکند اما خطاهای مرگباری هم دارد . خبر های بدی هم وجود دارد ، به خاطر jommla 3.5 حمایت PHP7 به صورت برعکس دیگر ممکن نیست . درواقع بیشتر تغییرات در هسته ی PHP دیگر به صورت برعکس نیستند بنابراین Joomla هم همین وضعیت را دارد . اگر یک طراح هسته ی PHP باشید میتوانید لیست کامل تغییرات برعکس ناسازگار را ببینید .

 

 محیط آزمایشی

برای آزمایش این عملکرد من تصمیم گرفتم تا از آخرین به روز رسانی joomlaاستفاده کنم . jommla 3.5.1  . با نصبی تازه و یک نمونه ی داده ی بلاگ . این آزمایش ها روی سرور هاست محلی من و باستفاده از MAMP  برای OS X انجام میشوند .

در زمینه ی PHP های تست شده ، من عملکرد Joomla  را در PHP معروف و محبوب 5.6.10 استفاده کردم و البته PHP 7,0,0 .

 محیط آزمایشیمن روی تست های نرم افزار نهایی تمرکز کردم زیرا این میتوانست سود کلیدی تجربه ی کاربری برای بیشتر کاربران Joomla باشد . در نصب های آزمایشی ام ، قسمت ذخیره را در joomla خاموش کرده و ذخیره را در سرور محلی ام برای مقایسه ای خالص تر غیر فعال کردم .تراکم Gzip هم برای گرفتن نتایج دقیق بارگذاری غیر فعال بود . در همان ابتدا ی نصب joomla ماژول های مختلفی را نشان میدهد :

  • ماژول های لیست ماژول
  • ماژول های منو
  • ماژول های جستجو
  • ماژول های منوی اصلی
  • لیستی از تمام بازدید های نرم افزار نهایی
  • ماژول های منوی دوم
  • ماژول شبیه ورود                                                                                    من تصمیم گرفتم که رهایشان کنم چون هر ماژول جستاری های پایگاه داده هایی تولید میکند  و روی استفاده از حافظه و زمان بارگذاری تاثیر میگذارد ، بنابراین رها کردنشان یک نتیجه ی واقعی به وجود خواهد آورد . در این نصب بارگذاری صفحه ی روبه رویی 21 جستار MySQL تولید میکند که ارزشی زیاد برای محتوای وبسایت ها دارد و بستگی به تعداد افزونه های نصب شده ی سوم شخص  دارد اما بخشی از جستار ها همیشه در همان سطح باقی خواهند ماند . به خاطر عملیات های هسته ی joomla  مانند مدیریت بخش ها یا ماژول های منتشر شده .

 

عملکرد joomla 3.5 در PHP5.6  و PHP7

قبل از اینکه به بخش اصلی آزمایش برسیم ، در نظر داشته باشید که اثرات این آزمایش ممکن است زمانی که به سرور زنده ی شما میرسند دقیق نباشند ، هنوز محدوده ای از پارامتر های مختلف وجود دارند که میتوانند روی عملکرد تاثیر بگذارند . هدف اصلی این تست آزمایش عملکرد خالص Joomla  در PHP7 است . با وجود وبسایت هایی با ترافیک بالا یکی از نقاط کلیدی تعداد درخواست هایی است که سرور شده در ثانیه پاسخ میدهد ، اما این به این معنی نیست که Joomla  در PHP7 هیچ توسعه ای نداشته و ارزش امتحان را ندارد ، بنابراین یک آزمایش هاست مرکزی  میتواند موثر باشد – میزان حافظه ی استفاده شده برای بارگذاری و نمایش وبسایت و کل زمان بارگذاری . ما سرعت پایگاه داده ها را در این آزمایش در نظر نگرفتیم بنابراین از همان نسخه ی (MySQL ( MySQLi 5.5,42  در هر دو آزمایش استفاده کردیم ، با همان جستار و زمان آزمایش بدون توجه به اینکه کدام نسخه ی PHP فعال است .

در این تست من نتایج را از سه صفحه ی مختلف بررسی کردم :

در زیر شما به صورت شکل جزئیات خرابی  زمان های بارگذاری عناصر صفحه ها را میبینید ؛ همانطور که میبینید توسعه در PHP7 7,0,0  خیلی قابل توجه است . برای وظایف کوچک مانند BeforeRender تفاوت ماژول ها زیاد برجسته نیست اما برای مهم ترین لینک ها مانند afterInitalise و afterRender  joomla 305 سرعت بالا میرود ! ما میتوانیم در تصویر بالا ببینیم که afterInitialise در اصل 149.40 میلیونم ثانیه وقت گرفت و afterRenderComponent 141.23 میلیونم ثانیه تا بارگذاری شوند ، در حالیکه بعد از به روز رسانی این زمان ها به 62.80 و 60.93 کاهش یافتند. بنابراین باjoomla 3,5,1  و PHP7 فرایند بارگذاری این لینک ها دوبرابر سریع تر از PHP5,6,10  کامل میشود . این تقریبا موفقیتی است که مانند CMS در نظر گرفته شد . فقط با نسخه ی مختلف PHP . و فقط سرعت نیست بلکه حافظه ی کمتری هم اشغال میکند . ارزش استفاده از حافظه واقعا برای وبسایتهایی با ترافیک بالا مهم است و در اینجا برجسته ترین تغییرات مشاهده میشود .

 

عملکرد joomla 3.5 در PHP5.6  و PHP7

عملکرد joomla 3.5 در PHP5.6  و PHP7

یک نصب تمیز joomla با ماژول های پایه و یک مقاله با محتوای کامپیوتر در صفحه ی اصلی کمتر از 9 مگابایت حافظه میخواهد – 8.49 مگابایت . زمانی که در حال استفاده از نسخه ی قدیمی تر PHP هستیم نیاز به حداقل 12 مگابایت ( 12.05)  داریم تا همان صفحه را بارگذاری کنیم . که یعنی تعویض به PHP7 چهل درصد حافظه را نگه می دارد . یک نگاه سریع به زمان بارگذاری به ما بیشتر در مورد جزئیات میگوید ، سرعت کلی خیلی بهتر است .

 

عملکرد joomla 3.5 در PHP5.6  و PHP7

عملکرد joomla 3.5 در PHP5.6  و PHP7

چیزی که میتوانیم ببینیم این است که این تنها یک دستاورد معمولی نیست ، هر وظیفه ای سریع تر بارگذاری میشود . این نشان میدهد که ما دستاورد های مشابهی را در بیشتر آیتم های بارگذاری خواهیم دید . فراموش نکنید که در این آزمایش ما کل ذخیره را غیر فعال  کردیم و داده ها به صورت غیر فشرده در جستجوگر آورده شدند بنابراین وقتی این گزینه ها فعال شوند ،  میتوانیم انتظار دستاورد های بیشتری را هم داشته باشیم .

 

قبل از اینکه به PHP7  ارتقا دهید

برای من ، و همانطور که نتایج نشان میدهد ، معرفی PHP7 در آخرین joomla بزرگترین پیشرفت حاضر است و گزینه های به روز رسانی بیشتری ارائه میکند .  گرچه این چیزی نیست که شما لزوما در اولین بار متوجه شوید . چیزی که متوجه خواهید شد سرعت بارگذاری است که یک فاکتور برجسته در مورد سایت است  و حافظه ی توسعه داده شده تجربه ی قوی تری برای سایت هایی فراهم میکند که تعداد زیادی بازدید کننده و بازدید صفحه دارند ، به طور طبیعی ؛ گرچه استفاده از یک سرور هاست محلی مکان خوبی برای عملکرد کلی آزمایش است ، پس نوساناتی در هر سایت بسته به پیکر بندی سخت افزار در ماشین زنده دیده خواهد شد . با این حال امکان هر نوع بالا رفتن سرعتی ، چیزی نیست که بتوان انکارش کرد . در این تست ها تقریبا همه ی نیروی CPU استفاده میشود تا یک صفحه در یک جستجوگر کار کند ، در حالیکه هاست بودن شما احتمالا بازدید کنندگان بسیاری به صورت همزمان خواهد داشت ، بنابراین حتی پیشرفت های کوچک در زمان بارگذاری هم مهم خواهند بود . همراه این ، حافظه ی مدیریت بسیار زیاد است ، 40 درصد حافظه ی کمتر بر حسب صفحه خیلی زیاد است . با در نظر گرفتن همه ی اینها ، تنها سوالی که داریم این است که چرا حالا ارتقا ندهیم ؟

واضح است که پیشرفت سرعت و حافظه چیزهایی هستند که شما میخواهید خیلی زود از آنها بهره مند شوید ، اما بهتر است که خیلی عجله نکنید . امکانش وجود دارد که سایت شما اصلا نصب joomla نداشته باشد . همیشه افزونه هایی وجود دارند که نمیتوانیم بدون آنها کاری کنیم . اینکه joomla 3,5 از PHP7 حمایت میکند به این معنی نیست که هر کدام از افزونه های Joomla 3.5  با آخرین انتشار PHP کار خواهد کرد . بنابراین قبل از اینکه محصول سایتتان را به php7 تعویض کنید ، زمان بگذارید تا تحقیق کنید که آیا فراهم کنندگان افزونه هایتان از آن حمایت میکنند یا آیا در آینده اینکار را خواهند کرد تا بتوانید بر اساس آن برنامه ریزی کنید . البته برگرداندن ارتقا چیزی است که اگر به مشکل برخوردید میتوانید از آن استفاده کنید ، با PHPMyAdmin بیشتر هاست ها امکان گزینه ی ساده ای را برای انتخاب نسخه ی PHP میدهند ، اما برای هاست های کوچکتر برگشتن به تغییرات ممکن است یک مشکل باشد . فراموش نکنید که این را هم چک کنید که آیا فراهم کننده ی هاستتان php 7.0.0 را پشتیبانی میکند یا نه ، اگر نه پس الان زمان آن است که دنبالش بگردید تا بتوانید از مزایای این تاثیر برخوردار شوید .

امیدوارم که این مقاله به شما نشان داده باشد که چه دستاورد هایی را از ارتفا PHP و joomla انتظار دارید . اگر میخواهید بدنید که چه چیزی در Joomla  3.5  تغییر کرده نگاهی به تفکیک ویژگی های joomla 3.5 بیندازید .

ادامه مطلب

انواع معماری وب سرویس

انواع معماری وب سرویس

انواع معماری وب سرویس

یکی از مهمترین تحولات در صنعت نرم افزار، پیشرفت و بهبود در زمینه ی معماری نرم افزار و آنهم در سمت وب و اینترنت بوده است. سرویس های وب یا همان وب سرویس، تسهیلات لازم بمنظور ایجاد نسل جدیدی از برنامه های وب را ارائه می نمایند.

مقدمه

اگر قصد دارید نرم افزارها و وب سایت های از نوع distributed یا همان توزیع شده ایجاد کنید، می بایست به نکات زیر توجه کنید:

• در مواردیکه قصد ارتباط بین منابع نرم افزاری وجود داشته باشد، منابع می بایست بدرستی و بخوبی با یکدیگر مرتبط گردند( منابع مشخص و از یکدیگر متمایز گردند).
• ارتباط بین برنامه ها می بایست متکی بر استانداردهای اینترنت باشد.
• اینترفیس های ( بخش های مرتبط با استفاده کننده ) منابع نرم افزاری، می بایست برای استفاده عموم منتشر و امکان دسترسی به تعاریف اینترفیس بهمراه مستندات مربوطه وجود داشته باشد.
برنامه هائی که با لحاظ نمودن موارد فوق، طراحی و پیاده سازی می گردند ، مزایای زیر را بدنبال خواهند داشت :
• می توان از سرویس های نرم افزاری و منابع خارجی بمنظور طراحی و پیاده سازی نرم افزار مورد نظر خود استفاده کرد.
• امکان ایجاد منابع نرم افزاری بیشتری بصورت ماژولار، وجود خواهد داشت ( کیت های نرم افزاری با قابلیت استفاده مجدد ).
• هزینه تولید نرم افزار کاهش و بهره وری افزایش خواهد یافت .
• مطرح شدن ایده عرضه نرم افزار بعنوان سرویس . بدین ترتیب در مقابل عرضه یک نرم افزار Stand-alone ، می توان از رویکرد نرم افزار بعنوان سرویس ، استفاده نمود.

عناصر معماری مبتنی بر سرویس

معماری مبتنی بر سرویس (وب سرویس) برای پیاده سازی برنامه های توزیع شده یا distributed ،بسیار مناسب می باشد. معماری فوق، امکان پیاده سازی پویا ، آزاد و گسترده برنامه های توزیع شده را فراهم می نماید.
امروزه شاهد بکارگیری سیستم های متعددی می باشیم که خود از چندین برنامه و یا زیر سیستم استفاده می نمایند. با توجه به ارتباط بین سیستمها با یکدیگر، ایجاد و اعمال یک تغییر در ارتباط با هر یک از زیر سیستمها می تواند باعث بروز اشکال در تعداد زیادی از عناصر وابسته و یا سایر برنامه ها گردد . رویکرد فوق ، افزایش هزینه نگهداری این نوع سیستم ها را بدنبال خواهد داشت.
معماری مبتنی بر سرویس ، وابسته به سه عنصر اساسی است که هر یک دارای جایگاه خاص خود می باشند : Service Provider ( ارائه دهنده سرویس ) ، Service consumer ( مصرف کننده سرویس ) و Service broker ( کارگزار سرویس ).
ارائه دهنده سرویس ، گره ای در شبکه ( اینترانت و یا اینترنت ) است که امکان دستیابی به اینترفیس یک سرویس نرم افزاری را فراهم می نماید. گره ارائه دهنده سرویس ، امکان دستیابی به سرویس های یک سیستم تجاری ، یک زیر سیستم و یا یک عنصر را بوجود می آورد .مصرف کننده سرویس ، گره ای در شبکه است که به سرویس ارائه شده توسط یک ارائه دهنده سرویس مرتبط و از امکانات و پتانسیل های سرویس ارائه شده در جهت پیاده سازی سیستم خود استفاده می نماید. مصرف کننده سرویس را می توان بمنزله یک برنامه سرویس گیرنده بر روی یک گره در نظر گرفت . کارگزار سرویس ، گره ای در شبکه است که مسئول تشریح سرویس را برعهده داشته و می توان آن را بمنزله یک دفترچه آدرس در نظر گرفت که برای جستجو و یافتن سرویس ، مورد استفاده قرار می گیرد. مصرف کننده سرویس ( متقاضی ) ، درخواست خود را در ارتباط با سرویس موردنظر به کارگزار ارائه و کارگزار، سرویس درخواستی بهمراه ارائه دهنده مورد نظر را پیدا می نماید.

معماری وب سرویس

معماری وب سرویس

ارتبا ط بین وظایف سه گانه

عناصر سه گانه اشاره شده در معماری وب سرویس، با یکدیگر مرتبط هستند تا زمینه تحقق عملیات زیر فراهم گردد :
• عرضه سرویس : ارائه دهندگان سرویس ، سرویس ها ی خود را برای یک کارگزار سرویس ، عرضه می نمایند ( ثبت در دفترچه آدرس ) . اطلاعات ارائه شده شامل : تعریف اینترفیس سرویس ، محل ارائه دهندگان سرویس ، سایر اطلاعات حمایتی و یا مستندات ضروری خواهد بود.
• یافتن سرویس : مصرف کنندگان ، سرویس ها ی مورد نیاز خود را با کمک یک کارگزار ، پیدا خواهند کرد .
• ارتباط به سرویس : مصرف کنندگان سرویس به سرویس های خاصی که توسط یک ارائه دهنده سرویس ارائه شده است ، مرتبط و زمینه استفاده آنان از سرویس مورد نظر فراهم خواهد شد. فرآیند فوق ، شامل تائید مصرف کنندگان خواهد بود.
عملیات یافتن و نسبت دهی سرویس ها می تواند بصورت پویا انجام گیرد . بدین ترتیب برنامه ها قادر خواهند بود بصورت پویا خود را پیکربندی نمایند. مثلا” اگربرنامه ای تشخیص دهد که مدت زمان پاسخ از یک ارائه دهنده سرویس ، زمانی غیر معقول است ، می تواند در زمان اجراء ، تصمیم بر استفاده از یک ارائه دهنده سرویس دیگر نماید .

معماری سرویس های وب و معماری مبتنی بر سرویس

عناصر اساسی در معماری سرویس وب عبارتند از :
• ارائه دهنده سرویس وب .گره ای در شبکه که مسئولیت میزبان نمودن یک سرویس وب را برعهده خواهد داشت .
• مصرف کننده سرویس . گره ای در شبکه که مسئولیت میزبان نمودن هر سرویس گیرنده ای را که قادر به ارتباط با استفاده از HTTP باشد را برعهده می گیرد. مرورگرها ، برنامه های کنسول و برنامه هائی با رابط کار گرافیکی سنتی ، نمونه هائی از برنامه های سرویس گیرنده می باشند.
• کارگزار سرویس وب. گره ای در شبکه که مسئولیت میزبان نمودن یک ریجستری سراسری از تمامی سرویس های وب در دسترس را برعهده خواهد داشت .( نظیر یک کتاب آدرس جامع ) .
تمامی گره های فوق ، قادر به ارتباط با یکدیگر از طریق شبکه های مبتنی بر پروتکل TCP/IP می باشند . در سرویس های وب ، سه گره تعریف شده در معماری مبتنی بر سرویس ، متناظر با عناصر سرویس های وب خواهند بود:
کارگزار سرویس ، مسئولیت میزبان نمودن UDDI)Universal Description,Discovery and Integration ) را برعهده خواهد داشت .
ارائه دهنده سرویس ، مسئولیت عرضه سرویس های وب از طریق صفحات ASP.NET با انشعاب asmx . را برعهده خواهد داشت .
مصرف کننده سرویس ، قابلیت برقراری ارتباط از طریق HTTP ویا SOAP)Simple Object Access Protocol) را دارا می باشد .
همانگونه که اشاره گردید، در معماری یک سرویس وب از سه عنصر اساسی استفاده می شود : ارائه دهنده سرویس وب ، استفاده کننده سرویس وب و کارگزار سرویس وب . در ادامه به تشریح هر یک از عناصر فوق خواهیم پرداخت . ( در این بخش از مقاله به بررسی ارائه دهنده سرویس پرداخته و در بخش دوم این مقاله ، مصرف کننده سرویس و کارگزار سرویس ، تشریح خواهند شد ) .

ارائه دهنده سرویس

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

سرویس دهنده وب

یک ارائه دهنده سرویس می بایست حداقل شامل یک گوش دهنده ( listener ) پروتکل باشد . برای سرویس های وبی که توسط فریمورک دات نت و یا ویژوال استودیو دات نت ، پیاده سازی می گردند ، گوش دهنده پروتکل می بایست یک HTTP listener باشد . با توجه به اینکه یک ارائه دهنده سرویس قادر به میزبان نمودن چندین سرویس وب خواهدبود ،ارائه دهنده سرویس ،می بایست امکان هدایت مناسب یک درخواست به سرویس وب مناسب را دارا باشد . ( قابل مقایسه با سرویس RPCCC) Remote Procedure Call Subsystem)، که مسئولیت پاسخگوئی به درخواست های وارده DCOM وهدایت آنان به یک سرویس دهنده مناسب COM است) .مصرف کنندگان ناشناخته سرویس وب ، قادر به دستیابی به یک ارائه دهنده سرویس می باشند . بنابراین لازم است ، سرویس دهنده وب سرویس های پایه امنیتی را حداقل در سطح پروتکل، ارائه نماید. IIS ، که یک سرویس دهنده وب است ، سرویس های مورد نیاز یک سرویس وب را ارائه می نماید :
• IIS یک HTTP listener است
• IIS با استفاده از معماری ISAPI ، می تواند بعنوان یک gateway در رابطه با سرویس های وب رفتار نموده و علاوه بر میزبانی از سرویس های وب متعدد ، زمینه هدایت صحیح آنان را نیز فراهم نماید.
• IIS زیرساخت قابل ملاحظه ای در رابطه با امنیت را ارائه می نماید .

IIS و سرویس های وب

یک سرویس دهنده وب نظیر IIS ، قادر به فراخوانی یک سرویس از جانب یک سرویس گیرنده با استفاده از گزینه های متعددی است . سرویس دهنده وب قادر به فعال نمودن ( اجراء ) یک برنامه CGI)Common Gateway Interface) ، اجرای یک مفسر اسکریپت بمنظور برخورد با صفحات ASP و یا فراخوانی یک برنامه ISAPI است .زمانیکه IIS همراه با CLR فعالیت می نماید ، از یک فیلتر ISAPI بمنظوربررسی درخواست هائی در ارتباط با صفحات با انشعاب asmx استفاده و در ادامه یک میزبان زمان اجراء را فعال می نماید . میزبان زمان اجراء ، کد مربوط به سرویس وب را که توسط فریمورک دات نت پیاده سازی شده است ، اجراء خواهد کرد.
در این بخش به بررسی نقش و جایگاه مصرف کنندگان و کارگزاران سرویس ها ی وب ، خواهیم پرداخت .

مصرف کننده سرویس

در این بخش با حداقل قابلیت های موردنیاز یک مصرف کننده سرویس وب بمنظور استفاده از یک سرویس وب ، نحوه یافتن یک سرویس وب توسط مصرف کننده سرویس وب ، نقش پروکسی ها در پیاده سازی مصرف کنندگان سرویس وب ونحوه استفاده از پروکسی ها بمنظور فراخوانی غیرهمزمان سرویس های وب، آشنا خواهیم شد.
حداقل توانائی : بمنظور استفاده از سرویس وب ، یک مصرف کننده سرویس وب ، می بایست متدهائی از سرویس وب را بهمراه پارامترهای مورد نیاز و بکمک استفاده از پروتکل های موجود ( مثلا” SOAP ) و حمایت شده توسط سرویس مورد نظر را فراخوانی نماید . فرمت دهی مناسب پیام ها قبل از ارسال برای یک سرویس وب ، آشنائی و برخورد مناسب با جزئیات پروتکل هائی که سرویس وب حمایت می نماید، از جمله مواردی می باشند که می تواند چالش هائی را در زمینه سرویس های وب بدنبال داشته باشد.

فریمورک دات نت با ارائه کلاس هائی در این زمینه، اکثر جزئیات سطح پائین را کپسوله می نماید. کپسوله نمودن جزئیات سطح پائین، ضرورت پیاده سازی زیرساخت را از پیاده کنندگان سلب و آنان را از این فعالیت معاف می نماید .
مکان یابی سرویس : قبل از امکان استفاده از یک سرویس وب ،مصرف کننده می بایست قادر به یافتن آن باشد . یکی از راهکارهای موجود در این زمینه درج کد بصورت دستی ( برخوردی کاملا” ایستا ) در مصرف کننده سرویس وب و در هنگام طراحی است. در چنین مواردی آدرس سرویس ارائه شده بصورت مستقیم در برنامه مصرف کننده سرویس درج خواهد شد.
یکی دیگر از راهکارهای موجود در این زمینه ، امکان یافتن پویای یک سرویس وب توسط مصرف کننده سرویس وب و در زمان اجراء است . بدین ترتیب ، مصرف کننده سرویس وب دارای انعطاف لازم در خصوص انتخاب بین سرویس های وب رقیب با عملکرد مشابه و بر اساس ویژگی هائی خاص نظیر قیمت و کارآئی ، خواهد بود . روش استاندارد برای یافتن سرویس های وب ، تشریح سرویس و خدمات ارائه شده توسط آنان ، استفاده از یک ریجستری UDDI است . ( Universal Description,Discovery, and Integration )
پروکسی ها : در زمان پیاده سازی یک مصرف کننده سرویس وب ، پیاده کنندگان می توانند زمان خود را صرف افزایش بهره وری نموده و خود را درگیر موارد زیر ننمایند .
• فعالیت و درگیر شدن در ارتباط با پروتکل های زیربنائی
• پارسینگ بایت ها بمنظور استخراج داده
• بررسی صحت و اعتبار داده های ورودی ( دریافتی )
• ایجاد و ساخت بسته های اطلاعاتی بمنظور خروجی علیرغم توصیه های انجام شده ، اغلب پیاده کنندگان بمنظور انجام عملیات فوق ، وقت خود را صرف انجام فعالیت های فوق می نمایند ، چراکه در این رابطه کد از قبل ایجاد شده ای وجود ندارد. یکی از رویکردهای متداول در این زمینه (هندل نمودن فعالیت ها ی فوق ) ، کپسوله سازی و یا پنهان نمودن جزئیات پیاده سازی در کلاسی است که بعنوان یک پروکسی برای سرویس وب ، رفتار می نماید.
کلاس های پروکسی علاوه بر پنهان سازی جزئیات پیاده سازی ، یک مدل برنامه نویسی شناخته شده را بمنظور فراخوانی متدهای اشیاء در اختیار پیاده کنندگان قرار خواهند داد. تنها مسئله مرتبط با روش فوق ، پیاده سازی یک کلاس پروکسی برای هر اینترفیس سرویس وبی خواهد بود که یک مصرف کننده سرویس وب از آن بمنظور ارتباط استفاده خواهد کرد . مایکروسافت در این رابطه ابزاری با نام Wsdl.exe را ارائه که می توان از آن بمنظور پیاده سازی کلاس های پروکسی سرویس وب استفاده نمود. باتوجه به اینکه، یک اینترفیس سرویس وب با استفاده از XML تعریف می گردد، شایسته تر است که ابزارهائی را ایجاد که قادر به تولید اتوماتیک کلاس های پروکسی باشند.
فراخوانی غیرهمزمان : با توجه به اینکه دستیابی به سرویس های وب عموما” از طریق شبکه ها ( نظیر اینترنت ) که عمدتا” قابلیت اطمینان و سرعت شبکه های محلی را ندارند ،میسر می گردد ، شاید مناسبتر باشد که مصرف کنندگان سرویس وب ، بگونه ای پیاده سازی گردند که قادر به ایجاد فراخوانی غیرهمزمان به سرویس های وب باشند . پروکسی ها ئی که با استفاده از Wsdl.exe تولید و ایجاد می گردند ، این امکان را به صدازنندگان سرویس خواهند داد که فراخوانی غیرهمزمان به یک سرویس وب را داشته باشند. کلاس پروکسی با ترکیب RunTime ، مسئولیت برخورد با جزئیات مدیریت Thread pool ، اتمام یک متد callback notification و سایر موارد مرتبط را برعهده خواهند داشت .
نمونه هائی از مصرف کنندگان سرویس وب : برنامه های تجاری ( زمینه های متعدد تجاری ) اولین کاربران و متقاضیان سرویس های وب می باشند ولی تعداد زیادی فعالیت تجاری دیگر نیز وجود دارد که می توانند بعنوان مصرف کنندگان سرویس وب مطرح گردند . روزنامه های Online و ASP :Application Service Provider ، دو نمونه در این زمینه می باشند . یک روزنامه Online ، ممکن است از جندین سرویس وب خبری بمنظور تامین اخبار نشریه خود استفاده نماید . اخبار ورودی می توانند قالب بندی و فیلتر شده و برای آنان فهرست توصیفی تهیه و قابلیت جستجو بر روی آنان با توجه به خواست مصرف کننده ایجاد گردد . یک ASP ممکن است سرویس های وب متعددی را میزبان و یا خود راسا” اقدام به تولید سرویس های وب مورد نیاز و ارائه آنان به مشتریان مربوطه نماید.

معماری وب سرویس در بستر کلاد

معماری وب سرویس در بستر کلاد

کارگزار سرویس وب

همانگونه که یک معماری مبتنی بر سرویس نیازمند یک کارگزار سرویس است ، یک معماری وب سرویس service broker، نیز نیازمند یک کارگزار سرویس خواهد بود. بمنظور تسهیل در ارتباط ، بنگاههای تجاری نیازمند یک راه حل جامع و فراگیر بمنظور نشر اطلاعات خود به هر یک از مشتریان و یا شرکاء تجاری خود در سطح جهان می باشند .یک کارگزار سرویس وب ، هم با ارائه دهنده سرویس وب و هم با مصرف کننده سرویس وب ارتباط تا زمینه استفاده از امکانات ارائه شده توسط ارائه دهندگان سرویس های وب و استفاده از سرویس های وب ارئه شده برای مصرف کنندگان سرویس های وب ، فراهم گردد. سازمان ها با نشر اطلاعات مرتبط با سرویس ها و خدمات تجاری خود ، به پتانسیل های زیر دست خواهند یافت :
• امکان یافتن سریع همکاران تجاری از بین میلیون ها بنگاه تجاری Online
• تعریف نحوه مدیریت فعالیت های تجاری پس از یافتن بنگاههای تجاری مورد نظر
• ایجاد یک رویکرد گسترده صنعتی برای فعالیت های تجاری که ارتباط و همبستگی سریع و آسان با مشتریان و شرکاء تجاری بر روی اینترنت را بدنبال خواهد داشت .در این رابطه ، سازمانها قادر به ارائه اطلاعات مشترک در ارتباط با محصولات و خدمات خود بوده و امکان حق انتخاب در رابطه با گزینش نوع ارتباط با سایر فرآیندهای تجاری و سیستم ها نیز فراهم می گردد .
ارتباط بین کارگزار سرویس وب و ارائه دهنده سرویس وب : کارگزاران بمنظور ارائه صحیح سرویس های وب از ارائه دهندگان سرویس های وب درخواست اطلاعات متنوعی در رابطه با سرویس ارائه شده را خواهند داشت . اطلاعات اخذ شده بمنزله شناسنامه یک سرویس وب خواهد بود که پس از ارائه و تائید و طی مراحل مربوطه در ریجستری UDDI ذخیره تا امکان در اختیار قرار دادن آنان برای مصرف کنند گان سرویس های وب فراهم گردد .کارگزاران سرویس های وب ، اطلاعات عمومی زیر را در ارتباط با یک سرویس وب منتشر خواهند کرد :
• اطلاعات طبقه بندی شده ای که امکان گروه بندی سرویس وب را فراهم نماید .
• اطلاعات مورد نیاز بمنظور ارتباط با سرویس وب
• شرح خدمات ارائه شده توسط سرویس های وب
• لینک های مورد نیاز بمنظور استفاده از سایر مستندات که شامل اطلاعاتی در رابطه با سرویس وب است .
• آدرس ( مکان ) نهائی سرویس های وب . آدرس های فوق ، عموما” بصورت URL)Uniform Resource Locators) بوده و مکان و موقعیت سرویس های وب اعلام شده را مشخص می نمایند . با توجه به عدم توانائی ذخیره سازی تمامی اطلاعات بر روی رسانه های ذخیره سازی کارگزار سرویس وب ، از اشاره گرهائی خاص در این زمینه استفاده که باعث تسهیل در یافتن اطلاعات تکمیلی و مورد نیاز در ارتباط با سرویس وب خواهد بود. ماهیت برخی از اطلاعات مرتبط با یک سرویس وب نیز بگونه ای است که امکان استقرار آنان بر روی کارگزار وجود نداشته و می بایست از لینک های مورد نظر و معرفی شده توسط کارگزار بمنظور اخذ اطلاعات تکمیلی استفاده گردد (اطلاعات مرتبط با ملزومات مورد نیاز برای تائید اعتبار) .
ارتباط بین کارگزار و مصرف کننده سرویس : اولین و در عین حال مهمترین نوع ارتباط بین مصرف کنندگان سرویس وب و کارگزار سرویس وب ، جستجو برای یافتن سرویس وب است . کارگزاران می بایست تسهیلات لازم در خصوص جستجوی سرویس های وب را فراهم تا امکان یافتن آنان بسادگی و با سرعت مناسب برای مصرف کنندگان ، فراهم گردد .
ریجسترهای UDDI : کارگزاران ، بمنظور ارائه سرویس های وب از رویکردهای متعددی استفاده می شود . یکی از ساده ترین رویکردهای موجود در این زمینه ، استفاده از یک روش خاص با توجه به هدف مورد نظر برای مبادله اطلاعات و الزام تمامی همکاران تجاری برای تبعیت از آن است . در این رویکرد ،عملا” به یک کارگزار نیاز نخواهد بود . مثلا” برخی سازمانها از مبادله اطلاعات الکترونیکی ( EDI:Electronic Data Interchange ) استفاده و بسادگی مستندات EDI مورد نیاز همکاران تجاری را بر روی سایت سازمان خود قرار می دهند .در رابطه با رویکرد فوق ، می بایست به این نکته ( مسئله) اشاره نمود که روش فوق ، مکانیزم مناسب و ساده ای برای یافتن فعالیت های تجاری خارجی و سازگار با فعالیت تجاری سازمان مربوطه ، نخواهد بود .
یکی دیگر از رویکردهای موجود در این زمینه ، الزام تمامی همکاران تجاری برای استقرار یک فایل خاص بمنظور تشریح سرویس وب بر روی سایت های خود می باشد . در ادامهجستجو کننده وب می تواند بصورت اتوماتیک به یک URL ریجستر شده، دستیابی و ایندکس مناسبی از هر یک از فایل های تشریح سرویس های وب که بر روی هر یک از سایت ها پیدا می نماید ، ایجاد نماید . یک کارگزار سرویس وب می تواند در ادامه یک Portal را ایجاد که امکان دستیابی به ایندکس هائی که جستجو کننده وب آنها را ایجاد نموده است ، فراهم گردد. اتکاء و وابستگی به جستجو کنندگان وب برای ارائه ایندکس های سرویس های وب دارای مسائل مشابهی با روش استاندارد موتورهای جستجو است که ما امروزه با آن سروکار داریم . مشکل اساسی رویکرد فوق ، عدم وجود مکانیزم لازم بمنظور اطمینان از انسجام و یکنواختی در فرمت تشریح سرویس و ردیابی آسان و آگاهی از زمان مورد نظر دررابطه تغییرات اعمال شده است . همانگونه که ممکن است یک موتور جستجوی وب تعداد زیادی لینک غیر معتبر را برگرداند ، استفاده از روش فوق در ارتباط با سرویس های وب نیز ممکن است نتایج غیر معتبری در ارتباط با تشریح سرویس ها را ارائه نماید.
رویکرد کارگزاری ، که در ارتباط با سرویس های وب انتخاب شده است ، مبتنی بر یک ریجستری توزیع شده از بنگاههای تجاری و تشریح سرویس های مربوطه آنان با فرمت XML است . راه حل ارائه شده بمنظور پیاده سازی رویکرد فوق و برطرف نمودن مسئله یافتن سرویس های وب ، UDDI ) Universal Description,Discovery, and Integration ) نامیده می شود .

UDDI ، مشخصه ای برای اطلاعات مبتنی بر وب توزیع شده از سرویس های وب ریجستر شده است . با استفاده از UDDI ، بنگاه های تجاری قادر به ریجستر نمودن اطلاعات مرتبط با سرویس های خود بوده و بنگاه های تجاری متقاضی ، قادر به یافتن و استفاده از سرویس های وب خواهند بود . عنصر اساسی در یک ریجستری UDDI ، فایلی است که موجودیت یک بنگاه تجاری را بهمراه سرویس های وب مربوطه آن تشریح می نماید . اطلاعات مورد نظر بمنظور ریجستر نمودن یک فعالیت تجاری از سه بخش اساسی تشکیل شده است :
• آدرس بنگاه تجاری و اطلاعات لازم بمنظور ارتباط
• لیست طبقه بندی صنعتی منطبق بر استاندارد های موجود
• اطلاعات فنی در رابطه با سرویس های وب عرضه شده توسط بنگاه تجاری . اطلاعات فوق ، شامل مرجع لازم به مشخصه های اینترفیس سرویس وب ، پتانسیل ها واشاره گرهائی به فایل های متعدد اطلاعاتی است.

web service description language

web service description language

مدل برنامه نویسی سرویس های وب

بمنظور پیاده سازی و یا استفاده از یک سرویس وب ، لازم است با ویژگی های اساسی مدل برنامه نویسی سرویس های وب آشنا شویم .
پروتکل های وب : اولین ویژگی مدل برنامه نویسی سرویس های وب ، پروتکل ارتباطی است که معمولا” HTTP خواهد بود. پروتکل HTTP ، بطور ذاتی مفهوم استفاده از یک متد را حمایت نمی نماید . با توجه به محدودیت فوق ، مصرف کنندگان سرویس های وب اغلب از XML-Based SOAP ، بر روی HTTP برای فراخوانی ( صدا زدن ) متدهای سرویس های وب استفاده می نمایند . بنابراین ، لازم است پیاده کنندگان دارای دانش مناسبی در ارتباط با پروتکل HTTP و SOAP باشند .
StateLess : اکثر پیاده کنندگان با یک مدل شی Stateful آشنائی لازم را دارند. بعبارت دیگر ، نمونه ای از یک کلاس ایجاد و در ادامه عملیات متفاوتی بر روی شی انجام خواهدشد . بین هر فراخوانی متد ، شی وضعیت خود را نگهداری می نماید . در یک محیط stateless ، شی وضعیت خود را بین فراخوانی ها ، نگهداری نمی نماید. هر وضعیتی که می بایست بین فراخوانی ها نگهداری گردد ، در یک بانک اطلاعاتی و یا کوکی ذخیره می گردد . سرویس های وب اشیائی با رویکردهای سنتی نمی باشند. زمانیکه از ASP.NET بمنظور پیاده سازی یک سرویس وب استفاده می گردد ، می توان از یک کلاس سی شارپ بمنظور پیاده سازی آن استفاده نمود. صفحات ASP.NET برای مراجعه به کلاس فوق ، از یک فایل با انشعاب asmx . استفاده می نمایند. زمانیکه صفحه پردازش می گردد ، یک نمونه از کلاس ایجاد می گردد . مدت زمان حیات صفحه asmx . ، به عمر شی نتیجه محدود و یک نمونه شی متفاوت دیگر سایر فراخوانی ها به متد را پاسخ خواهد داد بنابراین ، کلاس هائی که یک سرویس وب را پیاده سازی می نمایند ، Stateless خواهند بود . با اینکه طراحی سیستم های Stateless در مرحله اول مشکل تر بنظر می آید ولی همزمان با افزایش حجم عملیاتی سیستم ، توان آنان در سرویس دهی افزایش خواهد یافت .
Loosely coupled : در یک برنامه غیر توزیع شده ، اگر هر یک از منابع نرم افزاری مورد نیاز، نظیر یک تابع کتابخانه ای در یک DLL)Dynamic Link Library) ، زمانیکه یک برنامه فعال می گردد در دسترس باشند ، امکان دستیابی به منابع فوق در مدت زمان حیات نرم افزار ، میسر خواهد بود . برای برنامه های توزیع شده ، خصوصا” برنامه های توزیع شده ای که از منابع نرم افزاری بر روی اینترنت استفاده می نمایند ، ممکن است منابع نرم افزاری مورد نیاز همواره در دسترس نباشند. برنامه های توزیع شده که با استفاده از سرویس های وب پیاده سازی می گردند ، می بایست دارای انعطاف لازم و بمراتب بیشتری در ارتباط با منابع نرم افزاری غیرقابل دسترس حتی در زمان اجراء باشند . بنابراین ، راه حل های مبتنی بر سرویس های وب ، می بایست دارای پتانسیل لازم بمنظور پیکربندی مجدد و پویای خود باشند (در مواردیکه منبع مورد نیاز دردسترس نمی باشد ) .

فرمت عمومی داده

فرمت عمومی داده در سرویس های وب ، XML است . در این رابطه ذکر نکات زیر ضروری است :
• پروتکل SOAP مبتنی بر XML است .
• داده برگردانده شده از یک سرویس وب ، یک سند XML است .
• سرویس های وب با استفاده از اسناد XML در یک ریجستری UDDI ریجستر می گردند .
• برنامه های ASP.NET با استفاده از فایل های پیکربندی XML پیکربندی می گردند .

ادامه مطلب