September 28, 2008
@ 09:57 PM
Comments [0]
Another WCF gotcha - calling another service/resource within a call
I wrote in the past how WCF defaults limit scalability but this thing (which had cost me two days of head scratching) is even worse.
Consider the following scenario:
 You have a WCF service/resource. when you get a message/request your codes needs to send another message to another service.
Sounds common enough now doesn't it? and it is - unless you happen to use a service with   WebHttpBinding (e.g. if you try to develop a RESTful WCF service or want to use POX services).  When you use WebHttpBinding and try to make a call within a call you are likely to find yourself starring at a ProtocolException with a 405 error - Method not allowed. Turns out WCF finds itself confused by the Operation Context (OperationalContextScope) of the incoming request so if you want things to work properly you need to create a new one for the request
var webBinding = new WebHttpBinding();
var channel = new ChannelFactory<ImContract>(webBinding, controlUri);
channel.Endpoint.Behaviors.Add(new WebHttpBehavior());
var proxy = channel.CreateChannel();
using( OperationContextScope((IContextChannel) proxy))
{
     proxy.Dostuff()
}

I already spent the time figuring this bugger out- I hope this post will save you the trouble


 
Tags: .NET | REST | WCF

September 21, 2008
@ 11:50 PM
Comments [2]
What's up with unit testing? part I
Back in may Andrew Binstock wondered "is the popularity of unit tests waning?" Andrew lists 5 indications he observed to support his conclusion:
  1. Commercial tools are waning
  2. Few OSS products
  3. Unit testing is not taught by major Java instructors
  4. Few books get published on unit testing
  5. xUnit alternatives are completely invisible.
I am not sure I agree with all these observations, nevertheless,in a followup article in Java World Andrew continued to ask "Is unit testing doomed?".
Andrew says that two issues with unit testing are that they seem to offer little value and that the evangelism of unit testing in general and TDD in particular also causes antagonism (I can say from personal experience with introducing unit testing to long time C and C++ developers that, indeed, the initial responses are rather cold)

Andrew also quotes former CEO of Agitar (Jerry Rudisin) saying that "unit testing hasn't taken off as mainstream practice". A survey ran by Scott Ambler for Dr. Dobb's also found that "The more difficult practices, such as TDD and executable specifications, have lower adoption rates than easier practices such as daily scrum meetings." (although another survey by VisionOne found that within companies where agile practices are used 77% use unit testing and about 49% use TDD)

I recently read another interesting post on the subject, this time by Dan North about the "end of endotesting" explaining why the record-reply idium of most mocking framework is not intuitive and more easy to use mocking frameworks like mockito (his example) or Moq and Mocha (my examples) are better.

Now, yesterday I read Roy Osherov's post "Goodbye mocks, Farewall stubs". Roy makes similar observation on the adoption (or lack therof ) of unit testing practices. Roy believes the number one reason holding back unit testing is the learning curve associated with it and suggests we simplify the tools and terminology (and gives a example similar to Dan's mentioned above)

What we see is that both in the Java and the .NET worlds unit tests adoption hit a few snags. The way I see it there are event  additional barriers to wide adoption of unit test and TDD but I'll talk about that in part II where I'll also try to talk a little about what can/should  be done

Powered by ScribeFire.


 
Tags: .NET | Java | TDD | Trends

September 20, 2008
@ 08:42 PM
Comments [2]
Architecture - It is always a tradeoff
(This part III of a series -see Part I, Part II)

