In a previous entry I referenced Rich Turner’s blog because I had some folks asking me about the choices, and I liked Rich’s comments. Then Rocky Lotka makes some good points about understanding the types of communications within an application suite. He talks about the fact that there are component tiers, physical tiers, and service tiers. I like his analogy, and he provides some good article references for backgrounder on making the choice. Now, Rich Turner has posted another phenomenal entry that further articulates how you should make these choices.

NOTE: I recommend you read these posts and all the comments in them before continuing on with the rest of this entry…because I’m building on what has been already said by Rocky and Rich

Ready?

Service Boundaries: What are they? Rich and Rocky talk about this and how Web Services are the best choice (really, the only choice for SOA) for defining the interface and supplying policy for access to services. I participated in Benjamin Mitchell’s chalk talk on SOA at Tech Ed in Amsterdam last month and one of the biggest areas of confusion was exactly this. What is a service boundary? How do developers know when to build a service interface for an application feature?

Let’s consider a real world use case from the Insurance industry. For several years was CIO at a company that provided a service to the industry for delivering Certificates of Insurance. We built and hosted a 24x7 system that handled the generation and delivery of these certificates by e-mail, fax and US mail. Our clients were agents and brokers that required an enterprise solution for managing the complex issuance and renewal process which would grow to require support for the issuance of some 100s of thousands of certificates per day during peak periods. The system relied on the receipt of the required form data from clients, and this data was typically stored in an agency management system already. Therefore, we provided a Web service interface to receive that XML to prevent dual entry, and other applications integrated with our system to supply data to the system. Considering the (very high level) architecture of the system in the next diagram, this service can be simplified as XML data in, PDF form out. That’s a service. Within that service boundary, however, is complex architecture that required the distribution of components over multiple tiers to balance load. PDF generation is costly, and e-mail deliveries put heavy load on SMTP services. The system had to be well documented via SLA to prove to a paranoid industry that it could scale, and would be reliable and secure.

The Web server was hosted in a DMZ, application logic at another physical tier, and PDF and e-mail generation located on another tier of machines that could be more widely horizontally scaled. Then we had a high-powered database server that had the horsepower to service transaction load and connection requirements with fully redundant mirrored drives.

What I’m trying to get across is that the service boundary was an outer contract for a very specific task that could easily be reused (I’ll talk about how, shortly) however behind this service boundary is the need for a highly scalable, reliable and secure architecture that has complex implementation requirements. Now we get to talk about component tiers and physical tiers. To get from the Web server to the application server, a physical tier is crossed.
What now?

• Do I want to do it securely? Yes
• Do I want to have reliable messaging? Yes

The point is, physical tiers should always be crossed securely, and reliably. And considering the same diagram, on the application tier, another boundary may be crossed to the database server (in a very large enterprise application) but this time requiring transaction support for component execution in order to keep the system consistent without rolling your own code to do so. Again, ES is your best bet for this. And yes, all of these demands for security and reliability and system consistency require trade-offs with performance. That doesn’t mean you must sacrifice performance you’re your application as a whole, but that the distribution of components may need to be compensated for by accommodating at the hardware level as well. I can tell you that from past experience that in the above scenario moving PDF and e-mail generation to another tier (off the application server) increased performance significantly on the whole, because the system could now be scaled horizontally on those tiers while the Web, application and database tier could service requests with one level of redundancy.

Not all applications require this level of consideration. I receive frequent questions regarding the design of simple Web applications, like a personal or small business Web site, that host with a third party where they do not have control over installing component services (for ES). That doesn’t mean the application is a toy, necessarily, however it clearly is not the application for a medium size business that has strict requirements on security and scalability. This is a business looking to contain costs with a simple application, possibly to get the business off the ground, and should still be designed with future component architecture in mind. That means, strip your code-behind of any business logic and build business components that can later be tiered. Sometimes ES is overkill for a small application out of the gate, just design components that can later fit into a distributed model so that the future doesn’t require re-architecting the application.

