A Solutions Architecture aims to address specific problems and requirements, usually through the design of specific information systems or applications, and typically accommodates many different audiences as it addresses direct business and technical concerns without dropping down to the nuts and bolts of the software architecture.

Note, that I provided a link to Wikipedia’s definition, but I have expanded that definition to be more specific regarding its intended audiences and provided level of detail.

It should be noted, that my intention is not to advocate a Solutions Architecture as another tedious task in the software development process, but to provide a software architecture practice that is

• practical and useful by a broad audience,
• flexible in its composition, and
• well understood, especially by business and technical folks.

Many times, I’ve seen the impedance mismatch, e.g., technical jargon, business jargon, expectations, communications, etc…, go unnoticed, or ignored, far too long. A Solutions Architecture provides a proven strategy to effectively guide architecting software systems.

In this post, I delve into the concept of Current State Architecture and Future State Architecture and how identifying these help guide us to the ultimate goal, the Solutions Architecture.  If it is discerned through the Solutions Architecture, that the current state architecture is unacceptable, work can begin on creating the future state software architecture.

Please click on the link if you are looking for information on helping you determine

“When is it time to revisit my current software architecture?” - another post by B. Buikema

Solutions Architecture

A Solutions Architecture is typically written as slides, e.g., a powerpoint presentation, not straight-up, highly-textual, documentation.  It is comprised of content and diagrams that provide a 360 degree view of a software architecture as a total solution.  Details such as algorithms, code snippets, detailed designs (i.e., UML class, sequence, state, etc…) are typically omitted.

NOTE:  Companies typically have business and engineering folks whose tolerance for documentation is either small or large, and this is driven by the company culture.  I recommend that the Solution Architecture is kept as tight and to-the-point as possible to match this tolerance.  However, make sure that any items deemed important by folks are, in fact, included to ensure buy-in by all parties.  I will also identify those items I believe are absolutely necessary.

Typical items found in a Solutions Architecture are

• Statement of Work (SOW)
• Goals
• Considerations
• Use Cases
• Conceptual Architecture
• Logical Architecture
• Security Architecture
• Information Architecture
• Physical Architecture
• Network Operations Center (NOC) Requirements
• CURRENT STATE:  Discussion of Business and Technical Gaps
• FUTURE STATE:  Solutions to Business and Technical Gaps
• Non-Functional Requirements (NFR’s)
• Engineering Development Staffing Requirements (e.g., roles/skills)
• NOC Staffing Requirements (e.g., roles/skills)
• Operations Staffing Requirements (e.g., roles/skills)

SOW

This is the statement of work and is usually a paragraph or two describing the intent of the system or application.

Goals

Provide key goals important to both the business and engineering.

Considerations

Key considerations include, but are not limited to

• targeted business markets/consumers
• targeted technologies/platforms
• keeping legacy features (or not)
• short and/or long-term business plans
• short and/or long-term technical plans
• user privacy policies
• sensitivity to cost and time

Use Cases

These are typically high-level and include all major actors and relevant use cases.  Include all roles and responsibilities, and, if you’re unsure, it is better to include than exclude.

Conceptual Architecture

This is the loosest of the architecture diagrams, but can set the stage for understanding the  other architectural views.

The Conceptual Architecture provides a view depicting high-level, conceptual systems, subsystems, and/or applications, and their importance to the actors and use cases.  This is commonly just arrows from the actors to a high-level component and stating the high-level use case it represents.  There are typically no hard and fast rules in creating a Conceptual Architecture, but it is useful when discussing the high-level architecture.

Logical Architecture

The Logical Architecture depicts the logical view of the system or application and commonly identifies the main software components as follows:

• systems
• subsystems
• applications
• servers (such as email and web servers)
• services

A Logical Architecture need not concern with the attributes of the physical environment.

• data in flight
• data at rest
• authentication and authorization

Information Architecture

The Information Architecture may include core data schemas, data flows, transactions, workflows, etc,… NOTE:  It’s advisable not to delve to deep on these, keep them at high-level to satisfy the use cases and come of the other architecture diagrams.

Physical Architecture

This depicts a diagram(s) the physical environment(s) of the components the system or application is hosted on.  Server nodes, clusters, firewalls, databases, are just some of the components identified.  Details to the physical hosting and interfacing are well established.

