Unwort des Jahres

Wissenschaftliche Diskussion auf Gerstensaftbasis. Alle öffentlichen Themen, die sonst nirgends dazu passen, kommen hier rein.
Benutzeravatar
Brett
Beiträge: 11101
Registriert: Mi Dez 29, 2004 1:00 pm

Beitrag von Brett » Mo Apr 12, 2010 5:58 pm

Hö?
Religion ist jetzt nicht einmal so blöd, als wie immer alle sagen.
Vita est peregrinatio.

Benutzeravatar
mastastefant
Schnapsbar
Beiträge: 3543
Registriert: Sa Dez 04, 2004 1:00 pm
Kontaktdaten:

Beitrag von mastastefant » Mo Apr 12, 2010 6:35 pm

Hrhr, Willkommen in meiner Welt :)

Auch gut: Modul, Pattern, Best Practice, und alles was mit Java Enterprise zu tun hat :)
Ein perfektes Beispiel hier ist JBoss: http://www.jboss.org/. Wers schafft, anhand der Webseite rauszufinden, was in Dreiteufelsnamen der Server tut bzw. was man damit konkret machen kann, verdient meinen Respekt :) (abgesehn davon, dass die Webseite Mist ist).

(Hab auch grad ein Paper lesen müssen, da hat einer praktisch alles als Modell mit Component und Interaction "erklärt"/reingezwängt: Differenzial/Differenzen-Glg, State-Machines, Synchrone/Async. Kommunikation, .. Weiß immer noch nicht, wozu überhaupt)

Benutzeravatar
sAik0
Beiträge: 1505
Registriert: Mo Nov 29, 2004 1:14 am
Wohnort: Klosterneuburg
Kontaktdaten:

Beitrag von sAik0 » Mo Apr 12, 2010 11:45 pm

masta_stefant hat geschrieben:Hrhr, Willkommen in meiner Welt :)

Auch gut: Modul, Pattern, Best Practice, und alles was mit Java Enterprise zu tun hat :)
Ein perfektes Beispiel hier ist JBoss: http://www.jboss.org/. Wers schafft, anhand der Webseite rauszufinden, was in Dreiteufelsnamen der Server tut bzw. was man damit konkret machen kann, verdient meinen Respekt :) (abgesehn davon, dass die Webseite Mist ist).

(Hab auch grad ein Paper lesen müssen, da hat einer praktisch alles als Modell mit Component und Interaction "erklärt"/reingezwängt: Differenzial/Differenzen-Glg, State-Machines, Synchrone/Async. Kommunikation, .. Weiß immer noch nicht, wozu überhaupt)
Also. Hier mein Verständnis kurz zusammengefasst:

1. Es handelt sich nicht um einen einzelnen server, sondern um eine Produktfamilie bestehend aus (grober Umriss):
- einen Application Server für Java Enterprise Edition Applikationen
- einen "lightweight web server" - im wesentlichen Apache Tomcat
- eine business process engine (abbildung von regeln/workflows)
- einen middleware server
- und einen portal server, der für mehrere backends ein einheitliches frontend zur spannen soll

dazu gibts grafische oberfläche, cluster managent, load balancing, transkaktionsmanagement (online/batch/forward&forget), monitoring etc. in allen komponenten

Also ziemlich genau das was die WebSphere Familie von IBM macht.

Wenn mans also im Sinne von Stacks betrachtet würde das zB so sehen:

Bitte um Auflösung bzw. Korrektur wenn ichs nicht gecheckt hab.
Scheint mir aber sogar als nicht-Elektriker einigermaßen verständlich (zumindest in meiner oberflächlichen Welt :) )

To do is to be (Karl Marx)
To be is to do (Jean Paul Sartre)
Do be do be do (Frank Sinatra)

Benutzeravatar
sAik0
Beiträge: 1505
Registriert: Mo Nov 29, 2004 1:14 am
Wohnort: Klosterneuburg
Kontaktdaten:

Beitrag von sAik0 » Di Apr 13, 2010 12:11 am

masta_stefant hat geschrieben: (Hab auch grad ein Paper lesen müssen, da hat einer praktisch alles als Modell mit Component und Interaction "erklärt"/reingezwängt: Differenzial/Differenzen-Glg, State-Machines, Synchrone/Async. Kommunikation, .. Weiß immer noch nicht, wozu überhaupt)
Ad "wozu überhaupt" verstehe ich das so:

wenn ich - sagen wir - in meiner systemlandschaft etwas mehr
als 5,000 autarke systeme habe, die miteinander kommunizieren sollen
wird es ziemlich unübersichtlich n*(n-1) (oder je nach Bedarf auch weniger) interface zu bauen, business rules / prozesse abzubilden, zu wissen wann welches system (schon) in die db schreiben darf, oder noch auf den outcome eines anderen warten muss, etc.

bei reinen lese-daten (zB reporting / controlling, konsolidierung) kann ich das ganz gut über ein data warehouse lösen in das ich alles reinstopfe

bei transaktionsdaten, die unmittelbar in den geschäftsprozessen stattfinden interagieren viele systeme of live miteinander. teilweise synchron, teilweise aysnchron.

nutzenbeispiele:
application server --> hilft standardisierte applikationsumgebungen zu schaffen und zu managen
middleware --> macht potentiell aus n*(n-1) nur mehr n interfaces (zugegeben mit vielen übersetzungen dazwischen)
portal server --> schafft für eine vielzahl von durch geschäftsprozesse betroffene systeme ein gemeinsames frontend
process engine --> definiert sämtliche business rules an einer zentralen stelle, diese sind dann nicht mehr hard-coded im system, in einzelsystemen parameterisiert, oder gar in der db

durch die entkopplung von einzelsystemen aus dem gesamtgeflecht bin ich potentiell flexibler einzelsysteme zu tauschen.
wenn ich neue business rules einführe (neuer prozess, neues produkt, neue gesetzliche rahmenbedingungen) tue ich mir auch leichter und bin daher als unternehmen agiler...

so hätte ich mir das halt erklärt.
was meinst du?

To do is to be (Karl Marx)
To be is to do (Jean Paul Sartre)
Do be do be do (Frank Sinatra)

Benutzeravatar
mastastefant
Schnapsbar
Beiträge: 3543
Registriert: Sa Dez 04, 2004 1:00 pm
Kontaktdaten:

Beitrag von mastastefant » Di Apr 13, 2010 2:08 am

Nun, das Wozu überhaupt war da speziell auf das Paper bezogen .. Ich hab echt keinen blassen Schimmer, warum ich eine differenzial-glg so beschreib, das die komponenten relationen zwischen funktionen sind, und die interaktion die funktionen selbst (so stehts im paper). Ich mein, alles richtig und schön und im prinzip das, was Simulink macht, aber ich weiß trotzdem, in dem Fall, nicht, was ich damit soll .. (Also, ich hab schon ne Ahnung, er zeigt verschiedene Modellierungsansätze, aber ich find einfach, man hat keinen Vorteil davon, es unbedingt in dieses Component/Interaction Modell zu zwängen)

Bez. Java: Ich weiß net warum, aber in Java ists einfach ganz extrem, dass da unglaubliche Komplexitätstürme aufgestapelt werden und man dann mit haufenweise Abkürzungen und schwammigen "Business Application Engine Models" usw. erschlagen wird. Das gibts in den Auswüchsen in keiner anderen mir bekannten Sprache bzw. Software-Sparte (als Java-Server-Apps).

Java ist eine hübsche Sprache, aber sie muss leider für vieles herhalten, wofür sie eigentlich nicht geeigent ist (Server, z.b., oder GUIs), leider auch deswegen, weils net wirklich eine Alternative gibt (außer C++, aber C++ ist zwar cool, aber grausig. Außerdem muss man für C++ richtig programmieren können ;) ). Eigentlich, genaugenommen finde ich, dass es für Java eigentlich kaum wirklich ein gutes Einsatzgebiet gibt.. (primär wegen den miesen Resource-Management der normalen VMs)

Bez. dem Rest:
- Application Server: ich weiß ehrlichgestanden nicht genau, was da der unterschied zwischen Application Server und Middleware genau ist, bzw. was der Application-Server jetzt im gegensatz zur Middleware zum Appliation server macht (genau das fehlt mir eben auf der homepage. Kann doch nicht so schwer sein, das in einem satz zu sagen, ohne die worte Business, Enterprise oder Model zu verwenden .. ).
Im prinzip denk ich aber auch, dass das ein Ding/Framework ist, das 'common tasks/libraries' zum 'richtige' Application-server baun ist (also etwas, das eine application per server bereitstellt).
- Middleware: meines verständisses ein Layer zwischen ganz unten (dem nackten Server), und der anwendungs-spez. Applikation (deswegen "middle"), der anwendungs-unspezifisch wiederum common-tasks wie Datenbank, konfiguration, .. per API zur Verfügung stellt, die App kann dann die API verwenden (ist aber wohl sicher Middleware-spezifisch, also eine JBoss-App, nicht eine 'Java-JSR-irgendwas-API', soweit ich das verstehe).
- Portal-Server: Da versteh ich einen Webserver drunter, der ein Web-Portal bereitstellt (zumindest, weil ich das früher mal programmiert hab .. ), kann aber auch das sein, was du meinst, weiß nicht genau. Was das Portal vom reinen Webserver unterscheidet ist, dass es Web-Applikationen drin gibt, die (User-Spezifisch) irgendeine interaktive Funktionalität bereitstellen. Wird normalerweise als Portlet pro App gebaut, da gibts nen Java JSR standard, aber der is so oberflächlich in wirklichkeit, dass die App dann erst wieder Portal-Server-Spezifisch ist, oder grottenhässlich aussieht und nix kann.
- Webserver: Da steht 'lightweight' auf der Webseite :) Wenn ein Java server alles ist, eins ist er sicher nicht: lightweigt :D
- Process Engine: Jo. Im prinzip halt einfach 'Steuerlogik', das is das woran ich als Techniker denk. Bei Java und Software-Engineering sagt man dann Business Rule dazu ;)

=> Application Server und co. erleichtern mir primär die Aufgabe, weil sie mir nen Haufen Standard-Funktionen fix fertig bereit stellen und mit massig 'Zusatz-Features' daherkommen (wie Diagnose-tools, Editoren, ..). Quasi gratis dazu bekomm ich zwangsweise ein modulareres Design verordnet, weil ich statt einem großen Ding jetzt viele kleine Plugins für den App-Server bau, die alle mit dem App-Server statt untereinander interagieren (im Idealfall .... ).

=> Flexibilität kommt allerdings eher durch gute Standards als durch Frameworks. Eine JBoss-Business-Logic-Komponente wird man denk ich nicht mal so eben in Websphere zum Laufen bringen, außer man baut intern einen 'Framework-Abstraction-Layer' ein.
Standard-Interfaces bedeuten eben, dass ich 1) keine Zusatz-Schmankerl übers Interface bieten kann, die andere nicht haben, und 2) ich meistens Performance verlier, weil das Interface nicht zu meinem Datenfluss und -format passt.
Deswegen gibts nur sehr selten gute Standard-Interfaces, und jeder Hersteller macht was eigenes -> siehe OpenDocument Format Theorie und Praxis. Dadurch wird man trotz interfaces und partitionierung in Komponenten letztlich trotzdem wieder an ein Framework/Software/.. gebunden.
Und flexibel bin ich natürlich, wenn ich mein Design nicht als einen monolitischen Klumpen plane, sondern gut partitioniere :)

=> Ein System wird natürlich viel überschaubarer und billiger, wenn man Interaktionen geregelt (z.b. über einen Monitor, der mir die geshareten Resourcen verwaltet, oder einen gemeinsamen Connector, der die div. Formate umkonvertiert) statt kreuz und quer ablaufen lässt :) Ist letztlich eine Frage der Selbst-Disziplin beim Design, ob man viele Legacy-Systeme zamintegrieren muss, und wie parallel/ausfallsicher/verteilt man das ganze ablaufen lassen will/muss.

Benutzeravatar
sAik0
Beiträge: 1505
Registriert: Mo Nov 29, 2004 1:14 am
Wohnort: Klosterneuburg
Kontaktdaten:

Beitrag von sAik0 » Di Apr 13, 2010 8:51 am

masta_stefant hat geschrieben: => Ein System wird natürlich viel überschaubarer und billiger, wenn man Interaktionen geregelt (z.b. über einen Monitor, der mir die geshareten Resourcen verwaltet, oder einen gemeinsamen Connector, der die div. Formate umkonvertiert) statt kreuz und quer ablaufen lässt :) Ist letztlich eine Frage der Selbst-Disziplin beim Design, ob man viele Legacy-Systeme zamintegrieren muss, und wie parallel/ausfallsicher/verteilt man das ganze ablaufen lassen will/muss.
Sowas rechnen die Kollegen gegenüber meines Schreibtisches für unsere Kunden aus :)

Selbst-Disziplin:
Gibts ned. Zumindest nicht in den Unternehmen die ich kennengelernt habe.
Da stehen immer kurzfristige Interessen (vergleichsweise schnelle und preislich verträgliche Umsetzung eines Vorhabens) vs. "saubere" Lösung die meistens länger dauert (=teurer, weil viele Projektressourcen von durchlaufzeit getrieben sind) und komplexer (höherer Integrationsaufwand, Entwicklungsaufwand).
Das geht meistens so lange, bis Betrieb, Betreuung, Wartung und Weiterentwicklung eines Gesamtsystems so komplex und teuer werden, dass man wieder mal 5-10 mEUR in die Hand nimmt und eine neue Zielarchitektur baut und die Hütte in einem 2-3jährigen Programm transformiert.

To do is to be (Karl Marx)
To be is to do (Jean Paul Sartre)
Do be do be do (Frank Sinatra)

Benutzeravatar
Brett
Beiträge: 11101
Registriert: Mi Dez 29, 2004 1:00 pm

Beitrag von Brett » Di Apr 13, 2010 3:53 pm

masta_stefant hat geschrieben:Ich weiß net warum, aber in Java ists einfach ganz extrem, dass da unglaubliche Komplexitätstürme aufgestapelt werden und man dann mit haufenweise Abkürzungen und schwammigen "Business Application Engine Models" usw. erschlagen wird.
Ich glaub, dir fehlt einfach ein gscheiter Java-Kurs (siehe Bilderwitz im Anhang) :)

Das Problem ist einfach, dass manche Leute noch recht drauf stehn, wenn jeder Mist durchgebranded und abstrahiert wird. Da gehts wohl einfach nur drum, Schulungen teuer verkaufen zu können. Kann ich mir kaum vorstellen, dass die Summen-Funktionalität nicht auch mit einem Viertel der Geschwüre zu erreichen wäre ... abturnend, sowas.
Dateianhänge
DSC00482.jpg
Religion ist jetzt nicht einmal so blöd, als wie immer alle sagen.
Vita est peregrinatio.

Benutzeravatar
mastastefant
Schnapsbar
Beiträge: 3543
Registriert: Sa Dez 04, 2004 1:00 pm
Kontaktdaten:

Beitrag von mastastefant » Di Apr 13, 2010 4:28 pm

Hrhr.. Bez. Selbstdisziplin: Meine volle Zustimmung, kenn ich genau so aus eigener Erfahrung. :)

Ganz gefährlich sind auch Prototypen.. Normalerweise sollte man von einem Design, wenn man noch keine Erfahrung mit so was hat (und das is quasi die Definition von "Projekt"), einen schnellen Prototypen erstellen, wegschmeißen, sauber richtig baun. Meistens landet der Prototyp dann gleich in der finalen Version, und dann wird gehackt und gepatcht :)

Oder wenn man versucht, zuviel in ein einziges System reinzupacken, ohne eine klare Grenze zu ziehen, was das Ding können soll, und v.a. wofür es nicht mehr zuständig ist. Erfahrungsgemäß, wenn man das in einem Satz sagen kann, dann hat mans meist mit einem übersichtlichen, schönen System zu tun, ansonsten wirds gefährlich ;)

Ein sauberes Design hat allerdings manchmal vllt. gar nicht so viel Nutzen für den Hersteller, muss man fairerweise sagen, denn wenn man sich eine ganz tolle, saubere, riesige Architektur für etwas ausdenkt, die dann Generationen halten soll, kommt man dann spätestens bei der 2. Erweiterung drauf, dass was grundlegendes fehlt, und man kann erst wieder zu patchen anfangen oder gleich neu anfangen. In der hinsicht sind gewachsene Strukturen einem Top-Down-Ansatz oft weit überlegen, sofern sie zumindest irgendwelche Methoden/Maßnahmen/Möglichkeiten drin haben, die Komplexität durch Partitionierung/zentrale Schnittstellen/.. beim Wachsen in Grenzen zu halten (klassisches Beispiel ist hier immer das Internet mit der IP-Protokoll-Familie).
Und wenn man auf ein bestehendes Legacy-System aufbauen muss, das irgendwer vor langer Zeit zamgebaut hat und schon viele Jahre auf dem Buckel hat, hat man sowieso verloren (ein Prof hat mal erzählt, dass in den USA bei einem Flughafen die Software, die den halben Flugleitsystem regelt auf irgendeinem Uralt-Mainframe läuft, und keiner traut sich da was angreifen, weil keiner mehr da ist der sich damit auskennt..).

