-
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.
Read Full Post
-
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...
Read Full Post
-
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...
Read Full Post
-
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...
Read Full Post
-
Before we dig into the code, let's talk at a high level about the various parts of our system...
Read Full Post
-
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...
Read Full Post
-
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...
Read Full Post
-
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...
Read Full Post
-
...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...
Read Full Post
-
...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...
Read Full Post