NOC Requirements

NOC requires various deployment and topological network diagrams for each environment they maintain to host the system or application.  This usually includes Production, Testing, Staging, and Development.

Discussion of Business and Technical Gaps

This is relevant to the Current State Architecture only (see below).

The business gaps can commonly be captured in a table format, identifying the feature, the problem/challenge, the folks affected, and the priority of importance.

The technical gaps are similar, but describe the technical difficulty, of course.

You can also see how useful this becomes when you map the two together to form an end-to-end understanding of why the business problems/challenges occur.

Solutions to Business and Technical Gaps

This is relevant to the Future State Architecture only (see below).

Taking the details discussed in the Discussion of Business and Technical Gaps, each item should be identified and given a description of the solution along with a measurement of how well the solution solve the actual problem/challenge,

For example, you can adopt 0 – 5, where

• 0 represents no solution,
• 1 represents 20% solved and
• 5 represents 100% solved.

NFR’s

NFR’s typically include details that are not always given to engineering, but are critical to operations

• availability
• disaster recovery
• performance and scaleability
• elasticity
• instrumentation
• data backup and retention

Representing a Solutions Architecture Through States

In order to effectively compare and contrast different solutions architectures, it is necessary to provide a baseline, also known as the current state architecture.  And new solutions known as the future state architecture.  This nicely allows us to describe the state of the union as we see it today, and optional solutions that are possibilities for the future.

Current State Architecture

Simply stated, this is the current state of the software architecture.  In addition to the architectural specifics, the gaps in both business and technical are included.

In addition to the typical items listed above, the following are specific to the current state:

• Business Gaps in the Current Architecture
• Technical Gaps in the Current Architecture

The exercise in creating the Current State Architecture is rewarding as the results make it much easier to justify arguments made in the past that were harder to prove.

Recommendations

I recommend the following, at a minimum, as I strongly believe they are core to defining a Solutions Architecture:

• Statement of Work (SOW)
• Goals
• Use Cases
• Logical Architecture
• Security Architecture
• Information Architecture
• Physical Architecture
• NOC Requirements
• Non-Functional Requirements (NFR’s)
• CURRENT STATE:  Discussion of Business and Technical Gaps
• FUTURE STATE:  Solutions to Business and Technical Gaps

The actual details for each of the above can be brief, as long as any details that can affect the final decision are surfaced enough for clear discussion.  For example, identifying high-level data schema(s) are suffice for the Information Architecture as long as key data stores (e.g., databases) are present in the diagram.

Using the Current and Future State Architectures to Identify the Winning Solutions Architecture

This is where the rubber hits the road and the real decisions can be made.

Now all of the facts are within easy reach to do comparisons and open up discussions that can include both business and technical folks.  This proves fruitful for a company’s future, as the business can share its short and long-term needs and engineering can understand its limitations, if any, and together well-informed decisions can now be made going forward.

Moving Forward

Coming up in the near future, I will discuss using the Solutions Architecture to drive creation of the Software Architecture.

Please click on the link below if you are looking for information on helping you determine

“When is it time to revisit my current software architecture?” - another post by B. Buikema

I also have many other posts regarding

• software architecture
• mobile (Android) development
• enterprise development
• design patterns
• and much more…

so look me up.

See you soon!

In this post, I discuss an important topic in software architecture:

“When is it time to revisit my current software architecture?”

As a software developer, software architect, solutions architect, software product manager, and software consultant (I’ve been all of them), I have to come into companies to help make decisions regarding the future of a current software architecture.  Typically, I’ve seen several camps, but we’ll keep our attention focused on these two:

Startup

Application coded/tested/deployed to early visionary’s specs.  Sales is able to sign up some clients.  Clients report mostly good things about the application.  Venture Capitalists (VC’s) are interested.  Demonstration to VC’s went great and funding approved!  But engineering says

• the architecture can’t scale
• it isn’t robust enough for rapid growth
• it wasn’t designed to do those fancy phase 2, 3, 4, etc…, features, since we were told to get phase 1 out the door asap.

We’ve all been there.  Now what?

Likely problem:  No real software architecture existed in the first place.  Consider this a working prototype, but no more than that.

Mature

Application has been in production for several years and supports our clients, but is horrible to maintain, operate, and extend.  The current technology platform is aging and is stifling the business’s ability to add features that the competition already provides, e.g., mobile support.  The CTO sees a new technology platform that may be the silver bullet to all of these problems.

But what now?

Likely problem:  Software Architecture Erosion.  I’ll discuss this in detail in the next section.

Limitations in the Current Software Architecture – Denial or Reality?

Most software folks know that there are weaknesses in the software.  Some even know, dare I say, that there are weaknesses in their own code!  However, is it really the code, the design of the code, or the architecture?

Keep in mind, the code can normally cleaned up (given time), and the design can be normally cleaned up (also given time).  This is considered re-factoring and is a normal part of software development.

Software architecture can be a different story, however.  Depending on the lack of proper logical layers, violation of architecture patterns, tightly-coupled interfaces, implicit or explicit use of technology platform-specific communications, strong dependency to a specific type of data store, and more, can contribute to a software architecture’s limitations.  These limitations normally result in adversely affecting one or more of the following:

• ability to provide a robust architecture that can handle any kind of stress in both extensibility and resource usage, including any changes to the operating environment, and still provide the desired application functionality
• ability to scale to meet growth demands
• ability to create/extend features without excessively increasing software complexity
• ability to communicate with other software components/technologies
• and more…

Ultimately, this leads to software architecture erosion.

Software Architecture Erosion

Simply stated, software architecture erosion is the deterioration of the software architecture by the cumulative effect of numerous implementation decisions that violate the planned architecture.

Let’s take a look at a typical software architecture as time passes.  Fig 1 depicts the development of new features that are released through new versions.

We’ll also see that during the first three versions, the software architecture has been adhered to as shown in Fig 2.

However, things changed for version 4 and 5, as the business decided to expand into other markets and required some conceptually new features that were not envisioned by the planned architecture.  Fig 3 depicts versions 1 through 5.

As can be seen by the dashed line, the system complexity has increased drastically as the software development team made the decision to violate the planned software architecture in order to accommodate the requested business features.  This is a sure sign of software architecture erosion and puts limitations on future features, release schedules, and more.

One might ask, “Is there a test I can apply to know if there is a need to rethink our current software architecture?”

One can look at

• feature time-to-complete creep,
• guage any increases in frustration in the software development team, and
• readily perform stress and load tests to obtain performance metrics.

One can also identify

• fragmented business logic spread in multiple layers/components,
• tightly-coupled interfaces, and
• technology platform-specific communications.

Keep in mind, the seniors on the engineering/NOC team know many of the limitations.  Don’t kid yourself.  The key is determining how much erosion as occurred and how will affect the business in the near and far future.

Don’t Look Now, but Someone Booked a Meeting During Your Lunch Hour!

So now talk about the limitations of the current architecture are omnipresent.

Time for meetings.

Commonly, I see meeting after meeting after meeting occur, where the business stake holders meet with engineering/IT/QA to convey/capture business needs, while engineering meets with platform vendors to attend presentations.  Usually, a few engineering folks quietly discuss what should really be done.  Sometimes business folks learn of a new upcoming technology, and pass this along to engineering as well.

While none of these are inherently bad by themselves, they do indicate a lack of direction that needs to occur.  Everyone has opinions and ideas that provide fragments of a solution, but collectively, these do not provide a complete solution.  Also, I’ve seen literally hundreds of man hours wasted because these meetings occur, often in silos, and, therefore, folks are not collaborating on

• understanding the challenges and problems with the current application
• understanding upcoming features and future targeted business growth (e.g., 6 mo’s, 12 mo’s, 24 mo’s) that the application must support
• prioritizing and time-lining of the above
• creating a strategy to help discover a solution

A common knowledge of the problem must be understood and shared, and a practical strategy must be identified to facilitate the collaborative discovery of a solution.

The Solution

What it comes down to is understanding all views, or dimensions, of your current software architecture, and conducting an objective review of it by all stakeholders.  You may be thinking,

“How can business folks possibly understand the technical details of the software architecture in order to provide valid input to this important exercise?”

The answer.  Because you will provide a Solutions Architecture that will accommodate many different audiences as it collectively, and without deep-down details, addresses direct business and technical concerns.

