Differences

This shows you the differences between two versions of the page.

--- mastering_enterprise_javabeans_3.0 [2019/06/25 10:32] – [Enterprise JavaBeans Technology] kalaschnikow
+++ mastering_enterprise_javabeans_3.0 [2019/06/25 17:12] (current) – [Service-oriented architectures and Enterprise JavaBeans] kalaschnikow
@@ Line 1: / Line 1: @@
+====== Mastering Enterprise JavaBeans 3.0 ======
+Konspekt vom Buch: ( C:/Users/kalaschnikow/Desktop/books/MasteringEJB4thEd.pdf or with backslashes: C:\Users\kalaschnikow\Desktop\books\MasteringEJB4thEd.pdf )
+===== Introduction =====
+...
+====== Part I Overview ======
+===== Chapter 1: Overview =====
+...
+==== Infrastructure Needs of Distributed Applications ====
+Enterprise Application is a distributed application. Every layer is independent and serves a distinct purpose. Which issues would need to betaken care of for such a deployment?
+A distributed deployment requires some things which should be considered:
+  * RMI (we need some mechanism to connect one tier to another)
+  * Load Balancing
+  * Transparent failover
+  * Transactions
+  * Clustering (all nodes have the same state, so if one crashes, another can do the further processing)
+  * Dynamic redeployment
+  * Clean shutdown
+  * Resource pooling
+  * ...
+Each of this aspects can be thought as a service in a multi-tier application.
+=== Application Server–Class Software ===
+In this chapter is meaned "Application server"-class software.
+We can go two ways:
+  * Build middleware service from scratch
+  * Buy middleware services via Application Server software
+The second way is usually better. Also we don't always have to buy this services, there are open source alternatives.
+=== Standardization of component frameworks ===
+If we use a proprietary server we risk that if the platform doesn't exist anymore or it does not fit our needs any more, we should rewrite our code. Much better approach would be to standardize the interfaces and components, so we don't need to rewrite components. In best case there is not necessary to recompile the code.
+Such standard component framework is for example EJB.
+==== Enterprise JavaBeans Technology ====
+EJB is a standard for developing and deploying server-side distributed components in Java. It defines a contract between application server and components.
+The three main value propositions:
+  * Ubiquitous industry standard
+  * Portability is possible
+  * Rapid application development
+Alternative examples:
+  * Spring
+  * .NET-managed components
+=== Why Java? ===
+...
+=== EJB as business tier component ===
+EJBs
+  * **not** client-side components
+  * server-side components
+    * perform business logic
+    * access database
+    * integrate with other systems
+Examples of EJB clients (= clients for EJBs):
+  * Application clients
+  * Dynamically generated web pages (Web frontend clients)
+  * Web service clients
+=== Distributed computing: the foundation of EJB ===
+A distributed component aka distributed object aka remote object is a component callable remotely.
+The main steps of remote method invocation:
+  * client calls stub (client-side proxy object)
+  * stub calls through the network skeleton (server-side proxy object)
+  * skeleton delegates to the appropriate implementation object
+The key point here: stub and skeleton have the same interface. (But to be exact: The interface is not really the same, e.g. they have different exceptions).
+The client "thinks" he calls the distributed object, but in reality it calls the stub, which knows how to call the remote object through the network. This concept is named //distribution transparency//.
+=== EJB middleware services ===
+== Explicit middleware approach ==
+The code uses all necessary services from the middleware by itself.
+Pseudocode:
+<code>
+transfer(Account account1, Account account2, long amount) {
+  // 1: Call middleware API to perform a security check
+  // 2: Call middleware API to start a transaction
+  // 3: Call middleware API to load rows from the database
+  // 4: Subtract the balance from one account, add to the other
+  // 5: Call middleware API to store rows in the database
+  // 6: Call middleware API to end the transaction
+}
+</code>
+Downsizes:
+  * Lower productivity
+  * Difficult to write
+  * Difficult to maintain
+== Implicit middleware approach ==
+The code uses all necessary services implicitly by annotations / descriptors and other "descriptive" mechanisms, so all necessary work will be done automatically in the implicit way.
+Pseudocode:
+<code>
+transfer(Account account1, Account account2, long amount) {
+  // 1: Subtract the balance from one account, add to the other
+}
+</code>
+== Implicit vs. explicit middleware service in EJB ==
+EJB uses normally implicit approach, but it also possible to use explicit interfaces. For example it can be useful not to bound transactions to methods, but to set transaction begin / end freely.
+=== Roles in EJB application lifecycle ===
+  * Bean provider -> writes beans
+  * Application assembler -> uses ready-to-use beans and maybe writes his own beans and the "glue" code
+  * EJB deployer -> deploys the application in the productive environment
+  * System administrator -> monitors the system
+=== EJB ecosystem ===
+  * EJB container aka EJB server
+    * A piece of software implementing EJB spec
+  * EJB tools
+==== Service-oriented architectures and Enterprise JavaBeans ====
+=== Defining service-oriented architectures ===
+...