Architektur einer modularen Webanwendung

[boks]

hi leute

Also, mein Prof findet PHP toll, bastelt seit 3 Jahren rum, sein Dok mag Ruby on Rails, klatscht in 3 Tagen das gleiche hin, beide haben ein ähnliches Projekt angefangen. Es soll nun aber doch ernst werden, und man will sogar zusammen sitzen und planen. ( ) Mir ist es eigentlich wurscht, in was ich implementier, fänds nur schade wenn aus dem Projekt nichts wird.

So solls sein:
Eine zentrale Datenbank erfasst Einträge mit einigen Parametern.
Ein Modul soll die Einträge und Parametern abfragen, daraus was berechnen und das Resultat zurückgeben und in der Datenbank ablegen.
Der User kann über ein Webinterface Einträge eingeben und auswählen welche Module benutzt werden sollen. Die Parameter kann er mitliefern oder aus der Datenbank holen. Die Ergebnisse sollen schön Präsentiert werden und als Report runterladbar sein. (Das ganze soll ev. auch als Service angeboten werden, so dass man eigene Clients schreiben kann für Batch Processing.)

Damit das ganze erweiterbar bleibt, sollten die Module möglichst unabhängig vom Rest sein, und es sollte möglich sein, verschiedene Programmiersprachen zu verwenden. (Schreit irgendwie nach SOA)
In Zukunft werden sicherlich noch einige Studenten und Doktoranden daran rumbasteln, ein gutes Fundament ist da essentiell.

Nun wollt ich fragen, ob hier jemand ne gute Idee hat, mit welchen Mitteln (Sprache/Plattform/Framework) man sowas implementieren sollte, damit es einigermassen wartbar und zukunftssicher bleibt.

Danke im voraus
Grüsse

[C++ Forumbot]

Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Webzeugs verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

[Unix-Tom]

Da fällt mir viel ein.
Es ist in PHP, Ruby on Rails, ASPNET u.s.w. machbar.

Ich würde aber dafür Windows. c# und ASP NET nehmen.

MSSQL 2008, IIS 7, vielleicht Moss 2007 wenn erforderlich.

Clients können geschrieben werden wie sie wollen da ein Webservice angeboten wird.
Reports werden über den MSSQL (alles bereits drin) erstellt.
Ist natürlich dann auch eine Kostenfrage aber UNI bekommt von MS sowieso alles was sie braucht.

[PRIEST]

Jo, kommt darauf an nich ^^ also ich bin ja für webanwendungen total der PHP-Fan(+FLEX || AJAX) ... und ASP verachter ^^

Aber mit asp würde sich das alles denke ich wirklich leichter realisieren lassen.
Kommt eben darauf an ob ihr es "leicht" haben wollt oder basteln wollt ^^

wobei leicht hier auch etwas schwammig ist ^^

[boks]

Sry fürs falsche Forum..

Also Windows kommt eigentlich nicht in Frage, wir alle drei nutzen Linux und ein Windows Server steht auch nicht zur Verfügung. Soll in-house gehostet werden, daher Linux oder Plattform unabhängig.

Da wir alle vom naturwissenschaftlichen Bereich kommen und keiner wirklich Erfahrung hat im Software Entwickeln, wäre 'leicht' natürlich ein Argument.

Ich denke das wichtigste ist die Erweiter- und Wartbarkeit, da viele Leute daran arbeiten werden. Die einzelnen Module sollten schon überschaubar sein.

Wie ist das eigentlich, mit Services? Ich hab überlegt, man könnte ein Interface mit PHP oder Ruby machen, und das greift dann auf die gleichen Services zu wie wenn man nen Client mit SOAP oder was auch immer macht. Ist das sinnvoll?
Die Services wären dann ja eigenständig und könnten auch individuell implementiert werden.

[boks]

Ach ja, ich vergas:
Es gehtmir hier nicht unbedingt um die Sprache, eher um die Architektur

[boks]

Ideen? Anregungen?

[DocJunioR]

Es gibt da die Schichten-Architekturen.

[Oberfläche]
[Geschäftslogik]
[Datenbasis]

Die Datenbasisschicht bildet eine Abstraktion der Datenbank, also Zugriffsfunktionen, login, etc.
Die Geschäftslogik bildet die eigentliche Bearbeitung der Daten
Die Oberfläche dient nur(!) der Anzeige, Eingabe und ggf. vorprüfung von Daten.

Die Verbindung zwischen Oberfläche und Geschäftslogik ist im Optimalfall so weit getrennt, dass man die Oberfläche ohne großen Aufwand austauschen kann.
Interessant ist das Design Pattern "Model View Controller"

Geschäftslogik- und Datenbankschicht sind gelegentlich auch ziemlich mit einander verwurstelt und gehen dann in einer Schicht auf. Nicht unbedingt designtechnisches Optimum, aber manchmal wärs sonst nen ziemlicher overhead

[Haha]

DocJunioR schrieb:

Es gibt da die Schichten-Architekturen.

[Oberfläche]
[Geschäftslogik]
[Datenbasis]

Die Datenbasisschicht bildet eine Abstraktion der Datenbank, also Zugriffsfunktionen, login, etc.
Die Geschäftslogik bildet die eigentliche Bearbeitung der Daten
Die Oberfläche dient nur(!) der Anzeige, Eingabe und ggf. vorprüfung von Daten.

Die Verbindung zwischen Oberfläche und Geschäftslogik ist im Optimalfall so weit getrennt, dass man die Oberfläche ohne großen Aufwand austauschen kann.
Interessant ist das Design Pattern "Model View Controller"

Geschäftslogik- und Datenbankschicht sind gelegentlich auch ziemlich mit einander verwurstelt und gehen dann in einer Schicht auf. Nicht unbedingt designtechnisches Optimum, aber manchmal wärs sonst nen ziemlicher overhead

Das geht schief, schau mal auf thedailywtf.com es gibt keinen business layer und alle Anwendungen die versuchen die business logic in einen eigenen layer zu bekommen wandern regelmäßig dort auf die Titelseite.

Ansonsten nehmt RubyOnRails, das gibt euch ein schönes Design vor, die Sprache und Programmierung ist nicht zu schwer, hört sich doch optimal an, oder nicht?

[Shade Of Mine]

Haha schrieb:

Ansonsten nehmt RubyOnRails, das gibt euch ein schönes Design vor, die Sprache und Programmierung ist nicht zu schwer, hört sich doch optimal an, oder nicht?

Ist Rails immer noch die Plattform der Zukunft?
Dachte diese seifenblase sei schon geplatzt...

[PRIEST]

Shade Of Mine schrieb:

Haha schrieb:

Ansonsten nehmt RubyOnRails, das gibt euch ein schönes Design vor, die Sprache und Programmierung ist nicht zu schwer, hört sich doch optimal an, oder nicht?

Ist Rails immer noch die Plattform der Zukunft?
Dachte diese seifenblase sei schon geplatzt...

is sie eig. auch ^^

[DocJunioR]

Haha schrieb:

DocJunioR schrieb:

Es gibt da die Schichten-Architekturen.

[Oberfläche]
[Geschäftslogik]
[Datenbasis]

Die Datenbasisschicht bildet eine Abstraktion der Datenbank, also Zugriffsfunktionen, login, etc.
Die Geschäftslogik bildet die eigentliche Bearbeitung der Daten
Die Oberfläche dient nur(!) der Anzeige, Eingabe und ggf. vorprüfung von Daten.

Die Verbindung zwischen Oberfläche und Geschäftslogik ist im Optimalfall so weit getrennt, dass man die Oberfläche ohne großen Aufwand austauschen kann.
Interessant ist das Design Pattern "Model View Controller"

Geschäftslogik- und Datenbankschicht sind gelegentlich auch ziemlich mit einander verwurstelt und gehen dann in einer Schicht auf. Nicht unbedingt designtechnisches Optimum, aber manchmal wärs sonst nen ziemlicher overhead

Das geht schief, schau mal auf thedailywtf.com es gibt keinen business layer und alle Anwendungen die versuchen die business logic in einen eigenen layer zu bekommen wandern regelmäßig dort auf die Titelseite.

Ansonsten nehmt RubyOnRails, das gibt euch ein schönes Design vor, die Sprache und Programmierung ist nicht zu schwer, hört sich doch optimal an, oder nicht?

Aalso ich sag mal so, die Frage war nach der Architektur. Man sollte die logische Architektur grundsätzlich von der physischen Umsetzung abstrahieren

[boks]

danke für die infos bislang.
das mit dem 3-tier dingens dacht ich mir schon so.
rails macht das mvc ja auch konsequent.
die kernanwendung soll die daten bloss holen, jobs verteilen und darstellen. dafür ist ruby wohl am ehesten geeignet, aufgrund der entwicklungsgeschwindigkeit.

meine frage ist nun weiter, wie ich am schlausten die module anspreche. aber es soll halt gut erweiterbar sein. die module selbst werden ev. in java sein, da sie zt sehr rechenintensiv ausfallen könnten. die module müssen auch nicht zwingend auf der gleichen maschine laufen. daher dachte ich an webservices. aber bin da unsicher ob REST oder SOAP besser geeignet ist, oder was ganz anderes.

hm verwirrend?

also mal ganz simpel:
user gibt daten ein.
controller guggt in der db ob resultate da sind
wenn ja, gib sie als view zurück.
wenn nein, schick die daten an die services und lass sie rechnen.
warte...
resultate da, gib sie als view zurück.

oder so ähnlich

[boks]

*püshchen*

[no one]

Was du brauchst: Client => Service architektur.

Wenn du eh auf der Suche nach einer serviceorientierten Architektur bist, solltest du dir mal den Ansatz von serviceorientierten Benutzeroberflächen anschauen.

Der Ansatz dahinter ist nicht neu (genau so wie AJAX und das Web2.0). Dennoch sehr effizient.

Das Prinzip ist folgendes (Client):
* Schreibe deine Webseite in JavaScript (möglichst komplett). MVC=>MVP Ansätze haben sich zu recht durchgesetzt. Geschäftslogik und Design sollte man trennen. Daher empfehle ich dir hier das Framework EJS (http://embeddedjs.com/)!
* Für die Kommunikation mit deinen Services (der Abstraktionsmöglichkeiten halber würde ich SOAP mit AXIS2 etc. nutzen) kannst du sehr gut JQuery (http://jquery.com/) nutzen. Dort gibt es Transformatoren mit denen du vom XML sofort zu JSON umwandeln kannst. Es gibt hier auch einige SOAP Plugins mit denen du Webservices ansprechen kannst. JSON direkt anzubieten ist leichtgewichtiger, aber nicht so kompatibel zu anderen (besonders älteren) programmiersprachen. Services solltest du über RESTful strukturierte URLs verfügbar machen.
* Das Design wie es sich gehört nicht mit Tabellen und komplett in CSS.

Jetzt ist es absolut egal, welche Logik hinter dem Service steckt. Es könnten 2 weitere Schichten aber auch 5 oder mehr Schichten mit SAP-Systemen und batching etc. sein. Der Service rettet dich hier vor der Komplexität die im Backend steckt. Auch andere Applikationen können die Services weiterhin nutzen. So kannst du Service chaining etc. betreiben. Falls du auf JavaScript verzichten möchtest, kannst du eine Applikation als Konsumenten der Services schreiben die HTML ausgibt

Das Prinzip ist folgendes (Server):
- Mit irgendeiner Bibliothek wie AXIS2, Xfire etc. bietest du SOAP services an.
- Dahinter ist es egal was passiert

Praktikabel: Das Backend mit Grails/Rails etc. schreiben. So kannst du zumindest die CRUD Aktionen in minuten implementieren. Und sparst jede Menge Code (high level abstraktion / Ausdrucksstärke).

Beispiel für AJAX Abfrage mit JQuery:

$.ajax({
  url: "test.html",
  cache: false,
  success: function(html){
    $("#results").append(html);
  }
});

Insgesamt wichtig: Eine Service Registry schreiben die alle Teammitglieder wissen lässt welche Services es gibt und was sie tun.

[boks]

hoi

sehr cool, danke dir. super!