Showing posts with label Methodology. Show all posts
Showing posts with label Methodology. Show all posts

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.

Cloud Foundry

IaaS has been proved it is a workable service model. I have seen the Openstack built up my Ubuntu virtual machine in a few minutes. Therefore I can easily create more resource for system development and test.
SaaS is an emergent model for software vendor who can charge their customer based on the usage of software rather than the installation licence. However, even with the support of IaaS, SaaS still face the huge maintain cost on system configuration and backup strategy. Although IaaS brought us a better way on virtualization management, we still have to install, configure and trouble shooting on the system's essential utility or framework such as JVM, HTTP server, Database etc. Hence, the PaaS can fill this gap and bring the SaaS vendor more efficient development cycle especially for those SaaS vendor whose client base requires more customized function.
Cloud Foundry is an opensource PaaS provided by the most famous virtualization solution provider - VMWare. Although Google has the Google App Engine for SaaS vendor. VMWare's solution would be really attractive to the company self-owning private cloud. Most Company who has applied virtualization technology can enhance the infrastructure into IaaS smoothly under the assistance of adequate tool. However, it is really difficult for most company to define or create a PaaS on their private cloud. Hence, most developers are still struggling on designing the platform building block, essential utility configuration, backup, deployment strategy and maintenance. The shortage of PaaS would be the consolidation of platform which might not fit into the certain software really well. Under this circumstance, we might have to customized some configuration or assemble the essential utility for special requirement. Nonetheless, the customized utilities could still be part of our PaaS co-working with the other standardized framework or utilities.

Dependency Management

In the system development, that is really usual that multiple members would join their project to work out a specific function for the coming demand on this system. As the past paradigm which focused on the software and package aspect about the system, the all dependency would be considered about at the early design stage and we have already whole bunch tools that help us to control on those "static binding dependency" between the different binary library files. The compiler is the first stop to be the static binding dependency checker for our software and package. And the programming language infrastructure like C++ has introduced the namespace concept into our practice and give the developers and IDE a good foundation to manage the static binding dependency. A good static dependency design brings benefit on the system flexibility in the future. Therefore, there are so many useful design pattern about how to depict the hierarchy of classes. A good design pattern would have percipient about future change and coordinate libraries in a modest way.
However, just like the beginning of this post, the static binding only solve the internal coupling issue of a set of binary libraries. There are more issues when we combine all those projects into a system. We can categorizing those issues into two genre. One is the issue at early binding. It's pretty common that our program is running on a runtime like .NET or JVM and container like IIS, Tomcat, WPF or even a windows service. The runtime and container provide the variety and useful core libraries for our application. Hence, we write the configuration file for deploying our binary file quite often. Those configuration file is the prime communication way to those runtime and container and tell them what kind of basic service we want those foundation to provide such as authentication method, session control, type including or Resource location. Once the configuration has trouble with the binary files we've deployed or the runtime and container's ability. The early binding activity would alert an error at the initiation of the executable file when Operation system load the whole application into memory. Those executable files such as w3wp, java.exe are the most common container and runtime which require a strong background knowledge about their configuration or command line parameters. Early binding issues require the modern IDE or some trouble shooting skill to dig them out when we try to deploy the application on new machine.
The second genre of dependency management issue other than static binding is the lately binding which is the hardest part without a reliable tool when we deploy the project that we don't familiar with. So called lately binding means that we might never be aware of some type or class implementation loss at deployment until the actual request or running application went through those particular section of our source code. The lost library or class are only initiated when the application ask for. Those libraries or classes are dynamically loaded or reflected by the program when it's necessary. Which means there might be no adequate audit or document that recalls that weak points of the deployment activity. The dynamic loading mechanism is pretty advanced feature in modern system development. Although the blind spot at deployment activity would jeopardize our online application, the flexibility and replaceable binary at runtime still be really attractive to a lot of developers adopt this mechanism into their system design.
The three dependency management aspects mentioned above are all talking about the dependency inside the same process image of a specific memory section that operation system has allocated. But there is a dependency issue that is quiet common at distributed system project. The issues are addressed about the remote service dependency like web service or client-server dependency. At usually circumstance, the consumer (i.e. client) require a specific service provided by a non-existing or accidentally missing server. The occasion was generated by the remiss on deployment activity. Like the missing of dynamical loaded libraries, the possibility of sending the request to a vacant service entry would rise the stake of a certain exception that damages our online application. However, this is due to the neglect of some specific service for the system and the remedy is pretty easy if we have dealt with those exception neatly, just start the remote service. The trade-off between flexibility and integrity of deploying should not be skipped while system analysis. And the balance of flexibility and integrity can also be affected by or do impact to the design of static binding mutually. But this big question is belonging to the domain knowledge among how we isolate the most often changed part in some certain applications. This philosophy perspective has beyond the scope of this article.