1 / 29

طراحي و ساخت سيستم‌هاي تجارت الکترونيک

طراحي و ساخت سيستم‌هاي تجارت الکترونيک. ساخت سيستم‌هاي تجارت الکترونيک ECSE. معرفي سرويس هاي تحت وب. لايه هاي سيستم هاي سازماني. Client هر کاربر يا برنامه اي است که مي خواهد عملي را از سيستم درخواست کند. Application Logic عملکرد واقعي سيستم را مشخص مي کند.

Download Presentation

طراحي و ساخت سيستم‌هاي تجارت الکترونيک

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. طراحي و ساخت سيستم‌هاي تجارت الکترونيک ساخت سيستم‌هاي تجارت الکترونيک ECSE

  2. معرفي سرويس هاي تحت وب

  3. لايه هاي سيستم هاي سازماني • Client هر کاربر يا برنامه اي است کهمي خواهد عملي را از سيستم درخواست کند. • Application Logic عملکرد واقعي سيستم را مشخص مي کند. • Resource Manager داده هاي لازم براي حمايت از اجراي برنامه ها را تامين مي کند. Client Presentation layer Application Logic Business rules Resource Manager Business objects Client Client Server Business processes Database Persistent storage

  4. تعامل بين لايه ها • تقسيم کردن برنامه ها به ماژول هاي مختلف امکان توزيع شدگي سيستم را فراهم مي آورد. • ماجولاريتي بيشتر سبب پيچيدگي بيشتر برنامه ها و سختي کنترل آن مي شود. • ماجولاريتي بالا سبب پايين آمدن Performance سيستم مي شود. • بايد دنبال راهي براي ايجاد تعادل بين ماجولاريتي و performance سيستم بود. هيچ مسئله اي در طراحي سيستم ها نيست که با اضافه کردن يک سطح ارتباط غير مستقيم حل نشود. هيچ مسئله اي از لحاظ performance نيست که با کاهش يک سطح ارتباط غير مستقيم حل نشود.

  5. top-down design PL-A PL-B PL-C AL-B AL-D AL-C AL-A RM-1 RM-2 طراحي Top Down • در اين نوع نگرش معماري سخت افزارها غالبا همنوع و مشابه بوده و سيستم از آغاز با توجه به توزيع شدگي طراحي شده است.

  6. New application Legacy application Legacy systems طراحي Bottom UP • اجزاي اصلي سيستم از قبل آماده هستند و نياز به يکپارچگي دارند. • برنامه هاي قديمي همزمان بايد اجرا شوند. • غالب کار در اين معماري فراهم آوردن Middleware براي فراهم آوردن Interface مشترک بين برنامه ها و ارتباط دادن آنها با هم و از بين بردن Heterogeneity است.

  7. مراحل طراحي سيستم Bottom up bottom-up design 1. مشخص کردن کانال هاي ارتباطي و سيستم کاربر client 2. مشاهده سيستم هاي فعلي و ثبت کارايي اين سيستم ها presentation layer application logic layer 3. پوشش دادن سيستم ها و منابع قديمي و يکپارچه کردن آنها در قالب يک سيستم واحد information system resource management layer 4. تبديل خروجي به فرمت مناسب براي سيستم کاربر

  8. 1-tier architecture Server سيستم هاي One tier: کاملا متمرکز • اين سيستم ها از آغاز بصورت يکپارچه يا Monolithic نوشته شده اند. • ارتباط کاربران از طريق ترمينال هاي نمايش صورت مي گيرد. • طراحي غالب Mainframe ها • مزايا • عدم نياز به context switch • کنترل راحت تر منابع • تا حد امکان بهينه

  9. 2-tier architecture Server سيستم هاي Two Tier: Client/server • با قدرتمند PC ها لايه Presentation به سمت کاربر منتقل شد. • در اين حالت: • کاربران مستقل از هم کار مي کنند . • ذخيره منابع Server • معرفي مفهوم API • مدير منابع فقط با لايه Application logic ارتباط دارند که سبب افزايش performance سيستم مي شود.

  10. جنبه هاي مختلف معماري Client/Server • معايب: • سرور مجبور به تعامل با حداکثر Client ممکن مي باشد. • کاربران مجبور هستند از Interface هاي مشخص جهت کار با هر سرور استفاده کنند. • در هنگام خرابي هيچ کس نمي تواند از سيستم استفاده کند. • Load کاربران بر روي هم تاثير مي گذارد. • مزايا: • بهره مندي از قابليت هاي سيستم کاربر • کارهاي سرور در يک محل اتفاق مي افتد. • طراحي سرور با حذف لايه نمايش از مراحل طراحي, ساده تر مي شود. • کنترلاين سيستم ها, همانند سيستم هاي One tier راحت مي باشد.

  11. محدوديت هاي اصلي معماري Client/Server • اگر کاربر بخواهد همزمان با دو سرور کار بکند, آنها هيچ اطلاع و ارتباطي با هم ندارند. • کاربر نقطه اتصال بين دو سرور است. • مسئوليت برخورد با تفاوت هاي دو سرور بر عهده کاربر است. • هيچ منطق تجاري براي اين کار وجود ندارد. • کاربر مسئول حفظ Consistency مي باشد. • اين راهبرد با توجه به منابع محدود کاربر ناکارآمد مي باشد. Server A Server B

  12. Three tire و Middleware ها 3-tier architecture • هر سه لايه کاملا از هم جدا هستند. • بهره مندي از خاصيت ماجولاريتي و توزيع شدگي کامل • معماري 3tier فقط در قبال حل محدوديت هاي معماري 2tier معنا پيدا مي کند.

  13. Middleware clients • Middleware تنها يک سطح ارتباط غير مستقيم بين کاربر و سرور است. • Middleware جهت پياده سازي منطق تجاري بوجود آمده است. • مزاياي Middleware : • راحت تر کردن طراحي • کاهش تعداد Interface ها • فراهم آوردن راهي براي ارتباط غير شفاف با منابع زيرين • مسئوليت فراهم کردن منابع , دسترسي به آنها و جمع آوري اطلاعات آنها Middleware or global application logic Local application logic Local resource managers middleware Server A Server B

  14. جنبه هاي فني Middleware External clients • مزايا • کاهش تعداد ارتباطات : کاربران و سرورها تنها با Middlewareدر ارتباط هستند. • قابليت کنترل متمرکز سيستم ها. • قابليت پياده سازي قابليت هاي جديد • يک قدم به جلو جهت رفع مشکل ناسازگاري نرم افزارها • معايب : • يک سطح ارتباطي جديد • پيچيده بودن از لحاظ نرم افزاري • فقط يک محيط توسعه و نه يک سيستم جامع internal clients control connecting logic middleware system user logic wrappers Resource managers 2 tier systems

  15. HTML filter Web server معماري N-tier : ارتباط با وب client N-tier architecture Web browser • N-tire معماری ارتباط دادن چندين سيستم 3tier به هم مي باشند. • خود لايه وب يک لايه اضافي است که امروزه در لايه نمايش ادغام شده است. presentation layer application logic layer middleware resource management layer information system

  16. ارتباطات Blocking or synchronous client server • سيستم هاي سنتي معمولا از ارتباطات Blocking استفاده مي کنند. • معايب: • نياز به online بودن طرفين ارتباط • سربارگذاري بر ارتباطات • نگهدري Session براي هر ارتباط • پرهزينه بودن نگهداري Session ها • اختصاص يک Thread به هر Session • امکان خرابي • مشکل در تشخيص خرابي Call Receive idle time Response Answer

  17. 1 request() do with answer 2 receive process return 4 3 1 request() do with answer timeout try again do with answer 2 receive process return 3 2’ receive process return 3’ مشکلات ارتباطات synchronous • با خرابي هر يک از سيستم ها ارتباط به طور کامل از دست مي رود. • چه کسي مسئول کشف خرابي است؟ • مشکل در پيدا کردن اينکه خرابي در کدام مرحله اتفاق افتاده است.

  18. request() queue receive process return queue do with answer راه حل هاي ممکن • ارتباطات asynchronous • پياده سازي از طريق: • فراخواني non-Blocking • استفاده از صف • مناسب براي طراحي توزيع شده • راه مناسب براي طراحي سيستم هاي پيچيده • راه طبيعي پياده سازي ارتباطات پيچيده بين سيستم هاي ناسازگار • حمايت از: • ارتباطات Transactional : در اين حالت ارتباطات در قالب ACID انجام مي شود. تنها اجراي کامل فرايند تضمين شده و انجام کامل آن تضمين نمي شود. • Server Replication : ولي مشکل همچنان در طرف کاربر باقي مي ماند.

  19. Remote Procedure Call

  20. Machine A (client) Machine B (server) Service request RPC Service response SOCKETS TCP, UDP IP Execution Thread راه هاي ارتباط دادن نرم افزار هاي توزيع شده • استفاده از socket programming • استفاده ازRPC(Remote Procedure Call) • مخفي کردن جزئيات ارتباط • ارتباط دادن سيستم هاي ناسازگار • RPC يک مکانيسم براي ارتباط بين سيستم هاي توزيع شده است.

  21. String length 6 A l o n s o String length 4 E T H Z cardinal 2 0 0 1 مسائل موجود براي ارتباط دو سيستم با هم • چگونه داده ها با Data type و Data Structure هاي مختلف را منتقل کنيم؟ • marshalling/un-marshalling • serializing/de-serializing • چگونه ارتباطات را بخشي نامحسوس از زبان برنامه نويسي کنيم ؟ • چگونه سرويس مورد نظر خود را در بين انبوه سرويس ها پيدا کنيم؟ • با خرابي ها چگونه برخورد کنيم؟

  22. Binding • يک سرويس در يک سرور با يک IP خاص قرار گرفته و به Port خاصي گوش مي کند. • Binding فرايند نگاشت نام سرويس به يک IP و Port خاص مي باشد. • راه هاي ممکن براي Binding : • محلي : کاربر آدرس سرويس را در اختيار دارد. • توزيع شده : سرور ديگري مسئوليت نگاشت را به عهده دارد. • در اين حالت نياز به مکانيسمي براي ثبت , جستجو و فراخواني يک سرويس مي باشد.

  23. CLIENT call to remote procedure Client process CLIENT stub procedure Bind Marshalling Send Communication module SERVER stub procedure Unmarshalling Return Communication module Dispatcher (select stub) SERVER remote procedure Server process وظايف اصلي RPC • فراهم آوردن يک Interface يکسان براي فراخواني سرويس ها (IDL) • توليد کد هاي اضافي براي ارتباطات تحت شبکه براي فراخواني سرويس • فراهم کردن Binder براي فراخواني سرويس

  24. Client code Client stub Comm. Module Comm. module Server stub Server code Binder Register service request RPC bind ACK Look up request Look up response send RPC request call return RPC response return نحوه ارتباط با جزئيات بيشتر

  25. Simplified Interface Top Level Intermediate Level Expert Level Bottom Level IDL (Interface Definition Language) • فراهم آوردن سطوح مختلف پيچيدگي و توصيف لايه هاي مختلف,توسط RPC • لايه هاي اضافي فرصت تعريف و کنترل بيشتر بر bindingو پرتکل های انتقالرا مهيا مي سازد. • توصيف سرويس به نحوي انتزاعي جدا از خواص زبان برنامه نويسي • فراهم آوردن محيطي براي توصيف سرويس بر اساس نام , ورودي و خروجي هاي آن • فراهم آوردن يک کامپايلر براي توليد stub براي طرفين • اضافه کردن stub کاربر بصورت يک فايل (مثلا *.h) براي استفاده از Interface

  26. SALES POINT CLIENT IF no_customer_# THEN New_customer ELSE Lookup_customer Check_inventory IF enough_supplies THEN Place_order ELSE ... Server 1 New_customer Lookup_customer Delete_customer Update_customer Customer database DBMS Server 2 New_product Lookup_product Delete_product Update_product Products database INVENTORY CONTROL CLIENT Lookup_product Check_inventory IF supplies_low THEN Place_order Update_inventory ... DBMS Server 3 Place_order Cancel_order Update_inventory Check_inventory Inventory and order database DBMS يک مثال عملي

  27. مزايا و معايت RPC • معايب • وجود تفاوت در پياده سازي و نسخه هاي مختلف , با قابليت هاي مختلف و ناسازگار • عدم حل مسائل سطح بالا و فقط توجه به فراخواني سرويس ها • فراخواني مانند سرويس هاي محلي • بدون توجه به محل سرويس دهنده • وجود يک Binder مرکزي • طراحي شده و پوشش دهنده تنها براي سيستم هاي Client/Server • کند بودن نسبت به فراوخواني محلي • مزايا: • فراهم آوردن يک مکانيسم براي پياده سازي برنامه هاي توزيع شده • حمايت شده توسط اغلب زبان هاي برنامه نويسي • بوجود آوردن قابليت طراحي ماجولار و طراحي سلسله مراتبي

  28. Distributed Applications Distributed File Service Time Service RPC Security Service Cell Directory Service Thread Service DCE Transport Service/ OS DCE • Distributed Computing Environmentپياده سازي استاندارد يک RPC شامل ماجول هاي لازم براي هر سيستم توزيع شده اي مي باشد که شامل اجزائ زير مي باشد : • RPC • Name and Directory Service • secure and authentication • sharing of files • support threads • DCE تنها معماري و توصيفات نيست(مانند CORBA ) بلکه شامل پياده سازي نيز مي باشد.

  29. DCE architecture DCE development environment client process server process client code server code IDL IDL sources language specific call interface language specific call interface client stub server stub IDL compiler RPC API RPC API interface headers RPC run time service library RPC run time service library RPC protocols security service cell service distributed file service thread service DCE runtime environment

More Related