# Unterschied Enterprise Anwendung und Web Anwendung



## Gast (8. Feb 2009)

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 (10. Feb 2009)

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


----------



## maki (10. Feb 2009)

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 (10. Feb 2009)

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 (10. Feb 2009)

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 (10. Feb 2009)

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 (10. Feb 2009)

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 (10. Feb 2009)

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 (10. Feb 2009)

Spacerat hat gesagt.:
			
		

> 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 (10. Feb 2009)

byto hat gesagt.:
			
		

> 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 (10. Feb 2009)

>> 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 (10. Feb 2009)

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


----------



## maki (10. Feb 2009)

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


----------



## Spacerat (10. Feb 2009)

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 (10. Feb 2009)

maki hat gesagt.:
			
		

> 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 (10. Feb 2009)

Spacerat hat gesagt.:
			
		

> 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 (10. Feb 2009)

> 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.



			
				Spacerat hat gesagt.:
			
		

> 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 (10. Feb 2009)

maki hat gesagt.:
			
		

> 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 (10. Feb 2009)

>> 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 (10. Feb 2009)

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 (10. Feb 2009)

Gast hat gesagt.:
			
		

> 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 (10. Feb 2009)

slawaweis hat gesagt.:
			
		

> Gast hat gesagt.:
> 
> 
> 
> ...


----------



## byte (11. Feb 2009)

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 (11. Feb 2009)

> 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 (11. Feb 2009)

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 (11. Feb 2009)

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


----------



## Ice-Tea (11. Feb 2009)

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 (11. Feb 2009)

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 (11. Feb 2009)

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 (11. Feb 2009)

Ice-Tea hat gesagt.:
			
		

> 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 (11. Feb 2009)

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:


----------

