.NET – vs. EJB

Question

Was ist die vergleichbare Technologie von EJB (Enterprise Java Beans) in .net?

Answer 1

WCF in .NET 3.5 ist das ähnlich, solange Sie nicht CMP zu verwenden versuchen. Während es Service-Endpunkte für SOAP-Typ Dinge erlaubt, erlaubt es auch binäre Remote.

Answer 2

Die Definition von Begriffen ist wichtig

Bei Vergleichen ist die Definition der Begriffe wichtig.EJB ist ein Komponentenmodell.Er definiert Persistenz, Transaktionen, Remoting, Aktivierung und Sicherheitsfunktionen (und möglicherweise andere) für Komponenten, die innerhalb von des Behälters.

Sie können sich vergleichbare Technologien in .NET ansehen, wenn Sie das sind after - die technischen Möglichkeiten des Komponentenmodells.

Auf der anderen Seite verwenden einige Leute "EJB" als Begriff, auf den man sich locker bezieht J2EE (oder Java EE?).In diesem Fall bezieht es sich nicht Nur zu einem Komponentenmodell, aber zu einer Reihe verwandter Java-Technologien, die in der Regel mit serverseitigen Anwendungen, einschließlich eines Komponentenmodells.Dies kann sogar Toolsets umfassen, die natürlich nur tangential mit dem Komponentenmodell in Verbindung stehen.Wenn Das ist die Vergleich, dann wird es treffender als "J2EE vs..NETZ".

Wieder andere Leute verwenden vielleicht eine noch unschärfere Definition für EJB, um z. B. Web-Service-Funktionen, REST/XML-Kommunikation oder andere Dinge, die streng außerhalb von Java EE oder EJB liegen.Mit anderen Worten: Wenn sie sagen „Vergleiche EJB mit .NET“, meinen sie in Wirklichkeit einen Vergleich zwischen „serverseitigen Java-Plattformen und serverseitigem .NET“.Letzteres scheint mir ein viel praktischerer Vergleich zu sein, als beispielsweise der Vergleich von Komponentenmodellen.

Bei den Vergleichen ist es wichtig, sich darüber im Klaren zu sein, was genau verglichen wird.

EJB – das Komponentenmodell

In EJB definieren Sie ein Objekt und markieren es als Session-Bean oder Entity Bohne.Es gibt auch die späte Hinzufügung von Message Driven Bean.Drei Aromen der Komponente in EJB.Die Session Bean wird aktiviert - wie sie funktioniert wird in Zeiten hoher Ressourcen in Gang gesetzt und ggf. "passiviert" Konflikt auf dem Server/Container.Der SB bekommt auch Sicherheit und Remotingdienste.

Die Grundidee besteht darin, ein Objekt zu definieren und ihm dann Attribute zuzuordnen. entweder über den Implementierungsdeskriptor oder über In-Code-Attribute, das Analogon, für das es heißt: Anmerkungen in Java.

Am nächsten kommt einem EJB-Session-Bean ein .NET-Objekt.In jedem .NET können Sie ein Objekt mit Transaktionsattributen markieren, einfach wie eine EJB SB.Wenn Sie möchten, können Sie es mit .NET remotefähig machen Remoting und weitere Attribute.Außerhalb von COM+ gibt es keine Passivierungstechnologie in .NETTO;.NET ignoriert einfach Pooling als eine allgemein interessante Sache, mit der man tun kann In-Memory-Objekte, und daher gibt es keinen Ansatz für die Aktivierung/Passivierung in .NET wie bei EJB.

---

Seitenleiste Nr. 1:das stimmt nicht ganz.In .NET bietet die Workflow-Funktion die Möglichkeit, lang laufende Aktivitäten durchzuführen, die passiviert und erneut aktiviert werden können und werden.Aber Workflow ist eine andere Metapher als „serverseitige Objekte“ oder „Dienste“, die den Mittelpunkt der meisten serverseitigen Anwendungsarchitekturen bilden, die .NET verwenden.

---

