Byju Veedu's List: SCJDWS

• An ENVELOPE MUST NOT have any element children of soap:Envelope following the   soap:Body element.
• The children of the soap:Body element in an ENVELOPE MUST be namespace qualified.
• An ENVELOPE MUST NOT contain soap:encodingStyle attributes on any element that is a child of   soap:Body.
• In a DESCRIPTION, declarations MUST NOT use wsdl:arrayType attribute in the type declaration.

• When they appear in a DESCRIPTION, wsdl:import elements MUST precede all other elements   from the WSDL namespace except wsdl:documentation. 

    When they appear in a DESCRIPTION, wsdl:types elements MUST precede all other elements from the   WSDL namespace except wsdl:documentation and wsdl:import. 
• The set of faultcode values defined in SOAP 1.1 document is: VersionMismatch,  MustUnderstand, Client, Server.
• A RECEIVER MUST accept faults that have any number of elements, including zero,   appearing as children of the detail element. Such children can be qualified OR unqualified.
• When an ENVELOPE is a Fault, the element children of the soap:Fault element MUST be unqualified.
• When an ENVELOPE is a Fault, the soap:Fault element MUST NOT have element children other than   faultcode, faultstring, faultactor and   detail.
• An ENVELOPE SHOULD NOT contain the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace".

• The soap:Envelope, soap:Header, and soap:Body elements  in an ENVELOPE MUST NOT have attributes in the namespace "http://schemas.xmlsoap.org/soap/envelope/".
• he value of the SOAPAction HTTP header field in a HTTP request MESSAGE MUST be a quoted string.

10 more annotations...

• The XML Schema specification consists of three parts. One part defines a set of simple datatypes, which can be associated with XML   element types and attributes; this allows XML software to do a better job of managing dates, numbers, and other special forms of   information. The second part of the specification proposes methods for describing the structure and constraining the   contents of XML documents, and defines the rules governing schema validation of documents. The third part is a primer   that explains what schemas are, how they differ from DTDs, and how one builds a schema.
• In SOAP 1.2 multireference values may be encoded in-place rather than as "top-level" elements (as in SOAP 1.1):
• id="henryford"

  • this is a mistake.It should be id=''mz"

• XML Schema defines four main elements: 

  1.   xsd:element declares an element and assigns it a type. 

  2.   xsd:attribute declares an attribute and assigns it a type.  

  3.   xsd:complexType defines a new complex type.  

  4.   xsd:simpleType defines a new simple type.  
• Facets include: length, minLength, maxLength,  pattern, enumeration, whiteSpace,  maxInclusive, maxExclusive, minInclusive,  minExclusive, totalDigits, fractionDigits.
• The enumeration facet lists all allowed values. Applies  to all simple types except boolean
• Each element in the xsd:all group must occur zero or once; that is minOccurs   and maxOccurs must each be 0 or 1. The xsd:all group must be the top   level element of its type. The xsd:all group may contain only individual element   declarations; no choices or sequences

5 more annotations...

• . "XML Schema Part 2: Datatypes" supports enumerations for all of the simple types except for   boolean.
• The recommended representation of an opaque array of bytes is the 'base64' encoding   defined in XML Schemas, which uses the base64 encoding algorithm. However, the line length restrictions that normally   apply to base64 data in MIME do not apply in SOAP. A "SOAP-ENC:base64" subtype is supplied for   use with SOAP

• Now arrays have two attributes: 

   

  •   itemType is the the type of the array (String, int,   XML complex type). 

  •   arraySize - The array's dimensions are represented by each item in the list of   sizes (unspecified size in case of the asterisk). The number of items in the list represents the number   of dimensions in the array. The asterisk, if present, MUST only appear in the first position in the list. 

      The default value of the arraySize attribute information item is "*",   that is by default arrays are considered to have a single dimension of unspecified size. 

   

   
• In XML Schema, we can use nillable attribute to indicate that whether the element's content could be   nil, as in <xsd:element name="birthDate" type="xsd:date" nillable="true"/>.  If the content of an element is nil, we can use xsi:nil attribute to signal the processor, as in  <birthDate xsi:nil="true" /> and this element must not contain any content.
• The JAX-RPC 1.1 specification defines that <xsd:any/> element is mapped to the SAAJ's   javax.xml.soap.SOAPElement interface. This means that the Service Endpoint Interface [SEI] will contain a   parameter or return value of type javax.xml.soap.SOAPElement for each place in the schema where   <xsd:any/> was used and, respectively, javax.xml.soap.SOAPElement[] if the   maxOccurs attribute is bigger than 1

3 more annotations...

• A SOAP node can be the initial SOAP sender, an ultimate SOAP receiver, or a SOAP   intermediary. A SOAP node receiving a SOAP message MUST perform processing according to the SOAP processing model   as described in this section and in the remainder of this specification. A SOAP node is identified by a URI
• The SOAP headers control and process a message as it moves along a   message path. They include information that controls messaging qualities of service such as security, reliability,   and addressing. By specifying new headers, you can create interoperable protocols based on SOAP. These form   the basis of the services architecture
• The env:Body element within the SOAP message is MANDATORY.
• When a SOAP node processes a SOAP message, the node is said to act in one of several roles.   A SOAP role identifies how a SOAP node should process a message. A URI identifies the SOAP role. It might be one   of the three roles within the SOAP specification or one that systems designers assign to meet the needs of some   applications. It appears as an attribute on the parent header block element
• A header block that has no   role attribute is targeted at the SOAP node that is acting as an ultimate SOAP receiver
• If a header block has a "mustUnderstand" attribute set to 0,   or there is no such attribute, a SOAP node might choose to ignore and not process the header block, even though it   might be targeted at it. If a header block has a "mustUnderstand" attribute and is targeted at   a SOAP node, the SOAP node is obliged to generate and return a SOAP fault if it is unable to process the header block.
• The SOAP processing model states that a node that processes a header must remove it from the message before passing   it to another node along the message path. This is because the SOAP specification errs on the side of caution,   making sure that an intermediary makes no assumptions about what will happen to the message header it has processed   later in the message path. The SOAP specification does, however, allow a node to reinsert a header into an   outbound message with its contents unchanged or altered in some way, but the default behavior of the node is   to remove the header after processing.
• Sometimes, however, a systems designer wants a particular header to be targeted at any or all nodes within   a message path. To allow this, SOAP 1.2 introduces the "relay" attribute. If this attribute   is set to true, a SOAP node that detects a header targeted at itself can forward the   header block to the next node if it chooses not to process it.
• Remember that if a header block also has the "mustUnderstand"   attribute set to true, this over-rules a "relay", and the node must process the header block   if it understands its meaning.

7 more annotations...

• SOAP 1.1 allows additional elements to follow the   SOAP Body element, SOAP 1.2 DISALLOWS these.
• An ENVELOPE MUST NOT have any element children of soap:Envelope following the   soap:Body element
• The element MAY contain a set of header entries each being an immediate child element of the SOAP   Header element. All immediate child elements of the SOAP Header   element MUST be namespace-qualified
• SOAP defines one particular direct child of the SOAP body, the SOAP fault, which is used   for reporting errors
• The children of the soap:Body element in an ENVELOPE MUST be namespace qualified
• The SOAP Fault element is used to carry error and/or status information within a SOAP message. If   present, the SOAP Fault element MUST appear as a body entry and MUST NOT appear more than once within  a Body element.
• A MANDATORY Code element.
• A MANDATORY Reason element information item.
• SOAP 1.1 allows extension of fault codes using a "dot" notation, SOAP 1.2 disallows this and provides   a more XML-like representation instead
• A SAAJ client is a standalone client. That is, it sends point-to-point messages directly to a Web Service that is   implemented for request-response messaging. Request-response messaging is synchronous, meaning that a request is   sent and its response is received in the same operation. A request-response message is sent over a   SOAPConnection object via the method SOAPConnection.call, which sends the   message and blocks until it receives a response. A standalone client can operate only in a client role, that is, it   can only send requests and receive their responses

8 more annotations...

• WSDL language can be described as having two layers:  

   

   
  1.  

     The service definition layer describes abstract properties:

      

      

      

      
     •  

       data types

        
     •  

       message types

        
     •  

       operations

        
     •  

       services

      
      
  2.  

     The binding layer describes concrete properties:

      

      

      

      
     •  

       protocols

        
     •  

       data formats
• e definitions element MUST be the root element of all  WSDL documents
• For interoperability the WS-I BP 1.1 requires that all messages must be sent  using the SOAP 1.1 protocol over an HTTP transport
• WS-I BP 1.1: A wsdl:binding in a DESCRIPTION MUST either  be a rpc- literal binding or a document-literal binding

2 more annotations...

