Subscribe: Jesse Ezell Blog
Added By: Feedage Forager Feedage Grade B rated
Language: English
action  background color  blog  building  color csharpcode  color  csharpcode  esb  object  public  tread  twrite  void  wcf 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Jesse Ezell Blog

Jesse Ezell Blog

.NET and Other Interesting Stuff


Building Custom HTTP Help Pages with WCF

Wed, 05 May 2010 00:44:00 GMT

Been asked this a few times and needed to figure it out myself, so I put together a post on how to host custom HTTP help pages for your WCF services:

A little help from the WCF team to open up some of the internal classes would make it more straightforward... until them, it takes a bit of hacking and black magic.

Angle Brackets Are Dead. Long Live XML.

Sun, 07 Feb 2010 21:39:00 GMT

Many people fail to realize that XML can be used to represent many formats beyond the standard text xml encoding that most people recognize. So, I wrote a little post about how WCF takes advantage of this idea to illustrate what is possible when you change the way you think about XML.

Neuron ESB on Endpoint.TV

Mon, 25 Jan 2010 22:26:00 GMT

We recently sat down with Ron Jacobs to talk about Neuron ESB on Endpoint.TV.

Building a Simple Web Server With WCF

Sun, 24 Jan 2010 01:08:00 GMT

Tired of seeing a million examples of using REST support in WCF (which blows) and not a single example that goes beyond the basics everyone knows. So, I wrote a simple web server today using WCF and blogged about it:

Back in Action

Fri, 22 Jan 2010 09:19:00 GMT

Everyone keeps asking me to start blogging again... so I'm finally doing it. I'm back in action after a year or so off from blogging. Been working with WCF 24/7 since joining the Neuron ESB Team and have plenty of WCF tricks to share.

Anyway, kicking off things with an intro post about the WCF Message Class.

ESB Series: Part 5

Thu, 09 Oct 2008 19:59:00 GMT

Been a really crazy month with a lot of projects all going into production at once. Finally had some time to blog about the progress on my WCF based ESB: There's been a ton of interest in the project for something that is still very early on. Thanks to everyone who has provided feedback so far.

Articulate '09 Product Launch

Tue, 30 Sep 2008 23:23:00 GMT


The Articulate team has released its '09 product suite. Our team has grown quite a bit since our last releases. Congrats to everyone!

If you haven't seen Articulate's tools, check them out here:

We won a ton of awards with the last suite and this one blows the previous out of the water. Good times ahead.

Configuring WCF Performance

Tue, 09 Sep 2008 16:36:00 GMT

Because the WCF team wanted to provide something secure out of the box and allow inexperienced developers to get up and running quickly, WCF will not perform well without tweaking. Here's a little help with the less obvious settings:


ESB Series Part 4

Mon, 01 Sep 2008 21:57:00 GMT

Long awaited part 4 of my WCF based ESB series is up:

 Code is being hosted on GitHub now for anyone that wants to browse and get some ideas (link to the source is at the bottom of the post). The ESB framework is coming along nicely.

Entity Framework: Right Problem, Wrong Place

Thu, 28 Aug 2008 14:05:00 GMT

I was listening to the recent .NET rocks episode about the Entity Framework advisory council and it was interesting to hear the team's point of view and the problems they are trying to solve with the Entity Framework. They have nice goals, but there is a fundamental problem here that some of the original database gurus like C.J. Date make quite clear. SQL is flawed. It's not that we need a million object relational mappers or that we need to look at our databases in terms of objects. In fact, that's the opposite of what the relational model was intended to do. When E.F. Codd invented the relational model, he intended for the database to be a collection of facts with relationships to other facts... not a collection of objects. The relational model was supposed to provide a way to look at and work with these facts in different ways, but SQL and modern RDBMS's fall short of what they were supposed to do. Somewhere along the way, the original plans were lost. Instead of building a truely relational storage system, vendors jumped on the semi-relational SQL model. The SQL model ties physical structure closely to the logical data model, which is where a lot of problems start coming into play. This leads to the situations we've all seen where we need to denormalize the data model to get decent performance numbers.  It seems to me that the solution to the problem should not start with mapping the data to objects, it should start inside SQL Server itself, transitioning from the flawed world of T-SQL to a true implementation of the relational model as it was intended, a world where the physical model is truely detatched from the logical model.

