Package com.sun.xml.ws.server
This document describes the architecture of server side JAX-WS 2.0.1 runtime.
JAX-WS 2.0.1 Server Runtime Sequence Diagram

Message Flow
A Web Service invocation starts with either the
com.sun.xml.ws.transport.http.servlet.WSServletDelegate
or the com.sun.xml.ws.transport.http.server.ServerConnectionImpl
.
Both of these classes find the appropriate com.sun.xml.ws.server.RuntimeEndpointInfo
and invokes the com.sun.xml.ws.server.Tie#handle(com.sun.xml.ws.api.server.WSConnection,
com.sun.xml.ws.spi.runtime.RuntimeEndpointInfo) Tie.handle
method. This method first creates a com.sun.pept.ept.MessageInfo MessageInfo
used to gather information about the message to be received. A
com.sun.xml.ws.server.RuntimeContext RuntimeContext
is then created with the MessageInfo and the RuntimeModel
retrieved from the RuntimeEndpointInfo. The RuntimeContext is then
stored in the MessageInfo. The com.sun.pept.ept.EPTFactory EPTFactory
is retrieved from the com.sun.xml.ws.server.EPTFactoryFactoryBase EPTFactoryFactoryBase
and also placed in the MessagInfo. A com.sun.pept.protocol.MessageDispatcher MessageDispatcher
is then created and the receive method is invoked. There will be two
types of MessageDispatchers for JAX-WS 2.0.1, SOAPMessageDispatcher
(one for client and one for the server) and an XMLMessageDispatcher
(one for the client and one for the server).
The MessageDispatcher.receive method orchestrates the receiving of a Message. The SOAPMessageDispatcher first converts the MessageInfo to a SOAPMessage. The SOAPMessageDispatcher then does mustUnderstand processing followed by an invocation of any handlers. The SOAPMessage is then converted to an InternalMessage and stored in the MessageInfo. The converting of the SOAPMessage to an InternalMessage is done using the decoder retrieved from the EPTFactory that is contained in the MessageInfo. Once the SOAPMessage has been converted to an InternalMessage the endpoint implementation is invoked via reflection from the Method stored in the MessageInfo. The return value of the method call is then stored in the InternalMessage. An internalMessage is then created from the MessageInfo. The SOAPEncoder is retrieved from the EPTFactory stored in the MessageInfo. The SOAPEncoder.toSOAPMessage is then invoked to create a SOAPMessage from the InternalMessage. A WSConnection is then retrieved from the MessageInfo and the SOAPMessage is returned over that WSConnection.
External Interactions
SAAJ API
JAX-WS creates SAAJ jakarta.xml.soap.SOAPMessage from the HttpServletRequest. At present, JAX-WS reads all the bytes from the request stream and then creates SOAPMessage along with the HTTP headers.
jakarta.xml.soap.MessageFactory(binding).createMessage(MimeHeaders, InputStream)
SOAPMessage parses the content from the stream including MIME data
com.sun.xml.ws.server.SOAPMessageDispatcher::checkHeadersPeekBody()
SOAPMessage.getSOAPHeader() is used for mustUnderstand processing of headers. It further uses jakarta.xml.soap.SOAPHeader.examineMustUnderstandHeaderElements(role)
SOAPMessage.getSOAPBody().getFistChild() is used for guessing the MEP of the request
com.sun.xml.ws.handler.HandlerChainCaller:insertFaultMessage()
SOAPMessage.getSOAPPart().getEnvelope() and some other SAAJ calls are made to create a fault in the SOAPMessage
com.sun.xml.ws.handler.LogicalMessageImpl::getPayload() interacts with SAAJ to get body from SOAPMessage
com.sun.xml.ws.encoding.soap.SOAPEncoder.toSOAPMessage(com.sun.xml.ws.encoding.soap.InternalMessage, SOAPMessage). There is a scenario where there is SOAPMessage and a logical handler sets payload as Source. To write to the stream, SOAPMessage.writeTo() is used but before that the body needs to be updated with logical handler' Source. Need to verify if this scenario is still happening since Handler.close() is changed to take MessageContext.
com.sun.xml.ws.handlerSOAPMessageContextImpl.getHeaders() uses SAAJ API to get headers.
SOAPMessage.writeTo() is used to write response. At present, it writes into byte[] and this byte[] is written to HttpServletResponse.
JAXB API
JAX-WS RI uses the JAXB API to marshall/unmarshall user created
JAXB objects with user created JAXBContext
.
Handler, Dispatch in JAX-WS API provide ways for the user to specify his/her own
JAXBContext. com.sun.xml.ws.encoding.jaxb.JAXBTypeSerializer
class uses all these methods.
Marshaller.marshal(Object,XMLStreamWriter)
Marshaller.marshal(Object, DomResult)
Object Unmarshaller.unmarshal(XMLStreamReader)
Object Unmarshaller.unmarshal(Source)
AttachmentMarshaller
AttachmentUnmarshaller
-
ClassDescriptionPartial implementation of
InstanceResolver
with code to handle multiple instances per server.PartialWSWebServiceContext
implementation.DefaultResourceInjector
.DefaultValidationErrorHandler
that just rethrows SAXException in case of errors.Tubes that implement this interface will receive notification of the WSEndpoint holding the tubeline after successful endpoint creation.Entry point to the JAX-WS RI server-side runtime.InvokerTube<T>Base code forProviderInvokerTube
andSEIInvokerTube
.SDDocument
implmentation.Tube
that does the schema validation on the server side.ServiceDefinition
implementation.InstanceResolver
that always returns a single instance.InstanceResolver
that looks at JAX-WS cookie header to determine the instance to which a message will be routed.Codec
throws this exception when it doesn't understand request message's Content-TypeWSEndpoint
implementation.ManagedObjectManager
proxy class forWSEndpointImpl
instances that could be used when Gmbal API calls need to be deferred.