General:

It’s the same old story always, you put a system in production, the first couple of months you maintain a rapid response team which cater to every whim and any operation error that can ever be, everybody is happy, the system implementation completed all things running smoothly and then it is time to go to “Business as usual” phase. The vendor wants to get there so that they can collect a license fee, the client wants to get there in order to disband the project, close the budget item and employ his application experts in new projects. And that’s if all is well.

But the system is still alive and issues that may have not been identified in time are already in and may only reveal themselves in 1,2,3 , 12 months time. Support wise, the online support is done by a dedicated help desk which may respond promptly or laid back but will always react.

Assumptions:

I’ll assume for the sake of the article that an information system is comprised of Items and these items may undergo Events scheduled or manually initiated. It doesn’t really matters what are the events or what are the items. A stock management system may include a scheduled expiry event for an item and an initiated event for sale. Or the items can be timesheets and the scheduled events can be working hours while the initiate ones are time offs. Regardless of the systems subjects they all can be categorized into items, scheduled events and initiated events.
Usually scheduled events will be executed by a scheduler in batch while initiated events will be triggered by a web service.

Weight and distributions

Most of the events on most information systems are actually scheduled events which happen on a daily or monthly frequency. The initiated events are usually 30 % off the total of accounts.

What can we do?

Aiming to act instead of react, the scheduled events may be predicted and so rolled forward.
Which means that out of any 10 activities in an information system, 7 can be predicted, i.e. performed and checked beforehand.

In order to implement such a methodology, it is required to age the whole system on outside the normal cycle and check for deviating values automatically,

Just to illustrate. Assuming an information system which mange items X each item may undergo an event A which should have consequences C on a monthly basis. This can be a contract billed for on a monthly basis and the consequences would be a cash balance or a purchase transaction.

Assuming that the consequences C can be tested by an SQL statement. It is possible to run the set of Events A and progress over a time line and check the results automatically.

The aging process will look like:

Given the above example, E would be a preauthorized cheque request or credit card transaction and the Check would comprise of an SQL which checks the cash balance, accounting transactions and goods supplied for deviating values.

Deviating values in this illustration will be any Check result which does not meet our expectation: transaction performed but not reported, transaction performed and cash balance remains the same, transaction performed but no change to goods or transaction not performed at all.

This should be analyzed and either have the expectation amended or the root cause identified.

What can be done with the results

These results are predictive in a sense that we do not actually know that these will be the results, so to act upon them directly would probably be wrong. Item 1 in the above example may not even be there on T1 if for example it’s a house hold in a neighborhood which is billed periodically for Jon J Jr’s piano lessons may move to Greanock by the end of T0. But what can be done is to prepare the business users. In some other cases the event E may be something that is mandatory and then a fix to item 3 can be applied.

The immediate result, however, should be a report, identifying the future problems and the future mitigation suggested.

What about initiated events

Although it is much more apparent how to predict scheduled events , initiated events can be predicted as well.

Taking the above example, the aging process can initiate a move to Greanock for all households in T0 and to identify which of the can actually complete the move.
this kind of a predictive check can be manifested as a health card attached to each household:

Item 1 can undergo monthly cash request while cannot be relocated to Greanock.

Where can we take this further

The health card and potential scheduled failures can be fed back to the system dictating whether the option to relocate to Greanock will actually be presented to the user until fixed.

Summary

By means of methodological change, system support can be altered from a responsive mode into an action mode.

The methodology includes execution of potential or scheduled events in advance, before the user performs them or the system initiates them and trapping inadequate or deviating results.

חלק ממודל חמשת השכבות הוא שכבת הגישה לבסיס הנתונים שכבה שבה כל המידע מיוצג באובייקטים במבנה בסיס הנתונים ושדרכו מתבצעות כל פעולות הגישה לבסיס הנתונים. לשכבה הזו שני רכיבים עיקריים: בסיסי ודינמי. הרובד הבסיסי מכיל בעבור כל טבלה מחלקה של מבנה הנתונים, שיטות INSERT לרשומה יחידה, שיטות UPDATE/DELETE לפי מפתח ושיטות SELECT לפי מפתח ראשי מלא או חלקי ומפתחות זרים. הרובד הדינאמי מכיל מחלקות שכל אחד מהם מייצג שליפה מורכבת ספציפית לצורך הצגה / דוחות.אבולוציונית את המודל הבסיסי ניתן לחזות במלואו מרגע שקיים מבנה הנתונים בעוד שהרובד הדינאמי נבנה תוך כדי מחזור החיים של האפליקציה.

מימוש

המימוש של שני הרבדים צריך לייצג את השוני הבסיסי בתפקודם בעוד שהבסיסי מכיל רשימת מלאי של מחלקות שכל אחד מהם מחולק לתפקודים כלליים שמממשים set, get, insert, update, select, delete. עקרונית ניתן לממש מחלקה אבסטרקטית שמממשת את כל הסט. הרובד הדינאמי מורכב ממחלקות עצמאיות שכל מחלקה מייצגת מודל נתונים מורכב ללא כל דמיון בין אחת לשניה. מומלץ למקם את שני הרבדים במרחב שמות אחד או כמרחבי שמות מקוננים. לדוגמא: afs.dal.base וafs.dal.custom
המימוש של הרובד הבסיסי צריך להיות מחולל

חילול DAL

הDAL מעצם טבעו וכל הפחות הרובד הבסיסי שלו קשורים קשר הדוק למבנה בסיס הנתונים כאשר כל מחלקה מייצגת טבלה או אובייקט בסיס נתונים אחר. ניתן עקרונית לכתוב כל מחלקה בנפרד בבסיס נתונים קטן ולא משתנה אולם לבסיס נתונים גדול ודינאמי, מומלץ לחולל את האובייקטים הבסיסיים בצורה פרוגרמתית. על מנת לעשות כן צריך לשאוב את המידע הרלבנטי מבסיס הנתונים. בבסיס הנתונים מצויים כל המאפיינים הנדרשים לחילול האובייקטים.
לפי כך לצורך העמדת רובד בסיסי של גישה לבסיס הנתונים יש לכתוב תכנית שמקבלת בתור קלט את בסיס הנתונים (Connection String) ושואבת ממנו את המידע הנדרש לגבי מבנה בסיס הנתונים והמפתחות ומייצרת את הרובד הבסיסי של ה DAL. פעילות זאת יכולה לחזור בכל מצב שבו בסיס הנתונים ישתנה.

נתונים נדרשים

לצורך חילול מחלקה אוטומטי נדרשים הנתונים הבאים:

• שם הטבלה – יהפוך לשם המחלקה
• שדות וסוגם – יהפכו למאפיינים במחלקה
• מפתח ראשי – ישמש ליצירת שיטת DELETE/UPDATE/SELECT ובמידה וכולל מספר שדות, גם לSELECT מדורג

לדוגמא, ניקח טבלה פשוטה של מחלקות בארגון כאשר כל רשומה מזוהה בעזרת מספר המחלקה ומספר המחלקה הממונה עליה:

שם טבלה: departments

המחלקה שתיוצר תכיל את המאפיינים הבאים:

ניתן לייצר שיטה של אתחול כללי או לייצר בנאי שמקבל כפרמטרים את המאפיינים:public departments (int _id, int _parentid, string _depname)
כמו כן אם כבנאי או כשיטה עצמאית תחולל שיטת SELECT שמקבלת את המפתח בתור פרמטר: public bool selectByKey(int kid, int kparentid)
שיטות הINSERT, UPDATE והDELETE תוגדרנה ללא פרמטרים : public bool insert(), public bool delete(), public bool update()
ממבנה הנתונים ניתן גם לחלל שיטה נוספת על שיטת הSELECT לפי מפתח :public int selectByParentId(int parentId,ref int[] id, ref string[] dep_name)

השיטות

מאחורי כל שיטה שאוזכרה למעט הבנאי או המאתחל שפשוט מאתחלים את מאפייני המחלקה עומדת פקודת SQL עם פרמטרים כאשר בפקודות הINSERT, UPDATE, DELETE הן לוקחות משתנים מתוך המחלקה וקושרות אותן לפרמטרים לדוגמא: UPDATE departments Dep_name=? where ID=? And parentID=?; השיטה UPDATE תקשור את המשתנים הקיימים לפרמטרים בשאילתא, תבצע את השאילתא ותחזיר מחווה הצלחה בוליאני.
שאילתות הSELECT גם מכילות SQL שמכיל פרמטרים לקישור (מפתח מלא או חלקי) אבל לאחר הביצוע כותבות את המידע המתקבל לתוך משתני המחלקה או מערך של ערכים.