• Annotations
• Annotations
• The implementation of the JAX-WS programming standard provides the following  enhancements for developing Web services and clients
• Better platform independence for Java  applications
• The @WebService annotation tells the server runtime  environment to expose all public methods on that bean as a Web service
• For JAX-WS Web services, the use of the webservices.xml  deployment descriptor is optional because you can use annotations to specify all  of the information that is contained within the deployment descriptor file. You  can use the deployment descriptor file to augment or override existing JAX-WS  annotations. Any information that you define in the webservices.xml deployment descriptor overrides any  corresponding information that is specified by annotations.
• Invoking Web services asynchronously
• With JAX-WS, Web services are called both synchronously and asynchronously.  JAX-WS adds support for both a polling and callback mechanism when calling Web  services asynchronously. Using a polling model, a client can issue a request,  get a response object back, which is polled to determine if the server has  responded. When the server responds, the actual response is retrieved. Using the  callback model, the client provides a callback handler to accept and process the  inbound response object. Both the polling and callback models enable the client  to focus on continuing to process work without waiting for a response to return,  while providing for a more dynamic and efficient model to invoke Web services.
• The asynchronous invocation that uses the callback mechanism requires an  additional input by the client programmer
• Using resource injection
• The application server also supports the usage of the @Resource or @WebServiceRef  annotation to declare JAX-WS managed clients and to request injection of JAX-WS  services and ports
• Data binding with JAXB 2.1
• JAX-WS leverages the Java Architecture for XML Binding (JAXB) 2.1 API and tools  as the binding technology for mappings between Java objects and XML documents
• Dynamic and static clients
• The dynamic client API for JAX-WS is called the dispatch client
• (javax.xml.ws.Dispatch). The dispatch client is an XML  messaging oriented client. The data is sent in either PAYLOAD or MESSAGE mode.
• When using the PAYLOAD mode, the dispatch client is only  responsible for providing the contents of the soap:Body  and JAX-WS adds the soap:Envelope and soap:Header elements
• When using the MESSAGE mode, the dispatch client is  responsible for providing the entire SOAP envelope including the soap:Envelope, soap:Header, and soap:Body elements. JAX-WS does not add anything additional  to the message
• The static client programming model for JAX-WS is the called the proxy client
• Support for MTOM
• Multiple data binding technologies
• Support for SOAP 1.2
• Development tools
• Support for WS-Addressing (JAX-WS 2.1)
• Support for JAX-WS 2.1 features

23 more annotations...

• JAX-WS allows developers to write message-oriented as well as RPC-oriented web  services
• With JAX-WS, clients and web services have a big advantage: the platform  independence of the Java programming language. In addition, JAX-WS is not  restrictive: a JAX-WS client can access a web service that is not running on the  Java platform, and vice versa. This flexibility is possible because JAX-WS uses  technologies defined by the World Wide Web Consortium (W3C): HTTP, SOAP, and the  Web Service Description Language (WSDL)

• A Java class (not an interface) annotated with a javax.jws.WebService annotation can be used to define a Web  service
• In pratice, in order to exclude a public method of a class annotated with WebService and not directly specifying a endpointInterface
• from the implicitly defined SEI, it is necessary to annotate the method with a  WebMethod annotation with the exclude element set to true.
• For mapping purposes, this class must be a top level class or a static inner  class. As defined by JSR 181, a class annotated with javax.jws.WebService MUST HAVE a default  public constructor
• A Java service endpoint interface (SEI) is mapped to a wsdl:portType element
• It MUST carry a javax.jws.WebService annotation
• javax.jws.WebMethod if used, MUST NOT have the exclude element set to true.
• the JAX-WS mapping again has a lot of annotations. Another difference is that  the JAX-RPC method can throw java.rmi.RemoteException  while the JAX-WS method is not defined to do so
• Exploring document/literal pattern
• @SOAPBinding(parameterStyle = ParameterStyle.BARE)
• a new annotation appears at the interface level as well, @SOAPBinding. This annotation provides information about the  parameter style. If absent, the default value for the parameterStyle attribute is wrapped

• Exploring the RPC/literal patterns
• @SOAPBinding(style = Style.RPC)
• JAX-WS does not support any mappings for WSDL documents that contain an encoded  representation for the data. This comes from JAX-WS's compliance with WS-I's  Basic Profile 1.1, which does not allow usage of encoded WSDL documents.
• For JAX-RPC, there are a set of classes defined by the specification as holder  classes for known types. These include types like java.lang.String and other primitive types. For user defined  types, JAX-RPC requires that custom holder classes be generated that can handle  the user-defined types. JAX-WS, on the other hand, makes use of the Generics  feature in Java 5 to provide a single class that can work for all types,  including user-defined types

