wsimport vs wsgen
The wsimport tool generates JAX-WS portable artifacts used in JAX-WS clients and services. The tool reads a WSDL and generates all the required artifacts for web service development, deployment, and invocation.
In the working directory, invoke the wsimport utility, which likewise comes with core Java 6:
% wsimport -p teamsC -keep http://localhost:8888/teams?wsdl
This utility generates various classes in the subdirectory teamsC (the -p flag stands for package). These classes make it easier to write a client against the service.
% wsimport
displays a short report on how the utility can be used. The first example with wsimport produces client artifacts against the TimeServer service.
After the ch01.ts.TimeServerPublisher application has been started, the command:
% wsimport -keep -p client http://localhost:9876/ts?wsdl
generates two source and two compiled files in the subdirectory client.- wsimport -keep -p client ts.wsdl
The wsgen tool reads a service endpoint implementation class and generates all of the portable artifacts for a JAX-WS web service..
The wsgen utility also can be used to generate a WSDL document for a web service. For example, the command:
% wsgen -cp "." -wsdl ch01.ts.TimeServerImpl
The wsgen utility produces the classes required to build the WSDL, classes known as wsgen artifacts. The command:
% wsgen -keep -cp . ch01.ts.TimeServerImpl
MessageContext, which is normally accessed in handlers: the subtypes SOAPMessageContext and LogicalMessageMessageContext are the parameter types, for example, in the handleMessage callbacks of SOAP and logical handlers, respectively.
In a handler or SIB, Java provides access to HTTP messages in a MessageContext. In a Java-based client, Java likewise gives access to the HTTP level but in this case through the BindingProvider and the request/response contexts, which are exposed as BindingProvider properties. The code examples illustrate application-level as opposed to handler-level access to transport messages.
SOAP Attachments
There are basically three options for SOAP attachments: SwA (SOAP with Attachments), the original SOAP specification for attachments; DIME (Direct Internet Message Encapsulation), a lightweight but by now old-fashioned encoding scheme for attachments; and MTOM (Message Transmission Optimization Mechanism), which is based on XOP (XML-Binary Optimized Packaging). JWS has a DIME extension whose main purpose is to interoperate with Microsoft clients. Up until the release of Microsoft Office 2003, a web service client written in Visual Basic for Applications (VBA) could handle only DIME rather than MTOM attachments. The SwA approach has drawbacks. For one, it is hard to use SwA with a document-style service, which is now the norm. Further, frameworks such as DotNet do not support SwA. MTOM has the W3C stamp of approval and enjoys widespread support; hence, MTOM is the efficient, modern, interoperable way to transmit binary data in SOAP-based web services.
REST
As Web-based informational items, resources are pointless unless they have at least one representation. In the Web, representations are MIME-typed. The most common type of resource representation is probably still text/html, but nowadays resources tend to have multiple representations.
The RESTful approach keeps the complexity out of the transport level, as a resource representation is transferred to the client as the body of an HTTP response message. By contrast, a SOAP-based service inevitably complicates the transport level because a SOAP message is encapsulated as the body of a transport message; for instance, an HTTP or SMTP message. SOAP requires messages within messages, whereas REST does not.
The @WebService annotation signals that the messages exchanged between the service and its clients will be SOAP envelopes. The @WebServiceProvider signals that the exchanged messages will be XML documents of some type, a notion captured in the phrase raw XML
A service annotated with @WebServiceProvider implements the Provider interface, which requires that the invoke method:
public Source invoke(Source request)
be defined. This method expects a Source of bytes (for instance, the bytes in an XML document that represents the service request) and returns a Source of bytes (the bytes in the XML response).
A RESTful Provider implements the method:
public Source invoke(Source request)
and a Dispatch object, sometimes described as a dynamic service proxy, provides an implementation of this method on the client side. Recall that a Source is a source of an XML document suitable as input to a Transform, which then generates a Result that is typically an XML document as well. The Dispatch to Provider relationship supports a natural exchange of XML documents between client and service:
The client invokes the Dispatch method invoke, with an XML document as the Source argument. If the request does not require an XML document, then the Source argument can be null.
The service-side runtime dispatches the client request to the Provider method invoke whose Source argument corresponds to the client-side Source.
The service transforms the Source into some appropriate Result (for instance, a DOM tree), processes this Result in an application-appropriate way, and returns an XML source to the client. If no response is needed, null can be returned.
The Dispatch method invoke returns a Source, sent from the service, that the client then transforms into an appropriate Result and processes as needed.
The fact that the Provider method invoke and the Dispatch method invoke have the same signature underscores the natural fit between them.
WADL stands for Web Application Description Language
JAX-RS (Java API for XML-RESTful Web Services)
For now, JAX-WS and For now, JAX-WS and JAX-RS are separate frameworks. It would not be surprising if, in the future, the two frameworks merged are separate frameworks. It would not be surprising if, in the future, the two frameworks merged.
Java Web Services Security
HTTPS (HyperText Transport Protocol over Secure Socket Layer)
Java has various packages that support SSL/TLS in general and HTTPS in particular. JSSE (Java Secure Sockets Extension) has been part of core Java since JDK 1.4.
Peer authentication
Alice needs Bob to authenticate himself so that she is sure about who is on the receiving end before she sends the secret message. Bob, too, needs Alice to authenticate herself so that he knows that the secret message is from her rather than an impostor such as Eve. This step also is described as mutual authentication or mutual challenge.
Confidentiality
Once Alice and Bob have authenticated each other, Alice needs to encrypt the secret message in such a way that only Bob can decrypt it. Even if Eve intercepts the encrypted message, she should not be able to decrypt the message because doing so requires enormous computational power or incredibly good luck.
Integrity
The message that Alice sends should be identical to the one that Bob receives. If not, an error condition should be raised. The received message might differ from the sent one for various reasons; for instance, noise in the communications channel or deliberate tampering by Eve. Any difference between the sent and the received message should be detected.
Symmetric Encryption/Decryption
Modern approaches to encryption follow two different approaches, symmetric and asymmetric. Under either approach, the bits to be encrypted (plain bits) are one input to an encryption engine and an encryption key is the other input (see Figure 5-3). The encrypted bits are the cipher bits. If the input bits represent text, then they are the plaintext and the output bits are the ciphertext. The cipher bits are one input to the decryption engine, and a decryption key is the other input. The decryption produces the original plain bits. In the symmetric approach, the same key—called the secret key or the single key—is used to encrypt and decrypt (see Figure 5-4). The symmetric approach has the advantage of being relatively fast, but the disadvantage of what is known as the key distribution problem. How is the secret key itself to be distributed to the sender and the receiver?
Asymmetric Encryption/Decryption
In the asymmetric approach, the starting point is a key pair, which consists of a private key and a public key. As the names suggest, the private key should not be distributed but safeguarded by whoever generated the key pair. The public key can be distributed freely and publicly. If message bits are encrypted with the public key, they can be decrypted only with the private key, and vice-versa. Figure 5-5 illustrates. The asymmetric approach solves the key distribution problem, but asymmetric encryption and decryption are roughly a thousand times slower than their symmetric counterparts.
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
The clientAuth attribute is set to false, thereby indicating that Tomcat does not challenge the client. The default client behavior is to challenge the server.
No comments:
Post a Comment