Web Applications, Services, & Loose Coupling
Tuesday, February 24th, 2009
I think it’s pretty safe to say that most web applications fall into one of two categories.
- Content Driven
- Data Driven
I also think it is pretty safe to say that they are easy to build. However, things can get a little dicey when it comes time to integrate services. The fact is that we are implementing reusable functionality as services and that means that our web applications must now include service clients.
That means we are now responsible for maintaining the client and the UI.
Here is a thought. How about we allow the services to generate their own forms and allow the users to interact with them directly? I do not want to continue playing the middle man.
This approach may not be appropriate for every service, but I suspect it is for quite a few. Here are a few services that are often associated with e-commerce web applications.
- Account Management
- Product Registration
- Payment Processing
Each of these is certainly reusable. In addition to the web application, these services may be consumed by customer support, technical support, and/or kiosks. The point is that it certainly makes sense to implement this functionality as services.
However, this functionality is ultimately user driven. That, and our web application is not going to provide any additional business logic with respect to these services. All it is really doing is generating the HTML form, performing validation upon submission, calling the service, and converting its response to HTML.
Perhaps the only issue is how to we provide a consistent UI if we are allowing the user to interact with the service directly. I think the answer is pretty simple. We’ll use Apache server side includes.
Ultimately, there are only three types of responses.
- Form
- Form + Validation Error(s)
- Result
We can further break that down into two types of tasks.
- Integrate Form with Page
- Integrate Validation Error(s)/Result with Page
Integrate Form with Page
The first one is pretty easy.
- User Sends Request to Apache
- Apache Sends Request to Web Application
- Web Application Returns Response w/SSI for Form
- Apache Sends Include Request to Transformation Service
- Transformation Service Sends Include Request to Service
- Service Returns Response (Form XML)
- Transformation Service Applies Transformation to XML
- Transformation Service Returns Response (HTML)
- Apache Returns Response (HTML)
I front the service(s) with a transformation service so that they are not responsible for generating the HTML. After all, the service may be used by other applications and those applications may or may not be web applications.
Integrate Validation Error(s)/Result with Page
The second one requires a little more work and is really a two step process (post get redirect).
POST
- User Sends Post to Apache
- Apache Sends Post to Transformation Service
- Transformation Service Sends Post to Service
- Service Returns Validation Error(s) or Result (XML)
- Transformation Service Caches Transformed Service Response (HTML)
- Transformation Service Returns Redirect
- Validation Error(s) – Redirect to Form
- Result – Redirect to Result
- Apache Returns Redirect
GET
- User Sends Request to Apache
- Apache Sends Request to Web Application
- Web Application Returns Response w/SSI
- Apache Sends Include Request to Transformation Service
- Transformation Service Sends Cached Response (HTML)
- Transformation Service Removes Cached Response
- Apache Returns Response (HTML)
Tags: apache, Architecture, Integration, loose coupling, services
One Response to “Web Applications, Services, & Loose Coupling”
Leave a Reply
Pages
Calendar
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Oct | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||
nice idea!