Phase 1 – first consulting meeting.

Hi all,
This is the second post in this very long posts chain I'm posting.
I thought it would be a great idea to post about my experiences as an independent consultant for companies.
The posts will not be personal experiences but the knowledge I'm getting and passing thought, whether its in the shape of a meeting, researching or sample applications.

If you want to lear more about the series, please head here and read.

Ok, so this is the post about the first meeting.

 

Usually when you come to a consulting meeting you know where you are going, you know what the client wants and you can better prepare yourself for it.
This meeting was different, the client had many questions, he wasn't sure what he wanted and how he wanted to do it.
Because the client is a startup company which deals with a lot of money, and has somewhere between 20-30K users, there is no rush in their behalf (unbelievable I know), they want it the best.

So, I had no preparations as to what the want, I knew the general idea, the have an html client, they want to transfer to flex. that's it.

 

 

When I got there, we started talking.

The first question that popped into the room was the communication method they should use.
should they use AMF/xmlSocket/Http service or what....

So, lets break it down.

Each method has pro's and con's.
Flex has the advantage of not limiting you into a single method, you can use a couple or more methods of server side communication in a single flex application.
You will need a very good team of developers and a superman project manager, but it is totally not an impossible mission, it can and was already done before.

So, lets dig further in...

Before stepping into the pro's and con's lets handle what they want to achive (again, without compromising any data or even the company name).

They have users, the users are divided into groups, each group can contain X amount of users (x is a variable not a constant )
Above the group is an organization, an organization can have X amount of groups.

The data in the group is personal and cannot be compromised to other groups or users, the same with users of course, no data should leak between users, groups or organizations.

The calculated data is group specific, meaning each group has their financial data, the calculations are based on their data and their data only.

Calculations, ok we are getting there...
Question by me: Does the user/Group/Organization need to do an action in order of the data to be calculated?
Answer: no, the calculations are done periodically (1 time per second in average) and need to be sent to the client without him even knowing about it, the data should be updated on his screen.

OK, sound about right. a well known scenario, you we guys using webforms or any other request/response are probably scratching your head right now... don't worry, its quite simple actually.

lets move forward please, lunch is almost here...

Question: what about other data on the screen, any other data needs this amount of crazy updating or should everything else be pretty standard?

The rest of the screen, containing somewhere between 10-20 parts should not be updated in this time periods, the other data is sometimes the result of a user action or a group action.

Question: should an action from a group be alerted to all the users inside it.
Answer: yes, sometimes the group did something that caused the users to loose/gain money so they should be alerted about it.

lunch

Client: the final thing we want to accomplish is the ability to reach every user/group/organization separately and send them admin messages about everything from a version update or a hosting change.

OK.

Great, I have my data, I asked my questions (I gave you a brief version of course). now let us talk.

1st - 1s calculated data.
Method of implementation.

Server - 1 calculating server based on Sql server 2005/2008 (we will not get into the configuration) a caching solution (sometimes the data is the same as before, why should the server sweat if the data has not changed).
2 - Messaging server connecting to that calculation server.
3. windows service using an xmlsocket connection based on clientIP, groupID, organizationID, when the data for an entity of those has changed you simply push the data to them, if the data has not changed you send out nothing, the GUI at the client will not change, the NET traffic will not overflow.

This way you keep it simple, you calculate the data on server 1, you send the data using server 2, connection to server 1 using a windows service which you can monitor performance.

Pro's: very rapid communication, no overflowing the servers with requests, if the data has not changed nothing happens.
Just for a reference, the client implemented the same feature in their current application using a 1second JavaScript timer and a service.
Do you want to guess what happened? (hint: guess who crashed first, server or client)

Con's scale up in this solution is not always easy and it is not done only in software, you need some hardware changing too, though in the beasts they have over there, they have time to worry about that.

2nd communication - client or group does something and data should change in the GUI.
For this solution I think the webOrb.net solution would be perfect, you get out of the box push in HTTP while the data changed, you don't have to write any custom code for it.

The WebOrb.net is a solution that lets you use AMF3 or AMF0 or RTMP communication with a flex client. It is very robust, easily configured and even has a built in monitoring solution.

Pro's: The weborb solution is hosted on top of IIS6/7 so you can configure it with flexibility of your choice.
you can write custom code, use the classes you already have in an asp.net application or generate a new application from scratch using the code generation solution.
scale up is very easy, using a load balancer and 2 servers you multiply the users that can use the system at once.
Clouding: you can pass this service into the cloud at AmazonEc2 or at any other clouding service and get out of the box scale up when needed.

Con's: The push is not always in a heart bit, mainly when you are talking about 20-30K users.
as always in a 3rd party solution, you cannot actually do ANYTHING you want.

3rd Method: Admin Messages: because the messages are not meant to be urgent, (urgent messaging will be sent on the socket already connected) the most efficient thing to do is by using FileSystem on the server for every group, user, organization and have the flex client check it once every 24 hours using an httprequest to the file it is using.
That way, this solution is not using any database in real time and will not slow down the db which is well needed on other crucial actions.

That's it....
That wasn't all of the meeting, but that's enough to chew on for this post, on the next post I will continue with the questions and answers that came up on the same meeting at this client.

Some of the subjects that we will discuss on that post:
1. Handling disconnect
2. Multilanguage
3. Skins
4. group work
5. svn
6. flex builder versions
7. graphic's team brief
8. graphic artist--developer--project manager. why, how, when, who???

   1: <?xml version="1.0" encoding="utf-8"?>

   2: <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationComplete="initApp()">

   3:     <mx:Script>

   4:         <![CDATA[

   5:             import mx.controls.Alert;

   6:

   7:             private function initApp():void

   8:             {

   9:                 cmdDoAction.addEventListener(MouseEvent.CLICK, showAlert);

  10:             }

  11:             private function showAlert(e:MouseEvent):void

  12:             {

  13:                 //do something here

  14:                 Alert.show(txtInputText.text);

  15:             }

  16:         ]]>

  17:     </mx:Script>

  18:     <mx:Button x="10" y="55" label="Do Action" id="cmdDoAction"/>

  19:     <mx:TextInput x="10" y="10" id="txtInputText"/>

  20: </mx:Application>

   1: <?xml version="1.0" encoding="utf-8"?>

   2: <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationComplete="initApp()">

   3:     <mx:Script>

   4:         <![CDATA[

   5:             import mx.controls.Alert;

   6:

   7:             private function initApp():void

   8:             {

   9:                 cmdDoAction.addEventListener(MouseEvent.CLICK, function (e:MouseEvent):void

  10:                 {

  11:                     showAlert(txtInputText.text, e);

  12:                 });

  13:             }

  14:             private function showAlert(s:String, e:MouseEvent):void

  15:             {

  16:                 //do something here

  17:                 Alert.show(s, e.target.toString());

  18:             }

  19:         ]]>

  20:     </mx:Script>

  21:     <mx:Button x="10" y="55" label="Do Action" id="cmdDoAction"/>

  22:     <mx:TextInput x="10" y="10" id="txtInputText"/>

  23: </mx:Application>