In the continuing Baby Steps to SOA series, we follow Doug and the IT team behind BuyMyWidget.com as they take steps to renovate their digital asset architecture. Up next is the centralization and sharing of the business layer to allow all applications to use a single source for business logic.   Along with the previous steps, this iterative step finally brings the team to a Service-Oriented Architecture for their primary website application.

The Evolutionary Roadmap

• Step One: Analyze and Plan
• Step Two: Measure It
• Step Three: Three Tiers for the Website
• Step Four: Single Sign-On
• Step Five: The Move to a CMS
• Step Six: Data Services
• Step Seven: Centralizing eCommerce
• Step Eight: Sharing the Business Tier
• Step Nine: Moving beyond the website
• Step Ten: Riding the ESB

Step Eight: Sharing the Business Tier

Moving eCommerce transactions into a centralized place was the first step to moving towards business logic being shared amongst all applications.  To accomplish a service-oriented architecture, the business layer needs to be decoupled from the rest of the application and separated into distinct business services.  By the end, the consumer applications should be delegating their operations to the service layer, just as they would have been delegating to managers in a business layer via procedural calls.

This can be done iteratively, and doesn’t need to be tackled as a big bang release.  The team can assign a portion of their sprints to this refactoring and move business logic during each release into a new web service layer.  The first iteration will likely need to be setting up the infrastructure to support the services, and then the team can begin installing new business services in the new architecture.

The best benefit will be seen by teams where the application being maintained has a mess of business code littered everywhere.  The simple act of moving the business code into a separate service application will force the architecture team to clean up the application structure and properly decouple the presentation layer from the business layer.

Just a Bunch of Web Services (JBOWS)

It is tempting to take the simple approach of copying all existing business logic methods over to new web service methods and simply updating the existing applications to directly invoke the web service instead of making procedure calls.  The decision could be to create endpoints for all  ‘public methods’, or perhaps for the initial entry methods into a particular component.  However, unless the original business layer is already properly architected around business operations, the end result is that the architecture will actually be Just a Bunch of Web Services (JBOWS), a term I believe was coined by Joe McKendrick back in 2005 in his article The Rise of the JBOWS Architecture.

In an iterative model, however, this JBOWS architecture may be the initial first step that needs to be taken.  While a JBOWS implementation will not be true SOA, at least we will be decoupling the business logic from the application itself.  A series of iterations can be taken to move application business logic piece by piece into a service back-end, performing regression tests along the way.

The best approach here is to minimize the number of temporary service endpoints that are created.  Since the re-architecture will be impending, investment in the temporary JBOWS architecture should be limited.

Business-driven architecture

The end-goal is to create services that are organized based on the needs of the business.  If the business needs to buy and ship products, there are some basic needs the business needs answered:

1. List the products available for sale.
2. Process purchases.
3. Send out shipments.

The business doesn’t need to know HOW those needs are met.  Service endpoints shouldn’t expose methods that are more granular than the business goals.  To move from a JBOWS architecture to this business-driven architecture requires identifying what the business needs are and then refactoring the business layer behind these higher-level endpoints.

Once this has been accomplished, the application will have been separated into services that can be shared and independently managed (or replaced).  During the planning for this step, the team may want to investigate whether some of the services may already be available from a third-party.  This cuts down on the amount of code being maintained by the application team, and allows them to focus on other business needs.  The downside, obviously, is that customization capability will be severely hampered.

Performance

Inevitably, performance issues will occur with this new architecture.  Code that was previously directly invoked will now be occurring over HTTP transactions, possibly even HTTPS depending on the nature of the data.  With the data layer now behind its own service endpoints, some transactions may be making multiple web requests for a single execution.

Code that previously ran perfectly fine on the server will now need to be performance tuned as much as possible.  Additionally, caching layers should be employed for transactions that do not change very often.  For example, retrieving a list of products will usually yield the same result for all users, so this can be cached at both the data layer service and the business layer, with different configurations on cache expiry for each layer dependent on the needs of the applications.

In Our Scenario

