آیا وب سرویس دراین زمینه مفیده؟

[sama552]

با سلام
در برنامه ای که در یک زمان تعداد زیادی کاربر با آن کار می کنند و ودر دیتا بیس آن مدام insert وdeleteمیشود آیا این کار درسته که دستورات sqlرا در webserviceبنویسیم آیا اینکار به بالا بردن کارایی برنامه کمک میکند؟چون من خیلی جاها دیدم که دستورات sql را در وب سرویس می نویسند؟دلیل اینکارشون چیه؟
لطفا اگه کسی می دونه کمک کنه برام مهمه

[mehdi.mousavi]

با سلام در برنامه ای که در یک زمان تعداد زیادی کاربر با آن کار می کنند و ودر دیتا بیس آن مدام insert وdeleteمیشود آیا این کار درسته که دستورات sqlرا در webserviceبنویسیم آیا اینکار به بالا بردن کارایی برنامه کمک میکند؟چون من خیلی جاها دیدم که دستورات sql را در وب سرویس می نویسند؟دلیل اینکارشون چیه؟ لطفا اگه کسی می دونه کمک کنه برام مهمه


سلام.
خود Web Service رو باید به لایه های منطقی دیگه ای شکست که DAL میتونه یکی از این بخشها باشه. به بیان دیگه، Web Service میتونه با استفاده از DAL و Business Logic Object ها سرویس مورد نظر رو به Client ارائه کنه.

اما این مساله ربطی به کارایی و سرعت بالا/پایین کار با بانک پیدا نمیکنه. دقیقا بفرمایید کاری که میخواهید انجام بدید چی هستش، تا روش خوبی رو بهتون پیشنهاد بدم.

موفق باشید.

[sama552]

سلام.
خود Web Service رو باید به لایه های منطقی دیگه ای شکست که DAL میتونه یکی از این بخشها باشه. به بیان دیگه، Web Service میتونه با استفاده از DAL و Business Logic Object ها سرویس مورد نظر رو به Client ارائه کنه.

اما این مساله ربطی به کارایی و سرعت بالا/پایین کار با بانک پیدا نمیکنه. دقیقا بفرمایید کاری که میخواهید انجام بدید چی هستش، تا روش خوبی رو بهتون پیشنهاد بدم.

موفق باشید.
مرسی از را هنماییتون
یعنی شما نظرتون اینه که زمانی که تعداد زیادی کاربر در زمان واحد با سرور کار می کنند استفاده از وب سرویس مفیده
در ضمن میشه در مورده شکستن وب سرویس به لایه های منطقی وDAl بیشتر توضیح بدید؟

[mehdi.mousavi]

سلام.


یعنی شما نظرتون اینه که زمانی که تعداد زیادی کاربر در زمان واحد با سرور کار می کنند استفاده از وب سرویس مفیده

بستگی داره. اگر از وب سرویس استفاده نکنید، چطوری می خواهید این سرویس رو به Client ها بدید؟ وب سرویس ها بصرف سریعتر انجام دادن کاری پدید نیومدن. Insert کردن 30 تا رکورد در بانک از طریق وب سرویس، همونقدر زمان میبره که Insert کردن همون 30 رکورد از طریق Client. بستگی داره کی کرنومترمون رو برای سنجش این زمان روشن کنیم.

وقتی یه Stored Procedure رو اجرا می کنید، دیگه اهمیتی نداره که Client اونو اجرا کرده، یا وب سرویس اما مهم هستش که اطلاعات مورد نیاز SP از طریق کدوم Boundary ارسال شده.

حالت ایده آل این هستش که وب سرویس و RDBMS شما هر دو در یک ماشین باشن تا وب سرویس برای ارتباط با بانک، نیازی نداشته باشه تا از مرز ماشین خارج بشه. خروج از این مرز، میتونه (بسته به شرایط) سرعت رو تا 1000 برابر پایین بیاره (این بخشی از مباحث DCOM هستش و ربطی به این بحث نداره. David S.Plat تو یکی از کتابهاش به این مساله اشاره کرده و در مورد این تفاوت فاحش سرعت، توضیح میده).

اما وقتی از این مرز خارج شدید، دیگه اهمیتی نداره که Stored Procedure مورد نظر رو Client خودش مستقیما فراخوانی کرده، یا این وظیفه رو به Web Service ای که در نقطه دیگه ای از شبکه وجود داره سپرده و Web Service نیز به نوبه خودش باید با RDBMS ارتباط برقرار کنه و اون کارو انجام بده. تازه اینجا سرعت پایینتر هم میاد، چون جای اینکه دستور از طریق Client مستقیما به RDBMS برسه، ابتدا به وب سرویس ارسال و سپس از طریق اون به RDBMS ارسال میشه.

اما این کل داستان نیست. ما آدمها، برای اینکه بتونیم اجزای مختلف یک سیستم بزرگ رو تحت کنترل خودمون بگیریم، اونو به بخشهای کوچکتر و "مدیریت پذیر" تقسیم میکنیم و در هر مرحله توانمون رو روی بهبود یکی از این بخشها متمرکز میکنیم. فرض کنید دستورات مستقیما به RDBMS ارسال بشن. منظورم دستورات CRUD هستش... تو این حالت چه اتفاقی میفته؟ هر Client ای جداگانه باید Authenticate بشه تا ببینیم اجازه اجرای فلان دستور رو داره یا خیر. فرض کنید به هر دلیلی شما مجبور باشید Connection String رو در Client ها تغییر بدید. ترجیح میدید از UDDI استفاده کنید و این کار رو بطور خودکار در Client ها انجام بدید، یا خیر، به فایل app.config هر یک از Client ها سرک بکشید و دونه به دونه فایل مزبور رو برای مثلا 50 تا Station بصورت دستی تغییر بدید؟

