couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Stanhope <stanh...@gmail.com>
Subject Re: A Call to Arms: Fighting the SharePoint/SQL Mobile Development Stack
Date Mon, 18 Apr 2011 14:28:18 GMT
I'd avoid getting stuck in the .NET is bad thinking. SharePoint and Dynamics
both have very rich WS-* compliant APIs in front of their data tier.

Having built apps that do exactly what the user scenarios are I think it's
best to think through a couple of points about data and potential for
concurrent updates.

1. The technician scenario inherently avoid many concurrency problems
because each technician ONLY gets their tickets. They have access to nobody
else's -- they are on a spoke.

2. The manager of the technicians has a view to all tickets and time a
ticket is opened. Some sort of data crumb needs to be left at time of ticket
"checkout" such that a conflict can be dealt with if, upon return (e.g.
technician got in a car accident and another technician was dispatched),
that any attempt to update the ticket is denied and manual reconcilation can
occur.

3. Because the backend stack has all sorts of HTTP(S) accessible web
services ... the client can be completely agnostic as to backend data store
and backend (SharePoint/Dynamics) presentation of the data form the hub's
perspective.

4. CouchDB can solve a significant part of the problem if it's used as the
temporary activity store. Data is copied out from SharePoint/Dynamics into a
master CouchDB database. Then Couch's ability to replicate shards (specific
technician's data) is used. Couch is used to manage conflicts on document
updates. Document update hooks at the hub are then used to push completed
tickets back into the main data depots.

The more that you can construct the dataflows such that it's truely hub and
spoke with human behavior enforcing the data update cycles ... the less
likely that any conflicts will ever occur in the first place.

This model has been proven time and time again against Lotus Notes and
similar partial replica synchronized systems for the past 25+ years.

The system can never be ACID ... but so what. Decrease the likelihood of
conflict in the first place ... and put the conflict resolution of the hands
of the few people who can resolve the conflict by manual intervention at the
point in time that it happens / is discovered.


On Mon, Apr 18, 2011 at 9:30 AM, Jason Lane <jasonlanexml@googlemail.com>wrote:

> On 18 April 2011 13:53, Chad Cross <chadcross@gmail.com> wrote:
>
> > It's encouraging that you were able to propose that sort of solution at
> > such
> > a company.
> >
> > I have a surprise meeting in 4 hours to discuss "solutions".  I think
> this
> > may be an admittance that SharePoint is not the right solution for what
> we
> > want, but unfortunately I don't have much of anything to show in such a
> > short period of time.
> >
> > Here is the basic usage scenario:
> >
> >   1. Technican approaches downloads building information/ticket
> information
> >   to his/her mobile for a service request.
> >   2. Technican enters building and no longer has connectivity to the
> remote
> >   server
> >   3. Technican enters data on their mobile about the work they've
> completed
> >   (assuming this is HTML/JS based, the local data store could be used to
> >   temporarily store this data?)
> >
>
> Absolutely. This is another are I have worked on. especially if the devices
> are iOS / Android HTML5 is a given
>
>
> >   4. Technican returns to coverage area and needs to send their data back
> >   to the remote server (by all accounts we have to create our own
> conflict
> >   resolution system if the records the Technican wishes to update have
> been
> >   updated while they were out of coverage)
> >
> > I'm sure this is small potatoes for the community at large to explain to
> > one
> > another, but what's the proper way to discuss this with peers/superiors
> > that
> > are completely stuck in a .NET mindset?
> >
>
> Technological debt!
>
>
> >
> > Thanks everyone!
> >
> > -Chad
> >
> > On Fri, Apr 15, 2011 at 3:08 PM, Jason Lane <jasonlanexml@googlemail.com
> > >wrote:
> >
> > > Why don't you look at non-blocking architecture throughout the stack.
> I'd
> > > recommend looking at Couchdb & Nodejs. I gave a presentation at work
> > > recently on concurrent, non-blocking, event based architectures at my
> > work.
> > > I work for Thomsonreuters, big lumbering corporation that it is.
> > >
> > > sent from my Nexus S
> > > On Apr 15, 2011 1:58 PM, "Chad Cross" <chadcross@gmail.com> wrote:
> > > > All,
> > > >
> > > > I'm in the middle of what could be a very interesting opportunity for
> > my
> > > > company and I'm in need of assistance.
> > > >
> > > > Our accounting system, Microsoft Dynamics SL, is central to
> everything
> > we
> > > > do. Right now we have a need for a mobile app that interacts with a
> > very
> > > > small subset of data stored in this system. Currently, others in my
> > tiny
> > > IT
> > > > department are pushing hard and evaluating a solution that involves
> > > > SharePoint 2010 (which we already own) for hosting, InfoPath for form
> > > > creation, and 3rd party wrappers that allow the "application" to be
> > > accessed
> > > > via Android, Windows Mobile 6.5, and iOS. Those wrappers include
> Mobile
> > > > Entree <http://www.mobileentree.com/>,
> > > > SharePlus<http://www.southlabs.com/detail.aspx?id=SharePlus>,
> > > > and others that they discover every day.
> > > >
> > > > Their biggest concern is concurrency. The idea that a service
> > technician
> > > > could be in the field and interacting with the software to pull down
> > > > information about a specific trouble ticket, walk into an area
> without
> > > > coverage, and still be able to input data. When they return to
> > coverage,
> > > > the app should handle pushing that data back to the database without
> > > > encountering concurrency issues.
> > > >
> > > > I'm sure some of you have experience battling suits when it comes to
> > > > proposing alternative solutions (and in my case, "alternative" means
> > > > non-Microsoft), so I would like for anyone that has experience with
> > > CouchDB
> > > > and MS-SQL interaction to please chime in!
> > > >
> > > > Thanks!
> > > >
> > > > -Chad
> > > >
> > > > P.S. For you Twitter users, please retweet!
> > > > https://twitter.com/#!/TheChadCross/status/58871610505039872
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message