Pick applications are traditionally deployed to a single server and
accessed by LAN users. Most Pick developers who extend their reach to
the rest of the world still route all requests through a single web
server and back to a single database server. This is a many-to-one
topology.

Let's compare that to Facebook or Twitter where all users are remote,
and software and data are distributed across a number of systems to
ensure that all requests are satisfied with minimal failure being
reported back to the user. This is a many-to-many topology. Data
syncs must be coordinated to keep data servers fresh. Failure of any
data server should not result in data loss or interrupt updates of
others. Not only must data be redundant, but requests for data must
also be managed so that a backup node can satisfy a request if the
original system processing the request fails.

When we WRITE an item in Pick, it's assumed that the item is being
stored locally. In a distributed topology that operation must trigger
a similar transaction to multiple systems in case any one system
fails. Related updates over a network must be bracketed in a
transaction to preclude partial updates on failure.

In short, in an effective distributed topology, we need to be able to
pull the plug on several nodes without end-users knowing anything has
happened.

I'm building such an environment over D3 but the tools to do this
aren't built into the DBMS. This will be hosted with Amazon,
eventually scaling to several dozen servers (dynamically if possible)
depending on volume. I'm keeping the code as platform-agnostic as
possible and have an open mind to shifting platforms for licensing and
technical benefits.

Does anyone else have experience with creating this topology with any
MV DBMS? Has anyone shifted to alternative technologies (or lost
business) because (supposedly) Pick doesn't do that?

Which MV environments natively allow implementation of this sort of
architecture at the DBMS level? I welcome DBMS Sales / Marketing /
Technical people to brag about product capabilities - and if possible
to cite examples of companies actually doing this. Feel free to
contact me off-list if required.

Thanks!
T

Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Nebula R&D sells mv.NET and other Pick/MultiValue products
worldwide, and provides related development services
remove.pleaseNebula-RnD.com/blog
Visit PickWiki.com! Contribute!
http://Twitter.com/TonyGravagno

On Jul 1, 3:19*pm, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid> wrote:
Tony,

Take a look at ECP (Enterprise cache protocol) which comes with Caché.
There are some massive sites using this to horizontally scale mission
critical enterprise applications Check out the case studies on the
InterSystems website for more details. I suggest you start off with
the Credit Suisse case study.

Regards

Jon

Jon wrote:
Thanks Jon. I will certainly be looking into this aspect of Caché.
I'm wondering if the MV extensions allow us to make use of that core
functionality. I know MV files are mapped over globals but there are
places where those mappings don't provide the same freedom as one has
with COS. I don't want to have to go down the route of "conversion"
into Caché using fully defined classes, etc. The application code I
have over this infrastructure is very platform-independent and I want
to keep it that way until we find a seriously compelling reason to get
real cozy with any one vendor.

Regards,
T

Pick is a fine product that makes development
easy, routine ad-hoc research pleasant, and
unexpected situations by-and-large manageable.
In fact, it may be overbuilt for your sort of project.

You'll effectively have a smallish pool of 'users'
briefly connected with your pick box, and they
are much more predictable and competant
than human users; you can add bulletproofing
against all the most common problem
situations, without end-users lobbying against you
{security and convenience are implacable foes.}
And you don't really need the ability to
rapidly develop new applications, or do ad-hoc
trouble analysis on an oddly-performing database.
Oh, and reports; Pick is light-years beyond what
you'll need in the way of printed reports.

Even if Pick isn't beyond your needs for your quality
overall cloud project, you have to wonder just how
bad the non-pick choices could be; after all,
cloud users have relatively low perfomance
expectations; many websites don't mind leaving
their pages drastically impaired for an hour or two
in the wee hours of each morning, or a department
store chain fudges in their catalog listings and says
'oh, that product has no fixed price listed here, and
price differs by store. In fact some stores may have
a different product' or a small business just laughs
it off when their internet provider won't connect them
to the internet for several dozen hours each month
due to recurring but expensive-to-prevent incidents
in the region.

On 7/3/11 10:37 AM, Frank Winans wrote:
I didn't see a smiley face after this, so it would
appear that you're serious...!?

--
frosty

"frosty" wrote
keeping all the various cloud nodes in hot syncronisation,
not to whatever software application you might write that
actually goes and _uses_ that Borg-like 'collective.'
From that more limited standpoint, yes, I think having Pick's
reporting ability versus, say, DOS's, is overkill to service
and maintain it. If any one office in the cloud needs more
smarts for the people-interface stuff, then by all means, buy
them a pick license and use the cloud-thingie as we now use
unix /tmp or windows c:\pickstuff directories, for scratch
pad storage of both working files and select lists,
or for a sort of limited offsite database replication. Other
nodes may be tasked with data archiving or automated sensor
collection, and won't need much pizazz. Sorry about that.

frosty wrote:
I was kinda wondering that through his whole posting.

Seriously now: I know the capabilities of the DBMS. That's not in
question. And I'm not concerned about basing a distributed
architecture on the MV platform. But the classic Pick environment
simply wasn't designed for this. An app needs to be designed at a low
level to operate like this. I'm just trying to figure out how much of
that I need to code manually, and exactly how far the MV DBMS vendors
have really progressed in doing this for us at an even lower level.

If I had to guess, I'd think the better recommendations are going to
point to the following platforms in the following order and for the
following reasons:

Caché - experience in this area, solid engineering, good pricing
Reality - improved communications, not sure about specifics
Universe - big systems experience, not much faith for cloud
jBase - versatile, closer to OS level, cloud experienced?
QM - solid technology, good pricing, no cloud experience
OpenInsight - no clue, doesn't seem like a fit

I can make D3 do whatever I want. It's a capable platform and in my
comfort zone. But the cost can be prohibitive, and it's just another
platform when it comes to doing something new like this. If I don't
need to spend time writing networking infrastructure I'd like to avoid
it.

I'm just looking for technical feedback on each platform from anyone
who has some experience in this area. ... Yeah, the precious few...

Thanks.
T

Tony,

If you are starting with a green field development in terms of an
application, then you have a better chance than if you were starting
with an existing application, primarily because from what I've seen of
existing applications, the vast majority of them don't operate with
the notion of transaction bracketing, which I assume would be a
requirement?

The whole notion of serializing discrete updates to transactions (even
when the "transaction" is a change of address details) is foreign to
most mv developers I believe, and if you are looking at a truely
distributed/scaleable model, then the conflict resolution strategy
would be "interesting", especially if the "end users" of the final
solution have not IT skills, so you ae likly to have to fall back to
some automated rules to fit many/most scenarios

We have used the low level framework within our Visage DRS product for
"simple" replication, but the scope of what you may be contemplating
could be a couple of orders of magnitude greater (unless you are
willing to acept "lossy" data in the event of a node failure ....
hmmm, though I could see a possibility for overcoming this, poviding
data had been transmitted to at least one other node assuming a mesh
style network)

Good luck on the journey .... but if you build it, who will come (and
pay thy bills)?

On Jul 2, 7:58*pm, Jon <jonmpa... (AT) gmail (DOT) com> wrote:
Tony,

Additionally for Caché you have database level mirroring with fail
over. This coupled with ECP can give you a true high-availability
option at a lower cost than many similarly featured systems. Also the
Amazon cloud offering is a supported platform.

If you are interested in doing any proof-of-concept let me know.

Rich Taylor