In my post, Creating a Solutions Architecture, I delve into the concept of Current State Architecture and Future State Architecture and how identifying these help guide us to the ultimate goal, the Solutions Architecture.

I also have many other posts regarding

• software architecture
• mobile (Android) development
• enterprise development
• design patterns
• and much more…

so look me up.

See you soon!

The process of splitting up data and storing portions of data on different machines is called sharding.  By splitting up data across machines, it becomes possible to store more data and handle much more load without requiring large or powerful machines, e.g., machines that consist of powerful CPU’s and/or massive amounts of RAM.

Two types are sharding can occur.  Manual sharding and autosharding.

In manual sharding, the application code manages storing different data on different servers and querying the appropriate server to get it back.  Manual sharding can be done with virtually any database software package.

In MongoDB autosharding, some of the administrative overhead required in manual sharding is eliminated.  The cluster of database servers, or shards, handles splitting up of data and rebalancing of data automatically.

Autosharding

The basic concept behind MongoDB’s sharding is to break up collections into smaller chunks, or documents.  These documents can be distributed across shards so that each shard is responsible for a subset of the total dataset.

As an example, consider the following.  When you set up sharding you choose a key from a collection and use that key’s values to split up the data.  This key is called the shard key.

Suppose we had a collection of contacts.  If we chose “lastName” as our shard key, one shard could hold documents where “lastName” starts with A-F, the next shard could hold last names from G-P, and the final shard could hold last names Q-Z.  As you add or remove shards, MongoDB would rebalance this data so that each shard was getting a balanced amount of traffic and a practical amount of data.

So when should you decide to start sharding?  Consider the following reasons:

• When you’ve run out of disk space on your current machine.
• You want to write data faster than a single mongod can handle.
• You want to keep a larger portion of data in memory to improve performance.

Setting up Sharding

Three different components are involved in sharding as follows:

shard

A shard is a container that holds a subset of a collection’s data.  A shard is either a single mongod server (for development/testing), or a replica set (for production).

mongos

This is the router process.  It routes requests and aggregates responses.  It doesn’t store any data or configuration information, although it does cache information from the config servers.

config server

Config servers store the configuration of the cluster.  For example, which data is located on which shard.  Used by mongos to determine request routing.

Starting the Servers

First we need to strat up our config server and mongos.  We need to start a config server because mongos uses it to get its configuration.

$ mkdir -p ~/dbs/config
$ ./mongod --dbpath ~/dbs/config --port 20000

Now we start a mongos process for an application to connect to.  Routing servers do not even need a data directory, but they need to know the location of the config server.

$ ./mongos --port 30000 --configdb localhost:20000

Shard administration is always done through a mongos.

Adding a Shard

Start a normal mongod instance (or replica set), since this is what a shard naturally is

$ mkdir -p ~/dbs/shard1
$ ./mongod --dbpath ~/dbs/shard1 --port 10000

Now connect to the mongos process started earlier and add the shard to the cluster.

First, start up a shell connected to the mongos process as follows:

$ ./mongo localhost:30000/admin

Now add this shard with the addshard database command:

> db.runCommand({addshard : "localhost:10000", allowLocal : true})
{
    "added" : "localhost:10000",
    "ok" : true
}

The “allowLocal” key is necessary only if you are running the shard on localhost and lets MongoDB know that you’re in development and know what you are doing.

Sharding Data

In order to allow MongoDB to distribute data, you have to explicitly turn sharding on at both the database and collection levels.  For example, the following enaables sharding for the database acme:

> db.runCommand({"enablesharding" : "acme"})

Once you’ve enabled on the acme database, a collection is sharded by running the shardcollection command as follows:

> db.runCommand({"shardcollection" : "acme.products", "key", : {"_id" : 1}})

Now the collection will be sharded by the “_id” key.  When data is added to acme, it will be automatically distributed across the shards based on the values of “_id”.

I hope this post enlightens you on the possibilities that MongoDB’s auto-sharding feature provides for ease of scaling.

• easy learning curve
• faster development than with traditional relational databases
• high availability and easy horizontal scalability
• extremely fast access times
• powerful indexing and querying capabilities, similar to its relational database counterparts
• an ideal database platform for both cloud and desktop computing
• schemaless, document repositories, via collections and documents, that naturally fit application domains
• an ideal database platform for embracing agile development

