The SOA consultants invaded the executive suite at your company or agency, preached the true religion, and converted the unbelievers. Now by divine imperative you must convert your legacy applications into a suite of reusable services. But as usual, you lack the time and resources that you need in order to develop the services properly. So you googled ......

In Part 1, I introduced Thomas Erl's notion of adopting the reusability analysis practices of ISVs when modeling reusable services. Today we look at what this entails. First, let's take a look at what happens to software that's supposed to be reusable if you do *not* perform reusability analysis. When my employer was launching its first enterprise product ......

Thomas Erl insists in his magnum opus, SOA Principles of Service Design, that you do not need to goldplate a service's capabilities, or consult with Madame Zelda and her crystal ball, to make the service reusable for future consumers and compositions. Certain types of software that we have been using for decades--operating systems, business productivity ......

Services, designed right, have much more runtime autonomy than components. That autonomy gives you much more ability to manage the security, reliability, and reusability of the encapsulated logic, although there can be a small cost in system performance. And service autonomy makes changes quicker and easier. That ability can save your bacon from time to time, just like it did for me one morning when I got to work....

Long Island Expressway...painless dentistry...dry wine...educational television. Inventing oxymorons like these is a wonderful party game; what others can we come up with today? How about: airline food...random order...House Ethics Committee...Service-oriented business intelligence....
That last phrase does seem like an oxymoron, at first glance. Service-Oriented Architecture (SOA) and Business Intelligence (BI) appear to be very different animals in enterprise architecture....
As I wa

Collocation of development team members from various disciplines (design, development, test) has many benefits. If you've been working in an agile environment, you know about the enhanced communication. But don't stop there! Get your teammates to review your work before you check it in, and you get crucial feedback and catch some bugs ASAP.

Just because a feature looks cool in a 5-minute demo doesn't mean it will do the job in real life. It might not scale for large amounts of data, for example. So make sure you're designing, developing, and testing for the real world! I saw this principle in action recently when I was called on to debug a performance problem....

We software engineers and architects sometimes feel like the rope in a tug-of-war. Pulling from one side is the short-term goal of delivering functionality, preferably yesterday. Indeed, our customers cannot justify paying for our services unless we deliver a working product, better and faster than our competitors. Pulling from the other side, however, is the long-term goal of quality. If our code becomes too disorganized or hard to understand, we cannot long remain in business, because we w

Some combinations go together well: New York, Yankees, and pinstripes; Oscar Peterson, Ray Brown, and Ed Thigpen; a loaf of bread, a jug of wine, and thou. To this list you may now add: unit tests, extension methods, and lambda expressions. Read on if you're interested in writing elegant unit tests.

If you're writing a reusable framework, you might want to avoid declaring a class or method as public if you don't want to support it as part of the interface. At the same time, you might want to use it from a different internal assembly--especially if you're writing tests. Believe it or not, there is a way to achieve both seemingly contradictory ends in one codebase. Read on to find out how you can have your cake and eat it, too!

I believe strongly in code clarity, and will reluctantly agree to greater complexity only if there is a clear gain that will clearly benefit the user--e.g., to optimize a bottleneck in a heavily-used code path. I was actually surprised to find that not everyone agrees with my stance. Read further for a friendly but vigorous debate between the two perspectives....

We all know how to perform data lookups based on last name, zip code, and so forth. But what if you need to do a lookup based on encrypted data? This could be an extremely expensive operation, if you have to decrypt the data in every record. But if you use secure hash codes, you can perform the lookup very inexpensively.

Evaluating technology options can be very murky--kind of like choosing a college or picking a spouse, only a lot more risky! If you can analyze the features you need, and score the technologies based on their ability to meet those needs, you can actually make some headway.

While I was busy customizing Microsoft's Exception Management Application Block to classify and log all exceptions thrown in our web and Windows apps, and writing instrumentation code that published timing events via System.Diagnostics.Trace, Microsoft was busy writing ASP.NET Health Monitoring. Microsoft has more resources, so their product is a little ......

The .NET Framework provides built-in capabilities for creating components and services as singletons. If you want to create a singleton process, though, you're on your own. But not really; if you read on, you will find out how to use a Mutex to do the job.