فردا روزی اگر کارفرما از شما خواست تا فرضا نحوه انتخاب یک Client فعال رو بر اساس فلان الگوریتم انتخاب کنید، بطور مثال، "ما نیاز به این قابلیت داریم که هر 20 تا مکالمه ای که اپراتور پاسخ داد، 3 دقیقه بهش تنفس بدیم و توی این 3 دقیقه بر اساس فلان منطق اپراتور دیگه ای رو انتخاب کنیم". اینجا چیکار می خواهید کنید؟ در حقیقت Workflow شما تغییر کرده و شما باید بتونید براحتی و بدون صرف زمان (و تلاش) زیاد، این تغییر رو در سیستم بوجود بیارید. آیا فکر ارائه چنین سرویسی رو از قبل کرده اید؟ کدوم واحد باید این منطق رو Encapsulate کنه؟ (منظورم توی Solution شماست). هر Client مستقلا داره با RDBMS ارتباط برقرار میکنه و (فرضا) اطلاعات مکالمات انجام شده توسط هر اپراتور رو بصورت جداگانه در بانک ذخیره میکنه. این وسط Controller ای وجود نداره...

اما اگر از Web Service یا یه لایه دیگه این وسط استفاده کنیم، اونوقت میتونیم به خیلی از این نگرانیها پایان بدیم. اولا بدین ترتیب هر Client میتونه توسط UDDI وب سرویس مورد نظر رو پیدا کنه و بصورت Dynamic باهاش کار کنه. بدین ترتیب میشه به چنین Client ای، یه Client هوشمند گفت.

گذشته از این، Connection String فقط در Web Service تعریف شده و در یک نقطه هم این تعریف باقی خواهد موند. فردا اگر بهر دلیلی قصد توسعه سیستم رو هم داشته باشید، میتونید با اعمال تغییراتی در وب سرویس، کل فرآیند کارکرد Client ها رو تغییر بدید. از طرف دیگه، عمل Authentication و Authorization هم بسیار ساده تر میشه، چون این اطلاعات رو میتونید بصورت inbound با هر درخواست ارسال کنید و نیازی نیست تا پارامترهای جداگانه ای برای ارسال UID/PWD به وب متودهای خودتون اضافه کنید.

این سیستم Extensible هستش، یعنی فردا بهر دلیلی قرار باشه توسعه پیدا کنه، با چند تا Config مختصر قابل توسعه هستش. این سیستم Interoperable هستش، به این معنا که هر کسی، تحت هر سیستمی، با هر زبان برنامه نویسی ای میتونه با وب سرویس شما ارتباط برقرار کنه و از سرویس مورد نظر استفاده کنه. این سیستم میتونه همواره Available باشه، چرا که اگر وب سرویس یک از کار افتاد، Client ها بطور خودکار به وب سرویس دو رجوع کنن و ...

خلاصه کنم، اینجا، شما می تونید Business Logic خودتون رو هم Encapsulate کنید. به بیان دیگه، منطق و فرآیند کاری که در نظر دارید رو میتونید در این نقطه قرار بدید... (که البته، تا من کل داستان رو ندونم، نمیتونم با اطمینان در مورد سیستم شما، نظری بدم).


در ضمن میشه در مورده شکستن وب سرویس به لایه های منطقی وDAl بیشتر توضیح بدید؟

متاسفانه خیلی از افراد فکر میکنن که وقتی از منوی File گزینه New رو انتخاب کنن و سپس ASP.NET Web Service Application رو بزنن، میتونن right away شروع به نوشتن کد کنن و ... این اصلا صحیح نیست.

همونطوریکه شما برای Client خودتون باید وقت بذارید و یه طرح خوب و جامع رو پیاده کنید، باید برای وب سرویس هم وقت بذارید و اونو به بخشهای کوچکتر تقسیم کنید. یکی از این بخشها، بخش کارکردن (ذخیره و بازیابی) با بانک هستش. کل منطق اینکار باید در یک DLL جداگانه ای تحت عنوان DAL یا Data Access Logic قرار بگیره. Business Object ها نیز باید جداگانه در معرض دسترس Web Service قرار بگیرن و ...

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

موفق باشید.

[Rejnev]

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

1-آیا بهتره این نوع برنامه ها به صورت سرویس بیس طراحی بشن؟

2-اگه سرویس بیس پیاده سازی بشه، آیا کش کردن دیتابیس روی رم سرور تاثیری روی سرعت سرویس دهی میذاره یا این که مثل حالت عادی هر لحظه که لازم شد به بانک رجوع بشه؟
منظورم اینه که، حالا که یک سرور به همه خدمات میده و دست بقیه از پایگاه داده کوتاهه چطوره که اطلاعات رو روی رم پردازش و ارسال و دریافت کنیم و هر موقع دوست داشتیم توی بانک ذخیره کنیم؟

3-آیا سیستمی مثل sql server برای هر بازیابی اطلاعات به دیسک مراجعه میکنه یا از کشینگ استفاده میکنه.
در صورت کشینگ، جواب سوال یک هنوز هم پا برجاست؟
روش دیگری که بشه برنامه های تحت شبکه پیاده سازی کرد چیست؟

پ ن: اگه سوالات گنگ بود ازشون رد بشین:خجالت: