This document describes the architecture of server side * JAX-WS 2.0.1 runtime.
* *
*
*
* A Web Service invocation starts with either the * {@link com.sun.xml.internal.ws.transport.http.servlet.WSServletDelegate WSServletDelegate} * or the {@link com.sun.xml.internal.ws.transport.http.server.ServerConnectionImpl ServerConnectionImpl}. * Both of these classes find the appropriate {@link com.sun.xml.internal.ws.server.RuntimeEndpointInfo RuntimeEndpointInfo} * and invokes the {@link com.sun.xml.internal.ws.server.Tie#handle(com.sun.xml.internal.ws.api.server.WSConnection, * com.sun.xml.internal.ws.spi.runtime.RuntimeEndpointInfo) Tie.handle} * method. This method first creates a {@link com.sun.pept.ept.MessageInfo MessageInfo} * used to gather inforrmation about the message to be received. A * {@link com.sun.xml.internal.ws.server.RuntimeContext RuntimeContext} * is then created with the MessageInfo and the {@link com.sun.xml.internal.ws.api.model.SEIModel RuntimeModel} * retrieved from the RuntimeEndpointInfo. The RuntimeContext is then * stored in the MessageInfo. The {@link com.sun.pept.ept.EPTFactory EPTFactory} * is retrieved from the {@link com.sun.xml.internal.ws.server.EPTFactoryFactoryBase EPTFactoryFactoryBase} * and also placed in the MessagInfo. A {@link 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.
*
*
JAX-WS creates SAAJ javax.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.
*javax.xml.soap.MessageFactory(binding).createMessage(MimeHeaders, InputStream)
*SOAPMessage parses the content from the stream including MIME * data
*com.sun.xml.internal.ws.server.SOAPMessageDispatcher::checkHeadersPeekBody()
*SOAPMessage.getSOAPHeader() is used for mustUnderstand processing * of headers. It further uses * javax.xml.soap.SOAPHeader.examineMustUnderstandHeaderElements(role)
*SOAPMessage.getSOAPBody().getFistChild() is used for guessing the * MEP of the request
*com.sun.xml.internal.ws.handler.HandlerChainCaller:insertFaultMessage()
*SOAPMessage.getSOAPPart().getEnvelope() and some other SAAJ calls * are made to create a fault in the SOAPMessage
*com.sun.xml.internal.ws.handler.LogicalMessageImpl::getPayload() * interacts with SAAJ to get body from SOAPMessage
*com.sun.xml.internal.ws.encoding.soap.SOAPEncoder.toSOAPMessage(com.sun.xml.internal.ws.encoding.soap.internal.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.internal.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.
*JAX-WS RI uses the JAXB API to marshall/unmarshall user created * JAXB objects with user created {@link javax.xml.bind.JAXBContext JAXBContext}. * Handler, Dispatch in JAX-WS API provide ways for the user to specify his/her own * JAXBContext. {@link com.sun.xml.internal.ws.encoding.jaxb.JAXBTypeSerializer JAXBTypeSerializer} class uses all these methods.
*{@link javax.xml.bind.Marshaller#marshal(Object,XMLStreamWriter) Marshaller.marshal(Object,XMLStreamWriter)}
*{@link javax.xml.bind.Marshaller#marshal(Object,Result) Marshaller.marshal(Object, DomResult)}
*{@link javax.xml.bind.Unmarshaller#unmarshal(XMLStreamReader) Object Unmarshaller.unmarshal(XMLStreamReader)}
*{@link javax.xml.bind.Unmarshaller#unmarshal(Source) Object Unmarshaller.unmarshal(Source)}
*{@link javax.xml.bind.attachment.AttachmentMarshaller AttachmentMarshaller}
*{@link javax.xml.bind.attachment.AttachmentUnmarshaller AttachmentUnmarshaller}
*JAX-WS RI uses these private API for serialization/deserialization * purposes. This private API is used to serialize/deserialize method * parameters at the time of JAXBTypeSerializer class uses all * these methods.
*{@link com.sun.xml.internal.bind.api.Bridge#marshal(BridgeContext, Object, XMLStreamWriter) Bridge.marshal(BridgeContext, Object, XMLStreamWriter)}
*{@link com.sun.xml.internal.bind.api.Bridge#marshal(BridgeContext, Object, Node) Bridge.marshal(BridgeContext, Object, Node)}
*{@link com.sun.xml.internal.bind.api.Bridge#unmarshal(BridgeContext, XMLStreamReader) Object Bridge.unmarshal(BridgeContext, XMLStreamReader)}
*