Unterschied Enterprise Anwendung und Web Anwendung

[Gast]

Moin,

Was ist eigentlich der Unterschied zwischen einer Enterprise Applikation und einer Web Applikation?
Kann man sagen, das eine Web Applikation nur aus Servlets, jsp und JSTL besteht, Enterprise Applikation dazu noch aus EJB, Persistenz API, Datenbank usw.???

 

[Guest]

Gibt es einen Unterschied oder ist die Frage zu blöd?

 

[maki]

zu blöd..

.. deswegen, weil du durch ein bisschen suchen dir die Frage hättest selbst beantworten können bzw. sinnvoller (=weniger allgemein) hättest stellen können.

 

[Guest]

Ganz versteh ich die NICHT- Präzision meiner Frage nicht, in der IDE NetBeans wird zwischen diesen beiden Projekttypen unterschieden und deshalb diese Frage.
Stimmt das ca. was ich oben als Unterschied angegeben habe?

Beste Grüße,

 

[maki]

NetBeans ist eine IDE, sonst nix.
JEE wird nicht anhand der IDEs festgelegt.

Nein, was du da geschrieben hast stimmt nicht.

Willst du wissen was der Unterschied ist zwischen einem Netbeans Enterprise Projekt und einem Netbeans Webprojekt?

 

[byte]

Ein Webprojekt wird für gewöhnlich als WAR-File auf einem Servlet Container deployed, während ein JEE Projekt als EAR-File auf einem JEE-ApplicationServer deployed wird.

Grundsätzlich halte ich die Benennung aber etwas unglücklich, weil die Servlet-Spezifikation auch Teil von JEE ist. Häufig wird Webanwendung wohl synonym für Anwendungen mit Web-Frontend (also Thin Clients im Browser) genommen. Allerdings kann man auch problemlos Servlets benutzen, um Dienste für Rich Clients (z.B. Swing Clients) bereit zu stellen.

 

[Spacerat]

Aha... Und diese "EAR"-Archive laufen dann auch z.B. auf Tomcat... Klar.
Neee... Der Gast hat dem zufolge mehr oder weniger doch recht. Natürlich greift eine J2EE Anwendung noch auf andere Dinge zu als so eine simple Web-Anwendung. Wenn ich z.B. eine Web-Anwendung mit MySQL-JDBC entwickle, müsste ich die Datenbank-Anbindung stets mit deployen. Bei einer J2EE-Anwendung muss ich das nicht.

mfg Spacerat

 

[ARadauer]

so blöd ist die frage gar nicht, zumal sich "JEE" schon lange zu einer marketing Floskel entwickelt hat, die mal gerne einfach ohne grund von einem Manager auf den Tisch geworfen wird....

war vs ear? wie das zip file jetzt hießt ist doch schon ganz egal, oder?

app server vs servlet container? naja ich weiß nicht... wenn ich nun eine fette anwendung mit spring realisiere, hibernate im hintergrund, rmi zur client server kommunikation und ein paar webservices zur anbindung von lagency systemen .. wie nenn ich sowas, nicht jee? nur weil ich keinen app server oder tomcat benutze?


meiner meinung nach beschreibt jee einfach eine plattform die aus einen haufen untersschiedlicher technologien besteht... wenn ich ein paar davon einsetze kann ich das ruhit ein j2ee projekt nenne...

zur netbeans frage... keine ahnung ;-)

 

[byte]

Aha... Und diese "EAR"-Archive laufen dann auch z.B. auf Tomcat... Klar.

Beziehst du dich jetzt auf meinen Post? Das habe ich nie geschrieben...

Natürlich greift eine J2EE Anwendung noch auf andere Dinge zu als so eine simple Web-Anwendung.

Und wie definierst Du JEE- bzw. Web-Anwendung?

Wenn ich z.B. eine Web-Anwendung mit MySQL-JDBC entwickle, müsste ich die Datenbank-Anbindung stets mit deployen. Bei einer J2EE-Anwendung muss ich das nicht.

Kannst Du das mal genauer ausführen, was Du meinst?

 

[Spacerat]

Kannst Du das mal genauer ausführen, was Du meinst?

Klar kann ich. Will nur Sagen, das der Gast mit seiner Annahme gar nicht so daneben liegt. Eine reine Web-Anwendung die z.B. auf einem reinen Tomcat laufen soll darf ausschliesslich das Servlet- und JSP-API verwenden. Da ist nicht mal 'ne Datenbank-Anbindung (ausser JDBC->ODBC Bridge, wofür ebenfalls noch Treiber installiert werden müssen) vorhanden. Bei J2EE muss man sich darüber jedoch relativ wenig Gedanken machen. Der Unterschied zwischen den beiden ist also sehr wohl das Fehlen oder Vorhandensein zusätzlicher APIs. Ganz wie es der Gast schon ausgeführt hat.

