Lessons Learned From This Week's Enterprise Services Workshop

• Design your services with care (esp. their granularity). Analyze your business services well, and shape your enterprise services around them. Avoid CRUD-like services.


• Apply the Service Agent pattern on the client-side, and provide a central Dispatch-Service on the server-side. Build stateless services only (your state is the database).


• Build a webservice wrapper around your enterprise services, and call against those wrappers during development time. This ensures your services work fine on top of a SOAP stack as well.


• DataSets have a much larger memory footprint than I would have expected. Don't transfer them over the wire, and don't clutter your services with DataSets (imagine hundreds or thousands of DataSets residing in server memory in parallel during concurrent service requests) - which ultimately results to: don't use them at all in an enterprise application scenario.


• Adopt plain old objects (valueholders only) instead of DataSets. Code them in C#. Wrap them inside messages for inter-tier communication (composed of objects, collections of objects and control data), and use tools like xsd.exe for automatic XSD creation.


• Implement your own custom databinding for WinForms. Consider a generic validation mechanism, and try to re-use it on the server-side as well.


• For large numbers of DataRows on the client, e.g. being display by a grid, plan for an efficient paging mechanism.


• Use COM+ infrastructure features like descriptive transaction management, container-managed security, component pooling, connection pooling, etc. (my words, my words)


• I probably overestimated the scalability- and performance-benefit of global database connection pooling (on a central application server), when the client is a WinForms application (which may alternatively run its business logic locally within InProc COM+ / Intranet of course). Esp. SQLServer can easily handle several thousand open connections. Although it's an important issue (and another benefit the application server provides), it is not of the same essence as on web applications, where no pooling would imply constant re-connect (deathblow for response time).


• Script COM+ application deployment and configuration. Don't deploy it manually - it's too error-prone.


• Avoid DataAdapters (another consequence of avoiding Datasets). Work with IDataReader resp. directly with IDBCommand.