Академический Документы
Профессиональный Документы
Культура Документы
A First Example
The Service Endpoint Interface and Service
Implementation Bean
rpc.ts.TimeServer
rpc.ts.TimeServerImpl
rpc.ts.TimeServerPublisher
rpc.ts.client.TimeClient
MEP
Request/Response
One-Way
Notification
Solicit/Response
Infrastructure needed
Message transport
Service contract
Type system
5. Client Code
document.team.*
teamC.TeamClient
WSDL
Package inversion
client.*
Steps
First, construct a Service object.
Invoke the get...Port method on the constructed Service
object.
Result
<message name="getTimeAsString"></message>
<message name="getTimeAsStringResponse">
<part name="time_response"
type="xsd:string"></part>
</message>
<message name="getTimeAsElapsed"></message>
<message name="getTimeAsElapsedResponse">
<part name="time_response"
type="xsd:long"></part>
</message>
Result
The SOAP response
document from the web service likewise reflects the change:
<?xml version="1.0" ?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soapenv:Body>
<ans:getTimeAsStringResponse xmlns:ans="http://ts.rpc/">
<time_response>
Mon Jun 1 21:20:09 CDT 2015
</time_response>
</ans:getTimeAsStringResponse>
</soapenv:Body>
</soapenv:Envelope>
WSDL Structure
At a high level, a WSDL document is a contract between a
service and its consumers.
The contract provides such critical information as the
service endpoint, the service operations, and the data
types required for these operations.
The service contract also indicates, in describing the
messages exchanged in the service, the underlying
service pattern, for instance, request/response or
solicit/response.
style
use
document
Literal
document
Encoded
Rpc
Literal
rpc
encoded
The setting:
use = 'literal'
means that the services type definitions literally follow the
WSDL documents XML Schema.
By contrast, the setting:
use = 'encoded'
means that the services type definitions come from
encoding rules, typically the encoding rules in the SOAP
1.1 specification.
By default, a Java SOAP-based web service is wrapped doc/lit, that is, wrapped document style with
literal encoding.
Unwrapped
wsimport -keep -p <pkgname> <wsdl> -b custom.xml
<jaxws:bindings
wsdlLocation =<wsdl>
xmlns:jaxws="http://java.sun.com/xml/ns/jaxws">
<jaxws:enableWrapperStyle>false</jaxws:enableWrap
perStyle>
</jaxws:bindings>
An Asynchronous Client
port.getAsync(, new MyHandler());
A JAX-B Example
The @XmlType and @XmlRootElement annotations direct
the marshaling of Skier objects, where marshaling is the
process of encoding an in-memory object (for example, a
Skier) as an XML document so that, for instance, the
encoding can be sent across a network to be unmarshaled
or decoded at the other end. In common usage, the
distinction between marshal and unmarshal is very close
and perhaps identical to the serialize/deserialize
distinction.
jaxb.*
int
Xsd:int
byte
Xsd:byte
java.lang.String
xsd:string
java.util.Calendar
BigDecimal
Xsd:decimal
What JAX-B brings to the table is a framework for binding arbitrarily rich Java
types, with the Skier class as but a hint of the possibilities, to XML types.
Instances of these Java types can be marshaled to XML document
instances, which in turn can be unmarshaled to instances of either Java
types or types in some other language.
cfca.*
UDDI
A UDDI (Universal Description Discovery and Integration)
registry is one way to publish WSDLs so that potential
clients can discover them and ultimately consume the
services that the WSDLs describe.
SOAP Handling
Need to process a Soap envelope.
SOAP now comes in two versions, 1.1 and 1.2. The good
news is that the differences between SOAP 1.1 and SOAP
1.2 have minor impact on programming web services in
general and programming JAX-WS in particular.
At handler level:
1.1
1.2
specification is a single
document,
SOAP Message
SOAP Format Sample
<?xml version="1.0"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<UserCredentials xmlns="https://richtypes.intro/">
<Username>WSTraining</Username>
<Password>ctli123</Password>
</UserCredentials>
</S:Header>
<S:Body>
<ns2:getTeams xmlns:ns2="http://richtypes.intro/"/>
</S:Body>
</S:Envelope>
Intermediary 1
Intermediary 2
Receiver
Body is required.
Header is optional.
An intermediary should inspect and process only the
elements in the SOAP header rather than anything in the
SOAP body, which carries whatever cargo the sender
intends for the ultimate receiver alone. The header, by
contrast, is meant to carry whatever meta-information is
appropriate for either the ultimate receiver or
intermediaries.
Example?
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<uuid xmlns="http://ch03.fib"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next">
ca12fd33-16e1-4a95-b17e-3ef6744babdc
</uuid>
</S:Header>
<S:Body>
<ns2:countRabbits xmlns:ns2="http://ch03.fib">
<arg0>45</arg0>
</ns2:countRabbits>
</S:Body>
</S:Envelope>
The header block with the uuid tag has an attribute, SOAPENV:actor, whose value ends with next. The next actor, in
this scheme, is the next recipient on the path from the
message sender to the ultimate receiver; hence, each
intermediary (and the ultimate receiver) acts in a next role.
A next actor is expected to inspect header blocks in some
application-appropriate way. If a node cannot process the
header block, then the node should throw a fault. In SOAP
1.2, this expectation can be made explicit by setting the
mustUnderstand attribute of a header block to true, which
means that a node must throw a fault if the node cannot
process the header block.
Handler Examples
Client Side
Server Side
Programmatically.
Configuration file.
Annotations.
Intro.rpc.*
Configuration File
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<javaee:handler-chains
xmlns:javaee="http://java.sun.com/xml/ns/javaee"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<javaee:handler-chain>
<javaee:handler>
<javaee:handlerclass>intro.rpc.TimeLogicalHandler</javaee:handler-class>
</javaee:handler>
<javaee:handler>
<javaee:handlerclass>intro.rpc.TimeSoapHandler</javaee:handler-class>
</javaee:handler>
</javaee:handler-chain>
</javaee:handler-chains>
Programmatically
In the client
service.setHandlerResolver(new
ClientHandlerResolver());
Handler class import javax.xml.ws.handler.Handler;
import javax.xml.ws.handler.HandlerResolver;
import javax.xml.ws.handler.PortInfo;
class ClientHandlerResolver implements HandlerResolver {
public List<Handler> getHandlerChain(PortInfo port_info) {
List<Handler> hchain = new ArrayList<Handler>();
hchain.add(new UUIDHandler());
hchain.add(new TestHandler()); // for illustration only
}
handleFault Method
division.*
First Approach
The binary data can be encoded using a scheme such as
base64 and then transmitted as the payload of the SOAP
body. The downside is that base64 and similar encoding
schemes result in payloads that are at least a third larger
in size than the original, unencoded binary data. In short,
byte encoding such as base64 results in data bloat.
Second Approach
The binary data can be transmitted as one or more
attachments to a SOAP message. A SOAP message also
may have attachments, which can carry data of any MIME
type, including multimedia types such as audio/x-wav,
video/mpeg, and image/jpeg. JAX-B provides the required
mappings between MIME and Java types: the MIME types
image/* map to Image, and the remaining multimedia types
map to DataHandler.
The downside is that the receiver then must deal with the
raw bytes, for example, by converting them back into
multimedia types such as images and sounds.
Wsimport
wsimport -keep -p skiC2 ch03/image/ski.wsdl
MTOM Change 1
The MIME subtype name application/octet-stream captures the optimization that
recommends MTOMthe image bytes will be streamed unencoded to the service client.
The bloat of base64 or comparable encoding is thereby avoided.
In the XSD, the expectedContentTypes attribute occurs twice. The changes are in bold:
<xs:complexType name="getImagesResponse">
<xs:sequence>
<xs:element name="return" type="xs:base64Binary"
minOccurs="0" maxOccurs="unbounded"
xmime:expectedContentTypes="application/octet-stream"
xmlns:xmime="http://www.w3.org/2005/05/xmlmime">
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="getImageResponse">
<xs:sequence>
<xs:element name="return" type="xs:base64Binary"
minOccurs="0"
xmime:expectedContentTypes="application/octet-stream"
xmlns:xmime="http://www.w3.org/2005/05/xmlmime">
</xs:element>
</xs:sequence>
</xs:complexType>
MTOM Change 2
For emphasis, the SkiImageService is annotated to show
that MTOM may come into
play:
import javax.xml.ws.soap.SOAPBinding;
@WebService(serviceName = "SkiImageService")
// This binding value is enabled by default but put here for
emphasis.
@BindingType(value =
SOAPBinding.SOAP11HTTP_MTOM_BINDING)
@HandlerChain(file = "handler-chain.xml") // for message
tracking
public class SkiImageService {
//**The binding value is the default, hence optional, but it is included for emphasis.
MTOM change 3
The next change is important. The revised publisher, with the work now divided among several methods for clarity:
package ch03.image;
import javax.xml.ws.Endpoint;
import javax.xml.ws.soap.SOAPBinding;
public class SkiImagePublisher {
private Endpoint endpoint;
public static void main(String[ ] args) {
SkiImagePublisher me = new SkiImagePublisher();
me.create_endpoint();
me.configure_endpoint();
me.publish();
}
private void create_endpoint() {
endpoint = Endpoint.create(new SkiImageService());
}
private void configure_endpoint() {
SOAPBinding binding = (SOAPBinding) endpoint.getBinding();
binding.setMTOMEnabled(true);
}
private void publish() {
int port = 9999;
String url = "http://localhost:" + port + "/ski";
endpoint.publish(url);
System.out.println(url);
}
}
JAS
Web container
Message-oriented middleware
Enterprise Java Bean (EJB) container
JNDI service provider
Security provider
Relational Database Management System
Client container
Web container
A web container deploys servlets and web services. A traditional web
application in Java is a mix of static HTML pages, servlets, higher-level servlet
generators such as JSP (Java Server Pages) and JSF (Java Server Faces)
scripts, backend Java-Beans for JSP and JSF scripts, and utility classes.
Tomcat is the reference implementation (RI) for a web container. Tomcat, like
other web containers, can be embedded in an application server. Web
components are deployed in the web container as WAR files, which typically
contain the standard configuration document web.xml and may contain
vendor-specific configuration documents as well (e.g., sun-jaxws.xml). To host
web services, a web container relies on a servlet interceptor (in the case of
Tomcat, a WSServlet instance) that mediates between the client and the web
service SIB.
Client container
The client container consists of the software libraries that a client requires to
interact with deployed components such as message topics or EJBs and to
use services such as JNDI and security.
5. JAX-WS Dependencies
By default, Tomcat does not comes with any JAX-WS dependencies, So, you
have to include it manually.
1. Go here http://jax-ws.java.net/.
2. Download JAX-WS RI distribution.
3. Unzip it and copy following JAX-WS dependencies to Tomcat library folder
{$TOMCAT}/lib.
jaxb-impl.jar
jaxws-api.jar
jaxws-rt.jar
gmbal-api-only.jar
management-api.jar
stax-ex.jar
streambuffer.jar
policy.jar
Wire-level security
HTTP/HTTPS
HyperText Transport Protocol over Secure Socket
Layer
Netscape did the original work called it SSL (Secure
Sockets Layer).
TheIETF (International Engineering Task Force) has
taken over SSL and renamed it to TLS (Transport
Layer Security)
HTTPS Basic Service
Peer authentication
Confidentiality
Integrity
Wire-level security
Public key encryption and decryption
Solves the key distribution problem
The public key approach solves the confidentiality problem for Alice
and Bob.
A hash value is also called a message digest, which is a fixed-length digest of arbitrarily many input bits.
Or A message digest is a crytographic hash function containing a string of digits created by a one-way hashing formula.
Integrity Digest
The message sent over HTTPS includes a digest, which
the receiver recomputes. If the sent digest differs from the
digest that the receiver computes, then the message was
altered during transmission, either by accident or design. If
the sent digest itself is altered during transmission, this
likewise counts as integrity failure.
2.
3.
Encrypts pre-master key using the public key received in the digital
certificate.
5. Server decrypts the pre-master key using its own public key.
6. Client and the server agree upon which cipher suite, or set of
cryptographic algorithms, should be used.
Otherwise server.xml can also be updated to point to the .keystore file location as follows:
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150"
scheme="https" secure="true" clientAuth="false" sslProtocol="TLS"
keystoreFile="C:/Users/ssathee/.keystore"/>
Restart the tomcat.
Try this URL: https://localhost:8443
To execute client
3. Run the modified client class with the VM arguments (in
eclipse, right click -> run configurations): No need to regenerate keystore newly. You need to use
the already generated keystore.
-Djavax.net.ssl.trustStore=C:/Users/ssathee/.keystore Djavax.net.ssl.trustStorePassword=changeit Djavax.net.ssl.keyStore=C:/Users/ssathee/.keystore Djavax.net.ssl.keyStorePassword=changeit
The command is sufficiently complicated that an Ant or
equivalent script might be used in production.
Application-Managed Authentication
com.tc.secure.application*
com.tc.auth*
tcauthClient*
Web.xml changes
<security-role>
<description>The Only Secure Role</description>
<role-name>bigshot</role-name>
</security-role>
<security-constraint>
<web-resource-collection>
<web-resource-name>Users-Roles Security</web-resource-name>
<url-pattern>/tcauth</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>bigshot</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
Generate client
There is one tricky aspect to the client: the use of the
wsimport utility to generate the artifacts in the tcauthClient
package. The problem is that the web services WSDL is
also secured and therefore requires authentication for
access. There are workarounds, of course. One option is
to generate the WSDL locally by using the wsgen utility on
the SIB. Another option is to get the WSDL from a
nonsecure version of the service. The locally saved WSDL
and its XSD are then fed into wsimport to generate the
artifacts.
Conf/Tomcat-users.xml
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="tomcat"/>
<role rolename="bigshot"/>
<user username="tomcat" password="tomcat"
roles="tomcat"/>
<user username="fred" password="rockbed"
roles="bigshot""/>
</tomcat-users>
Web.xml
Digest utility;
Conf/tomcat-users.xml replace the password
Client change tcauthDigest*
The revised client needs to be executed with the JAR files
bin/tomcat-juli.jar and
lib/catalina.jar on the classpath. The compiler needs only
the catalina.jar file on the classpath.
Digest utility
Tomcat provides a digest utility, in TOMCAT_HOME/bin,
that can be used to generate message digests using the
standard algorithms such as MD5 and SHA.
Here is the command to digest Freds password rockbed:
digest.bat -a SHA rockbed
WSSecurity - WSS
WS-Security is a family of specifications designed to augment wire level security by providing a
unified, transport-neutral, end-to-end framework for higher levels of security such as authentication
and authorization.
THANK YOU