Sunday, October 6, 2013

Composite Pattern on Web Service

In recent day, I have seen for some requirements that the system has been adopted to multiple devices other than web such as mobile, tablet etc. However, I found some system has their business logic embedded into some web page rendering code. As a Enterprise Distributed System Developer, there always turn out a question which software programmer might not have to encounter - Should I implement an Interface on Web service?
People like you might think : what's difference? Since you have decouple the modularity  through an Interface, so you could just make reference to the module in web page or some other project that consume this module as a client. But here are the things, first this Interface contains an composite pattern which provide so many operations we want them to be hidden from web UI which means the UI team doesn't have to understand the operation detail. Second is the crucial reason that the operations require spec change all the time and we don't want to publish or deliver this module with the consequence of impacting the UI (they might have to recompile for adopting new feature of the business logic that just has been re-design and re-implement).
Hence, the Web Service-lized Composite Pattern gives us the benefit that we can expose whole bunch powerful services within Enterprise Distributed System and the clients from the other department or business domain don't have to learn about the detail. Even more, as long as the interface hasn't been re-org or re-structured, the business logic inside could adopt the new governor regulation, company policy or business management methodology without impact the UI. However, things are not as simple as I thought that just move the module of composite class onto web service. There are some point of view we have to consider about:
1. Are all the operation Thread-Safe? Assumable speaking your composite class can execute the complex business context. Then it might handle the multiple transaction between database. Or the class utilize the vendor's library which manage some file system or TCP/IP connection to the external legacy system. There always comes surprises within the library of black box especially when the module deal with so many business contexts as the system's feature advanced. Usually I will use the ajax to simulate the simultaneous request to a composite class that has just been implement behind web service. We need a developer with substantial business knowledge who is hard to be recruited for tracing the any resource contention or transaction lock inside the class. You could wrap the composite class with singleton pattern for managing the potential trouble of intrinsic multi-threaded web request. However, this superficial solution would bring the next question.
2. Would the labor operation drag down the performance and stability of Web Application Server severely? Web Server can not do every thing for us while the operation is really laboring and time consuming. While you have a resident daemon in OS that work for a laboring job, the web interface on this operation for monitoring, event dispatching and notification might not a good design due to the object management and scope would be handed out to web server not your daemon. Web server has its limit and we shouldn't treat it like a dummy daemon with all benefit about web access.
3. Do you have good solution to deal with Stateless Connection on State-full Transaction Management? Business context might be long and synchronization required. If you use your composite class within an application which provide the state management of data model. Then you should prepare that any context cutting and state synchronization effort would emerge in coming future.
4. How you handle the Authentication and Authority Logic rely on Domain or other Client Certificate Technique? These crucial features are resident in whole business context. Separating the composite class bring you to verify the authentication and authority between client library and web service again. For some enterprise systems, the principal-deputy relationship, surrogate operation and audit regulation might be your major burden while you want to pull out some business context for flexibility and accessibility.
Those issues should be considered at the beginning of the system and architecture design. Unfortunately, many projects are implemented before they realize where are the composite pattern. Even worse, the UI's code and business Logic have been entangled that require a lot of re-factor work before we extricate the composite class to web service.

No comments:

Post a Comment