Best Practices


This section delves into some tips and advice about the design and implementation of WebLogic Web services. As with any evolving technology, the topic of best practices is in the process of constant discovery and refinement. These guidelines work well primarily for extra-enterprise (for outside client consumption) or inter-enterprise (between two disparate enterprises or partner companies) Web services. For intra enterprise Web services, some of these rules may be relaxed .

Employing Coarse-Grained Interactions

One of the basic tenets of Web services is that they should employ coarse-grained interactions. This point is akin to the EJB design principle that entity beans are inherently fine-grained and hence should be fronted by session beans. In other words, a Web service interaction should be embodied in as few operation calls as possible. This approach has several advantages:

  • It reduces network traffic, which optimizes performance.

  • Fewer operation invocations can simplify exception handling.

Remember to export services , not your application components . You should not be able to detect your component architecture through the Web service. Why? First of all, doing so would almost inevitably make your Web service too fine-grained. Second, you don t want your Web service to be too tightly coupled with your component architecture. That way, your internal system architecture can change and evolve without necessarily affecting your published Web services. If possible, create a separate front, or layer of wrapper code (maybe EJBs), between your components and the Web service. This greatly increases flexibility and reduces fragility. Remember, your service description or WSDL will tend to outlive your application components.

Your Web service should offer interactions at a business level, utilizing the business vocabulary for the particular domain. In fact, the engineers and architects who are building such services may not be the best people to design the service interactions (operations); perhaps a business or corporate developer is more fitting. Incidentally, that is the goal of WebLogic Workshop: to empower business professionals ”that is, non-programmer types ”to create enterprise Web services.

Promoting Loose Coupling

Loose coupling means that the client should not in any way have knowledge or dependence on how a service is implemented. Also, a client s interaction with the service should be within the confines of a published or public interface ”no secret backdoors or clandestine agreements ( especially error codes or function codes). Presume nothing about your client or server, except what is published in a service description, like a WSDL file. Now that we ve said that, the truth is that WSDL files today do not carry enough semantic information, so some presumptions must be made; for instance, you can only deduce that a service named StockTrader with an operation called buy must be a request to buy shares of company stock.

Deciding What Service Mode Is Important

Synchrony or asynchrony in a Web service solution can make or break the model. In general, you should use a synchronous (RPC) Web service when its operation response or result is necessary for the client process or execution to continue. Asynchronous interactions are generally more natural for application-to-application communications because they can hide mismatches in the performance and availability of the communicating systems. Asynchrony also tends to localize interaction failures; because timing is not an issue, there is likely no Domino Effect. Therefore, asynchrony is usually necessary in cases where there are complex, multi-party interactions or transactions.

Avoiding Method Overloading

The SOAP specification distinguishes operations only by name, without regard for their signatures. Whereas Java allows two methods of the same name to co-exist if they have different argument lists, a SOAP message or WSDL file cannot distinguish between the two. This is not to say that your Web service back-end Java components cannot have overloaded methods. It can; you just cannot expose all such overloaded methods without having to rename them for uniqueness in the web-services .xml file. You can also select one particular overloaded method for inclusion into the Web service without renaming it by specifying both the method name and its signature when mapping the method to an operation in the web-services.xml file.

Knowing That Web Services Are Not Always the Answer

Web services do not always provide the solution you re seeking either. More well established distributed computing technologies such as RMI, JMS, or CORBA are still relevant and, in fact, solve many problems that Web services cannot yet address. A Web service is not meant to replace all binary protocols. The biggest claim about Web services thus far is that they can tie together totally disparate and incompatible systems, regardless of their programming language or platform legacies.



BEA WebLogic Platform 7
BEA WebLogic Platform 7
ISBN: 0789727129
EAN: 2147483647
Year: 2003
Pages: 360

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net