WebSphere Application Server

Transcription

IBM Italia SpA
WebSphere Application Server - Overview
Marco Dragoni
IBM Software Group – Technical Sales Specialist
IBM Italia S.p.A.
| Milan, 26 November 2008 |
© 2007 IBM Corporation
IBM Value Assessment
Agenda
Course and speaker introduction
What is an Application Server
Model-View-Controller Pattern
WebSphere Basic Architecture and mapping to MVC
– EAR file composition
– J2EE standard
– WebSphere Application Server Family
Understand difference between Basic and Network Deployment
Accessing Application Server Resource
A typical application flow

HTTP Server and Plug-in
Class Loader role
JNDI role
JDBC resource
Web Services for J2EE
2
© Copyright IBM Corporation 2008
Who am I and what is my job ?
Marco Dragoni
Working for IBM from 1990 at present as WebSphere Technical
Sales inside SWG (Software Group)
– My job consist of provide technical assistance during the sell cycle
to the seller people through technical presentation, PoC, lab
exercise and support for critical situation. This for some products
of WebSphere family (focus on BPM).
Software
Certification :
2007 IT Specialist
2007 IBM Certified SOA Associate (664)
2007 IBM Certified SOA Solution Designer (667)
2007 WebSphere Integration Developer (094)
2008 WebSphere ND 6.1 Advanced System Administrator (806)
3
Course Introduction
26 November 2008 (08.30-10.30) – WebSphere Application Server
Overview (Marco Dragoni)
28 November 2008 (13.30-15.30) – BPM and SOA and IBM products
description (Marco Dragoni)
02 December 2008 (11.30-14.30) LAB 01 – Building a simple serviceoriented application through step-by-step instruction
09 December 2008 (11.30-14.30) LAB 02 – Build a process to
integrate an existing web application to obtain a complete sell cycle
4
What is an Application Server
An Application Server is a runtime environment for hosting applications
that are written following the J2EE specification
An Applications Server, compliant with J2EE specification, offers services
such as Security (JASS), Transaction (JTA), Messaging (JMS), Naming
Services (JNDI), Database Connectivity (JDBC), etc.
Any Web applications that are written to the J2EE specification can be
installed and deployed on the server
J2EE is:
–

