Adoption of CAB and recommendations for services

Topics: CAB & Smart Client Software Factory
Jul 14, 2005 at 8:30 AM
originally posted by: eichert12

Hey CAB Team,

I originally sent this email to Peter and he recommended posting it here so I could get feedback from the remainder of the team.

Let me give you a little background. I recently switched jobs and am now on a team responsible for the re-architecture of an existing application that was originally written in VB6 and migrated to VB.NET.

The app is going to be re-written as a Smart Client with the goal of moving a lot of the logic into a set of services that will reside on App Servers.

Some of the guys who have been working on the project have considered .NET Remoting and WS as the "connection" between the Smart Client and the "Services".

Anyway, one of the bigger items we'll be attacking is the development or adoption of a Smart Client framework that will allow us to quickly build features onto the application and do so in a manner that allows us to ensure everything is working as expected via Unit Tests (using TDD ideally).

So my questions...
1. Who is using the CAB currently, are there any big companies adopting the block and if so how is their development going using the block?
2. Have you guys done any performance related testing on the block? There is a big concern internally with the overall performance of the existing app which is one of the reasons for the re-architecture.
3. Not related to the CAB specifically but more towards Smart Clients do you have any thoughts on the .NET Remoting vs. Web Services decision?

I appreciate any feedback you can provide.

Jul 17, 2005 at 8:24 AM
originally posted by: eugeniop

Hi Steve -

Some answers to your questions:

1- Regarding customers using CAB: we know of many "big" customers using or planning to use CAB. I can't name them publicly without their permission though. However, their requirements have been driving the features in CAB from the very begininng. In other words, our success will be measured by the fitness of CAB in their environments. Early intervention and engagement has been the approach we used to make sure we invested in the right features. Even now, we are still listening to what you have to say about CAB and will still shape CAB until its final release based on what we hear in this community.

We do have some other customers that have used an approach similar to CAB with a different implementation. Most notably the recently published Dell case study. Dell solution in their Call Center has been extremely successful in achieving their goals of enhanced dev productivity, operational efficiency, end-user productivity; etc. CAB goal is to enable all this.

2- Performance is something that it is included as part of our testing. We acknowledge the concern of enterprise solutions around this and this is a key requirement for us. CAB will definitely impose an overhead on plain, hardwired winforms (every abstraction does); but we think that cost your are paying will be highly compensated by the benefits in terms of maintenance, dev productivity, quality, etc. Also, there's a threshold in the overhead also that we track and test against. I can't remember the exact number now, but I think it's about 5%.

3- Regarding Remoting/WS. I would look at WS first; because this is the general direction the world is heading now and you'll get a better long-term story in terms of tools support, runtime stacks, interoperabilty, etc. Of course, as an engineer, I would first ask you: what are your requirements? Why are you even considering these 2 alternatives? Is it performance? is it legacy implications? is it skills sets? Even if for any reason, you decide remoting is the technology you will use, I would still adhere to the principles of services design (contracts, schema sharing, etc.) which, even though a little bit harder, are possibole to do and will put you in a better position to move forward as technology evolves.

Hope this helps
Jul 17, 2005 at 1:24 PM
originally posted by: headlam

Steve I'm not part of the CAB team, but here is my 2 cents

While we have not yet deployed a solution based on CAB, I think I can provid you some insight based on what we have done in the past and some of the work we’ve done with CAB.

We have several solutions in place today, one of the solution consist of a number of WinForm applications that run in their own discrete process space and communicate with each other (on the desktop) via .NET Remotting . The solution works, but it is far from ideal on a number of levels; development experience, ease reusability, ease of composition, runtime memory footprint, application warm startup time, etc. We can achieve better results using the principles of composition and running the discrete applications within a container. This allows us to isolated what appear to be multiple discrete applications (read as EXE processes) into a single process (i.e., a host). We achieve the same think as having the multiple processes and we gain a better event model (as compared to eventing with .NET Remotting), fatter processing speed (i.e., no process boundary crossing), etc. This is of course similar to what you see on the server with ASP.NET (modulus the AppDomain stuff). Additionally if we want to still communicate with legacy application we can still do so.

Regarding .NET Remotting vs. Web Services question, I would agree with Ed and really consider Web Services as the solution. If your concern is around performance and HTTP/HTTPS you can always use TCP (take a look at what WSE or Indigo offers). That said, we have had great success with HTTP/HTTPS and the tooling is getting better.