Yes, the technology choices matter

O'Reilly books has published a report on “the state of the computer book market 2008”

O'Reilly used sales data to determine the health/strength of various computer languages used in programming. Based on that information, you can pretty easily see what is popular and what is not, etc.

Take a look: here is the link
http://radar.oreilly.com/2009/02/state-of-the-computer-book-mar-22.html

I’ll point out two things. The number one language in 2008 was C# -- it overtook java of all things this past year. eoStar is completely C#, so that was very encouraging.

But they go on to classify groups of languages by sales figures… I’ll pick on the two bottom ones

I like this list. 1000-1999 units



So there were only 1783 F# books sold in 2009. O'Reilly still considers this immaterial.


But I saved the best for the bottom bunch. Take a look at this:



You will note a particular language of interest here is "RPG". I bring this up because RPG is utilized by several of eoStar's competitors as the choice for technology they use.

Let's look at the eoStar language table again..



What does this mean and why is this important?

Let's say your company goes with a software provider, for your core system, written in the "less than immaterial" languages such as RPG. Deciding on a system is a very big choice because it touches on so many parts of an organization. As a customer, I need to be confident that the decision I make is a good one. Now what happens if my RPG based vendor cannot get the resources they need (RPG programmers) when I ask them to get something done? My request is serviced in a not-so-timely manner, or worse, never at all. It's not that the RPG enabled vendor doesn't want to do the work, it is that they cannot get the resources (programmers) to do it because the language is dead in the technical world.

Evidence of growth, or lack thereof, for any computer language is highlighted by those providers of programming knowledge.

The eoStar system has been C# since the beginning. We've started with C# since the pre-v1.0 series and continue using it. The language is growing and soon C# 4.0 gets released out (we are already playing with it in the labs in CTP form). Having the sales of C# books overtake all other languages is fantastic from *our* business point-of-view because the developmental resource pool grows and is growing. That is good news for our customers because it means that the tools *we* use to create and grow eoStar are getting bigger and better. Our customers can look forward to continued innovation in the eoStar system because our tools get better.

The technology choices do matter.

eoStar Communications

I get asked many times about the technical details on how the eoStar Route Accounting software package communicates to the main server in the office. You can click on the thumbnail of the diagram above to see the overall architecture.

In all, it basically works like this: A mobile eoStar user (Preseller, Driver, Merchandiser, Warehouse operations) uses the eoMobile software, which provides all of the functions needed for the particular user (or any combination of roles, combo presales/driver, etc).

When the user synchronizes with the home database, the mobile device (Any windows mobile 2005 or newer, or tablet XP or newer) then makes contact with the eoNetservice box. The eoNetservice box is an ASP.NET IIS7 capable box that runs the eoNetservice software (comes free with the eoStar system) which is an ASP.NET web services software. The eoNetservice box then communicates with the Microsoft SQL database server on behalf of the mobile user.

Most of those people then ask why we don't talk to the SQL server directly. There are two major reasons: Security and Scalability. With regards to security, the SQL box can stay behind firewalls and not be exposed to possible attack surfaces. Additionally in the area of security, the eonetservice process is responsible to create and manage a secured communications channel between the mobile device and itself. It is the traffic cop in the first place. We had a group of professional hackers try and break the eonetservice process and outright attack it. It has survived completely. On the scalability front, any one eonetservice box can service multiple database servers. Likewise, any database server can be serviced by any number of eonetservice machines. Thus a larger organization can deploy a web farm to manage communications and security with ease.

More importantly, the eonetservice process is a headless process. That is, there is no console or some interaction involved by the administration to 'watch what it is doing'. It is also self-cleaning as it stores no database data (outside of the data being transmitted at that moment).

The eonetservice box can be located anywhere. Most companies place it on their networks where it is accessible from the field, so that the mobile users synchronize anytime they want. There is NO preparation required for a synchronization of information between the mobile device and the main database. No administration has to 'build files' or tell something that it is time to download new information. The mobile device asks the eonetservice to provide all updates needed at the time of communication. The comm has become automatic for the office staff. As soon as data is updated in the database, it is available immediately for update on the mobile device. That is very cool.

A more detailed note about the security. In particular, we do transfer data on port 80 (standard http web services port). That is to be able to wind through intermediary firewalls. In that scenario, it was imperative to secure the messaging and data payloads. That is performed by standard x.509 certificates with multi key encryption (2k keys for the USA, 48bit for the rest of the world).

A note about comm time. On average, full sync times are less than 3 minutes for a large set of data.

THE MOST CRITICAL aspect of the communications comes into the design when uploading things such as payments, orders, etc. The app protocol utilized is a positive-acknowledgement-database transaction committed system. That means, when the mobile device says to the user that data was 'posted to the database', that the mobile device has received POSITIVE acknowledgement from the SQL server that data was successfully COMMITTED to the database server. This is SOOOO critical and is the primary differentiator from us and other route accounting systems. We KNOW the data was posted to the database. Unless the mobile device gets this positive acknowledgement from the POSTED data, the orders are not released from the mobile device. This is a desirable design for any modern system. When the software says it 'got there', it had better got there!

Hope that is informative, and thanks for looking into the eoStar route accounting system. By far, we think it is the most definitive solution for the Direct Store Delivery wholesaler available today.

Cover Girls

How cool is this!! We made the cover of Portals Magazine (an MiBiz Journal). Pictured here (L-to-R) are Michael Rutherford, Shawn Gary and me. The picture was taken at Kent Beverage (Shawn is VP there). You can see the PDF of the issue as well as the text transcript of the issue. Iz very cool

Welcome everyone

Hello all and welcome! This blog is what I am doing to provide some insights into the inner workings of the eoStar world.

You can read through and subscribe to the blogs of other individuals at Rutherford for these areas:

Thu's eoStar tech world

Kent's eoStar development world

I encourage you to visit them often. You will probably learn quite a lot about our software products there.

Most of what I will provide is information in and around the businesses that use our software, as well as the industries we serve. There are lots of cool things going on and I know you will enjoy it.