HealthVault Uses XML Storage

Tue, 29 Jul 2008 19:32:00 GMT

Via EricGu:

From the "perhaps this might be interesting" file...

Since the end of the HealthVault Solution Providers confererence in early June - and the subsequent required recharging - I've been spending the bulk of my time working on HealthVault data types, along with one of the PMs on the partner team. It interesting work - there's a little bit of schema design (all our data types are stored in XML on the server), a little bit of data architecture (is this one data type, or four?), a fair amount of domain-specific learning (how many ways are there to measure body fat percentage?), a bit of working directly with partners (exactly what is this type for?), a lot of word-smithing (should this element be "category", "type", or "area"?), and other things thrown in now and then (utility writing, class design, etc.). [1]

Definitely in the "interesting file." Please post more details :) I would love to hear more about this.



Agile Development: Warning Signs

Tue, 29 Jul 2008 19:25:00 GMT

Alok Srivastava has an excellent post discussing agile development and areas that can put agile projects at risk. I'm currently doing clean up on an agile project gone south, and I wholeheartedly agree that the issues he points out should be warning signs if you are considering agile development. That's not to say that agile is bad by any means, just that you should think carefully before you make the jump, especially if your project will have the issues Alok mentions:


Making the Possible More Impossible

Mon, 28 Jul 2008 01:42:00 GMT

Jared Parsons thought it would be nice if we could have a ReadOnlyList object in our generic template instead of IEnumerable. I think that's an excellent idea, so a few minor modifications and we have an even better solution, not requiring the generic constraint TWrite : TRead: .csharpcode { FONT-SIZE: small; COLOR: black; FONT-FAMILY: Consolas, "Courier New", Courier, Monospace; BACKGROUND-COLOR: #ffffff } .csharpcode PRE { FONT-SIZE: small; COLOR: black; FONT-FAMILY: Consolas, "Courier New", Courier, Monospace; BACKGROUND-COLOR: #ffffff } .csharpcode PRE { MARGIN: 0em } .csharpcode .rem { COLOR: #008000 } .csharpcode .kwrd { COLOR: #0000ff } .csharpcode .str { COLOR: #006080 } .csharpcode .op { COLOR: #0000c0 } .csharpcode .preproc { COLOR: #cc6633 } .csharpcode .asp { BACKGROUND-COLOR: #ffff00 } .csharpcode .html { COLOR: #800000 } .csharpcode .attr { COLOR: #ff0000 } .csharpcode .alt { MARGIN: 0em; WIDTH: 100%; BACKGROUND-COLOR: #f4f4f4 } .csharpcode .lnum { COLOR: #606060 } public interface ILockedObject { void Read(Action action); void Write(Action action); void Replace(ReplaceAction action); } public class ReaderWriterLockedObject : ILockedObject { public ReaderWriterLockedObject(TWrite value, Converter makeReadOnly) { MakeReadOnly = makeReadOnly; _value = value; } public Converter MakeReadOnly { get; private set; } TWrite _value; ReaderWriterLockSlim _rwLock = new ReaderWriterLockSlim(); #region ILockedObject Members public void Read(Action action) { _rwLock.EnterReadLock(); try { action(MakeReadOnly(_value)); } finally { _rwLock.ExitReadLock(); } } public void Write(Action action) { _rwLock.EnterWriteLock(); try { action(_value); } finally { _rwLock.ExitWriteLock(); } } public void Replace(ReplaceAction action) { _rwLock.EnterWriteLock(); try { action(ref _value); } finally { _rwLock.EnterWriteLock(); } } #endregion } public delegate void ReplaceAction(ref T value);   Oh, and here is a ReadOnlyList class to go along: .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: Consolas, "Courier New", Courier, Monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } public class ReadOnlyList : IEnumerable { IList _list; public ReadOnlyList(IList list) { _list = list; } public T this[int index] { get [...]

Making the Possible Impossible

Sun, 27 Jul 2008 17:00:00 GMT