Allerdings bringt ein sauberes Design natürlich viel für den User, weils leichter zu verstehen ist, und z.B. immer den selben Ablauf für verschiedene Tasks hat weil auch immer der selbe Code dahinter steht. Wenn man Features dazubaut, kann man die gleich an viel mehr Stellen verwenden, statt nur dort, wo mans eingebaut hat. Das kann allerdings auch ein Nachteil sein, wenn das Feature Bugs hat :)

Ein wirklicher Killer ist ein schlechtes Design allerdings dann, wenns darum geht, zu zeigen dass das System zuverlässig ist, bzw. zertifiziert werden muss. Für ein zusammengefrickeltes System erst im Nachhinein, wenns fertig ist, zu zeigen, dass es auch sicher ist, kann schon mal ein Vielfaches von den ganzen Entwicklungskosten ausmachen, bzw. einfach unmöglich sein.

In der Praxis wird da allerdings auch oft nur mit Wasser gekocht, was Zertifizierng betrifft:
http://www.it-tuv.com/internet-explorer
Sicher ists, weil man den Quellcode nicht kennt und weils Updates gibt :)
(Fairerweise muss man sagen, dass man bei Firefox zwar den Code kennt, aber das Ding aufgrund der Art der Entwicklung wohl nie zertifiziert werden wird, und das vllt. auch zu Recht).

Benutzeravatar
mastastefant
Schnapsbar
Beiträge: 3543
Registriert: Sa Dez 04, 2004 1:00 pm
Kontaktdaten:

Beitrag von mastastefant » Di Apr 13, 2010 4:53 pm

@Brett: Da gabs vor kurzem einen Artikel:
http://www.heise.de/ix/artikel/Direktei ... 58569.html
Ist ein Paradebeispiel dafür.

Der Kommentar dazu hats gut auf den Punkt gebracht:
http://blog.fefe.de/?ts=b5546b0c
Ein einziges Buzzword-Bingo mit Begriffen wie "Dependency Injection" und Referenzen auf weitere Pseudotechnologien wie JSF, EJB und JSR. Früher gab es mal die Entschuldigung für dieses jugendliche Fehlverhalten, dass man so prima Risikokapitalisten ins Koma schwafeln konnte, bis sie einem Geld geben.

:)

(Im Prinzip gehts darum, dass man Funktionsaufrufe umbiegt, ohne dass der Caller oder der Callee was mitbekommt davon, um bei jedem Aufruf zusätzlich/stattdessen anderen Code auszuführen, ohne den Original-Code zu ändern bzw. das explizit unterstützen zu müssen.
1) Nachdem das Java nicht kann, baut mans jetzt hintenrum über XML und ausführbare Kommentare ein. Das ist ansich schon schrecklich genug.
2) Das Prinzip an sich ist natürlich furchtbar, weil man am Code nicht mehr erkennt, was dann zur Laufzeit passieren wird, und man an einer ganz anderen Stelle das Verhalten von Code ändern kann, ohne dass die Stellen sichtbar einen Zusammenhang haben. Kann sich jeder selber überlegen, ob das wirklich keine Seiteneffekte hat, und wie lustig Bugs fixen ist :) )

Benutzeravatar
Brett
Beiträge: 11101
Registriert: Mi Dez 29, 2004 1:00 pm

Beitrag von Brett » Mi Apr 14, 2010 9:59 am

masta_stefant hat geschrieben:ein Prof hat mal erzählt, dass in den USA bei einem Flughafen die Software, die den halben Flugleitsystem regelt auf irgendeinem Uralt-Mainframe läuft, und keiner traut sich da was angreifen, weil keiner mehr da ist der sich damit auskennt..
Geil. Dieser Mainframe wird noch über Jahrhunderte, weil "unberührbar", stehen bleiben. Bis keiner mehr weiß, was das überhaupt ist und wohers kommt und er schließlich den Status eines genialen Leonardo da Vinci Werks erreicht. :cat: ;)

Na, im Ernst: Eine komplexe Technologie mit Ablaufdatum hat wohl fast so etwas Erhabenes wie ein kreatives Genie. :)
Die 1980er bis 2000er Jahre werden noch sowas von verflucht werden - weiteren Entwicklungen blick ich wechselweise ge- und entspannt entgegen. Eine massive, globale Back-to-Basics Strömung innerhalb der nächsten Jahrzehnte erwart ich allenfalls (für die Industrienationen).
Religion ist jetzt nicht einmal so blöd, als wie immer alle sagen.
Vita est peregrinatio.

Antworten