An open and standard based platform for developing, deploying and
managing n-tier, Web-enabled, server-centric, and componentbased enterprise applications
J2EE add value to
–
Developer
–
Vendors
–
Business Customer
5
A Brief History of Enterprise Java
Spring
Hibernate
SDO
Portlets
SCA
2006
BPEL
2003
2001
2000
1998
EJB 1.0
Servlet 2.1
J2EE 1.2
•EJB
•Servlet
•JSP
•JMS
•JavaMail
J2EE 1.3
•EJB
local EJBs
abs. CMP
MDB
•Servlet 2.3
Events
Filters
•JSP
XML
•JAXP
•Connectors
•JAAS
J2EE 1.4
•EJB 2.1
timers
pluggable JMS
•Web Services
Basic SOAP/HTTP
Registry
•JMX Mgmt
•J2EE Deployment
•JACC
6
Java EE 5
•EJB 3
POJO components
POJO persistence
•Web Services
POJO components
protocol independence
JAXB
StAX
•JSF
•JSP
common EL
•Annotations
IoC
J2EE – MVC Pattern (Model - View - Controller)
Model to represent the underlying
data and business logic behaviuor
in one place (Entity and Session
EJB). Make data and behaviour
independent from presentation.
Represented by EJB.
View display information
according to client types, display
result of business logic.
Represented by JSP.
Controller serves as the logical
connection between the users
interaction and the business
services on the back.
Represented by Servlet.
7
J2EE Architecture
Web Tier
EJB Tier
The Presentation Tier processes input from the Client Side Tier, calls components
in the Business Logic Tier, and then sends a response back to the Client Side Tier
(Servlet, JSP)
The Business Logic Tier provides a framework for executing business logic and
for accessing business data in a distributed transactional environment (EJB)
8
Web Applications and anatomies
It is often advantageous to treat each layer as an independent portion of
your application
Do not confuse logical separation of responsibilities with actual separation
of components
Some of the layers can be combined into single components to reduce
application complexity
J2EE application anatomies samples:
– HTML client, JSP/Servlets, EJB, JDBC/Connector (4 tiers)
– HTML client, JSP/Servlets, JDBC (3 tiers)
– EJB standalone applications, EJB, JDBC/Connector (3 tiers)
When to use EJB ?
– Application needs to be scalable or support variety of clients, transactions are
required to ensure data integrity, make data and behaviour independent from
presentation, manage business logic behaviuor in one place .
9
Java EE Application Components
Deployment
Descriptor
Web Module
EJB Module
Session
Resource
Adapter (RAR)
HTML
Application
Client Module
Main Class
Java beans
Servlet/JSP
Deployment
Descriptor
Entity
RA Java
Classes
MDB
Deployment
Descriptor
Deployment
Descriptor
Runs in Application Server
10
RA Java
Classes
Deployment
Descriptor
Runs in Application
Client Container
WebSphere AS Packaging
WebSphere XD
yDynamic Operation
yHigh Performance Computing
yManagement Facility
WebSphere ND
WebSphere
Process
Server
Application Server
Express/Base
WebSphere CE
Based on Apache
Geronimo
yClustering
Failover
yExtended Transaction
Workload Mgmt
Support
yDistributed
Administration
yApplication Profiling
yAsynchronous Execution yWeb Services
yDynamic Query
UDDI Registry
yScheduling
Web Services Gat.
yStartup Beans
yEdge Components
yIBM Ldap for prod env.
yService Integration Bus
yTAM for prod env.
yDB2 Session Persistance
WebSphere
ESB
yProcess Choreography
yBusiness Rules Engine
yMediation
Functions
11
WebSphere AS Basic Architecture
Web
Browser
Application
Application Server
Server
Balancing and
static content
HTTP Server
HTTP
Server
Plug-in
Plug-in Configuration
File
HTTP/S
Web Container
Embedded HTTP Server
HTTP/S
Servlet
JSPs
Web Services
Engine
EJB Container
XML
Configuration
Files
EJBs
Messaging
Engine
Application
Databases
Application
Data
Dynamic Cache
Name Server
Security
Data Replication
JMX
Transaction.
…
…
….
12
WebSphere AS Basic Administration
WebSphere
Administrative Clients
Application Server
WEB Container
9060
Web Browser
Internet or
Intranet
Config
Files
Administrative
Console
Application
Scripting Client
(wsadmin)
Update
Configuration
Repository
Soap/HTTP
or
RMI-IIOP
Custom Java
Administrative
Clients
J2EE
Apps
(EARs)
Administrative Services
Stand-alone Node
Administrative Console run inside the same JVM running customer
application
13
WebSphere AS Express, Base – Sample Topologies
All in one machine
Example 1
Easy to maintain
Low cost
HTTP Server
Low performance
WAS
Database/EIS
Example 2
Http Server + WebSphere Plug-in
Database/EIS
WebSphere AS
DMZ Network
Intranet Network
All in different machine
A DMZ can be established
No competition between DB and other resources (different tuning)
14
WebSphere AS Network Deployment Architecture
A deployment manager process
manages the node agents
– Holds the configuration repository for
the entire management domain,
called a cell
– Administrative Console runs inside
the DMgr
A node is a logical grouping of
servers
– Each node is managed by a single
node agent process
– A managed node is a node that
contains a node agent
– An unmanaged node is a node in the
cell without a node agent
V6
Application
Server
…
V6
Application
Server
…
V6 Node
Cell
Network Deployment : File synchronization
Deployment manager contains the master
configuration
Node agents synchronize their files with
the master copy
Automatically
At start up
Periodically
Manually
Administrative console
Command line
During synchronization
1. Node agent asks for changes to
master configuration
2. New or updated files are copied to
the node
16
…
V6
Application
Server
V6 Node
Enables the rest of the environment to be
aware of the node
15
V6
Application
Server
Network Deployment : System Administration
V6 Deployment Manager
Administrative Clients
Internet
or
Intranet
Master
Configuration for
the Entire Cell
WEB Container
Config
Files
9060
J2EE
Apps
(EARs)
Web Browser
Administrative
Console
Application
Scripting Client
(wsadmin)
Soap/HTTP
or
RMI-IIOP
Administrative Services
Config
Files
J2EE
Apps
(EARs)
Custom Java
Administrative
Clients
ND allows you to manage the entire cell (all processes)
from a central Deployment Manager
– Administrative clients connect to Deployment Manager
Changes made by the administrative clients are saved in
the master configuration
The configuration is then synchronized with the Nodes
V6
Application
Server
J2EE
Apps
(EARs)
WebSphere AS Example configuration (ND package)
WebSphere AS
Cluster2 (2 JVM)
WebSphere AS
Infrastructure
(3 JVM – 2NA +
1 DMGR) and
WebSphere
Plug-in on HTTP
Server
18
V6
Application
Server
V6 Node
Config
Files
17
WebSphere AS
Cluster1 (3 JVM)
… …
V6
Application
Server
V6
Application
Server
…
V6 Node
Config
Files
J2EE
Apps
(EARs)
How to access Application Server Resources
Application
Application Server
Server
Web browser
HTTP(S)
REST/AJAX
SOAP/HTTP(S)
Web Services
client
.Net and Java communication
RM
OP
I/II
Web
Container
EJB
Container
Servlets/JSPs
Web Services
Engine
EJBs
Messaging
Engine
SOAP/JMS
Java client
JMS Client
Asynchronous Communication
Java to Java communication
19
Consideration on accessing resources
Use HTTP when you need a standard user interface, like your browser, to access
the resources available inside the Application Server. UI content enrichment can
be done through Web 2.0 technology (AJAX, REST, JSON). AS resources access
from Internet (HTTP is a standard protocol).
Use web services when interaction is machine-to-machine (a web services client
is a program executed in another machine, usually a remote machine) and you
need to interact between heterogeneous environment (Java and .Net). AS
resources access is from Internet (HTTP is a standard protocol).
Use RMI/IIOP directly when instead of a browser you are building a standalone
Java application for your desktop (the user interface is a java application, so you
do not need the presentation layer) or you need a faster communication between
Java application.
Use JMS when you need an
asynchronous communication
between components (mainly used
from other program)
20
A new emerging way to access resources
Publish and Subscribe Event Handling
Enables dynamic scenarios such as
streaming stock updates and real time
collaborative web applications
WebSphere
Application Server
Proxy
JMS
EJBs
Services
Ajax Proxy
Provides safe, reliable access to
Internet based services and mashups
from browser based Ajax applications
POJOs
IBM $125.25 +$2.50… MSFT $43.75 -$1.50 …
JSON and HTTP Enablement
Simplifies Ajax and web 2.0 based
access to traditional web services,
Java objects and EJBs in the
application server
Ajax Client Runtime
Eases development of client side Ajax
code; based on Dojo, an open source
JavaScript library
21
Web 2.0 style services – key concepts
service
REST
– REpresentational State Transfer
– Server side architectural style relying on HTTP
semantics to access services or resources
– Easily invoked by browsers via Ajax
JSON
– JavaScript Object Notation
– Data format used to exchange information between
browser and a service
– Directly consumable by JavaScript clients
Browser
Ajax
– Asynchronous JavaScript And XML
– Browser based technology to provide highly interactive
and responsive web pages
– Enables the browser to invoke services directly from the
client
22
22
The flow of an application
Phase 1
1,2,3,4,5
Phase 2
6
Phase 3
7,8a,8b,9
Phase 4
10
23
Plug-in configuration file
The plug-in configuration file (plugin-cfg.xml) contains routing information for
all applications mapped to the Web server. This file is read by a binary plug-in
module loaded in the Web server.
24
Plug-in XML tag description
VirtualHostGroup, VirtualHost:
– A group of virtual host names and ports that will be specified in the HTTP Host header when the user
tries to retrieve a page. Enables you to group virtual host definitions together that are configured to
handle similar types of requests. The requested host and port number are matched to a VirtualHost
tag in a VirtualHostGroup.
UriGroup, Uri :
– A group of URIs that will be specified on the HTTP request line. The incoming client URI is compared
with all the Uri tags in the UriGroup to see if there is a match to determine if the application server
will handle the request for the Route in conjunction with a virtual host match.
Route:
– The Route definition is the central element of the plug-in configuration. It specifies how the plug-in
will handle requests based on certain characteristics of the request. The Route definition contains the
other main elements: a required ServerCluster, and either a VirtualHostGroup, UriGroup, or both.
Using the information that is defined in the VirtualHostGroup and the UriGroup for the Route, the
plug-in determines if the incoming request to the Web server should be sent on to the ServerCluster
defined in this Route. The plug-in sets scores for Routes if there is a VirtualHost and Uri match for an
incoming request. Once the plug-in processes all Routes, the Route chosen is the one with the
highest score.
ServerCluster, Server:
– The located ServerCluster from the Route tag contains a list of Server tags that in turn contain the
requested object. The ServerCluster located by finding the correct Route can optionally specify the
WLM algorithm. This will then be used to select one Server from within the ServerGroup.
Transport:
– Once a Server has been located, its Transport tags describe how to connect to it.
25
Plug-in workload management policies
Weighted round robin
– When using this algorithm, the plug-in selects a cluster member at random from which
to start. The first successful browser request is routed to this cluster member and then
its weight is decremented by 1. New browser requests are then sent round robin to
the other application servers and subsequently the weight for each application server
is decremented by 1. The spreading of the load is equal between application servers
until one application server reaches a weight of 0. From then on, only application
servers with a weight higher than 0 will have requests routed to them. The only
exception to this pattern is when a cluster member is added or restarted or when
session affinity (next slide) comes into play.
Random
– Requests are passed to cluster members randomly. Weights are not taken into
account as with round robin. The only time the application servers are not chosen
randomly is when there are requests with sessions associated with them. When the
random setting is used, cluster member selection does not take into account where
the last request was handled. This means that a new request could be handled by the
same cluster member as the last request.
26
Plug-in configuration file – Session Affinity
In a clustered environment, any HTTP requests associated with an HTTP
session must be routed to the same Web application in the same JVM.
This ensures that all of the HTTP requests are processed with a
consistent view of the user’s HTTP session.
The exception to this rule is when the cluster member fails or has to be
shut down.
content
value
Cache ID
0000
Session ID SHOQmBQ8EokAQtzl_HYdxIt
separator
:
Clone ID
vuel491u
<?xml version="1.0" encoding="ISO-8859-1"?>
<Config>
......
<ServerCluster Name="MyCluster">
<Server CloneID="vuel491u" LoadBalanceWeight="2"
Name="NodeA_server1">
<Transport Hostname="wan" Port="9080" Protocol="http"/>
<Transport Hostname="wan" Port="9443" Protocol="https">
......
</Config>
27
Plug-in configuration file – Session Failover
Server clusters provide a solution for failure of an application server.
Sessions created by cluster members in the server cluster share a common
persistent session store (Memory or Database).
Any cluster member in the server cluster has the ability to see any user’s session
saved to persistent storage
If one of the cluster members fail, the user can continue to use session information
from another cluster member in the server cluster. This is known as failover.
Failover works regardless of whether the nodes reside on the same machine or
several machines.
28
Java Class Loader
Class loaders enable the Java virtual machine (JVM) to load classes. Given
the name of a class, the class loader locates the definition of this class.
Each Java class must be loaded by a class loader.
When you start a JVM, you use three class
loaders: the Bootstrap class loader
(<JAVA_HOME>/lib), the Extensions class loader
(<JAVA_HOME>/lib/ext), and the System class
loader (CLASSPATH).
The Extensions class loader is the parent for the
System class loader. The Bootstrap class loader is
the parent for the Extensions class loader. The
class loaders hierarchy is shown
Delegation is a key concept to understand when dealing with class loaders
29
ClassLoader behavior example
A class called WhichClassLoader1 loads a class called
WhichClassLoader2, in turn invoking a class called
WhichClassLoader3
If all WhichClassLoaderX classes are put on the system
class path, the three classes are loaded by the System
class loader, and this sample runs just fine.
Now suppose you package the WhichClassLoader2.class
file in a JAR file that you store under
<JAVA_HOME>/lib/ext directory.
As you can image, the program fails with a
NoClassDefFoundError exception, which might sound
strange because WhichClassLoader3 is on the system
class path. The problem is that it is on the wrong class
path.
30
ClassLoader behavior example cont.
The WhichClassLoader2 class was loaded by the Extensions class loader. In
fact, the System class loader delegated the load of the WhichClassLoader2 class
to the Extensions class loader, which delegated the load to the Bootstrap class
loader. Because the Bootstrap class loader could not find the class, the class
loading control was returned to the Extensions class loader. The Extensions
class loader found the class and loaded it.
Now, the Extensions class loader needs to load the WhichClassLoader3 class. It
delegates to the Bootstrap class path, which cannot find the class, then tries to
load it itself and does not find it either.
A NoClassDefFoundError exception is thrown. Once a class is loaded by a class
loader, any new classes that it tries to load reuse the same class loader, or go up
the hierarchy to find a class.
A class loader can only find classes by going up the hierarchy, never down.
31
WebSphere Class Loader policies
The top box in red represents the Java (Bootstrap, Extension and System) class
loaders. WebSphere loads just enough here to get itself bootstrapped and
initialize the WebSphere extension class loader.
The WebSphere extensions class loader is where WebSphere itself is loaded
EJB modules, utility JARs, resource
adapters files, and shared libraries
associated with an application are
always grouped together into the
same class loader. This class loader
is called the Application class loader.
Depending on the application class
loader policy, this application class
loader can be shared by multiple
applications (EARs), or be unique for
each application, which is the default.
32
WebSphere ClassLoader policies cont.
There are settings in WAS that allow you to influence WebSphere class loader
behavior.
– When the application class loader policy is set to Single, a single application class
loader is used to load all EJBs, utility JARs, and shared libraries within the application
server (JVM). If the WAR class loader policy then has been set to Application, the Web
module contents for this particular application are also loaded by this single class loader.
– When the application class loading policy is set to Multiple, the default, each application
will receive its own class loader for loading EJBs, utility JARs, and shared libraries.
Depending on whether the WAR class loader loading policy is set to Module or
Application, the Web module might or might not receive its own class loader.
Single
Multiple
Module
Application
33
WebSphere ClassLoader delegation
WebSphere’s application class loader and WAR class loader both have a setting
called the class loader mode.
There are two possible values for the class loader mode: PARENT_FIRST and
PARENT_LAST
PARENT_FIRST. This mode causes the class loader to first delegate the loading
of classes to its parent class loader before attempting to load the class from its
local class path. This is the default policy for standard Java class loaders.
PARENT_LAST, the class loader attempts to load classes from its local class
path before delegating the class loading to its parent. This policy allows an
application class loader to override and provide its own version of a class that
exists in the parent class loader.
34
JNDI
WebSphere Application Server provides a JNDI implementation that you
can use to access CosNaming name servers through the JNDI interface
CosNaming provides the server-side implementation and is where the
name space is stored.
JNDI essentially provides a client-side wrapper of the name space stored
in CosNaming, and interacts with the CosNaming server on behalf of the
client.
WebSphere application clients use the naming service to obtain
references to objects related to those applications, such as EJB homes.
These objects are bound into a mostly hierarchical structure, referred to
as a name space.
In this structure, all non-leaf objects are called contexts.
35
JNDI
Naming operations, such as lookups and binds, are performed on
contexts.
All naming operations begin with obtaining an initial context. You can
view the initial context as a starting point in the name space. For
example:
– The name myApp/myEJB consists of one non-leaf binding with the name myApp,
which is a context.
– The name also includes one leaf binding with the name myEJB, relative to myApp.
The object bound with the name myEJB in this example happens to be an EJB home
reference.
– The whole name myApp/myEJB is relative to the initial context, which can be viewed
as a starting place when performing naming operations.
36
JNDI
The name space can be accessed and manipulated through a name server.
Users of a name server are referred to as naming clients
Naming clients typically use Java Naming and Directory Interface (JNDI) to
perform naming operations. Naming clients can also use the Common Object
Request Broker Architecture (CORBA) CosNaming interface.
Notice that all WebSphere
Application Server processes host
their own naming service and local
name space (remove bottleneck)
37
JNDI
There are three options available for binding EJB (<ejb-ref>) and resource
(<resource-ref>) object names to the WebSphere Application Server name
space:
– Simple name -- ejb/webbank/Account
– Compound/fully qualified name -- cell/nodes/node1/servers/server1/ejb/webbank/Account
– Corbaname -- corbaname::myhost1:9812/NameServiceServerRoot#ejb/webbank/Account
The binding you can use to look up an object depends on whether or not the
application is running within the same application server.
38
JNDI - Federated namespace
The system partition is a reflection of the cell topology and is read-only. This part of the name
space cannot be changed programmatically, because it is based on the configuration rather
than runtime settings.
The persistent partitions are primarily for the
storage of resource configuration, such as data
sources, JMS destinations etc.
Cell persistent root. This partition is used
to register persistent objects that are
available to all the nodes and managed
processes of a cell.
Node persistent root. This partition is
used to register persistent objects available
to the nodes and it their managed
processes.
The server root transient partition is updateable through APIs, and is meant for
information such as EJB bindings and JNDI names. This name space is
transient and bindings are created each time a server process starts. It reads
configuration data from the file system, for example EJB deployment
descriptors, to register the necessary objects in this space.
39
JNDI example (1)
40
JNDI example (2)
41
JDBC Resource
A data source represents a real-world data source, such as a relational
database.
When a data source object has been registered with a JNDI naming
service, an application can retrieve it from the naming service and use it
to make a connection to the data source it represents
Information about the data source and how to locate it, such as its name,
the server on which it resides, its port number, and so on, is stored in the
form of properties on the DataSource object. This makes an application
more portable because it does not need to hard code a driver name,
which often includes the name of a particular vendor
The connection is usually a pooled connection. That is, once the
application closes the connection, the connection is returned to a
connection pool, rather than being destroyed.
Data source classes and JDBC drivers are implemented by the data
source vendor.
42
JDBC Resource
The programming model for accessing a data source is as follows:
– 1. An application retrieves a DataSource object from the JNDI naming space.
– 2. After the DataSource object is obtained, the application code calls getConnection()
on the data source to get a Connection object. The connection is obtained from a pool
of connections.
– 3. Once the connection is acquired, the application sends SQL queries or updates to
the database.
– 4. Once the application component is finished with the connection, it calls the close()
method on the connection. Closing a connection handle should not close the physical
connection to the EIS.
43
JDBC Resource
In WebSphere Application Server, connection pooling is provided by two parts, a
JCA Connection Manager and a relational resource adapter