Seitenleiste #2:Früher dachten die Entwickler serverseitiger Plattformen, dass jeder das Objekt-Pooling nutzen möchte, um effizienter zu sein.Nun stellt sich heraus, dass JVM und .NET CLR schnell genug Objekte erstellen und genügend Speicher vorhanden ist, sodass Objekt-Pooling im Allgemeinen keinen praktischen Nutzen hat.Für den allgemeinen Fall ist es nicht mehr interessant, obwohl es sich für teure Objekte wie Datenbankverbindungen immer noch lohnt.

---

Wie bei EJB können Sie auch in .NET -Attribute zu einem Objekt hinzufügen, damit es basierend auf der Identität des Anrufers oder andere "Beweise".

Entity Beans sind ein anderes Tier.Während Persistenz und Remoting in den meisten praktischen Ratgebern zusammengefasst werden, lautet die Empfehlung, dass ein Entity Bean macht keine Remote-Schnittstelle verfügbar.Stattdessen wird in der Empfehlung eine Session-Bean, um eine Entity-Bean aufzurufen.Betrachten wir also EB's einfach als persistente Objekte.

In .NET gibt es hier eine Reihe von Alternativen.LINQ-to-SQL bietet eine Option - mit ORM- und Persistenzdiensten.Die ADO.NET Entität Framework ist vielleicht eine vergleichbarere Technologie.Natürlich sind alle anderen Dienste in .NET - Transaktionen, Sicherheit und Remoting usw. - können auch wird auf Objekte angewendet, die ADO.NET Entity Framework oder LINQ verwenden.

Auf der anderen Seite, je nachdem, wo Ihr Schwerpunkt in der EJB liegt Umbrella gibt es möglicherweise bessere Vergleiche.Wenn Sie EJB hauptsächlich für Remoting - und mit dem Aufkommen von REST, SOAP und anderen leichten Protokolle, das macht fast niemand mehr, soweit ich das beurteilen kann - dann wird ein besser vergleichbar in .NET ist WCF.

Schließlich sind die mit EJB MDB vergleichbaren .NET Queued Components.

EJB-Remoting

Alle diese Arten von EJBs haben einige gemeinsame Aspekte – wie zum Beispiel Remote-Schnittstellen.Tatsächlich empfehlen die meisten Architekten, dass Sie Ihre EJBs nicht verteilen.Mit anderen Worten: Sie halten Menschen davon ab, den so häufig diskutierten Remote-Aspekt zu nutzen.Stattdessen sollte ein Servlet ein lokales EJB aufrufen, anstatt eines auf einem Remote-Computer aufzurufen.Das ist Fowlers erstes Gesetz: Verteilen Sie Ihre Objekte nicht.

Andererseits muss man es manchmal auch tun.
WCF ist das Kommunikationsframework in .NET und der Aspekt in .NET, der am ehesten mit EJB-Remoting vergleichbar ist.Aber sie sind nicht gleichwertig.WCF ist ein sehr allgemeines Framework für die Remote-Kommunikation, das Synchronisierung und Asynchronisierung, mehrere Protokolle sowie ein erweiterbares Transport- und Kanalmodell unterstützt, während EJB-Remoting ziemlich begrenzt ist.

Ist es der richtige Ansatz, mit EJB zu beginnen?

EJB sagt (soweit ich weiß) nichts über Webdienste oder REST, oder Management- oder Lightweight-Frameworks oder sogar HTML oder Entwicklertools.Das Starten einer Vergleich mit "EJB vs leer" schränkt die Diskussion künstlich ein Ein bisschen.Es rahmt die Diskussion in einer Weise, die möglicherweise nicht optimal.

Es gibt in EJB nichts, was beispielsweise eine HTML-Seitenmetapher verarbeiten könnte.Sie erhalten dies in Servlets oder einem ihrer Cousins ​​(Portlets usw.), von denen einige in J2EE selbst vorliegen.Aber genau genommen wird die HTML-Ausgabe nicht von EJB abgedeckt.

Nun, vielleicht beabsichtigen Sie eine der ausführlicheren Definitionen von EJB.Zu diesem Zweck hat J2EE nun Webdienste in die Spezifikation aufgenommen.Dennoch bin ich mir nicht sicher, wie relevant es ist, die Spezifikation zu berücksichtigen, angesichts der Vielzahl an zusätzlichen Java-basierten Frameworks für SOAP-Webdienste und REST.