Doug and Lynn’s team, at this point, have been working on the re-architecture for over a year.  Multiple releases have gone out, and the team has managed to refactor their primary website into a much cleaner state to prepare it for this step.  The data layer is positioned behind data services, the eCommerce and Authentication capabilities have already been centralized, and the content management portion has been pushed into a CMS.  The website now only contains the presentation layer and the business logic, which the team has already refactored to separate from each other.

Now, the team needs to break the tie between the presentation layer and the business logic.  Lynn’s first step is to analyze the business layer refactoring done by the team to see what logical areas it has been broken into.  Based on the current business logic entry points, Lynn formalizes a plan for the new services to mimic the current structure.

Unfortunately, much of the business logic layer is dependent on state.  Lynn plans on moving to a RESTful web service architecture, and this will mean that the existing business logic layer will need to get all state information from the request.  The team begins to move the logic iteratively, each time creating a service endpoint and then refactoring both the website and the webservice for a stateless transfer of data.  For many of the calls, this just involves having the consuming application pass the user credentials, but in some cases additional user state information is required in order to properly execute the logic.

As the architecture emerges, Lynn notices that the endpoints are far too granular.  As the team iteratively improves the site, Lynn begins designing the new endpoints that will be used for the business-oriented architecture.  Meeting with members from Operations, Marketing, Sales, and Management, Lynn ensures that her design is meeting the current strategic goals of the business, and prioritizes the business functions based on BuyMyWidget.com’s current investment themes.

With a new design in place, Lynn begins forming the business endpoints, and new stories begin to be created in the backlog to achieve the migration of the existing endpoints into the new design. However, with so many stories affecting so much of the architecture at the same time, the stability of the application has become compromised.  The quality assurance team is consistently finding errors during regression testing, and performance has dropped significantly with all of the new layers of communication in the primary eCommerce application.

Doug informs Lynn that the refactoring needs to slow down and focus on stability and performance for their end users.  This means pulling some of the stories related to refactoring and spreading them out over upcoming iterations.  During backlog planning sessions, the team finds the most critical issues and pulls those forward into the next few iterations instead. To ensure the team doesn’t lose momentum, Lynn works with the product owner to ensure that a steady stream of stories regarding the creation of  business endpoints continues to be a part of each sprint.

Eventually, it becomes apparent that one of the problems is that the application is going through two communication layers in order to get data.  The initial call to the business service is then transmitted through a data service, and then the data is passed back through both layers before reaching the website.  To solve this, the team decides to use caching on their data services for a majority of the calls that are retrieving read-only information.  This will mean fewer real-time updates to the website of the products, but improves the business tier performance dramatically.

When the stories for creation of the JBOWS services have all been completed, the team begins tackling the remaining backlog stories for the business-oriented architecture refactoring.  As the code becomes more and more contained behind isolated web service functions for different business goals, fewer transactions are made by the website application and performance improves again.

With the business layer now exposed for all, Lynn takes her team to analyze their Events website for re-use of the business logic so that a centralized code layer can begin to be executed by both applications.  With the eCommerce solution already shared between the two websites, and SSO already implemented, the majority of the Events website has already been centralized.  The remaining events listing logic and some of the other site business logic appears to be a fairly straight-forward re-use of the new SOA business layer, so the team begins the update of the Events application as well.

How much will this step cost?

Assuming that the previous steps have already been completed, the majority of the effort will have been done during the refactoring stage.  If the business layer has already been refactored correctly, this will mostly be a matter of moving code from one project into another, and setting up endpoints.

It is likely that a few senior developers will be needed to implement the endpoints, implement a caching layer, and update the codebase to be stateless.  Two senior developers for a month with a single testing resource should be able to accomplish this work.

If a JBOWS-to-SOA refactoring is also required, an architect and business analyst will likely be needed to meet with the business stakeholders to ensure their new architecture meets with the business strategy.  Two or three 2-hour meetings to isolate, refine, and finalize the business needs and the architecture are probably required.

Performance testing will be required, as well as continued regression testing.  Expect that the testing team will likely need 2 weeks to turn around a full check and then another 2 weeks to verify any fixes made by development.

What’s next?

This series continues with the team continuing with the architecture refactoring beyond the website applications.