Professional Documents
Culture Documents
Page 1
UNIT 4
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.
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
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.
Page 17
Vendor platforms accomplish this by supporting the
creation of proxy components. These components is
auto-generated from the service provider WSDL
definition.
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.
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.
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:
Page 28
Architecture components
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.
Page 31
Programming languages
The standard Java language can be used to
build Web services.
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:
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:
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.
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.
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
Page 49
Communication between a JAX-WS Web Service
and a Client
Page 50
Creating a Simple Web Service and Client with JAX-
WS
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.
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.
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.
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);
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);
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?
..some code..
Function() Function()
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
Page 73
Disadvantages of RPC in web service
Page 74
What is JAX-RPC?
Page 75
JAX-RPC introduction
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 architecture based on JWSDP
JAX-RPC service
Web server
Page 79
JAX-RPC architecture based on JWSDP
Page 80
JAX-RPC architecture based on JWSDP
Page 81
JAX-RPC architecture based on JWSDP
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;
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)
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.*;
Page 88
HelloIF helloPort = myHelloService.getHelloIFPort();
((Stub)helloPort)._setProperty
(Stub.ENDPOINT_ADDRESS_PROPERTY,args[0]);
System.out.println(helloPort.sayHello("Jake!"));
System.exit(0);
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.
Page 91
XML registries
The ebXML Registry and Repository standard
Page 92
What Is JAXR?
JAXR enables Java software programmers to use a
API to access a variety of XML registries.
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
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
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.
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");
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();
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).
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);
Page 107
Finding Services and ServiceBindings
To find that organization's services and the service
bindings associated with those services.
Page 108
WSIT- Web Services
Interoperability Technology
Page 109
Web Services Interoperability Technology
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
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.
Page 115
Message Optimization Technology
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.
Page 116
Reliable Messaging Technology
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.
Page 120
In this diagram the ASP.NET + WSE and Assemblies layers
correspond to the Web and Component Technology layers.
Page 121
Page 122
Architecture components
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
Runtime environments
The architecture components rely on the Common Language
Runtime (CLR) provided by the .NET framework.
Page 124
Programming languages
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,
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.
Page 129
.NET Service provider
Page 130
Service agents
Page 131
.NET service agents
Page 132
Service requestors
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.
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
Page 138
The .NET Framework and Visual Studio .NET
Page 139
Common Language Runtime (CLR)
Page 140
CLR
Page 141
CLR: Execution Model
Source VB C# C++
code Unmanaged
Compiler Compiler Compiler
Component
JIT Compiler
Native Code
Page 142
Microsoft .Net Languages Source Code are compiled into Microsoft
Intermediate Language (MSIL) or Intermediate Language (IL) or
Common Intermediate Language (CIL).
The CLR uses metadata to locate and load classes, generate native
code, provide security, and execute Managed Code.
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.
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
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
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
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
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 )
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
Page 157
WebTime.aspx Example
How the Code in an ASP.NET Web Page Executes
Page 158
WebTime.aspx Example
Creating an ASP.NET Web Application using Visual Studio
Page 159
WebTime.aspx Example
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
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
WebTime.aspx Example
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.
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
Runtime Environment
Operating System
Page 168
The .NET Framework
Windows
Page 169
The Competition: The Java
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.
Page 172
Web Services Platform
ASP.NET
ATL Server
.NET remoting
Microsoft SOAP Toolkit
J2EE
Page 173
ASP.NET Web Service
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
Creating a Web Service (2)
.asmx and .asmx.cs
Web.config
Global.asax
WebService1.vsdisco
Page 176
Creating a Web Service (3)
Inside Service1.asmx
Page 177
Creating a Web Service (4)
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
Creating a Web Service (5)
Compile the Web
service
Page 179
Creating a Web Service (6)
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.
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.
Page 184
Built-in filters:
Page 185
WSE Filter Pipeline
Page 186
Integration with ASP.NET Web Service Proxies
(Sender-side)
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.
Page 187
The WebRequest instance parses a request
stream containing a SOAP message into an
instance of the SoapEnvelope class.
Page 188
Page 189
WebResponse
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.
Page 192
END
Page 193