Infosys Microsoft Alliance and Solutions blog

« February 2010 | Main | April 2010 »

March 30, 2010

Load up your clouds just about right - need for capacity planning

Well, if I have compute and storage available on-demand then I would not worry about capacity planning,Right?

Continue reading "Load up your clouds just about right - need for capacity planning" »

March 24, 2010

ROI message on Windows 7

Last week, I was at Partner Summit at Seattle. During a session with one of senior executive from Microsoft, one partner representative asked what is the ROI message for Windows 7 adoption to the clients. While there is no doubt that concrete messaging on ROI directly from Microsoft will be useful; I think there are enough data points as a businress case for adoption of Windows 7. The promise of savings of $90 to $160 per PC per annum as mentioned during the launch of Windows 7, improvement in productivity, better efficiencies with new features like BranchCache, DirectAccess, Federated Search and savings due to lower power consumption etc. could also be quantified. However, this computation will obviously depend on individual client context. I tend to believe that as a broad thumb rule for an organization having 10,000 desktops to be migrated for creating a Dynamic Core Infrastructure the deployment cost could be break-even in 12 - 15 months timeframe. 

March 23, 2010

Workflow 4.0

Windows Workflow (WF) 4.0 part of .NET framework 4.0 and will be shipped as RTM (Release to manufacture) on 12th April 2010. WF 4.0 has some exciting things on offer. Here are some interesting ones which one can consider while choosing Workflow 4.0 over Workflow 3.5 while engineering .NET applications

1) Improved Performance - WF 4.0 is re written from the scratch, the new runtime in WF 4.0 promises 10 to 100 times performance improvements. Speed improvements are due to increase in execution speed as well as the reduced size of persistence information. To understand the what went behind to cause this improvement, refer this
2) New activities – Several new OoB activities introduced. Newly introduced Parallel activity helps in writing logic in parallel without needing to write explicit thread synchronization. State Machine workflows in WF 3.5 are no more around; Flowchart is introduced as a new workflow type. To understand list of various activities supported through WF 4.0, refer this
3) Fully declarative workflows and activities
Declarative workflows have been possible earlier but to build the UI declaratively using XAML in the business layer was not easy. In WF 4.0, it is very simple to create a workflow declaratively in XAML. Writing workflows in XAML eases versioning, deployment and maintenance. The advantage is there is no code (behind) and the workflow can be changed dynamically and deployed easily.
4) Better integration with WCF 4.0 (Workflow as a service)
Workflow can be exposed as service without needing to write WCF service wrapper.
5) Workflow persistence – State Machine workflows are no more supported in WF 4.0. The workflow persistence can be achieved using Persist activity and can be applied to Sequential or Flowchart workflows.
6) Correlation support – Correlation is the ability to tie up related workflow services messages to the same instance of workflow. Workflow 4.0 supports 3 types of correlations: context, content and message based correlation. Refer this to understand various correlation mechanisms supported in WF 4.0
7) Compatibility with the previous versions
In WF 4.0, System.Activities.* assemblies hold everything related to WF. But the older System.Windows.* assemblies have been retained to ensure backward compatibility, so your WF 3.5 based workflows will work in 4.0 through newly introduced interop activity. Check this for WF 3.5 to WF 4.0 migration guidance.
8) Workflow host (App Fabric) – Appfabric is used to host workflows and services. It provides out of box monitoring, scaling (instance management), persistence which otherwise will have to be implemented and managed through custom extensions.
9) Simplified Designer - In WF 4.0, the designer comes with performance and usability improvements. The workflow designer is completely rebuilt using WPF and this gives it a great, rich user interface.  It is possible to create and open large workflows without loss in performance.
10) Re-hosting designer - In the previous versions, developers would need to write a few hundred lines of code to re-host the designer where as with WF 4.0 it is just a few lines of code. One can re-host workflow designer in WPF with a few lines of code.
11) Improved developer productivity – it takes 80% less code to write custom activities as against earlier version. WF 4.0 also removes the notion of a root activity; any activity can now comprise a workflow as compared to just Sequence and State Machine Activity previously.

While this is not an exhaustive list on what WF 4.0 has on offer. Am sure many would be keen to adopt and exploit what WF 4.0 has on offer.

Silverlight 4 and Windows Phone 7

MIX 2010 that happened in Las Vegas last week (15 - 17 March), like all earlier MIX events, had some amazing new technologies to showcase. It is very evident that Microsoft is investing heavily into user experience and the new Windows Phone 7 was a prime technology piece that was showcased with many cool demos.

In the Keynote for day 1 Scott Guthrie and Joe Belfiore talked about and showcased Silverlight 4, Blend 4 and Windows Phone 7. Silverlight 4 developer release, Blend 4 beta and developers tools for Windows Phone 7 were released and are available for everyone to try out. There is more integrated support for working with Silverlight 4 in Visual Studio 2010 now, which is already available as RC. 

The keynote talk had some very interesting demonstrations. Along with Silverlight 4 and Blend 4 showcase, there were many demos around Windows Phone 7, all the way from how easily one can build applications for Windows Phone 7 from VS 2010 or Blend 4, to some fun apps that included Scott using the accelerometer feature to have Steve's avatar bouncing around and another one where they controlled a cannon from a Windows Phone 7 app and fired T-Shirts into the audience.

It was great to note that Silverlight 4 now has a control that can help view Pivot collections. If you want to start to build on Silverlight 4, you can download the required tools from here. In case you want to try out applications for Windows Phone 7, you can download the tools from here. The really cool part is that you can use Silverlight 4 and all its capabilities to build applications targeted to Windows Phone 7. Note that for working with Silverlight 4 or Windows Phone 7 toolset you need to have VS 2010 RC.

MIX had many more very interesting sessions and in case you want to see them, you can start from here. And yes, there is expectation that the RTM version of Silverlight 4 and Blend 4 will be available along with VS 2010 RTM that happens on 12th April.

March 4, 2010

Size of a .net object

While trying to debug a service call, where we suspected a buffer overrun situation, we wanted to find out the size of the object being returned by the service call. However finding size of a .net object is not trivial and if you thought you could do a sizeof(object), then you are wrong. This will only return the size of the object based on the size of each field in object that itself is based on the type of the field. This doesn't returns the size of the object in memory with data loaded into it.

Another option people try to use is Marshal.Sizeof(object), but this gives the size of the unmanaged representation of the object and the layout in managed and unmanaged world may be very different.

Chris Brumme (earlier was in the CLR team) had written that there is no direct API in .net to provide this size and he has explained it here.

Some forums talk about using a serialization approach. So you essentially create a memory stream and then use  binary formatter and serialize the object in the stream and then get the size of the stream. While this can be used, be aware of potential pitfall. The size thus obtained is really the serialized size and not the in-memory size. Why will the two differ? These can differ for

  1. The layout of the object in memory/byte alignment etc will cause the diference and
  2. If the object overrides and has custom serialiation, it might alter what all get's serialized and thus the size will differ.

Another option, that possibly is the best according to me is to use GC.GetTotalMemory() API before and after the call to create the object. See details here. However this itself has its own challenges in that this isn't thread safe, as the blog also points out. Multiple things can happen between the two calls to GC and other threads may release or allocate other objects and hence the size difference you will get may not truely reflect the size of only this object. Another aspect is that this object itself may need multiple steps to fully populate and hence enclosing these steps within calls to GC.GetTotalMemory() may be tricky.

There is one last option, which will mostly be 100% accurate, and that is to take a memory dump of the process once the object is allocated and then using WinDBG find out the total size of the object by using the objsize command. See some explaination of how to use WinDBG for this purpose here.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter