Introduction to J2EE Part 2-Introduction to Java Programming-Lecture Slides, Slides of Java Programming

Download Introduction to J2EE Part 2-Introduction to Java Programming-Lecture Slides and more Slides Java Programming in PDF only on Docsity!

Trends

22 cs420 Fall 2010

Moving from single-tier or two-tier to multi-tier architecture Moving from monolithic model to object-based application model ` Moving from application-based client to HTML- based client

So based on this evolution, we can observe a few trends. First, moving from a single tier or two‐tier model to multi‐tier model. Second, moving from the monolithic code to object‐based application model. Lastly, HTML browser based clients are taking some strong hold.

Comparison

23 cs420 Fall 2010

Multi-tier

z No separation among presentation, business logic, database z Hard to maintain

z Separation among presentation, business logic, database z More flexible to change, i.e. presentation can change without affecting other tiers

Single tier

Now let's compare the single‐tier model against multi‐tier model. In a single tier model or even two‐tier model, there is no separation among presentation, business, and data access logic, which makes it harder to maintain the code while in multi‐tier model, there are separation among those three functionality. And because they are separated, a change in one area should not impact the others, which provides much more flexible way of maintaining the code.

Comparison

24 cs420 Fall 2010

Object-based

z 1 Binary file z Recompiled, relinked, redeployed every time there is a change

z Pluggable parts z Reusable z Enables better design z Easier update z Implementation can be separated from interface z Only interface is published

Monolithic

Now let's compare monolithic model and object‐based model. In a monolithic model, everything is intertwined. This means every time you make a change, the whole thing has to be recompiled and re‐linked and redeployed. In the object‐based model, things are more flexible and reusable. Again, the implementation can change without affecting the other programs residing in different tiers as long as interface remains the same.

Outstanding Issues & Solution

25 cs420 Fall 2010

` Complexity at the middle tier server still remains

` Duplicate system services still need to be

provided for the majority of enterprise

applications

Concurrency control, Transactions Load-balancing, Security ` Resource management, Connection pooling

` How to solve this problem?

**Commonly shared container** that handles the above system services Proprietary versus Open-standard based

Now the issue of “middle tier still need to deal with system level issues such as concurrency control and resource management” still remains the same. Furthermore, since every application has to deal with these issues, there could be duplication among the applications in the area of system services.

So what could be the solution? The solution is to come up with an architecture or framework where the common container which can be shared among all applications provide system services mentioned above.

And that is where next evolution has occurred, initially with proprietary form and later on based on an open‐ standard.

Proprietary Solution

26 cs420 Fall 2010

` Use " component and container " model

Components captures business logic Container provides system services

` The contract between components and

container is defined in a well-defined but with

proprietary manner

` Problem of proprietary solution: Vendor lock-in

` Example: Tuxedo, .NET

So in both proprietary and standard based model, the idea is to use component and container model in which business logic is captured as components and the container provide host execution environment where system services are also provided. Of course, the proprietary model locks you in a single product and single vendor and the examples are good old Ttuxedo and of course .NET is another prime example of this.

Open and Standard Solution

27 cs420 Fall 2010

` Use " component and container " model in

which container provides system services in a

well-defined and as industry standard

` J2EE is that standard that also provides

portability of code because it is based on Java

technology and standard-based Java

programming APIs

Open and standard based solution is that a standard specification defines the contract of the component and container model in a well‐defined and in an industry‐standard.

And J2EE is that standard. And because it is based on Java technology, the portability of code also can be achieved regardless underlying OS or hardware architecture.

Slide 28

Why J2EE?

Fall 2010 cs420 28

Slide 29

Platform Value to Developers

29 cs420 Fall 2010

Can use any J2EE implementation for development and deployment Use production-quality standard implementation which is free for development/deployment Use high-end commercial J2EE products for scalability and fault-tolerance Vast amount of J2EE community resources Many J2EE related books, articles, tutorials, quality code you can use, best practice guidelines, design patterns etc. Can use off-the-shelf 3rd-party business components

First, let's talk about J2EE platform value to developers.

Now with J2EE, developers do not have to be tied up with particular vendor platform because they can use any J2EE‐compliant implementation as their development platform while application portability is still guaranteed. For example, you can use freely available J2EE implementations such as Sun Java System App Server Platform Edition for development while you might want to use high‐end commercial platforms for actual production deployment especially when scalability, reliability, fault‐tolerance, and high‐performance are important factors.

Second,J2EE is, for that matter, Java, is all about community. There is vast amount of J2EE community resource that be leveraged by J2EE developers, for example, books, articles, tutorials, and quality code that you can use, best practice guidelines and design patterns people have spent time to develop. If you think about it, these are very significant value.

Thirdly, because J2EE is based on component model, that is, 3rd party components can be used to build enterprise applications thus saving time and money.

Slide 30

Platform Value to Vendors

30 cs420 Fall 2010

` Vendors work together on specifications and

