WebServices in Java

What are Web Services?

a piece of business logic, located somewhere on the Internet, that is accessible through standard-based Internet protocols such as HTTP or SMTP

Characteristics

XML based

Loosely Coupled

Coarse grained

Ability to be Synchronous or Asynchronous

Supports Remote Procedure Calls (RPCs)

Supports document exchange



Major Web Services Technologies


Simple Object Access Protocol (SOAP)

Web Service Description Language (WSDL)

Universal Description, Discovery, and Integration (UDDI)

Simple web service interaction



Why Java Web Services

Ability of enterprises using different computing platforms to communicate with each other

Java ensures code portability

J2EE ensures scalability

APIs hide all the implementation details

Components are reusable

Development time is substantially reduced

Java Web Service Developer Pack

Free integrated toolkit that allows Java developers to build, test and deploy Web services

Web services standards WSDL, SOAP, UDDI

APIs provided

Java API for XML Messaging (JAXM)

Java API for XML Registries (JAXR)  Java API for XML-based RPC (JAX-RPC)


Sample Scenario-Online Book store









JAX-RPC API for XML based RPC



RPC-based Web service is a collection of procedures that can be called by a remote client

Ties, the low-level classes that the server needs to communicate with a remote client

WSDL document used for creating stubs, the low-level classes that are needed by a client to communicate with a remote service.

Stubs can be static or dynamic.

Tools wscompile and wsdeploy

simplify our job




Service consists of

Interface:

Declares the service's remote procedures

Implementation class:

Implements the remote procedures.



Configuration files jaxrpc-ri.xml and web.xml contain all the parameters needed to deploy the service.



Client is a Java program which uses the stubs created from the WSDL document of the service

Configuration file config.xml contains the location of the WSDL document.

Service Interface

public interface BookIF {

public Book getPriceList();

public String orderBook(String BookName, int quantity);

}



Implementation class

public class BookImpl implements BookIF {

public Book getPriceList() { . . . }

public String orderBook(String BookName, int quantity) { . . . }

}



Client code



public class BookClient {

public static void main(String[] args) {

BookIF BookOrder = new BookServiceImpl().getBookIF();

Book priceList = BookOrder.getPriceList():

for (int i = 0; i <>JAXM API for XML Messaging



Provides a standard way to send XML documents over the Internet

Based on SOAP and SOAP with Attachments specifications

Messaging provider service, which does the behind-the-scenes work required to transport and route messages

Standalone client also possible for request-response type of messaging

Very useful when Enterprise work on shared schemas.(e.g.. Schema for order form in Online Book Store)



Advantages over JAX-RPC

One-way (asynchronous) messaging

Routing of a message to more than one party

Reliable messaging with guaranteed delivery



Steps

1.Setting up Connection with the end-point.

2.Creating the SOAP message and populate it.

3.Sending the message.



JAXR API for XML Registries



Provides a convenient way to

access standard business registries

Supports two standards ebXML and UDDI

Standards groups have developed

schemas for particular kinds of XML documents, and two businesses might for example, agree to use the schema which is stored in the registry.

Querying a registry-Useful methods

1.findOrganizations

which returns a list of organizations that meet the specified criteria

2.findServices

which returns a set of services offered by a specified organization

3. findServiceBindings

which returns the service bindings (information about how to access the service) that are supported by a specified service



Similar methods exist for Managing Registry Data.

All About JSF

Java Server Faces (JSF)

What is JSF??


• A set of Web-based GUI controls and associated handlers

– JSF provides many pre-built HTML-oriented GUI controls, along
with code to handle their events.

• A device-independent GUI control framework

– JSF can be used to generate graphics in formats other than HTML,
using protocols other than HTTP.

• A better Struts
– Like Apache Struts, JSF can be viewed as an MVC framework for
building HTML forms, validating their values, invoking business
logic, and displaying results.

JSF V/S Struts


• Custom components

– JSF makes it relatively easy to combine complex GUIs
into a single manageable component; Struts does not

• Support for other display technologies
– JSF is not limited to HTML and HTTP; Struts is

• Access to beans by name
– JSF lets you assign names to beans, then you refer to
them by name in the forms. Struts has a complex process
with several levels of indirection where you have to
remember which form is the input for which action.

• Expression language
– The JSF expression language is more concise and
powerful than the Struts bean:write tag.

• This is less advantageous if using JSP 2.0 anyhow.

• Simpler controller and bean definitions
– JSF does not require your controller and bean classes to extend any particular parent class (e.g., Action) or use any particular method (e.g., execute). Struts does.

• Simpler config file and overall structure
– The faces-config.xml file is much easier to use than is the struts-config.xml file. In general, JSF is simpler.

• More powerful potential tool support
– The orientation around GUI controls and their handlers
opens possibility of simple to use, drag-and-drop IDEs

• Established base and industry momentum
– Struts has a large core of existing developers and momentum among both developers and IT managers; JSF does not.

• Support for other display technologies
– JSF is not limited to HTML and HTTP; Struts is

• Confusion vs. file names
– The actual pages used in JSF end in .jsp. But the URLs used end in
.faces or .jsf. This causes many problems; in particular, in JSF:

• You cannot browse directories and click on links

• It is hard to protect raw JSP pages from access

• It is hard to refer to non-faces pages in faces-config.xml

• Self-submit approach
– With Struts, the form (blah.jsp) and the handler (blah.do) have
different URLs; with JSF they are the same.

The JSF Expression Language

Access bean property or method

#{myBean.myProperty}

#{myBean.myMethod}

Access for array, list element or map entry

#{myBean.myList[5]}

#{myBean.myMap['key']}



Boolean Expression ==, !=, <=, ... #{myBean.myValue != 100 } #{myBean.myValue <= 200 } The Request Processing Life Cycle



Restore View

Extract the view ID -> find current

view

Look up the components for the

current view, create them if necessary

Restore or create component values,

event listeners, validators and
converters

If no (new) user input -> skip to

Render Response Phase



Application Request Values

Decoding: extract user input from

input components

Create Action Events and add them to

Faces Context for later processing

if immediate = "true"

-Validation of submitted values

-Action Sources fire action events


Process Validators
Convert submitted values

Validate submitted values

Conversion or validation errors ->

Render Response (6), else ...

Set local value to the converted and

validated submitted values

Fire value change events

Update Modal Values

Find appropriate bean in the scope

(request, session, application)

Set the bean property to the new value


Invoke Application

Handle all fired events

-Execute default action listener method

-Call the event handler methods of all

registered event listeners

Decide navigation

-depending on the outcome of the fired

action method

Render Response

Display the next view

-Render tree of UIComponents

-with the updated values from the backing

beans

Invoke converters

Save the state of the new view

-for later use in the Restore View Phase

JSF Application Configuration


Setting Up JSF

Download jsf jar files

Put jar files in class path

Download jsf-blank-myfaces war file

Directory Structure




Deployment Descriptor






The Standard JSF Components


Shared Attributes

Id-Identifier for a component

rendered- Boolean value false suppresses rendering

Value-The components value,typically a value binding

Required- Boolean value true requires a value to be entered into the input field

styleClass-CSS class name

Converters and Validators

Type Conversion

and Input Validation


Automatic Conversion

All basic Java types are automatically

converted between string values and

objects.

BigDecimal

BigInteger

Boolean, boolean

Byte, byte

Character, char

Integer, int

Short, short

Double, double

Float, float

Long, long

Design Patterns in Java/J2EE

What is the design Pattern?

If a problem occurs over and over again, a solution to that problem has been used effectively.
That solution is described as a pattern. The design patterns are language-independent strategies for solving common object-oriented design problems .

Type of design patterns

Creational Patterns
Structural Patterns
Behavioral Patterns
J2EE Patterns

Creational Patterns

Abstract Factory
Builder
Factory Method
Prototype
Singleton

Factory Method

Provides an abstraction or an interface and lets subclass or implementing classes decide which class or method should be instantiated , based on the conditions or parameters given.

Where to use & benefits

A class wants its subclasses to specify the object.
A class cannot anticipate its subclasses, which must be created.
A family of objects needs to be separated by using shared interface.
The code needs to deal with interface, not implemented classes.
Factory methods can be parameterized.
The returned object may be either abstract or concrete object.
Hide concrete classes from the client.

Abstract Factory

Provides an abstraction or an interface and lets subclass or implementing classes decide which class or method should be instantiated , based on the conditions or parameters given.

Where to use & benefits

A class wants its subclasses to specify the object.
A class cannot anticipate its subclasses, which must be created.
A family of objects needs to be separated by using shared interface.
The code needs to deal with interface, not implemented classes.
Hide concrete classes from the client.
Factory methods can be parameterized.
The returned object may be either abstract or concrete object.


Ex of Factory method

To paint a picture, you may need several steps. A shape is an interface.
Several implementing classes may be designed in the following way.



interface Shape {
public void draw(); }
class Line implements Shape { Point x, y; Line(Point a, Point b)
{ x = a; y = b; }

public void draw()
{ //draw a line; } } class Square implements Shape
{ Point start; int width, height; Square(Point s,
int w, int h) { start = s; width = w; height = h; }

public void draw()

{ //draw a square; } }

class Circle implements Shape { .... }

class Painting
{
Point x, y; int width, height, radius;
Painting(Point a, Point b, int w, int h, int r)
{
x = a; y = b; width = w; height = h; radius = r;
}

Shape drawLine()
{
return new Line(x,y);
}

Shape drawSquare()
{
return new Square(x, width, height);
}
Shape drawCircle()
{
return new Circle(x, radius);
}

.... }

... Shape pic; Painting pt;

//initializing pt .... if (line) pic = pt.drawLine();


if (square) pic = pt.drawSquare(); if (circle) pic = pt.drawCircle();


From the above example, you may see that the Shape pic's type depends on the condition given. The variable pic may be a line or square or a circle.

Singleton

One instance of a class or one value accessible globally in an application
Ensure a class has only one instance and provide a global point of access to it.

Where to use & benefits

Ensure unique instance by defining class final to prevent cloning.
May be extensible by the subclass by defining subclass final.
Make a method or a variable public or/and static.
Access to the instance by the way you provided.
Well control the instantiation of a class.
Define one value shared by all instances by making it static.
Related patterns include



Ex of Singleton method

For example, to make a unique remote connection,




final class RemoteConnection

{
private Connect con;

private static RemoteConnection rc = new RemoteConnection(connection);

private RemoteConne

ction(Connect c)



For example, to make a unique remote connection,

final class RemoteConnection

{
private Connect con;

private static RemoteConnection rc = new RemoteConnection(connection);

private RemoteConne

ction(Connect c)

usage: RemoteConnection rconn = RemoteConnection.getRemoteConnection; rconn.loadData(); ... The following statement may fail because of the private constructor RemoteConnection con = new RemoteConnection(connection); //failed //failed because you cannot subclass it (final class) class Connection extends RemoteConnection {} For example, to use a static variable to control the instance;

public static void main(String [] args) { try { Connection con = new Connection(); //ok }catch(Exception e)

{
System.out.println("first: " +e.getMessage()); }

try { Connection con2 = Connection.getConnection();

//failed. }catch(Exception e)

{

System.out.println("second: " +e.getMessage());

} } }

…




Structural Patterns

Adapter
Bridge
Composite
Decorator
Façade
Flyweight
Proxy


Adapter
Convert the existing interfaces to a new interface to achieve compatibility and reusability of the unrelated classes in one application. Also known as Wrapper pattern.

Where to use & benefits

Make unrelated classes work together.
Multiple compatibility.
Increase transparency of classes.
Make a pluggable kit.
Delegate objects.
Highly class reusable

Example


import javax.swing.*;

import java.awt.event.*;

class Test extends JFrame

{

public Test ()

{ setSize(200,200);

setVisible(true);



addWindowListener(new Closer()); } public static void main(String[] args) { new Test(); }

class Closer extends WindowAdapter { public void windowClosing(WindowEvent e)

{ System.exit(0); } } }




Facade

Make a complex system simpler by providing a unified or general interface, which is a higher layer to these subsystems

Where to use & benefits

Want to reduce complexities of a system.
Decouple subsystems , reduce its dependency, and improve portability.
Make an entry point to your subsystems.
Minimize the communication and dependency between subsystems.
Security and performance consideration.
Shield clients from subsystem components.
Simplify generosity to specification.
Related patterns include

Ex of facade


interface General

{

public void accessGeneral();

}

interface Special extends General

{

public void accessSpecial();

}

interface Private extends General

{

public void accessPrivate();

}





interface Private extends General { public void accessPrivate();

}

class GeneralInfo implements General {

public void accessGeneral() { //... } //...



class GeneralInfo implements General {

public void accessGeneral()

{ //... } //... }

class SpecialInfo extends GeneralInfo implements Special

{ public void accessSpecial()

{ //... } }

class PrivateInfo extends SpecialInfo implements Private

{ public void accessPrivate()

{ // ... } //... }

class SpecialInfo extends GeneralInfo implements Special

{

public void accessSpecial()

{ //... } } class PrivateInfo extends SpecialInfo implements Private { public void accessPrivate() { // ... } //... }



J2EE Patterns

MVC
Intercepting Filter
View Helper
Front Controller
Composite View

Service Locator
Transfer Object
Composite Entity
Data Access Object
Session Facade
Business Delegate

MVC

The Model/View/Controller
(MVC) is an architecture design pattern. Model means data, View means representation and Controller works on data and representation. MVC focuses on decouple the triad relationships among data, representation and controller

Where to use & benifits

Application architecture design.
Any data related design, including non-visual application.
Decouple complex object to improve maintainability.
Increase object reusability.
Achieve design flexibility.
Related patterns include
Almost all patterns can be used with MVC.


Core Issue

MVC consists of three kind of objects. The Model is an internal representation of the data, the View is the screen presentation of GUI, and the Controller coordinates changes between the Model and View.

Theory of MVC Design Pattern

To achieve the MVC architecture in your project, you have to decouple View and Model by Controller. Your GUI as View should be designed as a module. It can be launched separately.
Your data related classes as Model should be treated as a module too. Your controller classes should response to any data change on the GUI. Such design will increase reusability and flexibility.

Try to visualize that the user reacts with the GUI, a DataManager(Controller) listens to the GUI's call. If the user needs to load data, such request is sent to the DataManager, the DataManager starts loading
searching and extracting the requested data from the server and sends it back to the GUI. GUI is responsible to display data.
Here the server acts as Model, the DataManager acts as Controller and GUI acts as View. The DataManager can be used for both remote and local modes

the GUI can be replaced with any design and the data related classes can be packaged together and put on local and server sides. All of the three objects can be reused for other projects with little code alteration


Interception Filter


A pluggable component design to intercept incomming requests and outgoing responses, provide common services in a standard manner (independently) without changing core processing code.

Where to use & benefits

Logging and authentication.
Enhance security.
Add additional function to existing web application.
Decorate main process.
Debug.
Pre-processing or post-processing for specific clients.
Uncompress incoming request.



Front Controller

Using a single component to process application requests

Where to Use & benifits
JSP or Servlet.
Design request handling component.
Channel all requests through a single controller.
Centralize request processing and view selection.
Reduce business logic in a view
Improve manageability of security
Promote code reuse across requests


Composite View
Use a coarse-grained interface to manage interactions between fine-grained or coarse-grained and dependent objects internally. The Composite Entity is a coarse-grained entity bean. It may be the coarse-grained object or hold a reference to the coarse-grained object. Also known as Aggregate Entity.

Where to Use & benifits

Improve manageability by reducing entity beans.
Improve network performance
Reduce database schema dependency
Increase object granularity
Facilitate composite transer object creation.

Important Links

http://java.sun.com/blueprints/patterns/catalog.html
http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html
http://gee.cs.oswego.edu/dl/cpj/ifc.html
http://www.javacamp.org/designPattern/
http://www.fluffycat.com/java-design-patterns/
http://www.patterndepot.com/put/8/JavaPatterns.htm

All About EJB's

Enterprise JavaBeans


What is EJB?

EJB is a server-side component framework that simplifies the process of building the enterprise-class distributed component applications in java.

By using EJB, you can write scalable, reliable, and secure applications without complex distributed component framework.

EJB is a component.
EJB is a standard for developing & deploying server-side distributed components in java.


EJB involves a standardized agreement that enables a component to run within any application server (increasing code reuse).

The agreement is accomplished by implementing a set of Java interfaces from the EJB API.
EJBs are not GUI components.

Advantages

Many vendor application servers conform to the J2EE specification allowing one to select a best-of-breed solution.

To handle fluctuations in resource demand server-side resources can easily be scaled by adding or removing servers.

Application servers provide access to complex services, namely transaction and security management, resource pooling, JNDI, component lifecycle management, etc.

Disadvantages

EJB has a large and complicated specification.
EJBs take longer to develop.

Also, when things go wrong they can be more difficult to debug.

Occasionally the bug may not be in your code but in the application server itself.

No sooner have you deployed your EJB application than you see a new specification coming down the pipe with newer features, rendering your application obsolete.

When not to use EJB

when there is no need for scalability, transaction management, or security.

if you anticipate low numbers of read-only users.
if your team lacks EJB experience or cannot quickly obtain that experience.

The EJB learning curve is steep and overcoming it can easily derail an otherwise viable project.

The EJB Ecosystem

For an EJB deployment up and running, needs more than an application server and components.
There are six more parties that are involved:

The Bean provider
The Application Assembler
The EJB Deployer
The System Administrator
The Container and Server providers
The Tool Vendors (IDEs)

Types of EJB

Session Beans

Session EJBs are function-oriented components

They represent a set of behaviors that reside on a server and can be invoked by clients.

Represent business processes to be performed

They implement business logic, business rules, algorithms, and work flows

Their lifetime is equivalent to a client session
Session Beans can’t survive when application server crashes or machine crashes

A session bean can perform database operations, but session beans themselves are not persistent.

There are two sub-types of Session EJBs,

Stateless Session EJBs and Stateful Session EJBs.

Stateless Session Beans

Represents a set of related behaviors (methods) that do not retain client-specific states between invocations.


Stateless session beans can possess instance variables, but those variables must be shared among multiple potential clients (e.g., they should be

read-only).
The EJB specification allows some flexibility in the design of an EJB Server such that each method call to a single EJB client stub for a Stateless Session EJB

may be directed to a different instance of a Stateless Session EJB

Possibly each residing on a different physical machine.

This allows the EJB server to be flexible in its approach to workload management, providing safety and scalability.

These can serve business requests that span only a single method invocation

Stateful Session Beans

Each Stateful session EJB is "owned" by a single client stub and is uniquely connected to that stub.

Stateful session EJBs may retain client state across method invocations by the same client.
That is to say, a client may call a method that sets a variable value in one method and then be assured that another, later, method invocation to retrieve that value will retrieve the same value.

Stateful session beans are usually developed to act as agents for the client, managing the interaction of other beans and performing work on behalf of the client application


Like ATM Transactions-balance, fund transfer, or making a withdrawal

Entity Beans

Entity Beans model data entities and provide shared distributed transactional access to persistent data.

Entity Beans provide concurrent shared access to multiple users.

An individual Entity EJB represents a single persistent entity -- for instance a row in a relational database (RDB).

In contrast, Session EJBs model businesses processes and provide exclusive access to a single client either for a length of a method (in the stateless case)

or for the life of the bean (in the Stateful case).

There are two basic subtypes of Entity EJBs:


Container-Managed Persistence (CMP)

Entity EJBs
Bean-Managed Persistence (BMP) Entity EJBs.

CMP

CMP entities are those whose persistence (for example, the storing and retrieving of their data from a backing store like an RDB) is managed by the EJB container.

This means that the container would, for instance, manage both generating and executing SQL code to read and write to the RDB.

CMP allows multiple entity beans to have container-managed relationships among themselves

You can designate instance variables to be container-managed persistence fields (cmp fields) or container-managed relationship fields (cmr fields).

You define these cmp and cmr fields in the deployment descriptor or throug getter/setter methods defined in bean

BMP

Bean-managed persistence is more complicated than container-managed persistence because you must explicitly write the persistence logic into the bean class.

Bean-Managed Persistence (BMP) EJBs leave the management of such details as what SQL is executed to the developer of the EJB.

Bean-managed persistence gives you more flexibility in how state is managed between the bean instance and the database eg. complex joins, a combination of different databases, or other resources such as legacy systems will benefit from bean-managed persistence.

Each BMP EJB is responsible for storing and retrieving its own state from a backing store in response to specific "hook" messages (like ejbLoad() and ejbStore()) that are sent to it at appropriate times during its lifecycle.

Message Driven Beans

Message-Driven Beans are enterprise beans that allow applications to process messages asynchronously.

Act as a JMS message listener, which is similar to an event listener, except that it receives messages instead of events.

The most visible difference between message-driven beans and session or entity beans is that clients do not access message-driven beans through interfaces.

A message-driven bean's instances retain no data or conversational state for a specific client .

A single message-driven bean can process messages from multiple clients

EJB Interfaces

All bean classes must implement javax.ejb.EnterpriseBean, or one of its subinterfaces, at some level.

javax.ejb.EnterpriseBean extends java.io.Serializable.

Session beans implement javax.ejb.SessionBean.

javax.ejb.SessionBean extends javax.ejb.EnterpriseBean.

It defines methods: ejbActivate, ejbPassivate, ejbRemove, and setSessionContext.

Entity Beans implement javax.ejb.EntityBean.
javax.ejb.EntityBean extends javax.ejb.EnterpriseBean.

It defines methods: ejbActivate, ejbPassivate, ejbRemove, setEntityContext, ejbLoad, ejbStore, and unsetEntityContext.

Message Driven Beans implement javax.ejb.MessageDrivenBean.

javax.ejb.MessageDrivenBean extends javax.ejb.EnterpriseBean.
It defines methods: ejbRemove and setMessageDrivenContext.

EJB Components

EJB Object
Remote Interface
Home Object
Home Interface
Local Interfaces
Deployment Descriptors
EJB-JAR file

What and How is RMI ??

What is RMI

Enables the programmer to create distributed applications (Java-Java), in which the methods of
remote Java objects can be invoked from other Java virtual machines, possibly on different hosts.

RMI uses object serialization to marshal and unmarshal parameters and does not truncate types, supporting true object-oriented polymorphism

Architecture

Advantages

Object Oriented

Mobile Behavior

Design Patterns

Safe and Secure

Easy to Write/Easy to Use

Connects to Existing/Legacy Systems

Write Once, Run Anywhere

How to implement RMI ?

Write and compile Java code for interfaces

Write and compile Java code for implementation classes

Generate Stub and Skeleton class files from the implementation classes

Write Java code for a remote service host program

Develop Java code for RMI client program

Install and run RMI system

Note: while declaring & implementing methods they should throws RemoteException

How to run a sample program ?

Interface


import java.lang.*;

import java.rmi.*;

public interface Hello extends java.rmi.Remote {

public String sayHellow() throws java.rmi.RemoteException;

}

Implementation Class:

import java.rmi.*;

import java.rmi.server.*;

class HelloImpl extends UnicastRemoteObject implements Hello {
HelloImpl () throws java.rmi.RemoteException { }
public String sayHellow() throws java.rmi.RemoteException

{

System.out.println(“In say Hello ");

return” Hello! Welcome to the world of RMI”;

}

}

Creating the Server

import java.util.*;

import java.rmi.*;

import java.rmi.RMISecurityManager;

public class HelloServer

{

public static void main( String args[] )

{

System.setSecurityManager( new RMISecurityManager());

try {

System.out.println ("Starting Hello Server");

HelloImpl hello =new HelloImpl ();

System.out.println ("Binding Server");

Naming. rebind (“hello", hello );

System. out. print ("Server is waiting");

}

catch( Exception e )

{

System. out. print ("An error occured");

e. printStackTrace ();

System.out.println(e.getMessage());

}

} }

Creating the Client


import java.util.*;

import java.net.*;

import java.rmi.*;

import java.rmi.RMISecurityManager;

public class HelloClient {

public static void main( String args[] ) {

System.setSecurityManager( new RMISecurityManager());

try {

System.out.println("Starting calcClient");

String url = new String( “rmi://"+ args[0] + "/hello");

System.out.println(“Hello Server Lookup: url =" + url);

hello = (Hello)Naming.lookup( url );

if(hello != null )

{ System.out.println(hello.sayHello());//invoking remote method

} else {

System.out.println("Requested Remote object is null.");

}

} catch( Exception e ) {

System.out.println("An error occurred");

e.printStackTrace();

System.out.println(e.getMessage());

}

}

}




Running the Client and the Server

Start the rmi registry

start rmiregistry

Compile all classes

Create stubs & skeletons

rmic HelloImpl

Start the server

java HelloServer

Start the Client

java HelloClient localhost

Sample program architecture