We need to face it, there are no absolute truths when it comes to software architecture( I guess that's part of the reason the term always looks so fuzzy. ) Should we use REST? it depends. Should we use OR/M or direct database access? it depends. Sometimes even a big ball of mud can be a good option. The good news is that we can always answer "It depends" to any architectural question and always be correct. The bad news is that it is our role to figure out what does it depend on and come up with a viable trade off.

The fact everything is a tradeoff doesn't mean that there aren't any cases where the trade-off is simple. E.g. if you just have to build a couple of data entry screens and a simple database you probably shouldn't spend a couple of months evaluating your options, just write the damn thing in your spare time. Nevertheless, just hacking it can mean it wouldn't be extensible, it that's what you needed then cool. if not, maybe you should have considered that.

This is one of the reasons I don't like the term "best practices" - it sends out a "you don't have to think anymore" message which is oh-so-incorrect. Patterns on the other hand, don't send  out this message, as they also include discussion on where to use them as well as their limitations and pointers to other patterns. Unless of course, patterns are seen as an end-goal rather than a means, in which case, they look pretty close to "best practices"

To sum this post - everything is a tradeoff. The most important bit here is to keep that in mind, even when the choices seems obvious. Awareness  is the key to better decisions.





Powered by ScribeFire.


 
Tags: Design | Software Architecture

September 2, 2008
@ 08:32 PM
Comments [1]
Google Chrome -The browser is the new Desktop
I've written a lot on the efforts in converging web and desktop applications (Adobe Air, Mozila Prism, Silverlight, JavaFX, Google Gears etc.). Now Google ups the ante with the introduction of its new webkit based browser - dubbed Chrome (You can see a comics explanation of its main concepts/features).

Let's do a quick recap before taking more about Chrome. Basically we see all the major players trying to blur the lines between desktop applications and web applications (a.k.a. Rich Internet Applications) some players are on the offensive (Adobe, Google) and some on the defensive (Microsoft, Sun) but the direction is identical. The web oriented companies understood that RIAs are becoming more real application and not "just" web pages. They also understand they need presence on the desktop for easier accessibility and better acceptance by users as a "serious" applications. Furthermore, the fact the applications become more serious and more mission critical, along with the fact that they can (and are) be used on-the-go where disconnects occur, the need for occasionally connecteness becomes more apparent. This is where smart-clients have a lead and technologies like Gears are trying to catch-up.

Now,in my opinion, Google makes a bold move to change the rules and re-define the playground - if webapss need to run on the desktop, let's make the browser the new desktop.
What makes me say that? because it is focused on application (see the comics),because the browser runs each tab in its own process, because it has a process monitor, because it is a link on the google home page...



From the chrome "OS" point of view we can look at javascript,HTML etc. as the IL (bytecode in java speak) on which the application run. This makes cross-compilers like GWT and the good side of MS Volta (vs. the bad side) the next abstraction layer. I expect these will be more significant in the future

Anyway, you can see for yourself if you download it now from www.google.com/chrome


 
Tags: RIA | Trends

August 31, 2008
@ 06:59 PM
Comments [0]
Think Hollistically
Software architecture is not a three-layer diagram (UI-Business logic-Data)! As an architect you need to consider the project/solution at hand from a lot of different angles and take care for all sorts of concerns from the technical, team, managerial and event esoteric ones

  • Technical- you need to consider things like threading models, data flow data strucutre, testability, security , user interface. A solution is only as strong as its weakest link. If the UI is great but the system is not stable you will fail. if the system scales well but the security is flawed you will fail.
  • Team - You have to understand the limitations and capabilities of your teams and thier structure. If everybody knows Cobol, maybe rails is not a good option. if the teams are spread out geographically, you need to make sure you partition the system into chunks that wil allow them to progress independetly as possible.
  • Managerial - brings things like What's the budget for the project?, How much time do we have? so can you really plan on using a rule engine if it eats 80% of your budget (maybe ?), Can you plan a cool piece of infrastructure if it will take 4 months to build?
  • Esoteric - Sometimes you even need to consider less than common stuff. There aren't general examples here since its, well, esoteric - but a couple of examples I've seen include a project where we had to see how much power the hardware we use needs (since it was to be deployed on a truck) or on another project where we designed a multi-monitor UI we had to figure out if it is better to design the UI for side-by-side or one atop the other
You should note that most probably you will not be able to be master of all the needed domains. you do need to be aware that they exist and work with other experts to cover the other bases of the solution.



 
Tags: Software Architecture

August 30, 2008
@ 10:30 PM
Comments [0]
A few pithy thoughts on Architecture
As a follow up on the previous post. There are few things I consider as important for software architects. I wouldn't go as far as to call them axioms but I still think they are worthwhile.
  • Think Hollistically
  • It is always a trade-off !
  • Pay attention to your soft skills
  • Get SPAMMED for architecture
I wrote a lot about the forth one (see for instance this article in Dr. Dobb's). I'll expand a little about the others in the next few posts


 
Tags: Software Architecture

August 30, 2008
@ 09:44 PM
Comments [0]
"97 Things" - Architect Axioms
I recently stumbled on "97 Things - Things every software architect should know" (via Bobby Woolf). This is a list of axioms for architects (which will eventually be a book by O'Reilly) edited by Richard Monson-Haefel. While I don't agree with all the axioms, and some, which I feel, are a bit overlapping (e.g. one on trade-offs and one on balancing), there's a lot of great stuff ther.
For instance, here are a few of the ones I like:



 
Tags: Software Architecture

August 21, 2008
@ 08:22 PM
Comments [1]
Using REST along other architecture styles
Following my latest post on evolving the architecture Dru asked me for more details on our RESTful control channels.
For one you can take a look at slide 25 of my presentation on REST which talks about the Sessions resource. The session resource returns an AtomPub feed of the current active sessions and then if you follow a link to a session you get the current status, the URIs of the participating resources etc.
I guess the more interesting questions are (especially in the light of all the on going REST debate we now see)
  1. Why rely on REST for the control channel
  2. Why not use REST for the whole system
So, why is REST a good option for the control channel?

  • the REST architectural style in general and REST implementation using web standards (HTTP, AtomPub etc.) in particular brings a lot of benefits in integration (what easy for humans to understand is easier to implement).
  • Another reason for REST (over HTTP) is standardization over languages and platforms. Any language and platform I've used has an implementation that allows sending and receiving HTTP messages. We have few components running on Linux and components running on Windows and we're planning even more heterogeneity down the road.
  • Lastly, REST allows for easy debugging and run-time interaction. This proved invaluable during system integration test where we could easily understand the current state of each of the components in the system as well as the general picture.
Ok, if everything is so good, why not use REST for the whole system? Well, because like any architecture or architectural style (especially, when incarnated in a technology), REST has things that it does well and things that it doesn't (personally, I don't buy the Only Good Thing(tm) for anything or as Brooks puts it there's no silver bullet).
Let's look at message exchange patterns for instance. REST over HTTP support the request/reply pattern.
This works extremely well in many business situation. For instance is we have an Order service (or resource for that matter) and we need to calculate the discount for a specific customer we can go to the Customer service and get her current status and check if she a VIP customer, senior citizen etc.
There are, however, places where it doesn't work as smoothly. Returning to our Order, lets consider what happen once the order is finalized and we need to both start handle it (notify the warehouse?) and Invoice it
The order service does not care about these notifications it isn't its business.
My favorite way to solve this is to introduce business events (incorporate Event Driven Architecture) so that the interested parties will get notified. Another common way to solve this is to introduce some external entity to choreograph or orchestrate it (BPM etc.) both options have different constraints and needs compared with REST. In my organization we have a lot of processes that lend themselves to event processing much better than they do REST over HTTP (though the implementation might end up aligned with the REST architectural style - I am not sure yet)

Another reason not to use REST is when you have to integrate with stuff that isn't RESTful, for instance we need to integrate with systems that use RTP and other such protocols so we are bound to that - and we are a startup with "green field" development. In an established enterprise the situation is much more complicated.

To sum up, in my opinion when you take a holistic view of a complete business you are bound to see places where different architectural principles are a good fit. Architecture styles (and architectural patterns) are tools you can use to solve the challenges.There are places where a hammer is a great fit, but it is also wise to make sure the toolset has more than just a hammer.

PS

It isn't that you can't do events with  REST over HTTP. e.g You can implement the events as an ATOM Feed and have the "subscribers" check this feed every once in a while (the way this blog works). It can even check the HTTP header before getting the whole feed. Still push is a more natural implementation for this for various reasons like you don't have to know where to find the event source and you can more easily improve latency (when needed) etc.

 
Tags: REST | SOA | Software Architecture

August 20, 2008
@ 03:59 PM
Comments [0]
Visual Studio 2008 Tip : Multiple startup projects
I was demonstrating a POC I wrote to one of my colleagues and I showed him one of the integration demo where I have a two console application - a producer and a consumer who communicate by WCF. He was surprised to see&nbsp; I get two separate console windows running from within Visual Studio.

So just in case you don't know that as well, all you need to do is to go to the solution properties (Right click on the solution-&gt;Properties) and under "Startup project" select "Multiple Startup project".
You can even decide which projects will run with a debugger and which won't :)


 
Tags: .NET | General