iServiceOriented.com - Practical Service Oriented Architecture

Building Our Own ESB - Publish Subscribe Part 5

Thu, 09 Oct 2008 14:48:37 GMT

The dust is settling now after a crazy month, so here we go with Part 5 of the ESB series. There is a lot of excitement building around this project. Keep in mind that the repository on GitHub will always contain the latest code if you want to keep up to date with the latest progress...Our original plan called for RuntimeServices to be able to customize the behavior of our bus. Today, let's look at how we can use RuntimeServices to add functionality to the bus.

Configuring Performance Options - WCF Gotcha 3

Tue, 09 Sep 2008 10:39:19 GMT

WCF does not perform well out of the box. If you want your WCF services to really perform, you are going to have to configure them properly. It is not that hard to do, but things can get messy if you don't know what you are doing...

Building Our Own ESB - Publish Subscribe Part 4

Mon, 01 Sep 2008 16:35:33 GMT

It's been a few weeks since the last part of the ESB series, but we can't build an decent ESB overnight now can we? We left off with a draft of the basic framework... Now, let's pick up where we left off...

Building Our Own ESB - Publish Subscribe Part 3

Fri, 25 Jul 2008 01:12:14 GMT

We've already talked at a high level, so we'll dive straight into the core code now. Feel free to ask questions if you have them, since I'm going to let the code do most of the talking today...

Building Our Own ESB - Publish Subscribe Part 2

Wed, 23 Jul 2008 08:38:49 GMT

Before we dig into the code, let's talk at a high level about the various parts of our system...

Building Our Own ESB - Publish Subscribe Part 1

Mon, 21 Jul 2008 08:32:18 GMT

If you only have a few services, an ESB (Enterprise Service Bus) might be overkill. That said, as the number of services you have deployed grow, an ESB will look more and more appealing. One of the main functions of an ESB is to give your services a central place to connect. If you only have a handful of services, manually updating each of their configurations each time a service location changes can be quite time consuming and error prone. When you have hundreds of services, that really isn't an option. An ESB supports your services, handling the grunt work for you so that you can focus on more important things. One of the best ways to understand a complex system is to take it apart, piece by piece and rebuilt it. That's exactly what we are going to do...

Delegation - WCF Gotcha 2

Tue, 15 Jul 2008 21:47:01 GMT

If you've done a little web development or written a few basic web services, you are probably familiar with the concept of impersonation. When impersonation is turned on, .NET will make certain API calls return the identity of the caller, instead of the account that the service is actually running as (for example, DOMAIN\SmithJ instead of MACHINE\Network Service). Impersonation, however, is mostly sugar coating. The web service doesn't actually execute as if it was that user, it just makes your application think that it is. When you connect to a database server on a remote machine or read a file from a file share, you perform those operations as the service account. The advantage of this approach is that security is easy to configure. You don't have to worry about granting tons of permissions on your servers. You simply trust the service to make the proper security checks on its own and give the service all the permissions it might need... but that ease of configuration comes at a cost. If you have a single account that the web service is executing under, which tends to be happen, that account ends up with permission to do everything. But what if the developers working on the web service forget to put in a security check? These god mode services often open up huge security holes...

Events Are Your Friend

Fri, 11 Jul 2008 15:18:54 GMT

Imagine trying to build a desktop application without events. How would you make a button click do what you want? One way would be to open the Button source code and add the code directly. That has approach has obvious problems, not the least of which is that the behavior of the button click will vary from button to button...

The Myth of Reusability

Sun, 06 Jul 2008 14:13:29 GMT

...It is at this point that you realize that all these systems didn't really get their extra functionality for free. The base car object now has 50 or so various properties on it, and you really don't know which ones the inventory system actually uses. You may be 90% sure about half of them--but you sure as hell wouldn't bet your paycheck on it. You didn't build the CRM system or the EDI interfaces, you had moved to management by then. To make matters worse, half the guys you worked with to build the inventory system are off doing other things now. Of course, even if you could narrow down which properties the inventory system was using, it wouldn't really matter. All of the other applications depend on the inventory system. They share the database. They share the classes. They share the tests. You can't possibility rewrite the inventory system without rewriting everything else. Oh... Shit...

Indisposable - WCF Gotcha 1

Wed, 02 Jul 2008 22:37:19 GMT

...When you have the code behind the service ready to go, you deploy it to the server of your choice and are ready to call the service. At this point, you will most likely do one of two things to consume the service: Create a ChannelFactory and reuse your interface, or use the "Add Service Reference..." option inside Visual Studio. Either way you go, you will almost certainly get the next part wrong... even if you know your shit when it comes to the rest of the .NET framework...

Introduction to Service Oriented Architecture

Sat, 17 May 2008 19:30:19 GMT

At a basic level, a service oriented architecture allows you to take code and place it on another machine. Actually, I just made a gross oversimplification. Service oriented architecture helps you do this, but the key is that it reduces the chance of everything blowing up in your face...