A general set of MongoDB supported Use Cases, both well suited and less well suited are found here.

It should be noted that MongoDB shares the NoSQL spotlight with CouchDB.  Since MongoDB and CouchDB are both document-oriented databases with schemaless JSON-style object data storage, folks are naturally asking questions.  Please click here to compare MongoDB and CouchDB.

MongoDB Features

Here is a list of MongoDB features.  Click on the links for details.

• Document-oriented storage via JSON-style documents with dynamic schemas
• Full Index Support
• Replication & High Availability
• Auto-Sharding
• Querying
• Fast In-Place Updates
• Map/Reduce
• GridFS
• Commercial Support

The MongoDB Philosophy

MongoDB was not created to be just another database that tries to do everything for everyone.

Instead, MongoDB was created to work with documents rather than rows, was extremely fast, massively scalable, and easy to use.

In order to accomplish this, some features were excluded, namely support for transactions.  Therefore, MongoDB may not be a great fit for developing accounting applications.  However, it is quite common to strategize software architectures by using a hybrid of technologies.  For example, a relational database works well with accounting and transactional components.  While MongoDB is a great technology for storing and retrieving complex data and document storage.

At a high-level, MongoDB provides the following (this is not an exhaustive list):

• A Rich Data Model
• Easy Scaling
• Simple Administration
• Features such as indexing, embedded document references, stored javascript, fixed-size collections, file storage, aggregation, replication, auto-sharding, and more.
• And all of the Above without Sacrificing Speed

MongoDB is a document-oriented database.  It is not a relational one.  The primary reason for moving away from the relational model to the document-oriented model is to make scaling out easier, but additional advantages are found as well.

The fundamental idea is replacing the concept of a row with the more flexible model, the document.  By supporting embedded documents and arrays, the document-oriented approach makes it possible to represent complex hierarchical relationships with a single record.  This fits naturally with how data needs are addressed by developers using modern object-oriented languages.

More coming soon!

Installing and Running MongoDB on Ubuntu

I highly recommend installing MongoDB via the default repositories available in Ubuntu.  These repositories contain MongoDB, but may contain out-of-date versions.  Software installation from repositories is done through aptitude.  In order to obtain the latest versions of MongoDB, simply add the following line to your repository list found in /etc/apt/sources.list

deb http://downloads.mongodb.org/distros/ubuntu 10.4 10gen

where 10.4 is the version of Ubuntu I run.  Make sure to supply the version of Ubuntu you run.

Next, you need to tell aptitude to retrieve the new repositories as follows:

$ sudo aptitude update

And now install MongoDB using the following command:

$ sudo aptitude install mongodb-stable

As the last step in the installation process, you will need to create the data directory yourself.  Make sure and do this as a non-root user.

$ sudo mkdir -p /data/db/
$ sudo chown `id -u` /data/db

You can start the MondoDB service as follows, and again, make sure and do this as a non-root user:

$ sudo start mongodb
$ sudo status mongodb

And start the MongoDB shell with the following command:

$ mongo

Once in the MongoDB shell, some basic commands include the following:

> show dbs
> show collections
> show users
> use <db name>

Quick Reference to the MongoDB Upstart Scripts

Here is a quick reference to the commands that control the execution of the mongod server process:

$ sudo status mongodb
$ sudo stop mongodb
$ sudo start mongodb
$ sudo restart mongodb

Important in Case of Error Connecting to the Server

If upon starting the MongoDB shell, you happen to get an error message connecting to the server similar to the following:

Error: couldn’t connect to server 127.0.0.1} (anon):1137

You may also notice that even though you issued the command to start the service, it actually did not start.  The next step is to verify that you are unable to start MongoDB.

Run sudo start mongodb.  It will report

mongodb start/running, process XXXX

no matter what.  However, when you run sudo status mongodb again, you’ll get

mongodb stop/waiting instead of mongodb start/running

Note:  This condition is largely due to an unclean shutdown, and results in the creation of a lockfile /var/lib/mongodb/mongod.lock.

The fix is a quick two-step process as follows:

1. Remove the lockfile.
2. Run the repair script.

This is accomplished as follows:

$ sudo rm /var/lib/mongodb/mongod.lock
$ sudo -u mongodb mongod -f /etc/mongodb.conf --repair

Now when you run sudo start mongodb.  It will report

mongodb start/running, process XXXX

and when you run sudo status mongodb again, you’ll get the expected

mongodb start/running, process XXXX

Understanding Data Modeling under MongoDB

A MongoDB database is non-relational and schemaless.  Therefore a MongoDB database is not bound to columns and data types like relational databases are.  One of the primary benefits of a flexible schemaless design is that you are not restricted when programming in a dynamically typed programming language such as Python.  Keep in mind that even though MongoDB is schemaless, the data structure is not completely devoid of schema as you still define collections and indexes, as we will discuss later.  Nevertheless you will not need to predefine any data structure for any of your documents you will be adding.

The fundamental components of a MongoDB database are documents and collections.

Document is an item that contains the actual data, similar to a row in a SQL database table.

Collection is a collection of documents, similar to a table in a SQL database.  Unlike a SQL database, two or more completely different documents can co-exist in a single collection.

More coming soon!

Developing Applications under MongoDB using Python with Example Code

Python is a simple programming language that provides the natural ability to develop code that is perfectly readable.  Here are some links to Python code examples:

• Catalog of Python Code Examples
• Simple Python Programs

In this section, we will develop simple, clear, and powerful code that works with MongoDB through the Python driver known as the PyMongo driver.

Installing the PyMongo Driver

Before we begin to write Python code to access MongoDB databases, we first need to install the PyMongo driver.

I’m assuming you have Python 2.7 or greater up and running.  The steps for Python installation are simple once you obtain the source from python.org/download and extract the contents from the tar file, and are commonly listed as follows:

$ ./configure
$ make
$ make test
$ sudo make install

Of course, you should always consult the readme file to obtain up-to-date instructions.

The steps required to install the PyMongo driver are as follows:

Step 1

Obtain the Python setuptools egg for your version of Python.  For example, I obtained setuptools-0.6c11-py2.7.egg from http://pypi.python.org/pypi/setuptools#using-setuptools-and-easyinstall.

Step 2

Now execute the downloaded egg as if it were an acual shell script by typing (note your setuptools egg filename may be different depending on the version of Python you are using).

$ sudo sh setuptools-0.6c11-py2.7.egg

Step 3

$ sudo easy_install pymongo

That’s it!  But let’s test to ensure that our installation was a success.

From the Python shell, type the following:

>> import pymongo

You should be greeted with an empty cursor >>.  That’s success.

To take it one step further, we’ll insert data into a database and also retrieve it back.  Remember in MongoDB, if we try to retrieve a database that does not exist, MongoDB creates it for us automatically, as is the case with mytestdb below.

Type the following in the Python shell:

>> from pymongo import Connection
>> c = Connection()
>> db = c.mytestdb
>> collection = db.items
>> item = { "Title" : "Test Data", "Value1" : "1", "Value2" : "2"}
>> collection.insert(item)
>> collection.find_one()

{u'_id': ObjectId('4d432adc1d41c85d8a000000'), u'Value1': u'1', u'Value2': u'2', u'Title': u'Test Data'}

An Introduction to Working with MongoDB using Python via the PyMongo Driver

Now that you have the PyMongo driver installed and running, it is time to learn the basics in developing Python code that works with MongoDB.

Instead of reinventing an already great tutorial, I provide this link to the tutorial located on the mongodb.org site.

Enjoy.

Advanced:  Sharding

Since sharding in MongoDB is a key feature and large topic to discuss, I created a separate post found here.  This 15 minute high speed post provides a detailed overview of autosharding in MongoDB and, specifically, how to create shards supporting autosharding in MongoDB.

Enjoy.

This post discusses how to ensure your production CRM environment is tuned and optimized for top performance.

My knowledge in this area has been largely obtained by working closely with Robert Shurtleff, the Microsoft CRM Dynamics Architect at Ciber.

Therefore I supply a link to Robert’s post on this subject.

Enjoy!

Conversely, administering some common advanced performance tactics targeted at your specific usage can upgrade performance metrics to well above acceptable standards.

More coming soon.

1. Installation of a new mobile client and connecting using an existing client account.
2. General information backup to protect information loss.
3. Periodic or on-demand publishing of client approved information to the “cloud” for information sharing.  An example is advertisement services that base their marketing efforts on user attributes, e.g., user profile definition or actual user usage statistics.

NOTE:  #3 is beyond the scope of this discussion and is left to the reader to adapt and enhance this more general server-side backup-restore process.

Some quick examples of these are the following.

1. New mobile client installation, a.k.a., I bought a new smartphone and I want to install the same apps I had on my previous smartphone, but require that all of my information be imported (retrievable) as well.
2. General information backup/restore, a.k.a., my information is important to me, thus I require a way to backup/restore my information.
3. Publishing of client approved information to the “cloud”. This is beyond the scope of our discussion, but this use case illustrates a potential feature that could benefit from the actual information transfer involved in this process.

Overview

I’m writing this post since I recently required a server-side backup-restore process for a mobile application I’m developing, and I’m betting many others can benefit from this discussion, including the example client and server-side code.  Android is my target mobile platform and ASP.NET MVC, using RESTful services is my server-side platform of choice.

Design

For this exercise, I will create a file of json serialized records at the client.  Each record represents one business entity, e.g., address record, contact record, note record, etc…

A RESTful service accepts the file, the version of the user records, and the user’s Id, and stores the file on the server appropriately named to associate it to the user.

NOTE:  Another option for storing records on the server, is to store them as key-value pairs, suitable for storage into a document repository such as mongodb.

Client Side:  The UserRecords Entity

The UserRecords is a self-contained entity that actually does most of the work for us.  It is a full-fledged business object and DTO.  We will start with the basics, and develop more as we go along.  Our primary properties are as follows:

public class UserRecords {
    public long UserId = -1;
    public byte[] UserRecords = null;
    public String RecordVersion = "1.0";

    public UserRecords() {
    }
}

More coming soon!

1) Saturation of wireless carriers’ networks resulting in decreased throughput, a.k.a., s-l-o-w network.

2) And the second is the increase in speed of processors powering our mobile devices to over 1Gz and quickly rising.

More coming soon!

With that said, I’m very upset at the prospect of being required to purchasing another two-year contract with a wireless carrier in order to have wireless data services, aka, data plan. PCWorld has an interesting article on this found here.

You ask, what choices do you really have? The first that comes to mind is Tethering. The second is to purchase a Wi-Fi only tablet when available, thus not requiring a data plan.

Let’s look at the Pros and Cons of owning both a Smartphone and Tablet.

Pros

You will be able to have two slightly different, slightly similar devices to choose from depending on your immediate needs. For example, smartphones are more compact than tablets.

Maybe we will start using the actual “phone” feature on our smartphones again. And do more reading, typing, and gaming on our tablets.

Cons

You may have to buy two separate data plans, similar to the 2-year agreements we’re currently accustomed to.

Now you will own two quickly obsoleting devices.

You will have to learn how to use two different devices. Of course, if both are Android platforms, you should really have no, or very little ramp up time learning to use your devices.

The Future – How I would like to see Industry Accommodate the Consumer

I’ve had this discussion with a dozen or so folks. I want to purchase a powerfully equipped smartphone, complete with phone and data plans, and be able to purchase “touchscreen-only” tablets that come in a variety of sizes, e.g., 7″, 10″, etc,… that cost no more than $99 AND providing a docking mechanism for my smartphone.

In this way, my smartphone provides the CPU, memory, and power supply for the “touchscreen-only” tablet. And me, as a consumer, am not required to purchase a separate data plan for my tablet.  How cool is that!

Additionally, I am free to by “touchscreen-only” tablets as often as I choose, since they are relatively cheap at around $99 each.  I’m betting that the market will flood with a variety of tablets, and consumers will want to buy-and-try these at will.

I am really interested in everyone’s thoughts on this, and am sincerely asking that you comment on this idea.

I hope you find this interesting and innovative. Remember, we are in the infant stage of all things mobile, and we will see lots of innovation and changes in the coming months. 

Developing the “Places In My Proximity” Android Service

More coming soon!

Developing the “Retailer Rewards” Class – a POJO Requesting Campaign Details from the “Retailer Campaign” Server-side RESTful Service

More coming soon!

Developing the “Consumer Settings Activity” and Supporting XML Configuration Files

More coming soon!

Developing the “Rewards Notification” Class

More coming soon!

Developing the “Display Retailer Reward Activity” Class

More coming soon!