Cloud Based Jabber Client Aaron Munger and Devin McBride Team 6 Web Services

Outline Introduction Legacy System –Design –Features MVC Refactor SOAP vs. REST SCRUM Revisited Azure Target System Discussion

Introduction SOAP – Service Oriented Architecture Protocol REST – Representational State Transfer XMPP – eXtensible Messaging and Presence Protocol –Open –Standard –Decentralized –Secure –Extensible Azure – Cloud platform used to build/host/scale web applications within Microsoft’s data centers

Legacy System Jabber-net Chat client Uses jabber-net XMPP library Message with any XMPP compliant library –Google talk –Miranda –Apple ichat

Legacy Design

Features Send/Receive messages Get Buddy List Add/remove buddy

Legacy System Sequence

MVC Refactor (a first shot) Jabber-Net client object was essentially the model with only specific interfaces exposed. WCF Service deployed wrapping Jabber- Net client object. MVC3 Application for client to interface with Jabber-Net web service Limited client to a single-user mode to reduce complexity.

Implementation 1

Analysis All Jabber-Net functionality was wrapped within the WCF web service. Jabber-Net client objects getting disposed of whenever server is not actively being used. –Instantiating static objects did not stop objects from being disposed. –Concluded that Azure web services must be handling server connections. Client actions were not being immediately seen.

MVC Refactor (a second shot) Azure provides a template called a Background Worker Role – analogous to a Windows System Service. If we maintain a jabber-client database with the current state of what we expect the Jabber client object to reflect, we can ensure all actions are handled immediately. Easily maintain database using the Entity- Framework. We have full control over when Background Workers get disposed. In other words, we can ensure it does not get disposed of at all.

Implementation 2

Analysis Actions are reflected immediately. Jabber client maintains it’s connections at all times. We gained message history functionality – something not included as part of the XMPP specification (Google extended this independently.) Fine grained control over all client actions.

SOAP Implementation Analysis Communication via SOAP was extremely easy to implement as the WCF framework abstracts out the communication process allowing the client to deal with ordinary objects. Allowed rapid software development due to abstraction.

REST Implementation Analysis Used a Lo-REST implementation using only GET and POST. Very fast but was complicated to configure. Services modified to REST services using simple.NET decorators. Greatly increased development time on the client side due to the extra overhead of parsing the rest objects.

SCRUM Analysis - Pros Encouraged the active breakdown of work. Allowed us to estimate duration and actual-development time for individual features. Active communication allowed us to overcome obstacles faster.

SCRUM Analysis - Cons Our team of 2 was hindered by the overhead of the SCRUM process. –SCRUM is intended to allow larger teams (7 +-2) to maintain an agile workflow. –In our case, the process was made much more complex by the need to have a product owner, scrum master et al, developers, and testers. Most of our work was done in segments on specific days, so the agile process requirement of meeting daily did not actually happen in most cases.

Azure - Pros Fast to develop – literally copied files from normal mvc3 and wcf service projects. Easy to deploy – simply package and upload. (re)Deployment can be setup and completed directly through visual studio. Easy to maintain test and production environments in the Azure cloud. Abstracts out the infrastructure allowing us to not worry about the system the projects are running on.

Azure - Cons Local debugging is much more complex due to increased security policies on the Azure side. Entire solutions need to be uploaded every time you want to publish. –An empty project is approximately 50MB. –Takes a long time! Costly. Approximately $140 costly for around 2 weeks of 3 instances for this little azure demo.

Discussion SOAP encouraged rapid software development. REST is incredibly light weight, and fast. Do we prefer one over the other?

Questions?