Web services B2B implementation demonstration: Setting the scenario

In the first part of this series, we set the scenario for the development of a complete B2B Web services application. Learn how to implement use cases to relate user requirements to developers.

In the world of software development, there are a myriad of design principles, methodologies, patterns, and practices that encompass the development of an application. The philosophies and implementation details are as multifaceted as the people guiding the development of the applications.

Web services B2B implementation demonstration
Welcome to the first article in our series exploring in detail the implementation of a B2B Web service. The series will take you through the development of a complete B2B Web services application. During the course of the series, we encourage 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? Let us hear from you and we'll do our best to address the issues.

Looking to find the next article in the series: Kevin Koch implements the requirements established in his series' first article around an n-tier framework by creating the application components and developing exception handling and logging capabilities. Click here to find the next article.

There are some tried and true architecture patterns for software development employed by most architects. But what happens when your development team leaps into uncharted waters? Suddenly the legacy foundation of experience is no longer there and your design must turn towards innovation instead of lending itself to common practices.

Web services is one such area where architects must lean on their creative side and hope that their solutions are still successful. During the coming weeks we'll take an exciting voyage down the road of Web services application architecture by designing a business to business (B2B) collaboration example from the ground up. From requirements to use cases, to database design, to component frameworks, to user interfaces, I'll cover each and every aspect of system design required to build an application with collaborative Web services.

Background knowledge
These design patterns and implementation details are by no means presented as the most ideal and perfect way of designing an application. As with all developers, we each have our own coding style and bring our own flavors to the design of a system.

However, I'll be using as many common design patterns and best practices as possible. I'll also be applying knowledge gained through experience to create design patterns for Web services, which can become very vague at times.

I'll be using the following product technologies to build the final application:
  • Visual Studio .NET 2002 (You can also use 2003.)
  • SQL Server 2000—specifically the MSDE version packaged with VS.NET
  • Microsoft’s Data Access Application Blocks

The application framework will employ an n-tier architecture model, a commonly used model in more intricate enterprise systems. A simple diagram of this model can be found in Figure A.

Figure A
The n-tier architecture model

The application has five tiers of logical separation:
  • HTML GUI presentation layer
  • Code behind GUI logic layer
  • Business logic component layer
  • Data access component layer
  • Stored procedure SQL layer

It's important to study and understand the purpose of each tier so that when it comes to implementation details, you’re not guessing where each portion of code functionality should go. I'll break down the specifics of each tier in future articles as I build the application.

The scenario
The example scenario for this project consists of two fictitious companies: Tom’s Online Books, and John’s Wholesale Book Supplier. John’s company is merely a wholesale supplier of books. He has no storefront and no direct customer sales; he simply provides books at wholesale prices to other book suppliers. Tom’s company runs an online bookstore that allows Internet customers to purchase books through his shopping cart. Tom carries no inventory; instead, he accepts customer orders and passes them to John, who supplies the books.

Because John has no storefront, his only means of generating revenue is to have other bookstores place orders with him. To accommodate this, John has decided to build an ASP.NET application with a Web services layer to allow real-time sales with his vendors, and Tom has decided to increase his productivity and create his own online shopping cart system with ASP.NET and a Web services tie-in to John’s application. By making this business collaboration agreement, both hope to increase revenue and productivity.

Although I'll be acting as the system designer for both applications, the real world implementation of this scenario may have two separate teams of developers, perhaps even from different companies. Because the only link is through the Web services layer, providing a generic design allows both applications to be flexible enough for future expansion, and prevents Web service API conflicts between the two development parties.

Use cases
Use cases are a way of expressing user requirements to application designers and developers. The Unified Modeling Language (UML) specifications provide very detailed and lengthy explanations of properly documenting use cases. However, in this situation, I'll simply apply use cases to describe what each system should do.

The first client meeting is with John. After speaking with John about his requirements I gathered the following information:
  • Must be able to accept orders from other vendors, specifically Tom
  • Needs a way to manage his inventory of books
  • Needs to be able to view and process orders
  • Wants his inventory to be secured from unauthorized vendors
  • Wants to provide access to his book inventory to select vendors

By using extrapolation techniques you can identify the following use cases for John’s application:
  • View books
  • Edit book
  • View/search orders, with filters for client and order status
  • Confirm order (flag an order as completed)
  • Web service use cases
    —Create orders
    —Get orders
    —Search books (filtered by ID, author name, book name, or availability)

Extrapolation techniques explained
If you take the requirements I detailed for John’s application, here’s how you would break out use cases:
  • Must be able to accept orders from other vendors, specifically Tom
  • Needs a way to manage his inventory of books
  • Needs to be able to view and process orders
  • Wants his inventory to be secured from unauthorized vendors
  • Wants to provide access to his book inventory to select vendors
By identifying the sentence structure, specifically nouns and verbs, you can easily create a basic foundation of use cases which can be used to further extrapolate “hidden” use cases which may not be apparent at first. The easiest way to accomplish this is to print out the requirements and take a highlighter and simply highlight the nouns and verbs you feel are relevant. If you extract the key nouns and verbs from each of John’s requirements, you get:
  • Accept orders, which translates to create orders
  • Manage books; usually translates to create/update/view/delete (In this case, only view and update).
  • View and process orders becomes view/search orders (The verb process translates into confirm orders.)
  • Access inventory translates into search books

The next client meeting is with Tom. Tom has slightly more involved requirements because of the customer interaction. I learned the following from Tom:
  • Requires a public area for regular surfers and a secured area for authorized users
  • Needs to be able to track customer accounts
  • Must be able to search John’s database for books
  • Needs a customer login screen
  • Needs a shopping cart mechanism to let customers add/remove books from their cart
  • Needs an area to let customers review their cart and place an order
  • Needs a way to place orders in John’s application
  • Wants to let customers view the orders they’ve placed
  • Needs to have a way to let John’s application notify his system automatically on order completion
  • Wants to notify customers by e-mail when their order is completed
  • Wants a user friendly error page
  • Wants to display to customers the number of items in their cart in an area that’s always viewable to the customer

Again, by using our extrapolation techniques I can decipher the following use cases for Tom’s application:
  • Search books (filter by book name, author, or availability)
  • Add book to cart
  • Remove book from cart
  • View shopping cart (Secured)
  • Create order (Secured)
  • View customer orders (Secured)
  • Create customer
  • Log in customer
  • Web service use cases
    —Confirm order

You’ll notice that not all requirements translate to use cases. Many requirements are simply implementation features that are provided through the execution of other use cases. For example, the user friendly error page is not a use case, but rather a configuration detail I’ll address during implementation.

With my use cases and requirements documented and defined, I can begin planning the foundation and outline of the application. By molding the requirements around my conceptual n-tier framework, I can then create a baseline of how each application will be structured.

Editor's Picks

Free Newsletters, In your Inbox