Have you ever gone to a restraunt with a menu that was just too big? Every once and a while I wind up at a place with a huge menu and it takes forever to choose what kind of food I'm going to eat. That's not a problem when I go to a steak house. When I go to a steak house, I know exactly what I want. A rib-eye medium well with a side of mashed potatoes. Removing options always makes it easier to choose the right thing. Programming is the same way. A lot of complexity in code exists only because we give ourselves too many options. For instance, consider the following code: List myList = new List(); public void DoSomething(){  foreach(object o in myList) { Console.WriteLine(o); }} public void DoSomethingElse(){  myList.Add(new object());} This all looks fine and dandy, until two threads hit these methods at the same time and your app crashes. We can try to make this better like so: public void DoSomething(){  lock(myList)  {    foreach(object o in myList) { Console.WriteLine(o); }  }} public void DoSomethingElse(){  lock(myList)  {    myList.Add(new object());   }} Which again works, but you always have to remember to lock the object. Some times you might forget. Why? Because you can. Nothing in the compiler and nothing in the .NET framework will tell you that you have to lock the object, it just assumes you are a threading wizard. There must be a better way... a way that we can gaurentee that we will never forget to lock our objects, but not make our code a complete mess at the same time. How about explicitly coding our intentions. Something like: public void DoSomething(){  myList.Read(list =>  {    foreach(object o in list) { Console.WriteLine(o); }  });} public void DoSomethingElse(){  myList.Write(list =>  {    list.Add(new object());   }} Now, you might look at this code and say, "But I could still write to the list in the read block". Well, again, that is only if you give yourself that option. We can prevent that kind of situation completely with this little class I put together after reflecting on some comments from Eyal ( .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: Consolas, "Courier New", Courier, Monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } public interface ILockedObject where TWrite : TRead { void Read(Action action); void Write(Action action); void Replace(ReplaceAction action); } public class ReaderWriterLockedObject : ILockedObject where TWrite : TRead { public ReaderWriterLockedObject() { } public ReaderWriterLockedObject(TWrite value) { _value = value; } TWrite _value; ReaderWriterLockSlim _rwLock = new ReaderWriterLockSlim(); public void Read(Action action) { _rwLock.EnterReadLock(); [...]

All Clouds Are Not Made Equal

Fri, 25 Jul 2008 18:24:00 GMT

As we rollout Microsoft Online Services this becomes a crucial factor especially when you begin to delve in to the laws and regulations of each country and how they implement data privacy.

What’s my point here? My point is that all clouds are not made equal and it’s not a simple thing to flip from being a consumer cloud vendor to an enterprise cloud vendor. The rules and expectations are very different. Flipping the other way, enterprise to consumer is a damn sight easier I’d say.


Publish / Subscribe with WCF

Fri, 25 Jul 2008 14:44:00 GMT

I'm working on a series of articles about building an ESB on your own.

When at the end of each group of articles, I'll be providing downloadable source code to play with. Keep in mind this is simply to teach some concepts like message queueing, building extensible systems, and WCF. Though you are free to use any of the sample code, it is sample code, not a fully tested and supported product. If you want a great fully functional ESB, I highly recommend checking out Neuron. Anything Sam works on is gaurenteed to kick ass.

Fear the Cloud

Mon, 21 Jul 2008 14:48:00 GMT

If you are considering using "cloud services," you should read this:


NServiceBus = Fail?

Thu, 17 Jul 2008 02:00:00 GMT

Finally had a chance to dig into the NServiceBus code. My thoughts are here if you care (I'm sure Udi will respond with his thoughts, so comment there instead of here if you think I'm off base):

Basic summation: code is potentially buggy, doesn't follow standard .NET naming conventions (not uncommon but annoys me when public projects don't) and not really production quality (I saw numerous potential crashes and basic threading problems just in the two core classes I read through).

I do still think Udi is a really smart guy and has a lot of good stuff to say, I just don't like the code.

Update: Udi likes the feedback and will be looking at addressing these issues. I'll try to find some time to work through the rest of NServiceBus to find other potential issues.

Don't Mix Lambda Expressions and Using Statements

Wed, 16 Jul 2008 12:46:00 GMT

Lambda expressions are really cool, but they present some interesting problems because they aren't really inline code blocks like they appear: