Web Services best practices

1. Use XML Schema to define the input and output of your Web Service operations
2. A Web Service should be defined with a WSDL (or WADL in case of REST) and all responses returned by the Web Service should comply with the advertised WSDL
3. Do not use a proprietary authentication protocol for your Web Service.
4. Rather use common standards like HttpAuth or Kerberos.
5. Or define username/password as part of your XML payload and expose you Web Service via SSL
6. Make sure your Web Service returns error messages that are useful for debugging/tracking problems.
7. Make sure to offer a development environment for your service, which preferably runs the same Web Service version as production, but off of a test database rather than production data.
8. Important to retain
   
   • Naming conventions
   • parameter validation
   • parameter order
9. No session data
10. Resource does not need to be in known state
11. request alone contains all information
12. Always include version parameter
13. Handle multiple formates
14. Use heartbeat methods
    
    • method that does nothing with no authentication
      
    • shows service is alive
      
15. All services should be
    
    • accessible
      
    • documented
      
    • robust
      
    • reliable
      
    • simple
      
    • predictable
      
16. Always implement a reliability error listener.
17. Group messages into units of work
18. Set the acknowledgement interval to a realistic value for your particular scenario.
19. Set timeouts (inactivity and sequence expiration) to realistic values for your particular scenario.
20. Configure Web service persistence and buffering (optional) to support asynchronous Web service invocation.
21. Choose between three transport types: asynchronous client transport, MakeConnection transport, and synchronous transport.
22. Using WS-Policy to Specify Reliable Messaging Policy Assertions
    
    • At Most Once
      
    • At Least Once
      
    • Exactly Once
      
    • In Order
      
23. Define a logical store for each administrative unit (for example, business unit, department, and so on).
24. Use the correct logical store for each client or service related to the administrative unit.
25. Define separate physical stores and buffering queues for each logical store.
26. Using the @Transactional Annotation
27. Enabling Web Services Atomic Transactions on Web Services

Read more...

Hibernate best practices

1. Prefer crawling the object model over running queries
• Querying in hibernate always causes a flush
2. Make everying lazy
• First read will be slow but everything else will be cached
3. Use second level cache
4. Use cascade cautiously
• Hibernate is not good at saving a whole object tree in one go
5. Use Field access over method access
• will be faster since no relfection is used
6. Use instrumentation
7. Don't use auto generated Keys
• you have to wait until the object is persisted before its equals method works
8. Use id based Equality
9. Write fine-grained classes and map them using .
• Use an Address class to encapsulate street, suburb, state, postcode. This encourages code reuse and simplifies refactoring.
10. Declare identifier properties on persistent classes.
• Hibernate makes identifier properties optional. There are all sorts of reasons why you should use them. We recommend that identifiers be 'synthetic' (generated, with no business meaning) and of a non-primitive type. For maximum flexibility, use java.lang.Long or java.lang.String.
11. Place each class mapping in its own file.
• Don't use a single monolithic mapping document. Map com.eg.Foo in the file com/eg/Foo.hbm.xml. This makes particularly good sense in a team environment.
12. Load mappings as resources.
• Deploy the mappings along with the classes they map.
13. Consider externalising query strings.
• Externalising the query strings to mapping files will make the application more portable.
14. Use bind variables.
• Even better, consider using named parameters in queries.
15. Don't manage your own JDBC connections.
• Hibernate lets the application manage JDBC connections. This approach should be considered a last-resort.
• If you can't use the built-in connections providers, consider providing your own implementation of net.sf.hibernate.connection.ConnectionProvider.
16. Consider using a custom type.
• Suppose you have a Java type, say from some library, that needs to be persisted but doesn't provide the accessors needed to map it as a component.
• You should consider implementing net.sf.hibernate.UserType.
• This approach frees the application code from implementing transformations to / from a Hibernate type.
17. Understand Session flushing.
• From time to time the Session synchronizes its persistent state with the database.
• Performance will be affected if this process occurs too often.
• You may sometimes minimize unnecessary flushing by disabling automatic flushing or even by changing the order of queries and other operations
  within a particular transaction.
18. In a three tiered architecture, consider using saveOrUpdate().
• When using a servlet / session bean architecture, you could pass persistent objects loaded in the session bean to and from the servlet / JSP layer.
• Use a new session to service each request. Use Session.update() or Session.saveOrUpdate() to update the persistent state of an object.
19. In a two tiered architecture, consider using session disconnection.
• Database Transactions have to be as short as possible for best scalability.
• This Application Transaction might span several client requests and response cycles.
• Either use Detached Objects or, in two tiered architectures, simply disconnect the Hibernate Session from the JDBC connection and reconnect
  it for each subsequent request.
• Never use a single Session for more than one Application Transaction usecase, otherwise, you will run into stale data.
20. Don't treat exceptions as recoverable.
• This is more of a necessary practice than a "best" practice.
• When an exception occurs, roll back the Transaction and close the Session.
• If you don't, Hibernate can't guarantee that in-memory state accurately represents persistent state.
• As a special case of this, do not use Session.load() to determine if an instance with the given identifier exists on the database;
• use find() instead.
21. Prefer lazy fetching for associations.
• Use eager (outer-join) fetching sparingly.
• Use proxies and/or lazy collections for most associations to classes that are not cached at the JVM-level.
• For associations to cached classes, where there is a high probability of a cache hit, explicitly disable eager fetching using outer-join="false".
• When an outer-join fetch is appropriate to a particular use case, use a query with a left join fetch.
22. Consider abstracting your business logic from Hibernate.
• Hide (Hibernate) data-access code behind an interface.
• Combine the DAO and Thread Local Session patterns.
• You can even have some classes persisted by handcoded JDBC, associated to Hibernate via a UserType.
23. Implement equals() and hashCode() using a unique business key.
• If you compare objects outside of the Session scope, you have to implement equals() and hashCode().
• If you implement these methods, never ever use the database identifier!
• To implement equals() and hashCode(), use a unique business key, that is, compare a unique combination of class properties.
• Never use collections in the equals() comparison (lazy loading) and be careful with other associated classes that might be proxied.
24. Don't use exotic association mappings.
• Good usecases for a real many-to-many associations are rare.
• Most of the time you need additional information stored in the "link table".
• In this case, it is much better to use two one-to-many associations to an intermediate link class.
• In fact, we think that most associations are one-to-many and many-to-one, you should be careful when using any other
• association style and ask yourself if it is really neccessary.

Read more...