mfg Spacerat

 

[maki]

>> Der Unterschied zwischen den beiden ist also sehr wohl das Fehlen oder Vorhandensein zusätzlicher APIs. Ganz wie es der Gast schon ausgeführt hat.

Das ist doch komplett daneben ; )

JPA (inkl. Hibernate oder TopLink oder...), JTA etc. pp. lassen sich von Tomcat aus nutzen.
Das einzige was auf dem Tomcat fehlt sind EJBs.

Servlets und JSP sind Teil der JEE spek, genaugenommen sind Webanwendungen schon JEE.

 

[byte]

Selbst EJB ist auf Servlet Containern möglich: http://openejb.apache.org/tomcat.html

 

[maki]

Ok, dann die eben auch... es wird zunehmend schwieriger die Unterschiede zu erklären

 

[Spacerat]

Und deswegen ist meine Aussage soooo daneben? Das man die APIs unter Tomcat nutzen kann ist Klar. Aber sie sind dort standardmässig nicht vorhanden. Und genau das macht J2EE aus.

mfg Spacerat

 

[byte]

Ok, dann die eben auch... es wird zunehmend schwieriger die Unterschiede zu erklären

Und selbst den Servlet Container kann man als einfache Jar-Datei embedden. Die Jetty-Jar ist grade mal ~400kB groß.

Es ist halt einfach falsch, JEE mit riesigen Applicationserver-Bollwerken mit viel Magie unter der Haube gleichzusetzen. Da ist nicht viel Magisches hinter JEE. Es sind einfach nur haufenweise Interfaces spezifiziert, die andere implementieren.

 

[byte]

Das man die APIs unter Tomcat nutzen kann ist Klar. Aber sie sind dort standardmässig nicht vorhanden. Und genau das macht J2EE aus.

Noch ist das richtig. Ein JEE Applicationserver muss die volle JEE-Spezifikation implementieren. Aber die Praxis zeigt schon lange, dass das häufig nicht gewollt ist. Was will ich mit einem dicken Applicationserver, wenn ich nur 10% der Features nutze?
Und genau deswegen geht der Trend mit den JEE 6 Profiles weg von diesem "One Size Fits All" Prinzip.

 

[maki]

Und selbst den Servlet Container kann man als einfache Jar-Datei embedden. Die Jetty-Jar ist grade mal ~400kB groß.

Es ist halt einfach falsch, JEE mit riesigen Applicationserver-Bollwerken mit viel Magie unter der Haube gleichzusetzen. Da ist nicht viel Magisches hinter JEE. Es sind einfach nur haufenweise Interfaces spezifiziert, die andere implementieren. icon_cool.gif

Schon klar byto, hab ja auch nix anderes behauptet, wie gesagt: JSPs und Servlets sind auch schonTeil von JEE.

Und deswegen ist meine Aussage soooo daneben? Das man die APIs unter Tomcat nutzen kann ist Klar. Aber sie sind dort standardmässig nicht vorhanden. Und genau das macht J2EE aus.

mfg Spacerat

Naja, voll daneben war das Beispiel mit ODBC

Tomcat bietet doch seit Urzeiten die Möglichekit, JDBC DataSources zu verwalten und per JNDI erreichbar zu machen.

 

[Spacerat]

Tomcat bietet doch seit Urzeiten die Möglichekit, JDBC DataSources zu verwalten und per JNDI erreichbar zu machen.

Beides aber nicht Bestandteil von Tomcat selbst, es muss hinzu installiert werden. Die JDBC->ODBC Bridge ist dagegen bei jeder standard JRE dabei (obwohl... bei älteren JREs unterhalb 1.3 bin ich nicht sicher).

mfg Spacerat

 

[maki]

>> Beides aber nicht Bestandteil von Tomcat selbst, es muss hinzu installiert werden.

Ähh.. nicht wirklich.

Falls du die JDBC Treiber meinst, du muss man natürlich selbst mitbringen (Lizenzrechtlich), aber die JNDI Konfig ist schon drinnen, nur auskommentiert.

User per LDAP oder JDBC zu authentifizieren und authorisieren (JAAS) ist auch shcon dabei.

 

[didjitalist]

das J2EE framework macht nich eine enterprise application aus, es ist spezifiziert worden, um den anforderung von enterprise applications zu entsprechen.

in enterprise applications ist die einzig wichtige frage, wie verteilte systeme miteinander agieren können. transaktionelle sicherheit und co. sind dabei die je nach anforderung wichtigen teilaspekte.

 

[slawaweis]