then compete in implementations

` In the areas of Scalability, Performance, Reliability, Availability, Management and development tools, and so on

` Freedom to innovate while maintaining the

portability of applications

` Do not have to create/maintain their own

proprietary APIs

So what are the J2EE value proposition to vendors? First vendors work together on creating specifications and then they compete in implementations. And the areas they compete include scalability, performance, reliability, availability, management and development tools, and so on.

This way, vendors have freedom to innovate in their implementations while maintaining the portability of their applications. So bottom line is that vendors can influence the future of Java while they can continue to innovate.

And vendors are free from having to maintain their own proprietary APIs. Instead they focus on better implementations.

Slide 31

Platform Value to Business Customers

31 cs420 Fall 2010

` Application portability

` Many implementation choices are

possible based on various requirements

` Price (free to high-end), scalability (single

CPU to clustered model), reliability,

performance, tools, and more

` Best of breed of applications and platforms

` Large developer pool

Now what about the business customers? First and foremost, to customers, application portability is guaranteed, which means they can choose best of breed applications as well as best of breed platforms based on many criteria, for example, price, scalability, reliability, and performance, and tools, and so on.

There are large developer pool they can tap with. And then they can use many quality open source implementations such Tomcat, Struts, Cocoon, and Axis and so on, over the J2EE platform

Slide 32

Fall 2010 cs420 32

J2EE APIs and

Technologies?

Slide 33

J2EE 1.4 APIs and Technologies

33 cs420 Fall 2010

J2SE 1.4 (improved) JAX-RPC (new) Web Service for J2EE J2EE Management J2EE Deployment JMX 1. JMS 1. JTA 1.

` Servlet 2.

` JSP 2.

` EJB 2.

` JAXR

` Connector 1.

` JACC

` JAXP 1.

` JavaMail 1.

` JAF 1.

So this is the summary slide of all Java APIs and technologies that will be part of J2EE 1.4. I put it here for your reference. The ones in red color are newly added features while the ones in blue color are the ones whose functionality is enhanced from the previous version.

Slide 34

Java EE 5

34 cs420 Fall 2010

` JAX-WS 2.0 & JSR 181

Java Persistence EJB 3. JAXB 2. JavaSever Faces 1.2 – new to Platform ` JSP 2.1 – Unification w/ JSF 1.

For J2EE 5. http://java.sun.com/javaee/sdk/features.jsp

Slide 35

35 cs420 Fall 2010

Servlet & JSP

Slide 36

What is a Servlet?

36 cs420 Fall 2010

Java ™^ objects which extend the functionality of a HTTP server Dynamic contents generation Better alternative to CGI, etc. Efficient Platform and server independent Session management ` Java-based

What is Servlet? A servlet is a Java object that extends the functionality of HTTP server by providing the capability of dynamic contents generation.

Now you might remember that people used to use CGI for dynamic contents generation. “What is wrong with CGI?” Lots of things. First, inefficiency. In CGI, every HTTP request from client results in a creating of a new process, even if they are from a same client, which is quite inefficient and of course because of that, cannot scale to handle large number of clients at the same time.

The servlet technology is designed to solve these problems associated with using CGI, or proprietary APIs such as NSAPI or ISAPI. For example, Servlet handles the HTTP client requests much more efficiently than CGI because it does not have to create new process every time there is a new client request. Instead, it creates a new thread. Because it is Java and because it is standard‐based, most of the web servers out there support servlet. It also handles session management for you so that you don’t have to deal with it yourself. By being Java code, it is cross‐platform technology as opposed to vendor‐specific or product‐specific technologies such as NSAPI or ISAPI.