Top 10 SOA Considerations

1. Interoperability
   With Web Service protocols evolving rapidly their implementation across the diverse infrastructure is likely to raise issues of interoperability due to different versions and inconsistent implementations by vendors. I recommended that Infrastructure elements will need to be upgraded in parallel to avoid interoperability issues.

2. Performance
   Web Service infrastructure will at least in the near term often constitute an additional layer of infrastructure, as opposed to replacement, impacting performance. However, this should only affect the Web Services themselves, not other messages and transactions passing through the same infrastructure element. I recommended to introduce a parallel infrastructure elements dedicated to Web Services to ensure existing operations are not affected.

3. Granularity of Service
   It is important to design the service interface with the proper level of granularity. Because you want your application to perform well, you should design Web services to be coarse-grained than individual session beans. A good way to achieve a coarse-grained interface is to design the Web service around the documents it handles, since documents are naturally coarse grained. You can apply these principles by exposing Web services that primarily exchange well-defined documents "eg.: purchase orders or invoices". These Web services may call multiple session bean methods to implement the services’ business logic..

4. Passing Parameters as XML Documents or Java Objects
   A SOAP client invokes a service’s functionality by calling the appropriate WebMethod on the service interface and passing the expected parameters. Parameters may be passed as either XML documents, which are represented as SOAPElement objects in the service interface.

5. Layering the Service
   Normally, it’s best when designing a service to separate the service’s interaction layer from the business logic processing layer. This is especially true when an incoming request uses a different data model than the data model used by the business logic. Recall that a service may divide its processing into layers if it handles requests that require significant pre-processing or when there is extensive mapping between the internal data model and the incoming data.

6. Delegating to Business Logic
   After receiving and pre-processing a request, the endpoint must next map the request to the appropriate business logic and delegate it for processing.

7. Publishing Web Service Details
   A Web service endpoint is described by its WSDL file, and clients of the service need access to the WSDL to obtain basic information about the service. One way to disseminate this information to clients is to publish the WSDL files in a Web Services Registry (WSR/UDDI), if the service is open to the general public.

8. Managing Complex Web Service Interactions
   An application may have multiple interactions with the same Web service, it may access different Web services, or it may expose many Web service endpoints. There may be different types of interactions. An application may be both a service and a client. A service endpoint may receive documents of multiple types and hence needs to handle them accordingly. All this makes for complexity in managing Web service interactions. Message-level metadata and a canonical data model are common helper strategies that support complex interactions, and they are good building blocks for adding functionality to a Web service message exchange. By consolidating Web service endpoints, wean make an application’s Web service interactions more manageable.

9. Consolidating Web Service Interactions
   Consolidating Web service interactions is a good way to simplify the complexity of a Web service application. What starts as a straightforward Web service application with basic interactions between a client and a single service often grows into an application that exposes more endpoints and may itself act as a client to other services. The application communication becomes more complicated, and the business logic often becomes closely tied to a particular service. When the number of Web service interactions grows beyond a certain point, you may want to factor out common code for reuse.

10. Building More Robust Web Services
    Both .NET and J2EE platforms conform to the WS-I Basic Profile standards. Conforming to these standards means that the platform uses HTTP as the underlying transport for Web service calls. Unfortunately, from a business communication point of view, the HTTP protocol provides only a low-level degree of robustness. To illustrate, HTTP has no automatic retries to re-establish a connection that disconnects. If the receiving end fails, the entire HTTP call fails and there is no attempt to connect later. This low-level degree of robustness is not necessarily bad, since it means that HTTP can accommodate the participation of all kinds of systems and networks in a distributed Internet environment. HTTP is also a fairly simple protocol that any system can implement with a reasonable amount of effort. Despite using more reliable hardware and software systems and communication links, enterprises have no guarantee against failures. Failures may occur during a Web service request between a SOAP client and a Web service that may leave an application in an ambiguous state.