Let’s come back to the distinction between component, physical tier, and service boundaries. My example above may give you some idea when to cross physical tiers (DMZ, scalability for bottleneck areas) and why not all applications require this but should still be designed with component architecture that can later be distributed. But, beyond distribution, there is another issue (big issue) to consider. SECURITY.

Rocky makes a statement that a well designed application should always run within a single application domain. For performance, this is certainly true. But, what about security? What if some of my components must run with higher privileges, for example, those that access the database, event logs, the registry, or invoke administrative functionality across a network tier? I don’t want ASP.NET to run with those privileges. In fact, I should be reducing the attack surface by using the <trust> element of the web.config to remove code access security privileges for the round trip. Now if ASP.NET invokes a component that accesses the database, the code inside the component can impersonate a configured account that has this privilege, for the duration of the call. That implies an externally configurable account, that must be secured, and code that impersonates that account (within the same application domain as the running ASP.NET code). This also implies that the code controls when the impersonation takes place, so if business requirements change, I have to recompile the code. But a registered component (ES) can be configured to run with a specific Windows account identity, and this is externally configurable, without touching the code. I suppose you could argue that the model you choose (impersonation or ES) may be based on deployment limitations (can you have ES installed?) and preferences for configuration. I would argue that the process identity configured in component services is more secure than developers writing their own impersonation code, reading the identity in configuration, and encrypting that data, placing it in a secure location.

So how do you know when to create a service boundary? In my earlier example, the entire application is a service, thus has a service boundary exposed through Web services. But this application can be consumed by other applications such as agency management systems. Consider this diagram:

The agency management system has many functions including certificate issuance and management, a general ledger, policy management, quote generation and carrier ratings. Vendors that create these systems usually have domain expertise for general ledger and policy management, but may not be experts at certificates, quotes and ratings. Regardless, the user wants all services through a single interface. This single interface is the hub for these related chunks of functionality. If designed as a smart client, this type of system can present the user with the best of the above services. If those services all support a common Web service interface binding, it would be incredibly easy to swap services wouldn’t it? This is one of the dreams of SOA that may be elusive simply because many businesses don’t want to be so easily replaced by another service and following a domain specific interface standard makes this too easy. That’s ok, because a shim can just as easily be created to wrap a service that doesn’t expose a consistent interface…no problem.

What the previous diagram is trying to get across, though, is that the agency management system is a single application, built by a particular vendor…however they may design it so that those major chunks of functionality are services, since their clients could ultimately demand a better service. A perfect example is the certificate management service, which could be replaced with my first service diagram in this post. Now we’re talking SOA, crossing application and corporate boundaries. Where those services are hosted shouldn’t matter so long as the application interface presents the results of the service in some consistent manner.

In summary, though I realize that every application requires a unique analysis on this topic, there are some generalizations you can take with you here.

• Create a Web service interface to major chunks of functionality that can be considered services that are replaceable or reusable.
• Design component architecture that can easily be reused, and redeployed to meet security and scalability requirements.
• Keep all business logic out of that code-behind file for your ASPX, ASCX and ASMX resources.
• Always securely invoke components across process and physical tiers.
• Cross process and physical tiers as security demands it, as reliability demands it, and as scalability demands it because of bottleneck areas. I agree with Rich's statements (see above link) regarding avoiding network traffic where possible, due to overhead. My scenario above required DMZ, so a boundary is crossed to application logic. The system benefited from the horizontal scaling of equipment for document generation and e-mail. Some very expensive database servers were part of the environment (Sun equipment for Oracle database) but it is not necessary to insert a boundary between the application and database server in all scenarios.
• If crossing physical tiers, employ MSMQ for reliable messaging where applicable, employ transactions where applicable to insure consistent state of the application. Do this considering performance trade-offs but remember that the application of Web services in their stead will also introduce performance issues with serialization and are better used for more SOA related functionality sharing. Remember that .NET remoting will not provide the security, transactions and reliable messaging support out of the box, nor is it consistent with the future, Indigo.