Konspekt vom Buch: ( C:/Users/kalaschnikow/Desktop/books/MasteringEJB4thEd.pdf or with backslashes: C:\Users\kalaschnikow\Desktop\books\MasteringEJB4thEd.pdf )
…
…
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:
Each of this aspects can be thought as a service in a multi-tier application.
In this chapter is meaned “Application server”-class software.
We can go two ways:
The second way is usually better. Also we don't always have to buy this services, there are open source alternatives.
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.
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:
Alternative examples:
…
EJBs
Examples of EJB clients (= clients for EJBs):
A distributed component aka distributed object aka remote object is a component callable remotely.
The main steps of remote method invocation:
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.
The code uses all necessary services from the middleware by itself.
Pseudocode:
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
}
Downsizes:
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:
transfer(Account account1, Account account2, long amount) {
// 1: Subtract the balance from one account, add to the other
}
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.
…