1. Start designing web service with WSDL and schema i.e., follow Top-Down approach.If already have classes or EJBs that need to be exposed as web services,then bottom-up approach is the only choice and the resulting WSDL will be generated by Web Services toolkit. It is easy to design a Web Service from exisiting classes but then it offers less flexibility when reuse of definitions are desired. Also, the WSDL will contain a format that is specific to the web services toolkit being used and it will not be possible to add extra information or annotations in the WSDL by including the documentation element of WSDL.
2. In RPC style of web services, the job of marshalling and unmarshalling is performed by SOAP engine. This may lead to significant performance degradations if complex operations are involved. However, RPC style web services are better suited for implementing fine-grained functionalities.
3. Implemention of Document style web services is complex and time-consuming. Document-style Web Services can handle large documents without any performance trade-offs. If coarse-grained functionality is required then Document style web service is the right choice. These are also suitable when asychronous operations are involved.
4. Using “encoding” requires both sides to have prior knowledge of the encoding style. It is the responsibility of SOAP engine to perform encoding adn decoding, which is an overhead. It is not preferred for complex data structures.
5. When use is set to “literal”, XML schema directly defines the data types. It is preferred when complex and custom data types are involved and better performance is desired.
6. To decide what style and use from available choices: RPC-encoded, RPC-literal, Document-literal and Document-encoded, should be used, following link that gives detailed explanation can be referred:
7. SOAP with attachment or SwA is useful for documents that conforms to schema in languages not supported by web service end point.Sending information as attachments rather than in SOAP body results in smaller body and faster processing. However, writing a SOAP handler can be tedious. Care should be taken while using Message Queues to transmit the message as the message queue capacity may be less and the message may require chopping.
8. Though services can maintain state whenever there is a high volume of related requests and responses and responses need to sent in pieces. Maintaning state is not desired when trying to implement Service Oriented Architecture though.
9. As XML is verbose and takes up considerable size, solutions like binary-XML can be used to zip or compress the message. Both client and server should be able to access the compression technique.
10. Use message oriented middleware (MOM) to handle asynchronous communication and where sensitive data are transmitted. This is a good choice to achieve Reliable Messaging.
11. Data binding specific to a SOAP engine is switched off in case of Document –literal style web service. Custom binding mechanisms like castor, xmlbeans, JAXB, JaxMe can be used by applications to offload the job of marshalling and unmarshalling from SOAP engine and handle custom data types.
12. SOAP engines use parsing mechanisms internally. Parsing is an overhead and it can lead to performance issues. Axis 2.0 uses a new mechanism called AXIOM (AXis Object Model) which is a StAX-based, XML Infoset compliant object model which supports on-demand building of the object tree.
13. Use WS-Security for transmitting sensitive data. However, always secure part of message and not the entire message. Usage of HTTPS for transport level security is desired. SAML should be used for identity management.
14. Use a test harness tool like SOAPUI for testing the web services client by creating mock or simulated web services. Use TCP/IP monitor for tracing the SOAP messages.
15. XML security gateways and proxies can be used to prevent Denial of Service (DoS) attacks.
16. ESB or Enterprise Service Bus can be used when there is lot of integrating logic and activities like message routing, validation, enrichment, transformation, monitoring, logging and event management need to be deferred. ESB is the underlying infrastructure for implementing SOA. Canonical applications can be exposed as web services using adapters and current world ESBs are equipped with adapters for such applications.
17. Use UDDI-based registry to maintain a system of record, increase visibility of services and manage lifecycle and versioning of services.
18. Use a workflow language like BPEL to orchestrate services and provide Business Process Management (BPM). This is important for facilitating agility and hiding technical complexities.
19. Check if your web service is WS-I basic profile compliant and conforming to all the rules. http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile