Project Management

Web services B2B implementation demonstration: Retrospection and reflection

In the ninth article of a continuing series, Kevin Koch presents a walkthrough of the entire application, including application flow and transaction threads. He discusses possible enhancements and reiterates the main design points and principles.


Having reviewed the methodologies and common practices for releasing an application to a staging and production environment, we’ve now reached the end of our journey. In our fictitious scenario, John and Tom would both have operational applications deployed onto production, business would increase, efficiencies would increase, and life is grand.

There has been a lot of information covered in the past eight articles and in this final installment, I’ll take the opportunity to review the key points and design features and also have a look at any enhancements that could be made.

Web services B2B implementation demonstration
Welcome to the ninth and final article in this series, which explores in detail the implementation of a B2B Web service. The series takes you through the development of a complete B2B Web services application. During the course of the series we've encouraged Builder.com members to comment on the progress of the application. Do you have a better implementation? Do you have a question about our B2B solution? Start an article discussion and let us hear from you; we will do our best to address the issue. All nine articles will be compiled into an upcoming download (part 10) for your convenience.

Want to catch up on the series?


The afterglow
There’s a certain feeling of pride and accomplishment upon completing a project successfully. You met the deadlines, captured all the customer requirements correctly, came in on or under budget, and the product exhibits minimal bugs and flaws. However, with some applications, this is where the real work is just beginning, so don’t spend too much time patting yourself on the back just yet.

This is where application development truly becomes a multidepartmental undertaking. It is now the responsibility of other departments to ensure the customer stays content and continues to use the application, consequently generating consistent revenue. Your QA/support staff and marketing department become integral to the continued success of the products you build.

Of course everything is dependent on the type of application that was built, the company business and billing models, and the product roadmap. Senior architects will likely wash their hands of the application, whereas project and product managers and a small development staff will usually be responsible for managing application maintenance.

Re-iterations
Not to be confused with iterative development, I'll re-iterate the main design points and their benefits for John’s and Tom’s applications:

1. Use case modeling
The extraction of concise customer requirements is an art in itself. Many organizations hire people solely for the purpose of capturing and documenting requirements. It requires someone who is capable of translating vague customer requests in layman's terms into detailed technical use cases. In our case we used a systematic process of identifying use cases and entities by simply examining nouns and verbs of the requirements sentence structure.

2. Database design
Once the requirements are defined they become the baseline for everything designed in the application. In our case we were able to identify the entities from the requirements and thus create a database structure of tables, fields and relationships. Additionally, because both applications shared certain information, we were able to normalize and reduce redundancy in the database tables.

3. Database tier component
The database tier exists as a separate assembly defined as a class library in our ASP.NET application. It is responsible for handling all database connectivity and contains classes which map directly to the tables and stored procedures in the database. Having separate assemblies allows the flexibility of running the components on separate servers in a clustered environment.

4. Business tier component
This component also exists as a separate assembly and acts as a facade layer wrapper for the database tier classes and methods. The purpose of this component is to place all specific business logic within these classes. Placing business logic in this component greatly reduces redundant coding in your presentation tier.

5. Presentation tier
This tier consists of all the ASPX pages and GUI logic. This is the tier that interacts with external Web services and the local business components. We reduced code and made our presentation tier more efficient by using static page references, a reusable navigation bar, and stylesheets.

6. Exceptions and logging
We created an easy-to-use logging mechanism by wrapping simple text-file logging around a complex exception-flow pattern. By creating layered components we were able to identify and log exceptions based on where they occurred, whether they had been logged already, and where they needed to be passed to.

7. Web services
Perhaps the most simplistic layer in the applications, this is without question the backbone of both applications and is the quintessential component to the business to business (B2B) collaboration aspect of the products. By implementing asynchronous Web service invocations we created a fast responding, multithreaded B2B information exchange between two business partners. Without Web services, the collaboration requirement of both customers could not have been met.

Enhancements
Because of the well-designed, multitier components implemented in these applications, providing additional features is a fairly easy process. By creating no interdependencies between classes and components, it would even be possible to add an entire new module and database table without affecting other portions of the application.

This is the goal of enterprise application design. We’ve created an application design where scalability should never be a concern. We’re also able to expand the application to any size without affecting other components, which reduces the hours spent on code volume and regression testing for the QA department.

The most critical point to remember about everything that’s been implemented is that the application is not defined by its functionality, but rather by the underlying design used to implement the features. What the product actually does is merely a byproduct of the requirements; the requirements came to fruition through a solid architectural framework.

That is the ultimate goal of an engineer, to create a reusable framework that can be applied to any requirements possibly conceivable. The most common mistake by most developers is to take a set of requirements and design an application that is one-dimensional and has no reusable features or framework.

By design
I’d like to reiterate that the method used for building these two applications is not by any means the ideal or perfect way to design applications. Nor is it to be considered as the ultimate in functionality. As far as features go, both applications are fairly small. The features themselves are just an extension of the framework.

The designs presented are just one way of doing things. There are literally hundreds of creative designs available that would all satisfy the same set of requirements. You may in fact read the previous articles and conjure up your own creative twists that make the design patterns even more effective.

Next in the series
In the tenth installment of Kevin Koch's Web services B2B implementation demonstration, we will provide a compilation download of the entire application, along with the accompanying articles that explain the application development from design to deployment.

If you have any questions or comments about the series, don’t hesitate to post them in the discussion forum or e-mail me directly.

Editor's Picks