Keving Boyle, one of my local Microsoft Architect Evangelists makes an interesting observation here...

http://blogs.msdn.com/socalarchitect/archive/2005/09/23/473399.aspx?CommentPosted=true#commentmessage

and I'm not surprised because I still hear from a lot of companies that need to get started with Web Services 101. SOA just sounds like this big huge ominous endeavor if you listen to all the buzz out there...yet it should be very simple in my opinion.

OOP to classes is like components to applications is like services to systems

The question is of when an “application“ becomes a system, and that is a question of composition, complexity and distribution.

Notice you did not see the term “web services“ above. Web services are NOT a requirement of SOA, there are an interoperability facilitator.

Enterprise systems should be designed so that major chunks of functionality can be moved, distributed, refactored, replaced with alternate application or vendor sources...without tumbling down the entire system. Today's system is no longer a single monolithic endeavor by a single vendor. We are now in the business of building composite systems that comprise many applications or feature sets that are respectively built by appropriate domain experts. So, systems must be sure that major sources of functionality are not tightly coupled. Major features become “services“. Each “service“ can receive inputs, or return outputs...and everything that happens in the middle should be completely independent of the rest of the application (black box). That means I should be able to move the service to another machine, another vendor and still have things work just fine so long as the location can be found. So, a service is designed to use its own tables, configure its own file IO directories, and manage all other resources needed to perform its function. That does not mean there is a different database for every service in an application. It just means that the service is programmed not to depend on another services table structure. Use the same database, use a different database, it should not matter to the application as a whole because the service maintains its own configuration.

Consider this progression.

An application that logs incoming Web service requests, records a transaction, and shoots off a request to generate a PDF from the XML.

The functionality that logs messages doesn't have to be on the same tier, and the application may leverage another application to do the work...therefore that is a service (logically speaking):

The transaction logging activity is a core part of the application, but could later be distributed therefore that can be considered a logical service as well. In particular the PDF generating functionality could receive XML inputs, and be considered a separate service as well:

But, let's not think small. This entire system could be considered a service to another application that requires PDF generating and transaction reporting activities. In this example, the system is a certificate issuance system (from a system I designed for the insurance industry years ago) - so that would be the purpose of this interoperable service endpoint:

SOA is an approach to system design that has been implemented in systems of many differing technologies in the past, that makes a business more agile. New technologies are making SOA easier to implement, Web services make SOA interoperable, but it is really about designing enterprise systems so that there is an appropriate level of configurability and reuse at the outer "service" or "functionality" layer.

Indigo (WCF) will just make the implementation of services a natural part of system development.

What do you think? Is SOA too confusing?

I recently received a question from a J2EE developer, who wanted to know how to get started with a multi-tiered architecture for .NET Web services.

The question:

I have some experience with J2EE and know that one good design is to create a multi-tier architecture. That is to say create control servers that will request processing from business tire (using some rpc) then forward the result to the display JSPs. I have never used .NET and need to build a web services application using this framework. My question is: what is the .NET alternative for that design? and where can I get the right information and documentation??

My answer:

.NET Web services are hosted within the ASP.NET runtime environment. They are exposed through .asmx endpoints which have what is known as a code-behind file that has a WebService-derived class linked to it. This class is essentially “the service”, and its methods (those marked with [WebMethod] attribute) are exposed as part of the automatically generated WSDL contract.

As a side note, typical of most platforms today, developers are building classes and methods to generate WSDL, however the better approach would be to create the WDSL contract first, and map that to business objects that handle processing. It requires discipline to follow this approach today.

The code that is encapsulated by the WebService object should never contain business logic, rather defer to other .NET assemblies that can be invoked in-process or out-of-process to perform the work required to execute the requested service method, and return a response (if not a one way method). That usually means that some form of façade layer is required to pull any business logic from the service class, and choreograph invocations to reusable business logic components (see Figure 1)

If you design your business logic in terms of logical, distributable services, then you should end up with a coupling of isolated sets of functionality that comprise an entry point assembly, one or more additional supporting assemblies, and some form of output or data store. For example, in Figure 1, you see that the application server tier has three entry point services: Service A, B and C. Imagine that Service C is a logging service that simply logs the Web service request “happened”; Service B is a service that handles the actual request processing, gathering data from the database, possibly committing some business information to the database; and Service A is a set of messaging and file IO services that handle generating some document output, like a PDF or email generated from the Web service request. Each of these business services can be isolated and distributed to whatever tiers you may desire, or be hosted entirely on the Web server tier, depending on your scalability requirements.

So, to your question, how do you distribute components and invoke them across tiers? Assuming your system is designed for reuse and distribution in this way, you can choose from Enterprise Services, Remoting or Web Services (these are the typical three choices).

1. Enterprise Services is the best approach if you want to migrate to future technologies like Indigo, since the programming model will follow this route. That means registering Service A assembly (for example) as a serviced component with COM+, which implies it will be invoked over DCOM with binary serialization messaging format. The beauty of this is that you can leverage COM+ to handle object pooling, encryption, authorization services, runtime identity services and distributed transactions. A recommended resource for this is Juval Lowy’s book, COM and .NET Component Services.
2. There are a few reasons why Enterprise Services may not be an option for you. One reason could be that restrictions were placed on the system deployment that precludes enabling COM+ services and MSMQ. This is usually an issue on inexpensive host domains (your $10/month service provider dilemma) or because the company imposes these restrictions (sometimes for no reason, sometimes for good reason). Remoting is an option for these cases, because it is a completely hand-rolled solution for invoking objects across process boundaries. Of course, this means rolling your own authentication, encryption, runtime identity impersonation, object pooling. No built-in support for distributed transactions will be provided here. A recommended resource for Remoting is Ingo Rammer’s book, Advanced .NET Remoting.
3. Lastly, you can slap a Web service in front of the business services shown on the application tier. Note, I call them business “services” because they are services in their own right, a la “service-oriented” system design. Each major function within the system should be designed in a service-oriented way so that distribution of the components of that business service can be accomplished transparent to how the entire system cohesively functions. In addition, those services could be reused by other “systems”.

So, the entry point to a business service can be through the remote invocation techniques described in 1 & 2, or through Web services if the business service either a) already exposed Web services due to its reuse outside of the firewall, or b) if the input to the service should be XML, and you want to reduce parsing overhead between the outer Web service and the business service. Behind the firewall, binary serialization over a speedy TCP/UDP protocol layer will perform better than XML over HTTP. The options for serialization and protocol selection will be seamless in future releases of the .NET framework (Indigo) however today it is a design decision that requires considering the deployment and invocation model during the design phase of the system.

Figure 1