13 more annotations...

• @WebService @BindingType(value="http://www.w3.org/2003/05/soap/bindings/HTTP/")
• In JAX-WS 2.0 service endpoint interface is no longer required. If a service  endpoint interfaces is desired, then the @WebService  annotation on the endpoint implementation is modified to specify the endpoint  interface and the actual service endpoint interface must also have a @WebService annotation
• NOTE: The following rules apply for methods on classes annotated with the  @WebService annotation
•  
  •  

    If the @WebService annotation of an implementation  class references an Service Endpoint Interface (SEI), the implementation class  MUST NOT have any @WebMethod annotations.

     
  •  

    ALL public methods for an SEI are considered exposed methods regardless of  whether the @WebMethod annotation is specified or not.  It is incorrect to have an @WebMethod annotation on an  SEI that contains the exclude attribute.

     
  •  

    For an implementation class that DOES NOT reference an SEI, if the @WebMethod annotation is specified with a value of exclude=true, that method is NOT exposed. If the @WebMethod annotation is not specified, all public methods  are exposed including the inherited methods with the exception of methods  inherited from java.lang.Object.

• javax.jws.OneWay

   

  The purpose of this annotation is to mark a method as a web service one-way  operation

• javax.jws.WebParam

   

  This annotation is used to customize the mapping of a single parameter to a  message part or element.

• javax.jws.WebResult

   

  This annotation is used to customize the mapping of the method return value  to a WSDL part or XML element

• JSR 181 also allows you to specify a SOAPBinding  annotation on a endpoint implementation or service endpoint interface. This  annotation lets the developer choose between document/literal wrapped,  document/literal bare, rpc/literal and rpc/encoded endpoints with the default  being document/literal wrapped. JAX-WS 2.1 does not support rpc/encoded.

   

  The main difference between document/literal bare and document/literal  wrapped is that methods on a document/literal wrapped endpoint can have multiple  parameters bound to the body of a SOAP message, while a document/literal bare  can only have one such parameter.

   

  The main difference between document/literal wrapped and rpc/literal is that  a document/literal invocation can be fully validated by a standard validating  XML parser, while an rpc/literal invocation cannot because of the implied  wrapper element around the invocation body.

• javax.xml.ws.RequestWrapper

   

  This annotation annotates methods in the Service Endpoint Interface with the  request wrapper bean to be used at runtime

• javax.xml.ws.ResponseWrapper

   

  This annotation annotates methods in the Service Endpoint Interface with the  response wrapper bean to be used at runtime.

• javax.xml.ws.WebServiceRef

   

  The @WebServiceRef annotation is used to define a  reference to a web service and (optionally) an injection target for it. Web  service references are resources in the Java EE 5 sense.
• •  

    NOTE: The @WebServiceRef annotation can be used to  inject instances of JAX-WS services and ports.

     

    NOTE: The @WebServiceRef annotation is only supported  in certain class types. Examples are JAX-WS endpoint implementation classes,  JAX-WS handler classes, Enterprise JavaBeans classes, and servlet classes. This  annotation is supported in the same class types as the @Resource annotation. See the Java Platform, Enterprise  Edition (Java EE) 5 specification for a complete list of supported class types.  

     
  •  

    javax.xml.ws.Feature
• The @Feature annotation is used to enable/disable a  feature to use for a web service endpoint implementation class. This annotation  is used with @BindingType annotation

• javax.xml.ws.Action

   

  The @Action annotation allows explicit association of  Action message addressing property with input, output,  and fault messages of the mapped WSDL operation

12 more annotations...

• APT

   

  A Java SE tool and framework for processing annotations.
• Fast Infoset is a binary encoding of XML that can improve performance.

• WsImport

   

  Tool to import a WSDL and to generate an SEI (a javax.jws.WebService) interface that can be either  implemented on the server to build a web service, or can be used on the client  to invoke the web service

1 more annotation...

• The starting point for developing a JAX-WS web service is a Java class annotated  with the javax.jws.WebService annotation. The @WebService annotation defines the class as a web service  endpoint
• The business methods of the implementing class must be public, and must NOT be declared static or final.
• The implementing class must NOT be declared final and  must NOT be abstract.

• The implementing class must NOT define the finalize()  method.
• 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 service's WSDL file

3 more annotations...

• When using the javax.xml.ws.Service.Mode.MESSAGE  mode, the Dispatch client is responsible for providing the entire SOAP envelope  including the soap:Envelope, soap:Header, and soap:Body elements.  

   

  When using the javax.xml.ws.Service.Mode.PAYLOAD  mode, the Dispatch client is only responsible for providing the contents of the  soap:Body and JAX-WS includes the payload in a soap:Envelope element.
• The Dynamic Proxy client is dynamically generated at run time using the Java 5  Dynamic Proxy functionality, while the JAX-RPC-based stub client is a  non-portable Java file that is generated by tooling. Unlike the JAX-RPC stub  clients, the Dynamic Proxy client does not require you to regenerate a stub  prior to running the client on an application server for a different vendor  because the generated interface does not require the specific vendor  information.

• Traditionally JAX-WS has never taken advantage of object state, just like  servlet. That is, the container creates only one instance of your service class,  and then have it serve all the requests concurrently. This makes it impossible  to set values to instance fields, as you will experience concurrency problem as  soon as multiple threads hit your service.

   

  On HTTP, session is often used to store state. This technique is still useful  for web services over HTTP
• MessageContext msgContext = wsContext.getMessageContext();  HttpServletRequest request = (HttpServletRequest) msgContext.get(MessageContext.SERVLET_REQUEST);  HttpSession session = request.getSession();
• Using @HttpSessionScope
• One can use @com.sun.xml.ws.developer.servlet.HttpSessionScope  annotation tells the JAX-WS RI to create one instance of Hello per each HTTP session

• Using @Stateful
• The stateful web service support in the JAX-WS RI resolves this problem by  having the JAX-WS RI maintain multiple instances of a service. By using  WS-Addressing behind the scene, it provides a standard-based on-the-wire  protocol and easy-to-use programming model
• Application service implementation classes (or providers) who'd like to use the  stateful web service support must declare @Stateful  annotation on a class. It should also have a public  static method/field that takes StatefulWebServiceManager

5 more annotations...

• One of the key characteristics of a RESTful Web service is the explicit use of  HTTP methods in a way that follows the protocol as defined by RFC 2616.
•  
  •  

    To create a resource on the server, use POST.  

     
  •  

    To retrieve a resource, use GET.

     
  •  

    To change the state of a resource or to update it, use PUT.

     
  •  

    To remove or delete a resource, use DELETE.  
• As a general design principle, it helps to follow REST guidelines for using HTTP  methods explicitly by using nouns in URIs instead of verbs. In a RESTful Web  service, the verbs - POST, GET, PUT, and DELETE - are already defined by the  protocol. And ideally, to keep the interface generalized and to allow clients to  be explicit about the operations they invoke, the Web service should not define  more verbs or remote procedures, such as /adduser or /updateuser
• To give client applications the ability to request a specific content type  that's best suited for them, construct your service so that it makes use of the  built-in HTTP Accept header, where the value of the  header is a MIME type.

2 more annotations...

• JAX-WS supports a "pluggable encoding" - meaning it can use formats other than  textual XML. This extension takes advantage of this and allows JAX-WS services  to be exposed via JSON
• @BindingType(JSONBindingID.JSON_BINDING)
• You just need jaxws-json.jar in your WEB-INF/lib for this to work.

1 more annotation...

• A SOAP-based design may be appropriate when
• A RESTFul design may be appropriate when
• REpresentational State Transfer (REST) is a key design idiom that embraces a  stateless client-server architecture in which the web services are viewed as  resources and can be identified by their URLs. Web service clients that want to  use these resources access a particular representation by transferring  application content using a small globally defined set of remote methods that  describe the action to be performed on the resource. REST is an analytical  description of the existing web architecture, and thus the interplay between the  style and the underlying HTTP protocol appears seamless.
• The web services are completely stateless
• The service producer and service consumer have a mutual  understanding of the context and content being passed along.
• A formal contract must be established to describe the interface that the web  service offers
• The architecture must address complex nonfunctional requirements. Many web  services specifications address such requirements and establish a common  vocabulary for them. Examples include Transactions, Security, Addressing, Trust,  Coordination, and so on.
• The architecture needs to handle asynchronous processing and invocation

6 more annotations...