כל השיטות הללו מחוללות על סמך האינפורמציה ששאבנו מבסיס הנתונים בלבד.

נקודות חשובות:

* לעיתים נרצה כי שאילתא של SELECT לפי מפתח חלקי תחזיר רשימה מקושרת של מחלקות. לצורך מימוש זה יש להגדיר מחלקה נוספת שמכילה שיטות לאחזור זה, שיטות אלו, יפעילו את המחלקה department, יקבלו את מערכי התוצאות ויצרו בעבור כל שורה מוחזרת מחלקה מסוג department, יקשרו אותן לרשימה אחת שתוחזר בסוף.

* במצבים כאשר ישנם ערכים המוגדרים על ידי טריגרים הנתונים שנמצאים במחלקה אינם מדוייקים אחרי הפעלת INSERT או UPDATE ולכן מומלץ בסוף ביצוע השיטות הללו להפעיל שיטת selectByKey על מנת לשמור על המידע שנמצא במחלקה עדכני.

* שיטת INSERT לעיתים תדרוש דבר נוסף, במספר בסיסי נתונים ניתן להגדיר(IC) IDENTITY Columns שדות שהערך שלהם נקבע בעת הכנסת הרשומה. כל עוד הערך אינו חלק מהמפתח, הפעלת selectByKey תשמור על המחלקה מסונכרנת עם בסיס הנתונים. כאשר הנתון שהוא IC הוא חלק מהמפתח נדרש טיפול קצת שונה: לאחר פעולת הINSERT מתבצעת שאילתא נוספת המגלה את ערך השדה שהוגדר כIC ומעודכן.

אפשרויות חילול קוד

הדרך הפשוטה ביותר לחלל את הקוד לDAL היא לכתוב קובץ במבנה של תוכנית ואז ידנית לקמפל אותה. מתודה זו תעבוד בכל שפת תכנות או סביבה. בסביבת הדוט נט קיים לFRAMEWORK מרחב שמות מיוחד שמאפשר לעשות משהו אחר קצת. ספריית ה CODEDOM מאפשרת לחולל את הקוד כמחלקה וכשכזו כבר לקמפל ולקשר אותה לידי DLL ולידי ומלא.

GSS

The acronym GSS stands for Global State Services. Globally available service which employs a proprietary protocol which enables any licensed application to switch state between devices seamlessly and securely. The service is deployed using standard web services which enable any web enabled device to communicate with it using XML over HTTP.

Usability

Platform and content independent you can use the GSS services to transfer your state to any supported device, mobile or stationary. Any game, form or application can be restored to any capable device. A game invoked on your tablet can simply switch to a friend’s smart TV miles away. A smart form can be edited on a supplier’s desktop, digitally signed by a client in the other side of the globe and transferred back to the supplier’s dispatch centre in a different continent. Similarly the same mechanism can be used to control global web application load balancing.

GSS implementation

Any application may register with the GSS services, enabling it to persist across devices. All that is required is for the application to pack its state using the GSS format, transmit it to the GSS service using the GSS protocol, message the target device using the GSS handler and the state is restored to the target device.

The GSS components

The GSS vision is comprised on three main components

The GSS protocol

The GSS protocol is a form of transferring free form state in and out of the GSS cloud. The simple protocol is based on web data standards (XML) and is built in two sections:

The GSS section which includes a single use token and target application
The State section which is any well-formed XML
Any registered application will be supplied with a strong secured identification which is transmitted securely over https to identify the target application and a public unique identification which will be used when communicating with the target device. Every GSS invocation creates a unique single use token which is used to identify the individual state. Once a state has been pulled the token is invalidated

The GSS message

The GSS message is the carrier which identifies the target device that a state is available for a specific application. Only the target application’s public credentials are transferred alongside with the unique token. Once invoked on the target device, the application identifies itself to the GSS cloud in the secured hidden manner and receives an handle to pull the individual state.

The GSS cloud

The GSS cloud is approachable using standard web methods. Any call to the GSS cloud must include the application registered credentials and may be a push or a pull call.

Push Calls

A push call uploads an individual state to be stored as an encrypted stream of well-formed XML waiting to be pulled; the only return value is the one off token.

Pull Calls

A pull call requests a specific token for a specific application; the token’s validity and context are validated and once validated the token is destroyed and the target application receives a download handle. Once the download is completed, the state is nullified.