UNIT4

UNIT 4
Page 1
UNIT 4
SOA platform basics

SOA support in J2EE
Java API for XML-based web services (JAX-WS)
Java architecture for XML binding (JAXB)
Java API for XML Registries (JAXR)
Java API for XML based RPC (JAX-RPC)
Web Services Interoperability Technologies (WSIT)
SOA support in .NET
Common Language Runtime
ASP.NET web forms
ASP.NET web services
Web Services Enhancements (WSE)
Page 2
SOA platform basics
establish the physical development and runtime
environments required to build and implement
SOA-compliant services.
Basic platform building blocks
Need a development environment with which to
program and assemble the software program.
Need a runtime for which we will be designing our
software.
Need APIs that expose features and functions offered
by the runtime so that we can build software
program.
Finally, need an operating system on which to deploy
the runtime, APIs, and the software program.
Page 3
Page 4
Common SOA platform layers
contemporary SOA is a distributed architectural
model, built using Web services that provides support
for the Web services technology set.
Two new requirements:
We need the ability to partition software programs into self-
contained and composable units of processing logic
(components) capable of communicating with each other
within and across instances of the runtime.
We need the ability to encapsulate and expose application

logic through industry standard Web services technologies.
Page 5
The common layers required by a development
and runtime platform for building SOA.
Page 6
Relationship between SOA layers and technologies
The Web Technology layer needs to provide support for the first-
generation Web services technology set to enable to build a
primitive SOA.
The Web Technology layer needs to provide support for WS-*
specifications for fulfill some of the contemporary SOA
characteristics.
The Web Technology layer needs to provide a means of
assembling and implementing its technology support into Web
services.
The Component Technology layer needs to support
encapsulation by Web services.
The Runtime layer needs to be capable of hosting components
and Web services.
The Runtime layer needs to provide a series of APIs in support
of components and Web services.
The APIs layer needs to provide functions that support the
development and processing of components and Web services
technologies.
Page 7
Page 8
Fundamental service technology architecture
Service processing tasks
Supply a public interface (WSDL definition) that allows it to be
accessed and invoked by a service requestor.
Receive a SOAP message sent to it by a service requestor.
Process the header blocks within the SOAP message.
Validate and parse the payload of the SOAP message.
Transform the message payload contents into a different format.
Encapsulate business processing logic that will do something
with the received SOAP message contents.
Assemble a SOAP message containing the response to the
original request SOAP message from the service requestor.
Transform the contents of the message back into the format
expected by the service requestor.
Transmit the response SOAP message back to the service
requestor.
Page 9
service requestor
It can be any piece of software capable of
communicating with a service provider.
Service requestors are commonly expected to:
Contain business processing logic that calls a service
provider for a particular reason.
Interpret (and possibly discover) a service provider's WSDL
definition.
Assemble a SOAP request message in compliance with the
service provider WSDL definition.
Transform the contents of the SOAP message.
Transmit the SOAP request message to the service provider.
Receive a SOAP response message from the service
provider.
Validate and parse the payload of the SOAP response
message received by the service provider.
Transform the SOAP payload into a different format.
Process SOAP header blocks within the message.
Page 10
Service processing logic
The contents of the SOAP request are used to
perform some function that may result in a response.
service provider and requestor tasks into two distinct
categories.
Message Processing Logic
Business Logic
Message Processing Logic

The part of a Web service and its surrounding environment that
executes a variety of SOAP message processing tasks.
Message processing logic is performed by a combination of

runtime services, service agents, as well as service logic
related to the processing of the WSDL definition.
Page 11
Business Logic
Business logic is application-specific and depending on the
functionality exposed by the WSDL definition.
The back-end part of a Web service that performs tasks in
response to the receipt of SOAP message contents.
For example, business logic can consist of a single
component providing service-specific functions, or it can be
represented by a legacy application that offers only some of
its functions via the Web service.
Page 12
Service provider logic categorization.
Page 13
A revised service provider model including
an endpoint within the message
processing logic.
Page 14
The business logic
part of a service
requestor is
responsible for
initiating an activity
(and the resulting
SOAP message
exchange),
whereas the
business logic within
a service provider
responds to an
already initiated
activity.
Page 15
Service requestor logic categorization
Page 16
Message processing logic of a service.
processing layers
represented by the message
processing logic of a service
provider.
layers tasks, such as

header processing-that are
generic and applied to all
service providers.
Validation or transformation
tasks,
on the other hand, may

involve service-specific XSD
schemas and XSLT
stylesheets and therefore
may be considered exclusive
to the service provider
Page 17
Vendor platforms accomplish this by supporting the
creation of proxy components. These components is
auto-generated from the service provider WSDL
definition.
Proxies accept method calls issued from the regular

vendor platform components that contain the service
requestor business logic.
The proxies then use vendor runtime services to

translate these method calls and associated parameters
into SOAP request messages. When the SOAP request
is transmitted, the proxy is further able to receive the
corresponding SOAP response from the service
provider. It then performs the same type of translation,
but in reverse.
Proxies can exist as static components or they can be

dynamically created.
Page 18
Page 19
Business logic
business logic can exist as a standalone
component, housing the intelligence required
to either invoke a service provider as part of a
business activity or to respond to a request in
order to participate in such an activity.
As an independent unit of logic, it is free to act

in different roles.
Page 20
shows same unit of business logic being
encapsulated as part of a service provider but also
acting as a service requestor.
Page 21
Page 22
Service agents
A type of software program found within the message
processing logic of SOA platforms is the service
agent.
Its primary role is to perform form of automated

processing prior to the transmission and receipt of
SOAP messages. As such, service agents are a form
of intermediary service.
The types of tasks performed by service agents

include:
SOAP header processing
filtering (based on SOAP header or payload content)
authentication and content-based validation
logging
routing
Page 23
Service agents processing incoming and
outgoing SOAP message headers.
Page 24
Vendor platforms
SOA support provided by both J2EE and .NET platforms.
Architecture components
Runtime environments
Programming languages
APIs
Service providers
Service requestors
Service agents
Platform extensions
Page 25
SOA support in J2EE
The Java 2 Platform Enterprise Edition (J2EE) is one of
the two primary platforms currently being used to
develop enterprise solutions using Web services.
Platform overview
The Java 2 Platform is a development and runtime environment
based on the Java programming language.
It is a standardized platform that is supported by many vendors

that provide development tools, server runtimes, and middleware
products for the creation and deployment of Java solutions.
The Java 2 Platform is divided into three major development and

runtime platforms,.
J2SE -The Java 2 Platform Standard Edition is designed to support
the creation of desktop applications,
J2ME - the Micro Edition (J2ME) is geared toward applications that
run on mobile devices.
J2EE -The Java 2 Platform Enterprise Edition is built to support
large-scale, distributed solutions.
Page 26
The Servlets +
EJBs and Web +
EJB Container
layers (as well as
the JAX-RPC
Runtime) relate to
the Web and
Component
Technology layers
established
Page 27
Three of the more significant specifications that pertain
to SOA are listed here:
Java 2 Platform Enterprise Edition Specification

This important specification establishes the distributed J2EE
component architecture and provides foundation standards .
Java API for XML-based RPC (JAX-RPC)

This document defines the JAX-RPC environment and associated
core APIs. It also establishes the Service Endpoint Model used to
realize the JAX-RPC Service Endpoint.
Web Services for J2EE

The specification that defines the J2EE service architecture and
clearly lays out what parts of the service environment can be built
by the developer, implemented in a vendor-specific manner, and
which parts must be delivered according to J2EE standards.
Page 28
J2EE solutions inherently are distributed and
therefore componentized.
The following types of components can be used to
build J2EE Web applications:
Java Server Pages (JSPs)
Dynamically generated Web pages hosted by the Web server.
JSPs exist as text files comprised of code interspersed with
HTML.
Java Servlets
These components also reside on the Web server and are used
to process HTTP request and response exchanges.
Enterprise JavaBeans (EJBs)
The business components that perform the bulk of the
processing within enterprise solution environments.
They are deployed on dedicated application servers and can
therefore leverage middleware features, such as transaction
support.
Page 29
Struts
An extension to J2EE that allows for the development
of Web applications with sophisticated user-interfaces
and navigation.
Struts provides its own Controller component and