Was ist eigentlich der Unterschied zwischen einer Enterprise Applikation und einer Web Applikation?
Kann man sagen, das eine Web Applikation nur aus Servlets, jsp und JSTL besteht, Enterprise Applikation dazu noch aus EJB, Persistenz API, Datenbank usw.???

der Unterschied zwischen einer Web Applikation und einer Enterprise Applikation liegt nicht in der Technologie, sondern in der Logistik. Manche würden vielleicht auch ergänzen "in der Psychologie". Mal ein Wikipedia Artikel:

http://en.wikipedia.org/wiki/Enterprise_software

Bei der Enterprise Software geht es primär nicht um Technik, sondern um Kosten & Nutzen. Wenn eine Firma eine neue Software anschaffen will, dann will sie vor allem ihre Geschäftsprozesse darauf abbilden oder optimieren. Dabei spielt natürlich eine Rolle, wie hoch die Anschaffungs- und Wartungskosten sein werden. Enterprise Software muss ein paar Kriterien erfühlen, für die dann jemand gerade steht soll. Erstmals muss Zuverlässigkeit in einem bestimmten Maß garantiert werden. Dann sollte man für die Wartung nicht den Betrieb lahm legen sollen. Weiterentwicklungen der Geschäftsprozesse (oder die regelmäßigen Experimente der Geschäftsleitung) müssen leicht und kostengünstig mit der Enterprise Software zu machen sein, ohne das der restliche Ablauf davon betroffen oder behindert wird.

Nehmen wir als Beispiel Amazon. Da greifen jede Sekunde Tausende von Kunden zu, rund um die Uhr, 24/7, auf der ganzen Welt. Da kann man nicht wegen einer Wartung für ein paar Minuten die Webserver abstellen oder gar neustarten. Wenn man das macht, dann ist man am nächsten Tag in der Zeitung, auf der ersten Seite mit Foto. Auch wenn Amazon z.B. neue Techniken in ihren Webshop integriert, darf man nicht einfach alles stilllegen. Auch falls ein paar Server abrauchen, darf der Kunde das nicht merken, entweder bei Einkauf, noch auf der Rechnung.

So sind "Enterprise Applikationen" nichts anderes als "Web Applikation". Es kommt aber auf die Verwendung an, den Enterprise Applikationen dürfen in der Geschäftsdurchführung nicht versagen, mit Garantie. Mit Technologie hat das wenig zu tun, den Enterprise Applikationen erfordern, abhängig von der Größe, einen Stab von Technikern, die es rund um die Uhr pflegen.

Das in der Welt der Technologien und IDE's sich Schlagwörter wie J2EE gebildet haben, ist nur ein Nebeneffekt bzw. Marketing. Damit preisen manche Hersteller ihre Produkte als "Enterprise-tauglich" aus, d.h. in realen Geschäftsprozessen verwendbar, mit bestimmten Garantien. Doch vor allem muss man sich mit den jeweiligen Technologien auskennen, denn dann wäre es egal, was man in der IDE auswählt.

Slawa

 

[Ice-Tea]

..."in der Psychologie". ...

Da stimme ich zu, der rest verfehlt schon fast das Thema:

Der große unterschied bei App-Servern ist ihre modularität.

Man muss nicht das gesammte Projekt deployen, was bei projekten spätestens ab größen von > 25MB auch nicht mehr viel Spass mach (schon alleine wegen den uploadzeiten).

Bei (Netbeans-) Enterprise-Projekten bekommst du diese Modularität gleich in die Hand gegeben, wärend du in (Netbeans-)Webprojekten 'alles in einer datei' hast.

Rein theoretisch ist ein (Netbeans-)Webproject, sofern es alle J2EE-Specs erfüllt, auch ein Einterprise.Project. Jedoch wird dies nur durch riesen-WAR-Dateien erkauft.

An alle nicht-Netbeans'er: Die riesendateien müssen natürlich nicht sein, aber das zu erläutern verfehlt ebenso das Thema.

Wie mein Vorredner schon sagte, die Psychologie bzw. Philosophie ist eine andere:

Entweder Modular und kleine Dateien

oder

J2EE-Specs (für einen Webcontainer) erkaufen und Riesendateien

 

[byte]

Ich würde den Unterschied nicht umbedingt anhand der Modularität ausmachen. Es gibt längst OSGi Serverlösungen auf Basis von Servlet Containern, die wesentlich modularer sind als jede JEE-Plattform. Siehe z.B. SpringSource DM Server.

 

[maki]

Ich würde den Unterschied nicht umbedingt anhand der Modularität ausmachen.

Sehe ich genauso.

Es gibt längst OSGi Serverlösungen auf Basis von Servlet Containern, die wesentlich modularer sind als jede JEE-Plattform.

..noch ein dito, und mit Maven2 als Build Tool sogar noch "modularer" als es eine IDE leisten könnte.

An alle nicht-Netbeans'er: Die riesendateien müssen natürlich nicht sein, aber das zu erläutern verfehlt ebenso das Thema.

Ach...

 

[Ice-Tea]

Innerhalb der Netbeans-IDE und vorallem für ein anfägerauge ist es aber Modularer!

Da ich schwer davon ausgehe das der Gast der die Frage gestellt hat, sich auf Netbeans bezieht, verfehlt auch ihr das Thema.

Das nächste mal werd ich zusätzlich diesen Satz einfüren: (Sry, das ich nicht immer gleich an alle denke)
An alle nicht-Netbeans'er: Die Modularität lässt sich auch anders erreichen....


Ich selber habe lange Zeit in PHP gearbeitet.
Und von wegen ohne IDE gibts keine Modularität: Mein Werkzeug ist bei php-Programmen immernoch Putty bzw. ein Editor plus FTP.
Und das sich sogar ein PHP-Programm an Modulare Strukturen halten kann, sieht man sehr schön an TYPO3!


Nochmal, es handelt sich bei meiner Ausführung um eine Philosophie der Netbeans-IDE, nichts weiter.

 

[byte]

Was ist denn an einem EAR File modularer als an einem WAR File?

 

[Ice-Tea]

Nichts, darum gehts ja.

Es ist nur ein Hilfestellung von Netbeans um dem Benutzer das leben leichter zu machen. Und vorallem Anfänger profitieren von diesen Features.

Mir persönlich ist es mitlerweile (fast) egal ob der Projektbaum mit einer "Enterprise Appl." anfängt und ne menge EJB's einbindet. Oder ob ich mir eine Webapp erstelle und die Jars als Bibliotheken mitgebe.

Jedoch bleibt der Vorteil, das man bei einem echten app-Server EJB Module nachladen bzw. einzelnd ersetzten kann. Damit meine ich jetzt nicht die EJB, die innerhalb der EAR steckt.
Es wäre mir neu, das man mit Tomcat eine Bibliothek (EJB) auf die 2 Verschiedene Webprojekte zugreifen deployen kann.
Soll heißen:
2 WAR's greifen auf eine EJB zu.

Das nenne ich Modular und vorallem Wiederverwendung von Code. Soweit wie ich weiß (korrigier mich wenn ich falsch liege) müsste ich bei Tomcat bzw. einem Webcontainer entweder ne Menge Bibliotheken mitgeben um ihn erstmal auf den stand eines App-Servers zu bringen oder ich müsste die Bibliotheks-EJB mehrfach deployen.

 

[maki]

Sieh es mal so Ice-Tea, ohne EJB und JEE AppServer, dafür mit OSGi:

Eine WebApp kann jederzeit Module/Jars (Bundles) nachladen, Updaten, Starten/Stoppen, der ganze WebServer kann als OSGi Bundle laufen, oder eben nur die Webanwendung & Module/Jars (Bundles) an sich.
Der Webserver ist geclustert.

Dafür braucht man kein EJB bzw. keinen JEE Appserver.

Enterprise oder nicht?
Modular oder nicht?

 

[Ice-Tea]

Das ist mit Sicherheit 'Enterprise'.
Nur basiert es nicht auf der Referenz-Inplementierung (von der Netbeans lebt).

Ich finde das Wort Enterprise grob gesehen sowieso ziehmlich daneben. Es ist halt ein Marketing-Schlagwort.

 

[maki]

Das ist mit Sicherheit 'Enterprise'.
Nur basiert es nicht auf der Referenz-Inplementierung (von der Netbeans lebt).

Naja, mit Netbeans geht viel, zB. finde ich die Maven Integration in Netbeans 'ne spur besser (&schneller) als in Eclipse.

Ich finde das Wort Enterprise grob gesehen sowieso ziehmlich daneben. Es ist halt ein Marketing-Schlagwort.

Ja, hat slawaweis imho noch am besten dargestellt.

Ist halt schwer mittlerweile die Unterschiede zu erklären, viel zu viele Möglichekiten/Alternativen.
Da es dem TS wohl um Netbeans ging, denke dass ihm deine Antwort wohl am meisten hilft.

 

[Ice-Tea]

Nach den vielen Antworten tut jetzt eine mehr auch nichts mehr zur sache.

Ist halt schwer mittlerweile die Unterschiede zu erklären, viel zu viele Möglichekiten/Alternativen.

Das lässt sich sehr schön in Mathe abstraieren:

Wenn 1 = Enterprise ist, wie erreiche ich die 1?

2-1= 1
1000-999= 1
(-5*5)²-624= 1

Was ist nun Enterprise :lol: