AppML- Verlauf

1999 entwickelte Refsnes Data die erste Version von AppML.

Schon damals basierte AppML auf der HTTP-Request-Kommunikation zwischen Webclient und Webserver. Später wurde diese Methode als AJAX bekannt.

Im September 2000 wurde ein Entwicklungsprojekt für einen großen norwegischen Kunden gestartet. Das Ziel des Projekts war es, ein riesiges Informationssystem (ca. 300 Anwendungen) von einer Windows-Desktopanwendung in eine moderne Internetanwendung zu konvertieren, wobei nur AppML verwendet wurde.

Das AppML-basierte System wurde 2001 einige Monate früher als geplant als weltweit erste kommerzielle AJAX-Anwendung eingeführt. Das Projekt war ein großer Erfolg, da die Entwicklungszeit im Vergleich zur normalen Webentwicklung um 75 % verkürzt wurde. Seitdem sind neue Anwendungen hinzugekommen, und das System deckt nun über 1000 laufende Anwendungen ab.

Im Februar 2015 hat W3Schools AppML als neues, öffentlich zugängliches Produkt neu auf den Markt gebracht.

AppML-Designziele:

• AppML-Anwendungen müssen über das Internet ausgeführt werden
• AppML-Anwendungen müssen plattformunabhängig sein
• AppML-Anwendungen dürfen nur Internetstandards verwenden (HTML, CSS, JavaScript)
• AppML-Anwendungen müssen eine Vielzahl von Anwendungsanforderungen unterstützen
• AppML-Anwendungen müssen selbstbeschreibend sein
• AppML-Anwendungen müssen einfach zu entwickeln, zu warten und zu ändern sein
• AppML-Anwendungen müssen zukunftssicher sein

Die folgenden Absätze beschreiben die ursprünglichen Visionen von Refsnes Data (1999) über zukünftige Webanwendungen.

Ausführbare Dateien werden sterben, JavaScript wird leben

Kompilierte ausführbare Dateien (kompiliert aus Sprachen wie C oder Java) können nicht auf anderer Hardware ausgeführt werden.

Ausführbare Dateien (EXE-Dateien, ActiveX- und COM-Objekte, DLL-Dateien) sind Komponenten, die die Entwicklung von Anwendungen verhindern, die über das Internet ausgeführt werden können.

Zukünftige Anwendungen werden keine ausführbaren Dateien oder andere auf dem Computer des Kunden installierte Komponenten verwenden oder sich darauf verlassen.

Unsere Vorschläge:

Schreiben Sie Ihre zukünftigen Anwendungen nur mit HTML, CSS und JavaScript.

Stellen Sie sicher, dass Ihre zukünftigen Anwendungen in jedem Webbrowser ausgeführt werden.

Webanwendungen werden Internetdienste sein

Die Geschichte ist voll von großen, speziell entwickelten Anwendungen. Viele von ihnen starben sehr schnell, weil sie Anforderungsänderungen nicht überleben konnten.

Anwendungen sollten flexibel und verallgemeinert sein und sich elegant an Änderungen anpassen, ohne zerbröselt oder zerstört zu werden.

Anwendungen sollten in der Lage sein, von der Unterstützung einiger weniger bis hin zu Millionen von Anfragen pro Tag zu skalieren.

Anwendungen sollten in der Lage sein, sich von einem Server auf viele zu verteilen oder zwischen Servern zu wechseln, ohne die Anwendung zu beschädigen.

Anwendungen sollten in der Lage sein, mit anderen Anwendungen zusammenzuarbeiten.

Anwendungen sollten keine großen Mengen an Code enthalten.

Anwendungen sollten in kleinere Dienste unterteilt werden, die einfach zu erstellen und zu warten sind.

Anwendungen sollten eine Reihe von Internetdiensten sein, die Daten an gesendete Internetanforderungen zurückgeben können.

Anwendungen sollten Dienste über Standard-Internetprotokolle anfordern, ohne eine permanente Verbindung zum Server aufrechtzuerhalten. 

Unsere Vorschläge:

Schreiben Sie Ihre zukünftigen Anwendungen mit internetbasierter SOA (Service Oriented Architecture).

Gestalten Sie Ihre Anwendungsdienste allgemein und flexibel und bereiten Sie sie darauf vor, verschiedene Arten von Anfragen zu bedienen.

Zukünftige Anwendungen werden einfach zu erstellen und zu bearbeiten sein

Clients und Server tauschen Daten auf leicht verständliche Weise aus.

Anwendungen werden nicht codiert, wenn es sich vermeiden lässt.

Anwendungen werden durch Bearbeiten von Modellen erstellt und geändert, nicht durch Bearbeiten von Code.

Anwendungsbeschreibungen werden von Menschen lesbar sein.

Anwendungsbeschreibungen sind selbstbeschreibend.

Anwendungen werden von Benutzern geschrieben, nicht von Programmierern.

Unsere Vorschläge:

Verwenden Sie für Menschen lesbare Textdateien, um Dienste zu beschreiben, und stellen Sie Dienste bereit, indem Sie diese Beschreibungen ausführen.

Verwenden Sie Textdateien (wie JSON-Dateien), um Anwendungen zu beschreiben.

Verwenden Sie Textdateien (wie JSON-Dateien), um Daten auszutauschen.

Verwenden Sie HTML, CSS und JavaScript, um Anwendungen auszuführen.

Drei kleine Webentwickler...

Es waren einmal drei kleine Webentwickler, die eine neue Website entwickelten.

1. Der erste Webentwickler verwendete AppML.

2. Der zweite Webentwickler verwendete seine bevorzugte Server-Programmiersprache.

3. Die dritte war die Verwendung eines professionellen Enterprise-Webentwicklungs-Frameworks.

Der erste Webentwickler hatte innerhalb von zwei Tagen eine Demo zum Laufen gebracht. Nach Zusammenarbeit mit den Benutzern war in einer Woche ein spannender Prototyp fertig. Und nach zweiwöchigem Testen war eine intelligente, schnelle und einfach zu bedienende Website zur Veröffentlichung bereit.

Der zweite Webentwickler hatte seine Website nach 6 Monaten fertig. Aber das WWW hatte seine Anforderungen geändert und war nicht zufrieden. Der Webentwickler konnte an seinem Projekt keine großen Änderungen vornehmen, da es zu viel Code enthielt. Also begann er mit der Entwicklung von Version 2.

Der dritte Webentwickler hat es nie geschafft, seine Arbeit abzuschließen. Das professionelle Webentwicklungs-Framework war sehr schwierig zu bedienen, sehr schwer zu verstehen und fast unmöglich zu testen.

Sehen Sie sich an, wie der erste Entwickler das gemacht hat .