integrates with other technologies to provide the
Model and the View. For the Model,
Struts can interact with standard data access
technologies, like JDBC and EJB, as well as most
any third-party packages, like Hibernate, iBATIS,
or Object Relational Bridge.
For the View, Struts works well with JavaServer
Pages, including JSTL and JSF, as well as XSLT,
and other presentation systems.
Page 30
J2EE supply two types of component containers that
provide hosting environments geared toward Web
services-centric applications that are generally EJB or
servlet-based.
EJB container
This container is designed specifically to host EJB components,
and it provides a series of enterprise-level services that can be
used collectively by EJBs participating in the distributed
execution of a business task.
Examples of these services include
transaction management,
concurrency management,
operation-level security,
object pooling.
Web container
A Web container can be considered an extension to a Web
server and is used to host Java Web applications consisting of
JSP or Java servlet components.
Web containers provide runtime services geared toward the
processing of JSP requests and servlet instances.
Page 31
The standard Java language can be used to
build Web services.
Examples of currently available development

tools are
Rational Application Developer from IBM,
Java Studio from Sun Microsystems,
JDeveloper from Oracle.
Page 32
APIs
J2EE contains several APIs for programming functions
in support of Web services. The classes that support
these APIs are organized into a series of packages.
Here are some of the APIs relevant to building SOA.
Java API for XML Processing (JAXP)
This API is used to process XML document content using a
number of available parsers.
Both Document Object Model (DOM) and Simple API for XML
(SAX) compliant models are supported, as well as the ability to
transform and validate XML documents using XSLT stylesheets
and XSD schemas. Example packages include:
~javax.xml.parsers
A package containing classes for different vendor-specific
DOM and SAX parsers.
~org.w3c.dom and org.xml.sax-These packages expose the
industry standard DOM and SAX document models.
~javax.xml.transform-A package providing classes that
expose XSLT transformation functions.
Page 33
Java API for XML-based RPC (JAX-RPC)
The most established and popular SOAP processing API,
supporting both RPC-literal and document-literal request-response
exchanges and one-way transmissions. Example packages that
support this API include:
~javax.xml.rpc and javax.xml.rpc.server

These packages contain a series of core functions for the JAX-RPC
API.
~javax.xml.rpc.handler and javax.xml.rpc.handler.soapAPI

functions for runtime message handlers are provided by these
collections of classes.
~javax.xml.soap and javax.xml.rpc.soapAPI

functions for processing SOAP message content and bindings.
Page 34
Java API for XML Registries (JAXR)
An API that offers a standard interface for
accessing business and service registries.
Originally developed for ebXML directories,
JAXR now includes support for UDDI.
~javax.xml.registry
A series of registry access functions that support the
JAXR API.
~javax.xml.registry.infomodel
Classes that represent objects within a registry.
Page 35
Java API for XML Messaging (JAXM)
An asynchronous, document-style SOAP messaging API that
can be used for one-way and broadcast message transmissions.
SOAP with Attachments API for Java (SAAJ)
Provides an API specifically for managing SOAP messages
requiring attachments. The SAAJ API is an implementation of the
SOAP with Attachments (SwA) specification.
Java Architecture for XML Binding API (JAXB)
This API provides a means of generating Java classes from XSD
schemas and further abstracting XML-level development.
Java Message Service API (JMS)
A Java-centric messaging protocol used for traditional
messaging middleware solutions and providing reliable delivery
features.
Page 36
Service providers
J2EE Web services are typically implemented as servlets or EJB
components. Each option is suitable to meet different
requirements but also results in different deployment
configurations, as explained here:
JAX-RPC Service Endpoint When building Web services for use

within a Web container, a JAX-RPC Service Endpoint is developed
that frequently is implemented as a servlet by the underlying Web
container logic. Servlets are a common incarnation of Web services
within.
EJB Service Endpoint The alternative is to expose an EJB as a Web

service through an EJB Service Endpoint. This approach is
appropriate when wanting to encapsulate existing legacy logic or
when runtime features only available within an EJB container are
required.
Regardless of vendor platform, both types of J2EE Web services

are dependent on the JAX-RPC runtime and associated APIs.
Page 37
The implementation of a J2EE service provider,
including:
Service Endpoint Interface (SEI)
A Java-based interpretation of the WSDL definition that is
required to follow the JAX-RPC WSDL-to-Java mapping rules
to ensure consistent representation.
Service Implementation Bean

A class that is built by a developer to house the custom
business logic of a Web service.
The Service Implementation Bean can be implemented as an
EJB Endpoint (Stateless Session Bean) or a JAX-RPC
Endpoint (servlet).
For an EJB Endpoint, it is referred to as an EJB Service
Implementation Bean and therefore resides in the EJB
container.
For the JAX-RPC Endpoint, it is called a JAX-RPC Service
Implementation Bean and is deployed in the Web container.
Page 38
Page 39
Service requestors
The JAX-RPC API also can be used to develop service
requestors. It provides the ability to create three types of client
proxies, as explained here:
Generated stub
The generated stub (or just "stub") is the most common form of service
client. It is auto-generated by the JAX-RPC compiler (at design time) by
consuming the service provider WSDL, and producing a Java-equivalent
proxy component.
Specifically, the compiler creates a Java remote interface for every

WSDL portType which exposes methods. It further creates a stub based
on the WSDL port and binding constructs. The result is a proxy
component that can be invoked as any other Java component.
JAX-RPC takes care of translating communication between the proxy

and the requesting business logic component into SOAP messages
transmitted to and received from the service provider represented by the
WSDL.
Dynamic proxy and dynamic invocation interface

The dynamic proxy is similar in concept, except that the actual stub is not
created until its methods are invoked at runtime.
Secondly, the dynamic invocation interface bypasses the need for a

physical stub all together and allows for fully dynamic interaction
between a Java component and a WSDL definition at runtime.
Page 40
Page 41
Service agents
Vendor implementations of J2EE platforms often
employ numerous service agents to perform a variety
of runtime filtering, processing, and routing tasks.
A common example is the use of service agents to process
SOAP headers.
To support SOAP header processing,

the JAX-RPC API allows for the creation of specialized
service agents called handlers ,runtime filters that exist the
J2EE container environments.
Handlers can process SOAP header blocks for messages

sent by J2EE service requestors or for messages received by
EJB Endpoints and JAX-RPC Service Endpoints.
Page 42
J2EE handlers as service agents.
Page 43
Platform extensions
Two examples of currently available platform
extensions.
IBM Emerging Technologies Toolkit
A collection of extensions that provide prototype
implementations of a number of fundamental WS-* extensions,
including
WS-Addressing,
WS-ReliableMessaging,
WS-MetadataExchange,
WS-Resource Framework.
Java Web Services Developer Pack
A toolkit that includes both WS-* support as well as the
introduction of new Java APIs.
Examples of the types of extensions provided include
WS-Security (along with XML-Signature), and
WS-I Attachments.
Page 44
Primitive SOA support
Service encapsulation
Loose coupling
Messaging
Support for service-orientation principles
Autonomy
Reusability
Statelessness
Discoverability
Contemporary SOA support
Based on open standards
Supports vendor diversity
Intrinsically interoperable
Promotes federation
Architecturally composable
Extensibility
Supports service-oriented business modeling
Logic-level abstraction
Organizational agility and enterprise-wide loose coupling
Page 45
How parts of the J2EE platform inter-relate.
Page 46
The Servlets + EJBs and Web + EJB
Container layers (as well as the JAX-RPC
Runtime) relate to the Web and
Component Technology layers established
Page 47
Page 48
JAX-WS- Java API for XML Web Services
Building Web Services with JAX-WS

JAX-WS is a technology for building web services and clients
that communicate using XML. JAX-WS allows developers to
write message-oriented as well as RPC-oriented web services.
In JAX-WS, a web service operation invocation is represented by

an XML-based protocol such as SOAP. calls and responses are
transmitted as SOAP messages (XML files) over HTTP.
On the server side, the developer specifies the web service

operations by defining methods in an interface written in the
Java programming language. A client creates a proxy and then
simply invokes methods on the proxy.
With JAX-WS, the developer does not generate or parse SOAP

messages. It is the JAX-WS runtime system that converts the
API calls and responses to and from SOAP messages.
Page 49
Communication between a JAX-WS Web Service
and a Client
Page 50
Creating a Simple Web Service and Client with JAX-
WS
The starting point for developing a JAX-WS web service is a

Java class annotated with the javax.jws.WebService
annotation. The @WebService annotation defines the class
as a web service endpoint.
A service endpoint interface or service endpoint

implementation (SEI) is a Java interface or class,
respectively, that declares the methods that a client can
invoke on the service. The web service implementation
class implicitly defines an SEI.
we may specify an explicit interface by adding the

endpointInterface element to the @WebService annotation
in the implementation class. we must then provide an
interface that defines the public methods made available in
the endpoint implementation class.
Page 51
Basic steps for creating the web service
and client:
Code the implementation class.
Compile the implementation class.
Package the files into a WAR file.
Deploy the WAR file. Using Application Server
Code the client class.
Use wsimport to generate and compile the
web service proxy needed to connect to the
service.
Compile the client class.
Run the client.
Page 52
Requirements of a JAX-WS Endpoint
The implementing class must be annotated with either
the
javax.jws.WebService or
javax.jws.WebServiceProvider annotation.
The implementing class may explicitly reference an
SEI through the endpointInterface element of the
@WebService annotation,
The business methods of the implementing class
must be public
Business methods that are exposed to web service
clients must be annotate with javax.jws.WebMethod.
Business methods that are exposed to web service
clients must have JAXB-compatible parameters and
return types.
Page 53
package helloservice.endpoint;
import javax.jws.WebService;
@WebService
public class Hello {
private String message = new String("Hello, ");
public void Hello() {}
@WebMethod
public String sayHello(String name) {
return message + name + ".";
}
}
Page 54
Testing the Service without a Client
Click Web Services in the left pane of the
project in netbeans.
Click Hello.
Right Click Test on web service.
Under Method returned, display the response
from the endpoint.
Page 55
Coding the Client
Uses the javax.xml.ws.WebServiceRef annotation to
declare a reference to a web service.
@WebServiceRef uses the wsdlLocation element to
specify the URI of the deployed services WSDL file.
@WebServiceRef(wsdlLocation="http://localhost:808
0/helloservice/hello?wsdl")
static HelloService service;
Retrieves a proxy to the service, also known as a
port, by invoking getHelloPort on the service.
Hello port = service.getHelloPort();
Invokes the ports sayHello method, passing to the
service a name.
String response = port.sayHello(name);
Page 56
JAXB
A Java API called Java Architecture for XML Binding (JAXB) can
make it easier to access XML documents from applications
written in the Java programming language.
Java developers can invoke a SAX or DOM parser in an application

through the JAXP API to parse an XML document.
SAX approach,
This parser starts at the beginning of the document and passes
each piece of the document to the application in the sequence it
finds it.
DOM approach
This parser creates a tree of objects that represents the content
and organization of data in the document.
The application can then navigate through the tree to access the
data it needs, and if appropriate, manipulate it.
Page 57
Accessing an XML Document
Bind the Schema
Unmarshal the Document
Building an XML Document
Bind the Schema
Create the Content Tree
Marshal the Content Tree
Validate an XML Document
Unmarshall the XML Document
Page 58
JAXB Architecture
Page 59
A JAXB implementation consists of the following
architectural components:
Schema compiler:
Binds a source schema to a set of schema-derived program
elements. The binding is described by an XML-based binding
language.
Schema generator:
Maps a set of existing program elements to a derived
schema. The mapping is described by program annotations.
Binding runtime framework:
Provides unmarshalling (reading) and marshalling (writing)
operations for accessing, manipulating, and validating XML
content using either schema-derived or existing program
elements.
Page 60
JAXB Binding Process
Page 61
The general steps in the JAXB data binding
process are:
Bind the schema for the XML document.
Binding: Binding a schema means generating a set of Java
classes that represents the schema.
All JAXB implementations provide a tool called a binding
compiler to bind a schema
The binding compiler generates a set of interfaces and a set
of classes that implement the interfaces
Generate classes:
An XML schema is used as input to the JAXB binding compiler
to generate JAXB classes based on that schema.
Compile classes:
All of the generated classes, source files, and application code
must be compiled.
Page 62
Unmarshal:
XML documents written according to the constraints in the
source schema are unmarshalled by the JAXB binding
framework.
Unmarshalling provides a client application the ability to

convert XML data into JAXB-derived Java objects
The content objects are instances of the classes produced by

the binding compiler.
Generate content tree:

The unmarshalling process generates a content tree of data
objects instantiated from the generated JAXB classes
This content tree represents the structure and content of the

source XML documents.
Page 63
Validate (optional):
The unmarshalling process optionally involves validation of the
source XML documents before generating the content tree.
Process content:
The client application can modify the XML data represented by
the Java content tree by means of interfaces generated by the
binding compiler.
Marshal:
The processed content tree is marshalled out to one or more
XML output documents. The content may be validated before
marshalling.
Marshalling provides a client application the ability to convert a
JAXB-derived Java object tree back into XML data.
By default, the Marshaller uses UTF-8 encoding when
generating XML data.
Page 64
The APIs are provided as part of a binding framework.
The binding framework comprises three packages.

javax.xml.bind
contains classes and interfaces for performing operations such
as unmarshalling, marshalling, and validation.
javax.xml.bind.util
contains a number of utility classes.
javax.xml.bind.helper
is designed for JAXB implementation providers.
Page 65
// create books
Book book1 = new Book();
book1.setIsbn("978-0060554736");
book1.setName("The Game");
book1.setAuthor("Neil Strauss");
book1.setPublisher("Harpercollins"); bookList.add(book1);
Book book2 = new Book();
book2.setIsbn("978-3832180577");
book2.setName("Feuchtgebiete");
book2.setAuthor("Charlotte Roche");
book2.setPublisher("Dumont Buchverlag"); bookList.add(book2);
// create bookstore, assigning book

Bookstore bookstore = new Bookstore();
bookstore.setName("Fraport Bookstore");
bookstore.setLocation("Frankfurt Airport");
bookstore.setBookList(bookList);
Page 66
private static final String BOOKSTORE_XML = "./bookstore-jaxb.xml";
// create JAXB context and instantiate marshaller
JAXBContext context = JAXBContext.newInstance(Bookstore.class);
Marshaller m = context.createMarshaller();
m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT,
Boolean.TRUE);
m.marshal(bookstore, System.out);
Writer w = null;
w = new FileWriter(BOOKSTORE_XML);
m.marshal(bookstore, w);
// get variables from our xml file, created before

System.out.println("Output from our XML File: ");
Unmarshaller um = context.createUnmarshaller();
Bookstore bookstore2 = (Bookstore) um.unmarshal(new FileReader(
BOOKSTORE_XML));
bookstore2.getBooksList().get(i).getName()
Page 67
Distinct Advantages
JAXB simplifies access to an XML document from a
Java program:
JAXB uses memory efficiently:
JAXB is flexible:
JAXB's binding behavior can be customized in a
variety of ways.
Page 68
JAX-RPC
Page 69
JAX-RPC
Topics
What is RPC?
JAX-RPC introduction
Creating JAX-RPC based web service
Creating JAX-RPC based web service client
Java-XML mapping for web service
Sample code basic web service and client based on
JAX-RPC
Page 70
What is RPC?
Remote Procedure Call

Term that refers to a program calling a function that resides on another
computer as if the function was local
RPC mechanism handles networking and packaging of data-parameter
and return value-
..some code..
Function() Function()
code..
RPC code Proprietary protocol RPC code
client server
Page 71
Shortcomings of (traditional) RPC
Proprietary protocol
Client and server needs to be using the same programming language
Not suitable for internet
No OO way of calling method
Page 72
RPC in Java Web Service
RPC in Java Web Service (jws) uses XML/SOAP-open standard-

Client and server both may be developed using different programming
language
RPC protocol is open standard
Service SOAP Invoke Service

requestor service provider
Page 73
Disadvantages of RPC in web service
Overhead of text formatted data exchange

Slower than traditional RPC
Currently web services are primarily uses HTTP to exchange data and
hence involves network connection overhead
Page 74
What is JAX-RPC?
JAX-RPC: Java APIs for XML based Remote Procedure Call

APIs for creating RPC based web services and a runtime environment for
web services applications
Web services Web services

client server
JAX-RPC JAX-RPC
APIs classes
JAX-RPC JAX-RPC
runtime SOAP runtime
Page 75
JAX-RPC introduction
JAX-RPC defines an APIs framework to create and deploy web service

client and server
Web service provider/server use JAX-RPC classes/interfaces to define
service end point (methods)
JAX-RPC supports exposing business methods as service
Web service requestor/client use JAX-RPC classes/interfaces to connect to
and make method/service call
JAX-RPC also comes with tool to create WSDL document from service
classes
JAX-RPC comes with tool to create classes to support client to use service
JAX-RPC defines mapping between Java and WSDL
Page 76
JAX-RPC architecture based on JWSDP
WSDL
document JWSDP
J2SE
Web services Web services
client server
Stubs/
Dyanmic proxy/
Tie classes
DII
JAX-RPC JAX-RPC
runtime SOAP
runtime
Page 77
JAX-RPC application architecture consist of following

JAX-RPC service
Business component implemented in Java
Can be accessed by non-Java client as well as Java client
Currently the service is deployed as Java servlet or EJB stateless
bean
public class DateServiceImpl implements DateServiceIF {
public String currentDate() {

.................
}
}
Page 78
JAX-RPC service
Web server
SOAP request JAXRPCEndpoint Web

servlet service
SOAP
response
Page 79
JAX-RPC service client

Client that can access service
Invocation model how service is accessed
WSDL
Stub based accesses local Java classes
Dynamic proxy
Dynamic Invocation Interface xrpcc
or
Client can use WSDL to generate stub classes wscompile
Java client Stub classes
Page 80
Serialization and deserialization

JAX-RPC serializes (converts) Java data type to XML (SOAP) and
deserializes from XML to Java
Custom data types (custom Java classes) can also be
serialized/deserialized
Page 81
xrpcc or wscompile tool

Used for
1. Creating WSDL from web service class
2. Creating stubs from WSDL for client
3. Creating classes for server side
Page 82
JAX-RPC Server Side
package helloservice;
The service
import java.rmi.Remote; endpoint
interface
Import java.rmi.RemoteException;
public interface HelloIF extends Remote {
public String sayHello(String s) throws
RemoteException;
}
Page 83
Implement the service
package helloservice;
public class HelloImpl implements HelloIF {

public String message ="Hello";
public String sayHello(String s) {
return message + s;
}
}
Page 84
Provide a config-interface.xml
<?xml version="1.0" encoding="UTF-8"?>
<configuration
xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config">
<service
name="MyHelloService"
targetNamespace="urn:Foo"
typeNamespace="urn:Foo"
packageName="helloservice">
<interface name="helloservice.HelloIF"/>
</service>
</configuration>
Page 85
Three steps to build
1. compile-service
2. generate-wsdl
3. generate-mapping from service classes
package names to namespace URIs in
the WSDL and create ties (skeletons)
J2EE1.4 provides an ant task to perform all

three steps
Page 86
On the client side
1. Static stubs
compiled by wscompile before runtime
2. Dynamic stubs
has an interface but fetches the WSDL at runtime
3. Dynamic Invocation Interface
knows no interface - the method names
and signatures
4. A J2EE Application Client
Locate the local web service with JNDI
Page 87
J2EE Application Client
import javax.xml.rpc.Stub;
import javax.naming.*;
public class HelloClient {
private String endpointAddress;
public static void main(String[] args) {

Ask JNDI for a
System.out.println("Endpoint address = " + args[0]); reference to a
stub for the object
try {
Context ic = new InitialContext();
MyHelloService myHelloService = (MyHelloService)
ic.lookup("java:comp/env/service/MyJAXRPCHello");
Page 88
HelloIF helloPort = myHelloService.getHelloIFPort();
((Stub)helloPort)._setProperty
(Stub.ENDPOINT_ADDRESS_PROPERTY,args[0]);
System.out.println(helloPort.sayHello("Jake!"));
System.exit(0);
} catch (Exception ex) {

ex.printStackTrace();
System.exit(1);
}
}
}
Page 89
JAXR
Page 90
What Is a Registry?
An XML registry is an infrastructure that
enables the building, deployment, and
discovery of Web services.
It is a neutral third party that facilitates

dynamic and loosely coupled business-to-
business (B2B) interactions.
A registry is available to organizations as a

shared resource, often in the form of a Web-
based service.
Page 91
XML registries
The ebXML Registry and Repository standard
The Universal Description, Discovery, and

Integration (UDDI) project, which is being
developed by a vendor consortium
A registry provider is an implementation of a

business registry that conforms to a
specification for XML registries.
Page 92
What Is JAXR?
JAXR enables Java software programmers to use a
API to access a variety of XML registries.
A unified JAXR information model describes content

and metadata within XML registries.
JAXR gives developers the ability to write registry

client programs that are portable across different
target registries.
The current version of the JAXR specification

includes detailed bindings between the JAXR
information model and both the ebXML Registry and
the UDDI version 2 specifications
Page 93
JAXR Architecture
The architecture of JAXR consists of the
following parts:
A JAXR client:
a client program that uses the JAXR API to access a
business registry via a JAXR provider.
A JAXR provider:
an implementation of the JAXR API that provides access
to a specific registry provider or to a class of registry
providers that are based on a common specification.
Page 94
A JAXR provider implements two main
packages:
javax.xml.registry
which consists of the API interfaces and classes
that define the registry access interface.
javax.xml.registry.infomodel
which consists of interfaces that define the
information model for JAXR.
The basic interface in this package is the
RegistryObject interface. Its subinterfaces include
Organization, Service, and ServiceBinding.
Page 95
Basic interfaces in the javax.xml.registry
package are
Connection
The Connection interface represents a client session with a
registry provider. The client must create a connection with the
JAXR provider in order to use a registry.
RegistryService
The client obtains a RegistryService object from its
connection. The RegistryService object in turn enables the
client to obtain the interfaces it uses to access the registry.
BusinessQueryManager
which allows the client to search a registry for information in
accordance with the javax.xml.registry.infomodel interfaces.
DeclarativeQueryManager
allows the client to use SQL syntax for queries.
BusinessLifeCycleManager
which allows the client to modify the information in a registry
by either saving it (updating it) or deleting it.
Page 96
Methods
JAXRException
When an error occurs, JAXR API methods throw a
JAXRException or one of its subclasses.
Object
Collection
Many methods in the JAXR API use a Collection
object as an argument or a returned value.
Using a Collection object allows operations on
several registry objects at a time.
Page 97
Page 98
Implementing a JAXR Client
Establishing a Connection
Preliminaries: Getting Access to a Registry
Any user of a JAXR client may perform queries on a registry.

In order to add data to the registry or to update registry data,
however, a user must obtain permission from the registry to
access it.
To register with one of the public UDDI version 2 registries,

go to one of the following Web sites and follow the
instructions:
http://test.uddi.microsoft.com/ (Microsoft)
http://uddi.ibm.com/testregistry/registry.html (IBM)
http://udditest.sap.com/ (SAP)
Page 99
The JAXR API has been tested with the Microsoft and
IBM registries and with the Registry Server, but not
with the SAP registry
These UDDI version 2 registries are intended for

testing purposes. When you register, you will obtain a
user name and password. You will specify this user
name and password for some of the JAXR client
example programs.
You do not have to register with the Sun ONE Studio

internal UDDI Server Registry in order to add or
update data. You can use the default user name and
password, testuser and testuser.
Page 100
Creating or Looking Up a Connection
Factory
A client creates a connection from a
connection factory. A JAXR provider may
supply one or more preconfigured connection
factories that clients can obtain by looking
them up using the Java Naming and Directory
Interface (JNDI) API.
import javax.xml.registry.*;
ConnectionFactory connFactory =
ConnectionFactory.newInstance();
Page 101
Creating a Connection and set as
connection properties
To create a connection, a client first creates a
set of properties that specify the URLs of the
registries being accessed.
For example, the following code provides the

URLs of the query service and publishing
service for the IBM test registry.
Page 102
Properties props = new Properties();
props.setProperty("javax.xml.registry.queryManagerURL",
"http://uddi.ibm.com/testregistry/inquiryapi");
props.setProperty("javax.xml.registry.lifeCycleManagerURL",
"https://uddi.ibm.com/testregistry/protect/publishapi");
ConnectionFactory factory = ConnectionFactory.newInstance();
factory.setProperties(props);
connection = factory.createConnection();
Page 103
Obtaining and Using a RegistryService Object
the client uses the connection to obtain a RegistryService object
and then the interface or interfaces it will use:
RegistryService rs = connection.getRegistryService();
BusinessQueryManager bqm = rs.getBusinessQueryManager();
BusinessLifeCycleManager blcm =
rs.getBusinessLifeCycleManager();
Typically, a client obtains both a BusinessQueryManager object

and a BusinessLifeCycleManager object from the
RegistryService object. If it is using the registry for simple
queries only, it may need to obtain only a
BusinessQueryManager object.
Page 104
Querying a Registry
A client to use a registry is to query it for information
about the organizations that have submitted data to it.
The BusinessQueryManager interface supports a
number of find methods that allow clients to search
for data using the JAXR information model.
Many of these methods return a BulkResponse. The
most useful of these methods are:
findOrganizations, which returns a list of organizations that
meet the specified criteria--often a name pattern or a
classification within a classification scheme
findServices, which returns a set of services offered by a
specified organization
findServiceBindings, which returns the service bindings
(information about how to access the service) that are
supported by a specified service
Page 105
Finding Organizations by Name
To search for organizations by name, you normally
use a combination of find qualifiers (which affect
sorting and pattern matching) and name patterns
(which specify the strings to be searched).
The findOrganizations method takes a collection of

findQualifier objects as its first argument and a
collection of namePattern objects as its second
argument.
The following code shows how to find all the

organizations in the registry whose names begin with
a specified string, qString, and to sort them in
alphabetical order.
Page 106
// Define find qualifiers and name patterns
Collection findQualifiers = new ArrayList();
findQualifiers.add(FindQualifier.SORT_BY_NAME_DESC);
Collection namePatterns = new ArrayList();
namePatterns.add(qString);
// Find using the name

BulkResponse response = bqm.findOrganizations(findQualifiers,
namePatterns, null, null, null, null);
Collection orgs = response.getCollection();
Collection findQualifiers = new ArrayList();

findQualifiers.add(FindQualifier.CASE_SENSITIVE_MATCH);
Collection namePatterns = new ArrayList();
namePatterns.add("%" + qString + "%");
// Find orgs with name containing qString

BulkResponse response = bqm.findOrganizations(findQualifiers,
namePatterns, null, null, null, null);
Collection orgs = response.getCollection();
Page 107
Finding Services and ServiceBindings
To find that organization's services and the service
bindings associated with those services.
Iterator orgIter = orgs.iterator();

while (orgIter.hasNext()) {
Organization org = (Organization) orgIter.next();
Collection services = org.getServices();
Iterator svcIter = services.iterator();
while (svcIter.hasNext()) {
Service svc = (Service) svcIter.next();
Collection serviceBindings = svc.getServiceBindings();
Iterator sbIter = serviceBindings.iterator();
while (sbIter.hasNext()) {
ServiceBinding sb = (ServiceBinding)
sbIter.next();
}
}
}
Page 108
WSIT- Web Services
Interoperability Technology
Page 109
Web Services Interoperability Technology
Web Services Interoperability Technology (WSIT)

is an open-source project started by Sun
Microsystems to develop the next-generation of Web
service technologies.
It provides interoperability between Java Web

Services and Microsoft's Windows Communication
Foundation (WCF) as used by .NET
WSIT is a series of extensions to the basic SOAP

protocol, and so uses JAX-WS and JAXB
Page 110
WSIT implements the WS-I specifications
including:
Metadata
WS-MetadataExchange
WS-Transfer
WS-Policy
Security
WS-Security
WS-SecureConversation
WS-Trust
WS-SecurityPolicy
Messaging
WS-ReliableMessaging
WS-RMPolicy
Transactions
WS-Coordination
WS-AtomicTransaction
Page 111
Page 112
Bootstrapping and Configuration
Bootstrapping and configuration consists of

using a URL to access a web service,
retrieving its WSDL file
using the WSDL file to create a web service

client that can access and consume a web
service.
Page 113
Steps Bootstrapping and Configuration
Page 114
1. Client acquires the URL for a web service that it wants
to access and consume.
2. The client uses the URL and use the wsimport tool to
send a MetadataExchangeRequest to access the web
service and retrieve the WSDL file. The description
describes the requirements that must be satisfied to
access and consume the web service.
3. The client uses the WSDL file to create the web

service client.
4. The web service client accesses and consumes the

web service.
Page 115
Message Optimization Technology
A primary function of web services applications is to share data

among applications over the Internet.
The data shared can vary in format and include large binary
payloads, such as documents, images, music files, and so on.
When large binary objects are encoded into XML format for
inclusion in SOAP messages, even larger files are produced.
When a web service processes and transmits these large files

over the network, the performance of the web service application
and the network are negatively affected.
the Message Optimization technology ensures that web services

messages are transmitted over the Internet in the most efficient
manner.
Page 116
Reliable Messaging Technology
Reliable Messaging is a Quality of Service (QoS) technology for

building more reliable web services. The primary purpose of
Reliable Messaging is to ensure the delivery of application
messages to web service endpoints.
The reliable messaging technology ensures that messages in a

given message sequence are delivered at least once and not
more than once and optionally in the correct order.
When messages in a given sequence are lost in transit or delivered
out of order, this technology enables systems to recover from such
failures.
If a message is lost in transit, the sending system retransmits the
message until its receipt is acknowledged by the receiving system.
If messages are received out of order, the receiving system may re-
order the messages into the correct order.
The Reliable Messaging technology can also be used to

implement session management. A unique message sequence is
created for each client-side proxy
Page 117
Security Technology
web services have relied on transport-based security
such as SSL to provide point-to-point security.
WSIT implements WS-Security so as to provide
interoperable message content integrity and
confidentiality
WSIT implements two additional features to improve
security in web services:
Web Services Security Policy
Enables web services to use security assertions to represent
security preferences and requirements for web service
endpoints.
Web Services Trust
Enables web service applications to use SOAP messages to
request security tokens that can then be used to establish
trusted communications between a client and a web service.
Page 118
SOA support in .NET
Page 119
Platform overview
The .NET framework is a proprietary solution runtime
and development platform designed for use with
Windows operating systems and server products.
The .NET platform can be used to deliver a variety of

applications, ranging from desktop and mobile
systems to distributed Web solutions and Web
services.
A primary part of .NET relevant to SOA is the

ASP.NET environment, used to deliver the Web
Technology layer within SOA.
Page 120
In this diagram the ASP.NET + WSE and Assemblies layers
correspond to the Web and Component Technology layers.
Page 121
Page 122
The .NET framework provides an environment
designed for the delivery of different types of
distributed solutions.
ASP.NET Web Forms
These are dynamically built Web pages that reside on the Web
server and support the creation of interactive online forms
through the use of a series of server-side controls.
ASP.NET Web Services
An ASP.NET application designed as a service provider that
also resides on the Web server.
Assemblies
An assembly is the standard unit of processing logic within the
.NET environment.
An assembly can contain multiple classes that further partition
code using object-oriented principles. The application logic
behind a .NET Web service is typically contained within an
assembly
Page 123
The architecture components rely on the Common Language
Runtime (CLR) provided by the .NET framework.
CLR supplies a collection of runtime agents that provide a

number of services for managing .NET applications, including
cross-language support, central data typing, and object lifecycle
and memory management.
Various supplementary runtime layers can be added to the CLR.

ASP.NET itself provides a set of runtime services that establish the
HTTP Pipeline,
An environment comprised of system service agents that include
HTTP modules and HTTP handlers
Established COM+ runtime provides a further set of services
including object pooling, transactions, queued components, and
just-in-time activation.
Page 124
The .NET framework provides unified support for a
set of programming languages, including
Visual Basic,
C++
C#.
Java
Perl
Python
Small talk
The .NET language used, programming code is
converted into a standardized format known as the
Microsoft Intermediate Language (MSIL). It is the
MSIL code that is executed within the CLR.
Page 125
APIs
.NET provides programmatic access to numerous framework
(operating system) level functions via the .NET Class Library,
A large set of APIs organized into namespaces. Each

namespace must be explicitly referenced for application
programming logic to utilize its features.
namespaces that provide APIs relevant to Web services

development:
System.Xml
Parsing and processing functions related to XML documents are
provided by this collection of classes. Examples include:
~The XmlReader and XmlWriter classes that provide functionality
for retrieving and generating XML document content.
~Fine-grained classes that represent specific parts of XML
documents, such as the XmlNode, XmlElement, and XmlAttribute
classes.
Page 126
System.Web.Services
This library contains a family of classes that support the
Web service interface and interaction layer on the Web
server. For example:
System.Web.Services.Description namespace.
It is used to represent the WSDL documents
System.Web.Services.Protocols namespace
Communication protocol-related functionality (including SOAP
message documents) are expressed through a number of
classes.
Services.Protocols namespace,
which allows for the processing of standard SOAP header blocks.
System.Web.Services
Represents a set of classes that express the primary parts of
ASP.NET Web service objects.
Page 127
System.Xml.Xsl
Supplies documentation transformation functions via
classes that expose XSLT-compliant features.
System.Xml.Schema
A set of classes that represent XML Schema
Definition Language (XSD)-compliant features.
System.Web.Services.Discovery
Allows for the programmatic discovery of Web service
metadata.
Page 128
Service providers
.NET service providers are Web services that exist as
a ASP.NET applications, called ASP.NET Web
Services.
It can recognize a URL pointing to an ASP.NET Web

Service by the ".asmx" extension used to identify the
part of the service that acts as the endpoint.
ASP.NET Web Services commonly comprised of an

ASMX endpoint and a compiled assembly separately
housing the business logic.
Page 129
.NET Service provider
Page 130
Service agents
The ASP.NET environment utilizes many system-level

agents that perform various runtime processing tasks.
such as authentication, authorization, and state
management.
Custom HTTP Modules also can be created to

perform various processing tasks prior and
subsequent to endpoint contact.
example of service agents used to process SOAP

headers are the filter agents provided by the WSE
toolkit
Page 131
.NET service agents
Page 132
Service requestors
To support the creation of service requestors, .NET provides a

proxy class that resides alongside the service requestor's
application logic and duplicates the service provider interface.
This allows the service requestor to interact with the proxy class
locally, while delegating all remote processing and message
marshalling activities to the proxy logic.
The .NET proxy translates method calls into HTTP requests and
subsequently converts the response messages issued by the
service provider back into native method return calls.
The code behind a proxy class is auto-generated using Visual

Studio or the WSDL.exe command line utility.
Page 133
.NET service requestor.
Page 134
Platform extensions
The Web Services Enhancements (WSE) is a toolkit
that establishes an extension to the .NET framework
to support key WS-* specification features for WS-*
specifications such as
WS-Addressing,
WS-Policy,
WS-Security
WS-SecurityPolicy
WS-SecureConversation
WS-Trust
WS-Referral
WS-Attachments
DIME (Direct Internet Message Encapsulation).
Page 135
Primitive SOA support
Service encapsulation
Loose coupling
Messaging
Support for service-orientation principles
Autonomy
Reusability
Statelessness
Discoverability
Contemporary SOA support
Based on open standards
Supports vendor diversity
Intrinsically interoperable
Promotes federation
Architecturally composable
Extensibility
Supports service-oriented business modeling
Logic-level abstraction
Organizational agility and enterprise-wide loose coupling
Page 136
.Net Framework
Page 137
Microsoft .Net Framework
The .NET Framework is Microsoft's Managed

Code programming model for building
applications on Windows clients, servers, and
mobile or embedded devices.
Page 138
The .NET Framework and Visual Studio .NET
Visual Basic C++ C# JScript
Common Language Specification
Visual Studio .NET

ASP.NET: Web Services Windows
and Web Forms Forms
ADO.NET: Data and XML
Base Class Library
Page 139
Common Language Runtime (CLR)
Page 140
CLR
The Common Language Runtime (CLR) is an language-

independent execution Environment . It works as a layer
between Operating Systems and the applications written in .Net
languages.
The main function of Common Language Runtime (CLR) is to

convert the Managed Code into native code and then execute
the Program.
The Managed Code compiled only when it needed, that is it

converts the appropriate instructions when each function is
called .
The Common Language Runtime (CLR) 's Just In Time (JIT)

compilation converts Intermediate Language (MSIL) to native
code on demand at application run time.
Page 141
CLR: Execution Model
Source VB C# C++
code Unmanaged
Compiler Compiler Compiler
Component
Managed Assembly Assembly Assembly

IL Code IL Code IL Code
code
JIT Compiler
Native Code
Operating System Services
Page 142
Microsoft .Net Languages Source Code are compiled into Microsoft
Intermediate Language (MSIL) or Intermediate Language (IL) or
Common Intermediate Language (CIL).
MSIL is a CPU independent set of instructions that can be converted

to the native code. Metadata also created in the course of compile
time with MSIL and stored it with the compiled code .
Metadata is stored in a file called Manifest, and it contains

information about the members, types, references and all the other
data that the Common Language Runtime (CLR) needs for
execution .
The CLR uses metadata to locate and load classes, generate native
code, provide security, and execute Managed Code.
Both Microsoft Intermediate Language (MSIL) and Metadata

assembled together is known as Portable Executable (PE) file.
Portable Executable (PE) is supposed to be portable across all 32-
bit operating systems by Microsoft .Net Framework.
Page 143
During the runtime the Common Language Runtime
(CLR)'s Just In Time (JIT) compiler converts the MSIL
code into native code to the Operating System.
The native code is Operating System independent and

this code is known as Managed Code , that is, the
language's functionality is managed by the .NET
Framework .
The CLR provides various Just In Time (JIT) compilers,

and each works on a different architecture depends on
Operating Systems, that means the same Microsoft
Intermediate Language (MSIL) can be executed on
different Operating Systems.
Page 144
Components of CLR
Page 145
Class Loader:
This loads classes into the runtime.
MSIL to native code compiler:
This converts MSIL code into native code.
Code manager:
This manage the code during execution i.e provides code check, the resources it
needs during execution.
Garbage Collector:
provide automatic memory management and avoid memory leaks.
Security Engine:
This enforces security restrictions and CAS (Code Access Security ).
Type Checker:
This enforces strict type checking.
Thread Support:
This provides multithreading support to applications.
Exception Manager :
This provides a mechanism to handle the run-time exceptions.
Debug Engine :
Allow you to debug different type of applications.
COM marshaler :
This allows .net application to exchange data with COM applications.
BASE Class library :
This provides the types the applications needed at runtime.
Page 146
ASP.NET Overview
ASP.NET provides services to allow the creation,
deployment, and execution of
Web Applications and Web Services
Like JSP, ASP.NET is a server-side technology
Web Applications are built using Web Forms
Page 147
ASP.NET Overview
Goals
Simplify: less code, easier to create and maintain
Multiple, compiled languages
Fast
Scalable
Manageable
Available
Customizable and extensible
Secure
Tool support
Page 148
ASP.NET Overview
Key Features
Web Forms Session management
Web Services Caching
Built on .NET Framework Debugging
Maintains page state Extensibility
Multibrowser support Separation of code and UI
XML configuration Security
Complete object model Simplified form validation
Cookieless sessions
Page 149
What is an ASP.NET File ?
An ASP.NET file is just the same as an HTML file
An ASP.NET file can contain HTML, XML, and scripts
Scripts in an ASP.NET file are executed on the server
An ASP.NET file has the file extension ".aspx"
Page 150
How Does ASP.NET Work?
When a browser requests an ASP.NET file, IIS passes the
request to the ASP.NET engine on the server
The ASP.NET engine reads the file, line by line, and executes
the scripts in the file
Finally, the ASP.NET file is returned to the browser as plain

HTML
ASP.NET Program is compiled into a .NET class and cached

the first time it is called. All subsequent calls use the cached
version.
Page 151
ASP.NET Execution Model
Client Server(IIS) public class Hello{
protected void Page_Load(
Object sender, EventArgs e)
{}
}
Hello.aspx.cs
First request
Postback
Output Cache
Page 152
ASP.NET Web form
Web Applications are built using Web Forms
Web Forms are designed to make building

web-based applications as easy as building Visual
Basic applications
Built on .NET Framework: any .NET programming

language can be used (C#, Visual Basic)
Page 153
WebTime.aspx Example WebTime.aspx ( 1 of 2 )
1 <%-- WebTime.aspx --%> ASP.NET comments
2 <%-- A page that displays the current time in a Label. --%> begin with <%-- and
3 <%@ Page Language="C#" AutoEventWireup="true" terminate with --%>,
CodeFile="WebTime.aspx.cs" and can span multiple
4 Inherits="WebTime" EnableSessionState="False" %> lines.
5
6 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" The Page directive
7 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> specifies information
needed by ASP.NET
8 to process this file.
9 <html xmlns="http://www.w3.org/1999/xhtml">
10 <head runat="server"> The document type
11 <title>A Simple Web Form Example</title> declaration, which specifies
12 </head> the document element name
13 <body> and the PUBLIC URI for the
14 <form id="form1" runat="server"> DTD that defines the
XHTML vocabulary.
15 <div>
16 <h2>Current time on the web server:</h2>
XHTML documents
The form that contains our The body contains have the root element
XHTML text and controls is set the main content html and markup
to execute on the server, which that the browser information about the
generates equivalent XHTML. displays. document in the head
element. 154
ASPX file that displays the web servers time. Page 154
WebTime.aspx
17 <p> ( 2 of 2 )
18 <asp:Label ID="timeLabel" runat="server" BackColor="Black"

19 Font-Size="XX-Large" ForeColor="Yellow"
20 EnableViewState="False"></asp:Label> Markup for a label
21 </p> web control.
The asp: tag prefix
22 </div> indicates that the
23 </form> label is an ASP.NET
web control, not an
24 </body>
XHTML element.
25 </html>
In an ASPX file a directive is delimited by <%@ and %>.
Page 155
The code-behind file (WebTime.aspx.cs)
1 // WebTime.aspx.cs
2 // Code-behind file for a page that displays the current time.
3 using System;
4
5 public partial class WebTime : System.Web.UI.Page
The Page_Init
6 {
method handles the
pages Init event,
7 // initializes the contents of the page
which indicates that
8 protected void Page_Init( object sender, EventArgs e )
the page is ready to
9 {
be initialized.
10 // display the server's current time in timeLabel
11 timeLabel.Text = DateTime.Now.ToString( "hh:mm:ss" );
12 } // end method Page_Init Retrieve the current
13 } // end class WebTime
time and formats it
as hh:mm:ss.
Code-behind file for a page that displays the web servers time.
Page 156
WebTime.aspx Example Run
The Page_Init method handles the pages Init event,

which indicates that the page is ready to be initialized.
Page 157
WebTime.aspx Example
How the Code in an ASP.NET Web Page Executes
When an instance of the page is created, the PreInit event occurs

first, invoking method Page_PreInit, which can be used to set a pages theme.
The Init event occurs next, invoking method Page_Init, which is used to
initialize objects and other aspects of the page.
Next, the Load event occurs, and the Page_Load event handler
executes.
The Init event is raised only once (when the page is first requested).
The Load event is raised with every request.
The page then processes any events that are generated by the pages
controls.
Once a response has been generated and sent, an Unload event occurs,
which calls Page_Unload, which typically releases resources used by the
page.
Page 158
Creating an ASP.NET Web Application using Visual Studio
Step 1: Creating the Web Application Project

Select File > New Web Site... and choose ASP.NET Web Site in the
Templates pane.
Select File System from the drop-down list closest to Location.
Set the Language drop-down list to Visual C#, and click OK.
Page 159
An ASPX file (i.e., Web Form) named Default.aspx is created
for each new project.
Visual Web Developer creates a code-behind file named
Default.aspx.cs.
The View Designer button opens the Web Form in Design
mode.
The Copy Web Site button allows you to copy the projects
files to another location, such as a remote web server.
Finally, the ASP.NET Configuration button takes you
to the Web Site Administration Tool.
Look at Toolbox displayed in the IDE when the project loads.
Standard and Data list of web controls.
Page 160
Editing the WebTime.aspx
When the project loads for the first time, the Web Forms
Designer displays the autogenerated ASPX file in Source mode.
Design mode indicates the XHTML element where the cursor
is currently located.
You can also view both the markup and the web-page design
at the same time by using Split mode
Right click the ASPX file in the Solution Explorer

and select View Code to open the code-behind file.
Page 161
Renaming the WebTime.aspx
Renaming the ASPX File
Right click the ASPX file in the Solution Explorer and select Rename.
Enter the new file name WebTime.aspx and press Enter. Both the
ASPX file and the code-behind file are updated.
Renaming the Class in the Code-Behind File and Updating the ASPX
File
Visual Studios refactoring tool, which automatically updates
the existing references to this class in the rest of the project to
reflect this change.
Right click the class name in the partial classs declaration and
select Refactor > Rename to open the Rename
dialog.
Page 162
Changing the Title of the Page
We change the pages title from the default Untitled Page to A Simple Web
Form Example.
Open the ASPX file in Source mode and modify the text between the
<title> tags.
Alternatively, you can modify the Web Forms Title property in the
Properties window.
To view the Web Forms properties, select DOCUMENT from the drop-
down list in the Properties window.
Designing the Page
To add controls to the page, you can drag and drop them from the Toolbox
onto the Web Form in Design mode.
Like the Web Form itself, each control is an object that has properties,
methods and events.
You can type text directly on a Web Form at the cursor location or insert
XHTML elements using menu commands.
163
Page 163
Running WebTime.aspx Example
Running the Program
You can view the Web Form several ways.
You can select Debug > Start Without Debugging, which
runs the application by opening it in a browser window.
To debug your application, you can select Debug > Start
Debugging. You cannot debug a web application unless
debugging is explicitly enabled by the web.config file.
To view a specific ASPX file, you can right click either the
Web Forms Designer or the ASPX file name and select View
In Browser.
Finally, you can run your application by opening a browser
window and typing the web pages URL in the Address field.
Page 164
Event Handling
GUIs are event driven.
When the user interacts with a GUI

component, the event drives the program to
perform a task.
A method that performs a task in response to

an event is called an event handler.
Page 165
Page 166
A Comaprison .NET or J2EE?
Which is best?
In what way?
For what purpose?
Performance
Cost
Developer time
Page 167
Application Platforms Today
Browser Web Services Local Other

Apps Apps Apps Apps
GUI Transaction Web Data More

Services Services Scripting Access
Standard Library
Runtime Environment
Operating System
Page 168
The .NET Framework

Apps Apps Apps Apps
Windows Enterprise ASP.NET ADO.NET More

Forms Services
.NET Framework Class Library
Windows
Page 169
The Competition: The Java

Apps Apps Apps Apps
Swing Enterprise JavaServer JDBC More

JavaBeans Pages
Standard Java Packages
Java Virtual Machine (VM)
Windows, Solaris, Linux, others
Page 170
But!
.NET IS COMPELLING!
It has everything an enterprise architecture
needs
It is fast
It is simpler to use than J2EE to develop
It has features that J2EE does not
eg web forms
Page 171
ASP.NET Web Service
A programmable application component that is accessible
via standard Internet protocols by making HTTP requests
across the Web.
Web page with functions
ASP.NET enables to create custom Web services, and to

call these services from any client application.
Page 172
Web Services Platform
ASP.NET
ATL Server
.NET remoting
Microsoft SOAP Toolkit
J2EE
Page 173
ASP.NET Web Service
Easy to build, deploy, and administer as a

Web application
File extension is .asmx
End point is represented by URL
Page 174
Creating a Web Service (1)
Open Microsoft Visual Studio .NET
Select the language
Select the project type: ASP.NET Web Service
Page 175
.asmx and .asmx.cs
Web.config
Global.asax
WebService1.vsdisco
Page 176
Inside Service1.asmx
<%@ WebService Language="c#"

Codebehind="Service1.asmx.cs"
Class="WebService1.Service1"
%>
Page 177
Inside Service1.asmx.cs
Add WebService attributes Namespace
property
[WebService(Namespace="http://localhost/webservice1/")]
public class Service1 : System.Web.Services.WebService
Uncomment the following code:
[WebMethod]
public string HelloWorld()
{
return "Hello World";
}
Page 178
Compile the Web
service
Page 179
Run the Web service
Page 180
Web Services Enhancements
Page 181
WSE
Web Services Enhancement (WSE) is a .NET
class library for building Web services using
the latest Web services protocols, including
WS-Security, WS-Secure Conversation, WS-
Trust, and WS-Addressing.
It enables developers to build secure Web

services
Page 182
Security Features in WSE
Digital signature of a SOAP message
X.509 certificates / username+password /
custom binary token
Encryption of a SOAP message
X.509 / shared secret / custom binary token
Authentication using security credentials
X.509 / username+password / custom binary
token
Page 183
WSE Architecture
WSE is an engine for applying advanced Web service protocols
to SOAP messages. This entails writing headers to outbound
SOAP messages and reading headers from inbound SOAP
messages.
It may also require transforming the SOAP message body for

instance,
encrypting an outbound message's body and
decrypting an inbound message's body, as defined by the WS-
Security specification.
This functionality is encapsulated by two sets of filters,

outbound messages
All messages leaving a process request messages from a client or
response messages from server are processed using the outbound
message filters
inbound messages.
All messages arriving in a process request messages to a server or
response messages to a client are processed using the inbound
message filters.
Page 184
Built-in filters:
Trace Filter (diagnostics)

Security Filter (WS-Security)
Timestamp Filter (WS-Security)
Referral Filter (used for WS-Routing)
Routing Filter (WS-Routing)
Page 185
WSE Filter Pipeline
Page 186
Integration with ASP.NET Web Service Proxies
(Sender-side)
WSE input and output filters are exposed to ASP.NET Web

services clients through a proxy base class called
WebServicesClientProtocol.
The proxy base class ensures that WSE filters have a chance to
process the SOAP messages that are exchanged whenever a
client sends a SOAP message.
The WebServicesClientProtocol proxy base class is

implemented using two communication classes from the
standard System.Net namespace:
WebRequest and WebResponse.
the WebRequest instance sends SOAP requests and the
WebResponse instance receives SOAP responses.
Page 187
The WebRequest instance parses a request
stream containing a SOAP message into an
instance of the SoapEnvelope class.
Then it passes the request through the chain of

output filters. Each filter has the chance to
modify the request data any way it likes. Often, a
filter simply adds protocol headers, but in some
cases they modify the body of a message too,
such as when the SOAP body is encrypted.
The set of filters and their behavior is controlled

through the policy associated with the SOAP
message.
Page 188
Page 189
WebResponse
The WebResponse operates on the SOAP message

the opposite of the WebRequest instance.
It parses a response stream containing a SOAP

message into an instance of the SoapEnvelope class
and passes it through the chain of input filters.
Each filter has the chance to examine and modify the

response data any way it likes. Input filters check the
validity of protocol headers and modify the contents of
the message's body (decryption, for example).
Page 190
Page 191
Integration with ASP.NET Web Services (Receiver-
side)
WSE input and output filters are exposed to ASP.NET Web
services through a server-side SOAP protocol factory,
WseProtocolFactory.
The WseProtocolFactory class copies inbound messages into

memory streams. It processes them using WSE input filters
before the message is deserialized into input parameters for the
target method.
The extension also sets up a memory stream for the target

method to serialize its output parameters into. After that
serialization step occurs, the output message is passed through
WSE output filter and then sent on its way.
Page 192
END
Page 193

UNIT4

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

UNIT4

Загружено:

Авторское право:

Доступные форматы

UNIT 4

SOA platform basics

We need the ability to encapsulate and expose application

Message Processing Logic

Message processing logic is performed by a combination of

layers tasks, such as

on the other hand, may

Proxies accept method calls issued from the regular

The proxies then use vendor runtime services to

Proxies can exist as static components or they can be

As an independent unit of logic, it is free to act

Its primary role is to perform form of automated

The types of tasks performed by service agents

It is a standardized platform that is supported by many vendors

The Java 2 Platform is divided into three major development and

Java 2 Platform Enterprise Edition Specification

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

Web Services for J2EE

Struts provides its own Controller component and

Examples of currently available development

~javax.xml.rpc and javax.xml.rpc.server

~javax.xml.rpc.handler and javax.xml.rpc.handler.soapAPI

~javax.xml.soap and javax.xml.rpc.soapAPI

JAX-RPC Service Endpoint When building Web services for use

EJB Service Endpoint The alternative is to expose an EJB as a Web

Regardless of vendor platform, both types of J2EE Web services

Service Implementation Bean

Specifically, the compiler creates a Java remote interface for every

JAX-RPC takes care of translating communication between the proxy

Dynamic proxy and dynamic invocation interface

Secondly, the dynamic invocation interface bypasses the need for a

To support SOAP header processing,

Handlers can process SOAP header blocks for messages

Building Web Services with JAX-WS

In JAX-WS, a web service operation invocation is represented by

On the server side, the developer specifies the web service

With JAX-WS, the developer does not generate or parse SOAP

The starting point for developing a JAX-WS web service is a

A service endpoint interface or service endpoint

we may specify an explicit interface by adding the

Java developers can invoke a SAX or DOM parser in an application

Unmarshalling provides a client application the ability to

The content objects are instances of the classes produced by

Generate content tree:

This content tree represents the structure and content of the

The binding framework comprises three packages.

// create bookstore, assigning book

// get variables from our xml file, created before

Remote Procedure Call

RPC code Proprietary protocol RPC code

RPC in Java Web Service (jws) uses XML/SOAP-open standard-

Service SOAP Invoke Service

Overhead of text formatted data exchange

JAX-RPC: Java APIs for XML based Remote Procedure Call

Web services Web services

JAX-RPC defines an APIs framework to create and deploy web service

JAX-RPC application architecture consist of following

public String currentDate() {

SOAP request JAXRPCEndpoint Web

JAX-RPC service client

Java client Stub classes

Serialization and deserialization

xrpcc or wscompile tool