RMI
מערכות מידע מבוזרות - אוסף של תוכנות הנסמכות אחת על השנייה התוכנה רצה אבל נסמכת על תוכנה אחרת שרצה באותו זמם או לא בדיוק באותו זמן.
לדוגמה: דוגמה פשוטה קליינט - ברואזר- סרבר. מישהו מנסה להריץ דפדפן על המחשב האישי אך אין משמעות לתוכנה הזו עם אין ווב סרבר בעולם שמאחסן את הנתונים של עיתון YNET יש לנו מערכת מחשב אישית דפדפן ושרת שכל אחד נסמך על השני כי לבדו אין לזה שום משמעות.
בעולם העסקים הדוגמאות הם למשל כל תוכנות לניהול שרשרת האספקה.
בתוך ארגון יש לי תוכנה CRM אבל בלי שהוא יקבל מידע על נתוני שימוש , הוא צריך לקבל נתוני חיוב מהמערכת החשבונות ואז לפלוט הנחות כלומר היא נסמכת על תוכנה אחרת בצורה מבוזרת.
למה זה קורה??
דבר ראשון אנו רואים שמושכ הארגון נחשק בעשורים האחרונים , פעם מושג החברה היה מאוד ברור יש מגדל משרדים וזה החברה - היום זה לא ככה , למשל ניקח את חברת סיסקו .
סיסקו היא לא באמת חברה - היא חברה שנבנתה ע"י רכישת חברות - אבל כל חברה שהם רכשו נשארה בתור חטיבה ארגונית נפרדת בתוך חברת סיסקו.
כולל מערכות המידע שבחברה הנרכשת שגם הם היו נפרדות- כלומר סיסקו היא בעצם חברת אחזקות, אז זו בדיוק סיבה למידור.
דוגמא נוספת יש לי חברה שיש לה מחלקת הנדסה מחלקת כספים מחלקת שירות לקוחות ואיני רוצה שיתפו בניהם את כל המידע לכן אני ממדר את מה שצריך ואת מה שנסמך אחד על השני אני מבזר.
זאת סיבה אחת.
סיבה נוספת:
אפילו עם יש לי חברה אחת ואני רוצה לבנות לה מערכת מידע אז אלך לכמה חברות שונות :תוכנה לניהול לקוחות תוכנה להנהלת חשבונות כל תוכנה מספק אחר אבל אני רוצה שידברו אחת עם השנייה לכן אני בונה מערכת מבוזרת.
יש עוד ועוד סיבות למשל חומרה אני רוצה שכל תוכנה תרוץ על חומרה אחרת , אחת על שרת אחת על מחשב אישי ואני רוצה שידברו אחת עם השנייה.
דוגמה חשובה מאוד היא שרידות במקרה של אסון על מנת לגבות את המידע כדאי שהערכת לא תהיה באותו מקום פיזי.
ארכיטקטורה 3 השכבות בדרך כלל באה ליישום ע"י ביזור.
אני רוצה עכשיו מתוך תוכנית JAVA לגשת לתוכנית JAVA במחשב אחר וככה תהייה לי מערכת מבוזרת.
בסיס הנתונים הארגוני זוהיא תוכנה מסויימת והלוגיקה הארגונית זו תוכנה אחרת ואם אני רוצה לעשות הצגה HTML כלומר אתר אז זו שוב תוכנה אחרת.
יכולה להיות מערכת מבוזרת שבסיס הנתונים עצמו מחולק לשתי חלקים שונים(לצורך שרידות לדוגמא).
ה לא שמערכת מידע מבוזרת שווה שווה לארכטקטורה שלושלת השכבות בגלל שיכול להיות שחלק מהשכבות האלו הם בעצמם מבוזרות, אבל שאתם רואים מערכת שמתוכננת לפי ארכיטקטורה 3 השכבות בדרך כלל היא גם תהיה מבוזרת בגלל שאין הגיון לשים את שכבת ההצגה באותו מקום שבוא נמצא הבסיס נתונים.
מה צריכה שכבת ההצגה כדי לעבוד יפה?
ערוץ תקשורת רחב, הכי טוב לשים אותו אצל ספק האינטנרט שלי לא אצלי .
בסיס הנתונים לעומת זאת ארצה שימצא קרוב אליי , ושם הערוץ נתונים יהיה מאוד מאובטח אך רוחבו לא חשוב במיוחד.
גם הלקוח הוא חלק ממערכת המידע שלנו , הוא מתממשק בצורה מסויימת יכול להיות דרך אתר אינטרנט בצורה מאוד פשוטה אבל זה גם יכול להיות בצורה מורכבת כמו למשל B2B - אני בנק והלקוח שלי הוא חברה בעלת חשבון אצלי .
מה תקשורת נתונים עושה לארגון?
1. ייעול תהליכים.
2. גשרים ג"א כבר לא חשובים כמו פעם , אין שום משמעות למיקום גאוגרפי בכלכלת המידע . זה מאפשר מיקור חוץ וכו'.
שתיכננו את מערכות התקשורת בצורה של 7 רמות הפשטה:
מתחיל למטה ברמה הפיזקלית ונגמר למעלה ברמת האפליקציה .
כל רמה מספקת שירותים מסויימים, מתמודדת עם בעיות מסויימות ועל הרמה הזו כאשר היא פטרה בעיות מסויימות מתיישבת רמה נוספת ופותרת בעיות אחרות.
אז לדוגמא יש רמה שאומרת רק איך מעבירים ביטים סצורה אלחוטית ממשדר למקלט שנמצא במרחק של לא יותר מקילומטר וחצי , עכשיו כמובן להעביר את הביטים מכאן לשם זה רק חלק מהבעיה כי הבעיה זה לא לדבר אם האנטנה ההיא, אני רוצה לדבר אם מישהו שנמצא במקום אחר בארץ ועל מנת להגיע אליו יש לפתור כמה בעיות :
דבר ראשון יש להעביר את האותות מהאנטנה פה לאנטנה שנמצאת על ידו , עכשיו יותר מזה בדרך כלל שאנחנו מדברים עם אנשים אנחנו לא מדברים ב 001, 11100 , 111000 וכו'זו לא שיחה בינארית .
כל בעיה כזו נפתרת ברמה אחרת .
אנחנו לא מודעים לכמה בעיות יש מכיוון שכבני אדם אנחנו מבנים קשרים וגם אני לדומגא לא ממש מובן הבנתם כבני אדם שהתכוונתי לדוגמא ולא לדומגא. בני אדם פותרים את הבעיות הללו בצורות מאוד מאוד מתוחכמות אבל לצערנו מחשבים הם אהבלים , הם לא מבינים אנחנו צריכים להסביר כל בבעיה ברזלוציה הכי קטנה ולהסביר להם איך לפתור אותם צעד אחרי צעד, זו עבודה מאוד משעממת ואפילו לא יוקרתית ואנחנו לא נלמד את כל הבעיות והפתרונות להם , למזלנו יש פקולטות לחשמל ויש אנשים שזה מה שמעניין אותם בחיים והם יושבים ופותרים את הבעיות הללו.
אנו נתמקד בכמה בעיות קריטיות בודדות.
אחת הבעיות המרכזיות שהיא שונה מכל מה שלמדתם על מחשבים עד היום , כאשר אתם תיכנתם ולא משנה באיזה שפה היו לכם בעיות לא פשוטות וכאשר עלתה בעיה בתוכנה - התוכנה נפלה - לא נעים אבל בזה נגמר העניין , והעניין נגמר פה מכיון שכאשר התעסקתם המחשבים התעסקתם בנקודות בודדות - עכשיו שאנו מתעסקים בתקשורת איננו יכולים להתמודד עם יחידה בודדת אנו מתמודדים עם מערכת ומערכת כאשר אחד המרכיבים מת או יש תקלה המערכת צריכה להמשיך להתקיים תוך הכרה שיש תקלה , שיש מחשב או ביט או לא משנה שהתרסק , נעלם . המערכת צריכה לחיות עם זה , עכשיו לראשונה אתם צריכים להתמודד עם שגיאות והשגיאות קיימות לאורך כל הדרך , ברמה הפיזית , ברשת ובכל מקום בו המערכת מתפקדת. לפעמים המחשב נפל ולא קיבל את כתובת הIP הנכונה אך האינטנרט לא יכול לעצור בגלל שיש איזה מחשב שנפל וצריך לחכות שיתקנו את השגיאה. דברים צריכים לעבוד, אנו כמתכנתים צריכים להכיר בזה שיש שגיאות.
בצורה שעובדים המודל השכבות לכל קובייה יש תקשורת עם שלוש קוביות שונות - זאת שמעליה , זאת שמתחתיה וגם הקובייה המקבילה לה במחשבים אחרים.
איך זה עובד? מקבלים בדרך כלל הוראות מרמה שמעלינו - לדוגמה כתובה איזה אפליקציה, שאומרת אוקיי תשיג לי רפרנס לאיזה נתון כלשהו , ההודעה הזו מחלחלת למטה במודל השכבות ומגיעה לרמת העברה , וברמת העברה נפתח סוקט עבור כתובת זאתי וזאתי. עכשיו הקובייה שמקבלת את ההוראות מלמעלה היא יודעת איך לפתור את הביות הזו - היא יועת לשלוח הוראות מדויקות לרמה מתחתיה ואז הרמה מתחתיה תעשה איזה קסם , תדבר עם המחשב שממול , תיצור קשר ברמה העברה המקבילה במחשב שממול ואז המחשב שממול יתחיל בפעולה לאחר השיחה, אז הורדה הוראה מסויימת ולאחר ההוראה עלתה אוסף של פעולות
מערכות מידע מבוזרות - אוסף של תוכנות הנסמכות אחת על השנייה התוכנה רצה אבל נסמכת על תוכנה אחרת שרצה באותו זמם או לא בדיוק באותו זמן.
לדוגמה: דוגמה פשוטה קליינט - ברואזר- סרבר. מישהו מנסה להריץ דפדפן על המחשב האישי אך אין משמעות לתוכנה הזו עם אין ווב סרבר בעולם שמאחסן את הנתונים של עיתון YNET יש לנו מערכת מחשב אישית דפדפן ושרת שכל אחד נסמך על השני כי לבדו אין לזה שום משמעות.
בעולם העסקים הדוגמאות הם למשל כל תוכנות לניהול שרשרת האספקה.
בתוך ארגון יש לי תוכנה CRM אבל בלי שהוא יקבל מידע על נתוני שימוש , הוא צריך לקבל נתוני חיוב מהמערכת החשבונות ואז לפלוט הנחות כלומר היא נסמכת על תוכנה אחרת בצורה מבוזרת.
למה זה קורה??
דבר ראשון אנו רואים שמושכ הארגון נחשק בעשורים האחרונים , פעם מושג החברה היה מאוד ברור יש מגדל משרדים וזה החברה - היום זה לא ככה , למשל ניקח את חברת סיסקו .
סיסקו היא לא באמת חברה - היא חברה שנבנתה ע"י רכישת חברות - אבל כל חברה שהם רכשו נשארה בתור חטיבה ארגונית נפרדת בתוך חברת סיסקו.
כולל מערכות המידע שבחברה הנרכשת שגם הם היו נפרדות- כלומר סיסקו היא בעצם חברת אחזקות, אז זו בדיוק סיבה למידור.
דוגמא נוספת יש לי חברה שיש לה מחלקת הנדסה מחלקת כספים מחלקת שירות לקוחות ואיני רוצה שיתפו בניהם את כל המידע לכן אני ממדר את מה שצריך ואת מה שנסמך אחד על השני אני מבזר.
זאת סיבה אחת.
סיבה נוספת:
אפילו עם יש לי חברה אחת ואני רוצה לבנות לה מערכת מידע אז אלך לכמה חברות שונות :תוכנה לניהול לקוחות תוכנה להנהלת חשבונות כל תוכנה מספק אחר אבל אני רוצה שידברו אחת עם השנייה לכן אני בונה מערכת מבוזרת.
יש עוד ועוד סיבות למשל חומרה אני רוצה שכל תוכנה תרוץ על חומרה אחרת , אחת על שרת אחת על מחשב אישי ואני רוצה שידברו אחת עם השנייה.
דוגמה חשובה מאוד היא שרידות במקרה של אסון על מנת לגבות את המידע כדאי שהערכת לא תהיה באותו מקום פיזי.
ארכיטקטורה 3 השכבות בדרך כלל באה ליישום ע"י ביזור.
אני רוצה עכשיו מתוך תוכנית JAVA לגשת לתוכנית JAVA במחשב אחר וככה תהייה לי מערכת מבוזרת.
בסיס הנתונים הארגוני זוהיא תוכנה מסויימת והלוגיקה הארגונית זו תוכנה אחרת ואם אני רוצה לעשות הצגה HTML כלומר אתר אז זו שוב תוכנה אחרת.
יכולה להיות מערכת מבוזרת שבסיס הנתונים עצמו מחולק לשתי חלקים שונים(לצורך שרידות לדוגמא).
ה לא שמערכת מידע מבוזרת שווה שווה לארכטקטורה שלושלת השכבות בגלל שיכול להיות שחלק מהשכבות האלו הם בעצמם מבוזרות, אבל שאתם רואים מערכת שמתוכננת לפי ארכיטקטורה 3 השכבות בדרך כלל היא גם תהיה מבוזרת בגלל שאין הגיון לשים את שכבת ההצגה באותו מקום שבוא נמצא הבסיס נתונים.
מה צריכה שכבת ההצגה כדי לעבוד יפה?
ערוץ תקשורת רחב, הכי טוב לשים אותו אצל ספק האינטנרט שלי לא אצלי .
בסיס הנתונים לעומת זאת ארצה שימצא קרוב אליי , ושם הערוץ נתונים יהיה מאוד מאובטח אך רוחבו לא חשוב במיוחד.
גם הלקוח הוא חלק ממערכת המידע שלנו , הוא מתממשק בצורה מסויימת יכול להיות דרך אתר אינטרנט בצורה מאוד פשוטה אבל זה גם יכול להיות בצורה מורכבת כמו למשל B2B - אני בנק והלקוח שלי הוא חברה בעלת חשבון אצלי .
מה תקשורת נתונים עושה לארגון?
1. ייעול תהליכים.
2. גשרים ג"א כבר לא חשובים כמו פעם , אין שום משמעות למיקום גאוגרפי בכלכלת המידע . זה מאפשר מיקור חוץ וכו'.
שתיכננו את מערכות התקשורת בצורה של 7 רמות הפשטה:
מתחיל למטה ברמה הפיזקלית ונגמר למעלה ברמת האפליקציה .
כל רמה מספקת שירותים מסויימים, מתמודדת עם בעיות מסויימות ועל הרמה הזו כאשר היא פטרה בעיות מסויימות מתיישבת רמה נוספת ופותרת בעיות אחרות.
אז לדוגמא יש רמה שאומרת רק איך מעבירים ביטים סצורה אלחוטית ממשדר למקלט שנמצא במרחק של לא יותר מקילומטר וחצי , עכשיו כמובן להעביר את הביטים מכאן לשם זה רק חלק מהבעיה כי הבעיה זה לא לדבר אם האנטנה ההיא, אני רוצה לדבר אם מישהו שנמצא במקום אחר בארץ ועל מנת להגיע אליו יש לפתור כמה בעיות :
דבר ראשון יש להעביר את האותות מהאנטנה פה לאנטנה שנמצאת על ידו , עכשיו יותר מזה בדרך כלל שאנחנו מדברים עם אנשים אנחנו לא מדברים ב 001, 11100 , 111000 וכו'זו לא שיחה בינארית .
כל בעיה כזו נפתרת ברמה אחרת .
אנחנו לא מודעים לכמה בעיות יש מכיוון שכבני אדם אנחנו מבנים קשרים וגם אני לדומגא לא ממש מובן הבנתם כבני אדם שהתכוונתי לדוגמא ולא לדומגא. בני אדם פותרים את הבעיות הללו בצורות מאוד מאוד מתוחכמות אבל לצערנו מחשבים הם אהבלים , הם לא מבינים אנחנו צריכים להסביר כל בבעיה ברזלוציה הכי קטנה ולהסביר להם איך לפתור אותם צעד אחרי צעד, זו עבודה מאוד משעממת ואפילו לא יוקרתית ואנחנו לא נלמד את כל הבעיות והפתרונות להם , למזלנו יש פקולטות לחשמל ויש אנשים שזה מה שמעניין אותם בחיים והם יושבים ופותרים את הבעיות הללו.
אנו נתמקד בכמה בעיות קריטיות בודדות.
אחת הבעיות המרכזיות שהיא שונה מכל מה שלמדתם על מחשבים עד היום , כאשר אתם תיכנתם ולא משנה באיזה שפה היו לכם בעיות לא פשוטות וכאשר עלתה בעיה בתוכנה - התוכנה נפלה - לא נעים אבל בזה נגמר העניין , והעניין נגמר פה מכיון שכאשר התעסקתם המחשבים התעסקתם בנקודות בודדות - עכשיו שאנו מתעסקים בתקשורת איננו יכולים להתמודד עם יחידה בודדת אנו מתמודדים עם מערכת ומערכת כאשר אחד המרכיבים מת או יש תקלה המערכת צריכה להמשיך להתקיים תוך הכרה שיש תקלה , שיש מחשב או ביט או לא משנה שהתרסק , נעלם . המערכת צריכה לחיות עם זה , עכשיו לראשונה אתם צריכים להתמודד עם שגיאות והשגיאות קיימות לאורך כל הדרך , ברמה הפיזית , ברשת ובכל מקום בו המערכת מתפקדת. לפעמים המחשב נפל ולא קיבל את כתובת הIP הנכונה אך האינטנרט לא יכול לעצור בגלל שיש איזה מחשב שנפל וצריך לחכות שיתקנו את השגיאה. דברים צריכים לעבוד, אנו כמתכנתים צריכים להכיר בזה שיש שגיאות.
בצורה שעובדים המודל השכבות לכל קובייה יש תקשורת עם שלוש קוביות שונות - זאת שמעליה , זאת שמתחתיה וגם הקובייה המקבילה לה במחשבים אחרים.
איך זה עובד? מקבלים בדרך כלל הוראות מרמה שמעלינו - לדוגמה כתובה איזה אפליקציה, שאומרת אוקיי תשיג לי רפרנס לאיזה נתון כלשהו , ההודעה הזו מחלחלת למטה במודל השכבות ומגיעה לרמת העברה , וברמת העברה נפתח סוקט עבור כתובת זאתי וזאתי. עכשיו הקובייה שמקבלת את ההוראות מלמעלה היא יודעת איך לפתור את הביות הזו - היא יועת לשלוח הוראות מדויקות לרמה מתחתיה ואז הרמה מתחתיה תעשה איזה קסם , תדבר עם המחשב שממול , תיצור קשר ברמה העברה המקבילה במחשב שממול ואז המחשב שממול יתחיל בפעולה לאחר השיחה, אז הורדה הוראה מסויימת ולאחר ההוראה עלתה אוסף של פעולות
אין תגובות:
הוסף רשומת תגובה