The JCA Connection Manager provides connection pooling, local transaction,
and security support
The relational resource adapter provides JDBC wrappers and the JCA CCI
implementation that allows BMP, JDBC applications, and CMP beans to access
the database
44
JDBC Resource – Connection Pooling
WebSphere® Application Server provides connection pooling for Java Database
Connectivity (JDBC), Java™ Message Service (JMS), and Enterprise Information
System (EIS) connections.
The purpose of pooling connections is to improve performance by reducing the
overhead involved in creating a new connection every time the application
requests one.
For JDBC connections, there is one connection pool for each data source that is
created in WebSphere Application Server
45
Web Services for J2EE (JAX-RPC and WSEE)
JAX-RPC (JSR-101) provides the programming model for SOAP-based
applications by abstracting the runtime details and providing mapping services
between Java and WSDL.
Web Services for J2EE Specification (WSEE JSR-109) adds additional artifacts
to those defined by JAX-RPC and brings JAX-RPC to the J2EE container.
WSEE defines the required architecture for Web services for the Java 2 Platform
Enterprise Edition (J2EE) environment.
WSEE standardizes the packaging, deployment, and programming model for
Web services in a J2EE environment.
Although WSEE does not restrict any implementation, it only defines two:
– Stateless session EJB in an EJB container
– Java class running in a Web container
46
JAX-RPC Client
A JAX-RPC client is capable of invoking a Web service irrespective of whether
the service has been defined on the J2EE platform or on a non-Java platform.
JAX-RPC clients can run inside a J2EE container or as a stand-alone Java
client.
There are three types of Web services clients:
– Static stub
– Dynamic proxy
– Dynamic invocation interface (DII)
47
JAX-RPC Client – Static Stub
After the proxy classes have been generated, they are copied to the client
machine. The client can then invoke the Web service based only on these proxy
classes.
These proxy classes are generated from the WSDL of the Web service.
– In WebSphere Application Server, the proxy classes can be generated by the tool
<WAS_HOME>/bin/WSDL2JAVA.
48
JAX-RPC Client – Static Stub, calling sequence
1. The client instantiates the service locator
(WeatherForecastServiceLocator.java)
2. The client calls the service locator to retrieve the Service Endpoint
Interface (an instance of the client stub that implements the SEI is
returned).
3. The client invokes a Web service through the SEI.
49
WSEE Client – Static Stub, calling sequence
1. The client makes an JNDI lookup to get an instance of the service object,
which implements a service interface.
2. The client uses a factory method of the service object to retrieve the client
stub. The client stub implements the SEI.
3. The client invokes the Web service through the SEI.
The configurations for the Web service client and server side are represented by
the client and server deployment descriptor shown at the bottom
50
JAX-RPC Client – Dynamic Proxy and DII
Dynamic Proxy
In dynamic proxy clients, the default destination of the Web service can be
changed in the client by specifying a different destination in the client application.
At runtime the service locator is instantiated. The SEI is retrieved using a
destination (QName).
Dynamic invocation interface (DII) - (limited support in WAS)
DII is used when the WSDL of the Web service can change considerably over
time. DII-based clients do not use proxy classes, but instead they read the entire
WSDL file during runtime:
–
–
–
–
Instantiate a DII service class.
Instantiate a Call object (Call is a class provided by JAX-RPC).
Populate the Call object.
Invoke the Web service operation on the Call object.
51
WSEE Server Container responsability
A server container provides a JAX-RPC runtime environment for invoking Web
services ports. The container is responsible for:
–
–
–
–
–
–
–
–
–
Listening to Web services SOAP HTTP requests
Parsing the inbound message
Mapping the messages to the implementation class and method
Creating Java objects from the SOAP envelope
Invoking the service implementation bean handlers and instance methods
Capturing the response
Mapping the Java response objects into a SOAP message
Creating the message envelope
Sending the message to the client
52
SOAP over HTTP request
The client request to the Java proxy is handled by the SOAP client and is routed
to the server over HTTP.
In the server, the WebSphere SOAP engine calls a JavaBean Web service as a
servlet, or uses a servlet in a Web router module to invoke an EJB Web service.
53
References
http://www.redbooks.ibm.com
54
IBM Italia SpA
Thank You
Marco Dragoni
© 2007 IBM Corporation