مدل client/server
مدل client/server یک مفهوم برای شرح اطلاعات هست بین فر آیند های محاسباتی که طبقه بندی شده هستند چنانکه مصرف کننده های سرویس (کلاینت ها) و توسعه‌دهنده های سرویس (سرورها )
- 2 لایه
- 3 لایه
- چند لایه
معماری کلاینت / سرور 3 لایه :
- لایه نمایش
- لایه business
- لایه بانک اطلاعاتی
یک معماری سه لایه سیستمی است که یک تفکیک کلی را اجرا میکند بین سه قسمت زیر :
1 لایه client یا سطح استفاده کننده .2 لایه میانی یا منطق تجارت
3 لایه data storage tier
به کار برده شده برای استعمال وب و برنامه نویسی مخرب ،سه لایه منطبق معمولاً مشابه است با جدایی فیزیکی بین سه نوع دستگاه یا سه گروه :
1 browser یا استعمال GUI.
2 web server یا Application server .3 سرور بانک اطلاعاتی
اگر چه علاوه بر سرور اجرایی ،یک قسمت دیگر کد برنامه نویسی وجود دارد به طرف سه لایه منطقی .
این نوع قسمت های مشابه ( معماری سیستم فیزیکی )هست در یک سیستم Jsp/servlet قدیمی این اشیا ابزار معمولی هستند .
مثلاً : jsp ها یا سرولت ها مسئول هستند برای خلق کردن html یا wml یا مسئول javabeans برای سرولتهای منطقی تجاری javabeans یا مسئول جاوا برای افزایش دیتا .این اشیا را معمولاً JDBC استفاده میکند برای سوال بانک اطلاعاتی .
در یک سیستم ejb سه لایه منطقی معمولاً ابزار تا حدی متقاوت هستند .
jsp ها سرولت ها یا درخواست کلاینت جاوا مسئول هستند برای اینتر فیس کاربر .
جلسه دانه ها یا دانه‌های وجودی که متدهای چه کسی تکمیل می کند منطق تجاری و قوانین تجاری دانه های هستی حوزه چه کسی اطلاعات را نشان می دهد .
این میدان ها (Persisted) هستند (ذخیره و پس گرفتن ) هر یک از آن دو به وسیله ejb سرور (برای پافشاری container-managed ) یا به وسیله دانه های وجودی خودشان ( برای پافشاری bean-managed) به طوریکه شما میتوانید ببینید تعریف دقیق tier ها می تواند تغییر کند به طور گسترده که وابسته است به نیازهای خاص و انتخابهای طراح کاربردی.
هر چند همه آنها تقسیمات کلی ذخیره را ادامه می دهند .اگر معماری شامل بیش از سه لایه منطقی شود برای مثال تغذیه اطلاعاتی گوناگون ،منابع اطلاعاتی معامله ای گوناگون،در خواستهای موکلی گوناگون سپس آن معمولاً نامیده میشود n-tierیا معماری distributed .
(Threetier) یک کمپانی توسعه مشاوره نرم افزاری است .
توسعه کاربردهای وب بیشتر بنابراین درخواست دسک تاپ قدیمی پیشنهاد میگردد .
سود های خیلی زیاد برای هر دو توسعه دهنده های نرم افزار و درخواستهای مشابه کابرهارا.
برای توسعه دهنده نرم افزار ارزش آشکاری دارد پس اندازی ندارد تا توزیع کند تقاضاها را روی یک واسطه فیزیکی .
به علاوه همه به روز شده ها چه در نگهداری یا همه ورژن های جدید فوراً در دسترس به کل هدف مشتری حاضر در زمان کاهش .
یک اندوخته نیروی نفرات زیادی هست قطع نظر از در خواستی که اثر گذار هست روی یک اینترانت یا اینترنت عمومی .
برای کاربرد متقاضی سادگی دسترسی تقاضا نیرو بخش است نیازی نیست تا مجموعه اینتستال ها انجام شود وبه علاوه وقتی تکنولوژی جدید وب مثل DHTML و مشخصات مایکروسافت برای کنترل ها یactivex هستند با یک در خواست کاربر از عهده زیادی اینترفیس برمیاید و عملکردی که کاربرهای desktop کامپیوتر دارند میپذیرد.
کاربرد محدود براوسرهای وب برای مشکل های اجرایی مربوط به اصلاح صفحه ها ساکن از سرور های راه دور .
به علاوه عملیات جدید نوعی جابجایی دکمه submit است قرار میگیرد روی بیشترسایتهای وب جاری دارای تاثیر روی یکدیگر .
تکنولوژیهای جدید پیشرفته وب قادرند هسته عملیات یک وب در خواستی برای ساختن در حد کامپیوتر موکل که شامل براوسر می شود .
وقتی رکورد جدیدی اطلاعات اساسی مورد نیاز است و نشان داده می شود نیاز نیست تا اصلاح شود صفحه HTML از سرور .تنها اطلاعات مشتری دوباره اصلاح و دوباره نقاشی می شود نه تمام صفحه .
این تکنیکها درخواستهای وب را می دهد همان اجرا و ظاهر تکان نمی خورد همنطور که کلاینت سرور قدیمیتر نزدیک می شود .
وقتی رکورد جدیدی اطلاعات اساسی مورد نیاز است و نشان داده می شود نیاز نیست تا اصلاح شود صفحه html از سرور .تنها اطلاعات مشتری دوباره اصلاح و دوباره نقاشی می شود نه تمام صفحه .
این تکنیکها درخواستهای وب را می دهد همان اجرا و ظاهر تکان نمی خورد همنطور که کلاینت سرور قدیمیتر نزدیک می شود .
در خواستهای وب میاید از راه دور از روزهای تک صفحه های html ساکن .
سرورهای وب اجرا می کنند سرویسهایی به عنوان ترکیبهای سرد یا asp های مایکروسافت هستند در حال توسعه توانایی دینامیکی ساخته شده صفحه های وب این صفحه های دینامیکی ساخته شدند با استفاده از سمت و سوی برنامه نویسی منطقی و اینترفیسینگ بانک اطلاعاتی .
نتیجه صفحه هایی هست که میتواند ترتیب بدهد روی نصب کردن تا منعکس کند زمان تجارت واقعی اطلاعاتی که توسط کاربر متقاضی بر درخواست میشود.
قبل از دسترسی سرورهای وب که توانستند صفحه های HTML را به صورت دینامیکی بسازند، تکنولوژی Defacto برای وب سایتهای دارای تأثیر روی هم.
اینترفیس دروازه معمولی (CGI) بود.
تعدادی محدودیت های تکنولوژی CGI به جای جدید منتقل شده و بیشتر سودمند برای زمان اجرا و محیط های پیشرفته.
درخواستهای وب ASP که فراهم میکند اطلاعات بانک اطلاعاتی بوسیله درخواستهای طبیعی 3-tier هستند.
اولین لایه معرف لایه ای هست که اجرا میکند در حد یک براسر وب .
این لایه معمولاً یک ترکیبی از HTML و اصل کلاینت ساید مثل جاوا اسکریپت است.
دومین لایه اجرا میشود روی سرور وب زیر سرور اطلاعاتی اینترنت مایکروسافت (IIS).
پیش فرآیندهای IIS صفحه های ASP (صفحه های HTML که یک امتداد فایل 'ASP' دارند.) در طول پیش مرحله صفحه های ASP، همه نوشته تهیه کردن سرور ساید (همچنین J script , VBScript) اجرا کردنی است.
نوشته با صفحه های ASP شامل میشود منطق تجارت را که درخواستهای وب را هدایت میکند.
برای درخواستهای بانک اطلاعاتی رانده شده، آن در حد نوشته تهیه کردن ASP هست که دسترسی های بانک اطلاعاتی رخ میدهد.
بانک اطلاعاتی که اغلب روی یک کامپیوتر جدا از IIS هست، شکلهای لایه سوم معماری 3-tier قرار گرفتن همه منطق تجارت به طرف صفحه های ASP بطوریکه نسخه برنامه نویسی ارائه میدهد یک تعداد مشکلات رو.
خوشبختانه این مشکلات آسان رفع میشوند با استفاده از اجزاء برنامه نویسی.
از آن جائیکه این عصر اطلاعات فرض شده و از آن جائیکه تمام اطلاعات لازم است نگهداری شود لایه اطلاعاتی که در بالا توصیف شد معمولاً یک قسمت اساسی است توسعه یک سیستم بدون یک لایه اطلاعاتی امکان دارد اما من فکر میکنم برای استفاده‌های بیشتر لایه اطلاعاتی باید وجود داشته باشد پس این لایه چه هست ؟
اساساً آن هست سیستم مدیریتی بانک اطلاعاتی (dbms) شما sql server ، access ، oracle ،mysql ، فایل های متن ساده هر چه شما دوست دارید.
این لایه به عنوان مجموعه و جامع میتواند باشد همان طور که محصولات باکیفیت بالا مثل sqlserver و oracle که شامل چیزهایی مثل query optimization وindexing و غیره همه راههای پایین ساده نگری فایل های متن ساده (موتوری که بتواند بخواند و جست و جو کند این فایلها را ) بعضی فرمتهای بیشتر معروف ساخته شده ،فایل های متن ساده شامل csv .
xml و غیره توجه کنید چطوری این لایه تنها نامزد از پس ذخیره سازی و اصلاح اطلاعات برآمده است .دلواپسی درباره چگونگی برنامه ای که روی عمل یا تحویل این اطلاعات ندارد این همچنین باید شامل روش های ذخیره سازی شما باشد قرار ندهید منطق تجارت را اینجا مهم نیست چطوری امتحان کنید .
-تقدیم لایه منطقی شما شاید با این لایه آشنا هستید آن عبارت است از اسناد استاندارد ما فرم های ویندوز و غیره ...........
این لایه ای است که تهیه میکند یک اینترفیس را برای کاربر آخر در تقاضای شما .آن هست آن کارهایی با بازده لایه تجاری برای تغییر شکل دست درون چیزهای قابل استفاده و قابل خواندن به وسیله کاربر آخری آن باعث توجه من است که توسعه کاربردهای بیشتری برای وب با این لایه سخن گو مستقیم به دسترسی لایه اطلاعات ونه حتی اجرای لایه تجاری .
بعضی وقتها لایه تجاری جدا نگهداری نمی شود از دو لایه دیگر بعضی کاربرها سازگار نیستند با جدا سازی این لایه ها وآن مهم است که آنها جدا نگهداری شوند .
بیشتر توسعه دهنده ها به سادگی ازمیان بعضی sql در asp آنها انتقال به بانک اطلاعاتی گرفتن رکورد است و حلقه در asp آنها تا بازده نتیجه دهد این معمولاً یک ایده خیلی بد است .
لایه جانشین و منطق توزیع: آن همچنین کوچک است، لایه جانشین مبهم.
"proxy" در تعریف است یک شخص (شئ) مجاز انجام دادن عمل برای دیگری.
این شئ در زمینه ما رجوع ره هر نوع کدی است که اجرای اعمالی برای چیز دیگری هست (client).
قسمت کلیدی تعریف هست "act for another" .
لایه جانشین "acting" بخاطر لایه منطقی توزیع شده (یا درخواستهای آخرین کاربر) هست تا تهیه کند دسترسیبه لایه بعدی، لایه تجارت.
چرا هر کسی به این نیاز خواهد داشت، این آسان میکند نیاز ما را برای محاسبه توزیع.
اساساً آن پایین می آید تا شما انتخاب کنید بعضی متدهای استاندارد ارتباطی بین این دو ماهیت را.
آن هست «چطوری می شود مشتری صحبت کند با سرور از راه دور؟
این هست جایی که ما پیدا میکنیم نیاز برای دسترسی پروتکل شو واحد (SOAP) SOAP یک متد خیلی واحد برای انجام آن تدارک میبیند راهی که 2 ماشین دارند "صحبت کردن" یا "ارتباط با دیگری" (CORBA، RMI، SOAP و ...
همه اساساً سودمندند به اندازه عملیات .) The client interface: باید توجه داشته باشیم که کاربر آخر ارائه میکند (فرمهای ویندوز ، ...) که مستقیم متصل میشود به لایه تجارت.
یک مثال خوب این خواهد بود که کاربر شما در سراسر شبکه منطقی (LAN) خواهد بود.
همچنین توجه کنید که آن ادامه دارد بالا و روی لایه منطقی توزیع شده.
این نامزد هست تا ثابت کند چطوری میتواند SOPA رو استفاده کند (یا بعضی انواع دیگر توزیع شده- محاسبه پروتکل پیامی) روی کلاینت منتقل کند با سرور و آن درخواستها را داشته باشد.
درخواستها تغییر شکل پیدا کند درون بعضی چیزهای قابل خواندن و قابل استفاده برای آخرین کاربر.
The Business tire این اساساً جایی هست که مغز کاربردی شما ساکن میشود.
آن شامل چیزهایی شبیه قوانین تجاری، ساختن اطلاعات و ...
می شود.
برای مثال، اگر شما در حال ایجاد یک موتور جستجو هستید و شمات میخواهید تا اندازه / سنجیدن هر آیتم جور شدنی بر پایه بعضی معیار عادت قرار دهید این منطق رو در این لایه.
این لایه هیچ چیزی درباره HTML نمی داند، همینطور خروجی آن.
نگرانی ندارد درباره ADO یا SQL و آن هیچ کدی برای دسترسی دیتابیس یا شبیه آن نباید داشته باشد.
آن ابزار ها تعیین کننده هر لایه مشابهی هستند بالا یا زیر آن ما باید یک فهم خیلی اساسی برنامه نویسی شی گرا (oop ) را در این زمان کسب کنیم .
برای روشن کردن به مثال دیگری نگاه کنید مثلاً یک کاربرد خرید cart تفکر در شرایط اشیا اصلی .
ما خلق کردیم یک شی را تا نمایش دهیم هر محصولی را برا ی فروش این شی تولیدی settersg getters خاصیت استاندارد دارد :getsize , setcolor , setsize, getcolor و غیره است آن یک واحد قو ابزاری هر محصول عمومی است از داخل آن تنها میداند چگونه برگرداند اطلاعات (getters)و بفهمد چطوری آن میتواند قانونی اطلاعاتی که شما میریزید به طرف آن (تنها برا استفاده محدود آن ) آن خود جاگیر است ( encapsulation) کلیدی اینجا هست تا encapsulate کند همه وابسته های منطقی را تا محصولات عمومی در حد این شی اگر شما سوال کنید آن را برای getprice آن بر خواهد گشت قیمت آیتم واحد آن تقدیم کند همچنین اگرشما آگاهی بدهید آن را به validate یا save آن brain هایی داردتا بتواند بکار بر داینرا بر گردونه هر اشتباهاتی و غیره .........
ما میتوانیم ببندیم این شی تولیدی در شی دیگر یک شی در cart این cart میتواند جا بگیرد و بکار برد تعدادی اشیا تولیدی آن همچنین گیرنده ها و گذارنده هایی دارد اما به طور آشکار روی یک نسبت یکجای دیگر حالا شما getprice را برای شی کارت صدا کنید آن معلوم است که آن باید معین کند هر محصولی که آن دارد جمع کردن قیمت برای هر و برگرداندن آن مجموع واحد وقتی ما می سوزونیم روش savecart آن حلقه خواهد زد برای هر محصول و صدا خواهد زد متد savecart آن را که این هم به اشیا لایه دسترسی اطلاعات ضربه خواهد زد و روشهای پافشاری خودش روی لایه اطلاعات .
Data access tier لایه دسترسی اطلاعات این لایه جایی است که شما بعضی متدهای عمومی را خواهید نوشت با اطلاعاتتان برای اینترفیس.
برای مثال ما یک متد برای خلق و باز کردن یک شئ ارتباطی (درونی) خواهیم نوشت و دیگر برای ایجاد و استفاده یک شئ فرمانی، همراه یک روش ذخیره شده (با یا بدون مقدار بازگشتی) و غیره.
آن همچنین بعضی متدهای ویژه خواهد داشت، مثل "save product" بطوریکه وقتی شئ تولیدی صدا زده میشود آن با اطلاعات مناسب، آن میتواند پافشاری کند برای لایه اطلاعات.
این لایه اطلاعاتی، به طور واضع در بر نمی گیرد قوانین اطلاعات تجاری یا اطلاعات دستی تغییر شکل منطقی.
آن فقط یک اینترفیس قابل استفاده است برای بانک اطلاعاتی.
conclusions ما باید معمولاً دو لایه تجارت و دسترسی اطلاعات را با هم ترکیب کنیم.
جایز شمردن لایه تجارت برای مذاکره مستقیم با لایه اطلاعات و نگران نشدن با لایه دسترسی اطلاعات برای تصدیق این حرف آخرین باری که من در اینترنت بودم سرعت سه تا چهار برابر بیشتر از حد معمول بود که این هم یعنی ما منتظریم تا کار و تولید در همان اندازه را ADO میتواند سنجیده شود همانطور که این لایه دسترسی اطلاعات آن ما را توسعه میدهد به طور مستقیم با اینترفیس.
الگوهای معماری کلاینت سرور سه لایه: معرفی: هنگام طراحی کردن درخواستهای توزیع شده برای تعهد سیستمهای اطلاعاتی شما مجبورید تصمیم بگیرید چطوری توزیع کنید همل درخواستی رو یا مسئولیت بین زمینه های فرآیند توزیه شده در دستور خوش بین بودن استفاده اجزاء و چاره خواستن.
این پخش عملیاتی حمله میکند با آن تعداد زیادی از شاخه ها.
آنها تأثیر خواهند داشت روی مسیر مدیریت پروژه شما طوری که درخواستهای شما در حال ساخت و بنا کردن هستند.
همچنین تکمیل این ایده واحد میتواند اثبات کند ادعا کردن زیاد را.
الگوهای ما تقسیم میشوند به سه قسمت که منعکس کننده این مناطق کاری هستند: الگوهای معماری معماری توزیع three-tier مطرح میکند تقسیم عملکرد درخواست رو به سه لایه ها: کلاینت های front- end حوزه یا سرورهای درخواستی و یک ذخیره و یک DB-server آدرس های معماری 4 لایه چگونه اشیاء در سیستم شما به عنوان یک دست نخورده میتواند سازماندهی شود تا بهتر جدا شود و شما را آماده کند برای توزیع و استفاده دوباره.
الگوهای سازمان دهی لایه های phase- in نشان می دهد چطور سیستمها استفاده میکنند از یک معماری 4 لایه میتواند ساخته شود از ابتدا برای یک معماری دولایه و سپس انتقال داده شود به یک معماری اضافه کار سه لایه.
trim client شرح میده چگونه اشیاء در یک معماری 4 لایه میتواند بهتر توزیع شود به طرف لایه های یک معماری دو یا سه لایه.
الگوهای استقرار سرورهای یا کاربرد تخصصی فرآیند تقسیم لایه میانی به چندین سرور کاربردی را هدایت میکنند.
تعامل اینترفیس بانکهای اطلاعاتی مجازی این کاربرد را بین سطح بانکهای اطلاعاتی مختلف قابل تعمیم میکند.
پروکسی ORB با بانکهای اطلاعاتی شئ گرا با یکپارچه سازی دیتاهای اغلب ناسازگار Object brokers و بانکهای اطلاعاتی شئ گرا سرو کار دارند.
قفل های اتوماتیک شئ توسعه دهنده ها از کارهای مزاحم و پر خطای قفل کردن و باز کردن دستی بانکهای اطلاعاتی شئ گرا رها میکند.
ارتباطات تقسیم شده بانکهای اطلاعاتی در مواردی بکار میرود که لازم است تا کاربرها همزمانی بیشتری داشته باشند.
داشتن کاربرهای بیشتر همزمان نسبت به تعداد اتصالات دیتابیسی که سرورها خواهند پذیرفت.
موافقت بر پایه مدیریت Thread نشان میدهد چگونه کنترل میتواند تکمیل شود در سرورهای درخواستی وقتی که بانک اطلاعاتی قفل میکند نمی تواند استفاده کند برای همزمانی کلاینت ها.
درباره زبان الگوهایمان این زبان الگو یک همکاری غیر معمولی و اتفاقی است بین سه گروهی که کشف کردند در کنفرانس "plop 96" که آنها کار میکردند روی مکمل واغلب الگوها را روی هم میگذاشتند.
یک راه دسترسی حقیقی بانک اطلاعاتی سه لایه یعنی شما که درخواستی رو اجرا میکنید در هر دو client و سرور.
کد درخواستی client و سرور مبادله میشود کد درخواستی اجرا می شود روی سروری که دسترسی دارد با بانک اطلاعاتی SQl به هر حال آن اجرا میشود روی یک سرور و اجازه میدهد client ها در برابر صحبت کردن زبان JDBC، SQL و انتقال درخواستها به طرف زبان هایی SQL اصلی و دست نزدن به آنها به طرف SQL سرور.
کد ویژه روی سرور اجرایی نیست.
هدفهای N-tier هدفهای کاربرد یک N-tier خوب - اگر شما تغییر دهید راه های اساسی دسترسی به اطلاعات راه، کد Client- side نباید تغییر کند.
- همه جریان دسترسی اطلاعات باید پدیدار شود طوریکه اشیاء بجای عملیات صدا زده شود.
به عنوان مثال بکار بردن ADO آسانتر شود نسبت به صدا زدن ODBC API.
- SQL باید حذف شود از کد client- side حذف شود.
Data sets میتوانند نام جدول و ستون های وجه اولی را به عنوان ویژگی ارائه کنند و با این کار لیستهای هوشمندی تهیه کنند که مانع لزوم تایپ کردن نام یک رشته شود.
این یعنی در زمان تألیف شکاف میتواند ساخته شود برای انواع اطلاعات و نام ستون‌ها.
کد ملاینت نباید نگهداری شود جایی که اطلاعات از آنجا می آید آن باید فقط نگهداری شود که آن میتواند بهبود و اصلاح شود اطلاعاتی در بعضی اشیاء و شئ مراقبت خواهد کرد از جزئیات .
- کدی که شما نیاز دارید تا انجام دهید روی client side باید ساده شود.
بجای استفاده از چندین عمل، درخواست شما باید بتواند بکار برد اشیاء را با خواص روشهایشان.
- آن آسانتر میشود تا ایجاد و استفاده کند از کلاس ها نسبت به کلاسهای عملیات - آن آسانتر است تا اضافه کنی عملی رو به درخواستهایتان و تغییر دهید عملیات بدون شکستن کد client side.