Feeling Azure the first time? Check this getting-started resource …

Check out this great article about how the DinnerNow.net application was ported to Windows Azure – Article.

Don’t forget to listen to the DotNetRocks #471 podcast about this whole process.

Recent “Application Patters for the Cloud” presentation for Boston Architect factory

 

Thanks for all the attendees. You’ve made this event a success! Thanks to all the organizers – without you this would have never happened.

 

You can find all the pictures are on Flickr and all the the presentations are hosted on the on Architect Factory collateral page (hosted on Azure Cloud).

You can access my presentation directly on the Slide Share:

 

Note: check out the price analysis article of “True Cost of Hosting” of a big web application deployments on Amazon AWS infrastructure – HotPads

Building GWT web clients [Part 4.1] – How to create an Azure RESTful web service?

Prerequisites: make sure that you have all the Azure SDK tools installed for your VS2008.

 

(1) Start by creating a new “Web Cloud Service” project in the Visual Studio. Give it a nice name.

(2) Add a new “WCF Service” to the WebRole project.

(3) Define a required contract:

The most important part here is to put attributes that will tell the WCF in what format to send/receive the message body (XML or JSON) …

[ServiceContract(Name = "service", Namespace = "http://www.igorshare.com")]
public interface IContactManagerService
{
    [OperationContract]
    [WebGet(UriTemplate = "/contacts", BodyStyle = WebMessageBodyStyle.Bare,
       ResponseFormat = WebMessageFormat.Json)]
    List<Contact> GetAllContacts();

    [OperationContract]
    [WebGet(UriTemplate = "/contacts/{filter}", BodyStyle = WebMessageBodyStyle.Bare,
       ResponseFormat = WebMessageFormat.Json)]
    List<Contact> GetContacts(string filter);
}

[DataContract]
public class Contact
{
    [DataMember]
    public string FirstName { get; set; }

    [DataMember]
    public string LastName { get; set; }

    [DataMember]
    public string Company { get; set; }
}

(4) Implement the service logic:

public class ContactManagerService : IContactManagerService
{
    private static readonly List<Contact> Contacts = new List<Contact>() { ... };

    public List<Contact> GetAllContacts()
    {
        return Contacts;
    }

    public List<Contact> GetContacts(string filter)
    {
        string f = filter.ToLower();

        var contacts = from contact in Contacts
                       where contact.FirstName.ToLower().Contains(f)
                            || contact.LastName.ToLower().Contains(f)
                            || contact.Company.ToLower().Contains(f)
                       select contact;

        return contacts.ToList();
    }
}

(5) Configure it to be exposed as a RESTful service:

To make it REALLY, REALLY simple for you, do this trick:

a) Comment out the system.serviceModel section in the Web.config file

b) Add the Factory attribute to the .svc file

<%@ ServiceHost Language="C#" Debug="true"
Service="ContactManagerCloudService_WebRole.ContactManagerService"
CodeBehind="ContactManagerService.svc.cs"
Factory="System.ServiceModel.Activation.WebServiceHostFactory" %>

(6) Build the service

 

You’re interested in 2 artifacts of the build:

1. .cscfg file – configuration for the Cloud Service deployment
2. .cspkg file – all the bits packaged (zipped)

 

At this moment you have 2 choices:

1. Run your project in the local Development Fabric (for testing and debugging), or …
2. Deploy it to the Azure Cloud (for staging or production)

 

To deploy your application to the cloud, do right-click on the CloudService project and select “Publish”.

Visual Studio will launch the Azure Service Developer Portal page. Log-in to your account, create a project and deploy your bits to the staging environment:

 

This is it!  You’re good to go.

BTW: make sure that your application works in the staging environment and then you can push it to Production by just switching it with the Staging.

 

 

Note: Check out a great explanation about the difference between the WCF REST Configuration for ASP.NET AJAX and plain REST Services by Rick Strahl.

Building GWT web clients [Part 4] – How to connect GWT client to Azure web service?

Stay tuned …

Building GWT web clients [Part 3] – How to connect GWT client to JAX-RS Jersey server?

Stay tuned …

Building fat GWT web clients [Intro] – How to create a GWT RPC client?

After months of working (mainly fighting with quirks of Java) with GWT I’ve accumulated so much knowledge on the topic so, I feel, it starts spilling over. I’m planning to convert this spill into a series of articles on how to build fat REST-full GWT web fat clients both on Java and .NET.

Here is the list of topics I’ll cover:

1. Building GWT fat client
2. Java REST-full Web services
3. .NET REST-full Web services
4. Internationalization and localization
5. IOC/DI
6. Unit testing and integration testing of all the components of the system
7. Build automation
8. and much, much more …

Here is a draft list of technologies I’ll be using:

1. GWT
2. Eclipse
3. Spring
4. Jersey
5. Tomcat
6. XStream
7. AJAX
8. JSON/XML
9. WCF
10. JUnit/TestND/NUnit
11. Selenium
12. Ant
13. TeamCity
14. and much, much more …

For starters, let’s see how to create a simple GWT fat client that talks to the REST-full Web services. As an example,

Google’s Data Centers revealed

Finally after years of secrecy Google unveiled the design of their modular data centers. Apparently they are designed to be 99.9% efficient. I’m a bit skeptical about this number, but, what I really liked, is that the whole center is built from a set of exactly the same modular containers (containing 1,160 servers each) that can be turned on and of separately or moved to a desired location. So not only servers can be switched/replaced but the portions of the data center. The data center modularization is taken to the extreme – the best scalability solution I’ve ever seen.

Read more and see a video of a server on Engaged and an on CNET.

CodeCamp 11 Presentation: Best Practices in building scalable cloud-ready Service based systems

This Saturday I’ve held a “Best Practices” Zen-style discussion during the CodeCamp #11 in Waltham.

Some people were great, but I really expected to have more heated discussions and interesting “war” stories.

You can find the slide deck on the SlideShare

Data in the Cloud: Data Camp presentation in Waltham

It was a lot of fun to present last Saturday at the very first Data Camp that was held in Waltham.

Almost every company I worked with needed some ways to store and process huge amounts of data on the cloud – that includes Intel, ICQ/AOL, Symantec and Broadserve. The latter was the worst case scenario – it was an online multimedia streaming on demand.

So, as you can guess, I’ve learned a great deal about this “trade” and, after release of Amazon AWS and, now, Azure, I’ve become a happy man – no more need in setting up and managing your own infrastructure.

In my view, the “DATA in the Cloud” is actually a mix of the following 3 main aspects (“pillars”):

1. Data Storage
2. Data Processing
3. Data Delivery
4. Access Control (Authentication + Authorization)

Yes, I know – it’s four, but where can you go without mentioning the last one? Nowhere – you’ll be eaten alive

In this presentation I’ve tried to distill all the different ways that Azure Fabric (Platform and Services) helps you to address all the (first) 3 aspects of working with the “Data in the Cloud”.

Enjoy the presentation!        (URL is here) 

While at this: I’d like to thank the organizers of the Waltham Data camp and Microsoft for providing support and the great location!!!

SOSA – Spaghetti-oriented Service Architecture

Just saw the Jim Webber’s presentation on "Guerilla SOA" – this is the must-see presentation for all the people that are working with the distributed services.

In my opinion I’d like to get rid of the SOA abbreviation – it’s an overloaded paradigm that is overused and abused. This is what you need to know if you build service-based products:

1. Talk to the business people – they are your main source in understanding the data flow
2. Make the interfaces as simple as possible (don’t overdesign)
3. Make the communication as simple as possible (for example: WCF – this allows you to take the transport decisions out of your code and will allow the IT to decide how the communication will happen)
4. ESB and BizTalk are great to access different services and data, but only behind your own service. Don’t expose these technologies to the enterprise – you’ll have to deal with all these complexities at every step of your business process. You don’t want that.