Wenn Sie UI-Funktionen wie Portlets, Servlets und AJAX in Betracht ziehen und sie mit den .NET-Äquivalenten vergleichen möchten, dann sind Sie weit über EJB und J2EE hinaus und in serverseitiges Java im Allgemeinen vorgedrungen.

Das bringt mich zurück zu meinem früheren Punkt - seien Sie klar und präzise in Ihrem eigenen Kopf darüber, was Sie an einer Untersuchung oder einem Vergleich interessiert sind.

---

Die EJB- und J2EE-Spezifikationen waren ehrgeizig und versuchten, die Frameworks für serverseitige Anwendungen zu definieren.Es gab jedoch immer eine Zeitverzögerung zwischen dem, was die Entwickler taten, dem, was in der Spezifikation stand, und dem, was die Anbieter lieferten.Wissen Sie, vielleicht gab es eine Verzögerung von einem Jahr zwischen der Fertigstellung einer neuen Version der J2EE-Spezifikation und der Veröffentlichung eines kompatiblen Servers von IBM.

Aus diesem Grund wirkte es irgendwie künstlich, im Nachhinein.Die Spezifikation beschrieb Dinge, die die Leute bereits taten.Dinge wie Spring kamen heraus und J2EE sagte nichts darüber.J2EE hatte lange Zeit nichts über REST, Webservices oder AJAX zu sagen.(Sagt es auch jetzt noch etwas über AJAX?Ich weiß nicht.)

Angesichts der Distanz zwischen der Theorie der Spezifikation und der Realität der tatsächlichen Praxis durch die Entwickler könnte ein besserer Ansatz darin bestehen, die Anwendungsanforderungen zu identifizieren, und und vergleichen dann die Eignung von EJB und anderen verwandten Technologien mit der Apps, die Sie erstellen möchten.

Mit anderen Worten: Angenommen, eine Ihrer Anforderungen besteht darin, dass die App über den Browser bereitgestellt wird und die Reaktionsfähigkeit von AJAX aufweist.In diesem Fall müssen Sie jQuery in Betracht ziehen, und das wird in J2EE oder EJB nirgends abgedeckt.AJAX-Frameworks sind in verschiedenen Produkten verfügbar (sowohl Java als auch .NET).Beispielsweise verwendet Visual Studio jQuery für das ASPNET AJAX-Material.Aber wenn man sich an die Spezifikationen hält, geht dieses Zeug irgendwie verloren.

Endeffekt

Die Quintessenz ist, dass jede App, die Sie mit EJBs erstellen, integriert werden kann .NET und umgekehrt.

Ich denke, ein Vergleich wie "EJB vs. .NET" kann als Akademiker interessant sein Diskussion, aber wenn Sie einen praktischen Einblick in die Verwenden Sie where, dann müssen Sie ein wenig anders denken.

Sie müssen Anforderungen identifizieren und priorisieren - wie z. B. die Geschwindigkeit der Entwicklung, Bereitstellungskosten, Bereitstellungsmechanismus, Tool-Unterstützung, Unterstützung der Bereitstellungsplattform, Sprachunterstützung, Leistung, UI-Erscheinungsbild, UI-Optionen usw.Wägen Sie dann die Optionen gegen die priorisierten ab Liste.

Answer 3

Man könnte leicht argumentieren Spring.NET ...

Der Frühling ist die Norm in der Java-Seite werden, entweder zusätzlich zu JavaEE / EJB oder gar ersetzt sie. Viele der Konzepte im Frühjahr sind sehr ähnlich zu JavaEE / EJB, sondern einfach besser. Spring.NET ist, natürlich, die .NET-Implementierung davon.

Darüber hinaus kann ich nichts anderes als ich aktiv nicht .NET in Jahren ...

Answer 4

eine Menge von der EJB-Funktionalität ist bereits nativen in .net (das heißt Datenbanktransaktion), aber es ist der Enterprise-Services-Namespace, die auch eine Vielzahl von Funktionen zur Verfügung stellt.