DivConq has just released an introductory presentation covering the JSON-Like data structures used within DivConq Framework.
Download PDF or View on SlideShare.
The presentation covers:
1) JSON Compatibility
2) Creating data structures
3) Accessing data structures
4) Use of dcSchema for data validation
DivConq has just released an introductory presentation on Stored Procedure use within DivConq Framework.
Download Power Point or View on SlideShare.
The presentation covers:
1) how DivConq connects to MUMPS
2) how to create a request
3) the request-response flow
4) Java example code
5) schema example declaration
6) MUMPS example code
7) JSON and interoperability
In Part One of this series we got to see some simple examples of M code being used as Stored Procedures from Java. We saw that how Stored Procedures are named and how to use the name to call it from Java or from the M command prompt.
Part two will cover a deeper example that involves storing and reading data in a M Global – similar to how you may end up using the Stored Procedures feature your applications. In the process we’ll cover in more detail how to write the M code, how to declare the procedure in dcSchema, how to call from Java and how to process the return values.
Today we released DivConq Framework 0.4.5 to introduce “dcTables” a new feature which supplements the benefits of stored procedures. Download.
As you know, the main purpose of our open-source DivConq Framework is to let Java developers quickly harness the power of MUMPS-compatible “NoSQL” databases. To fully harness that power you need to code stored procedures in MUMPS. But sometimes you just need something *like* a relational table, and why should you have to code that?
At DivConq we say you can have your cake and eat it too. With dcDb you get the power, flexibility and speed of NoSQL when coding stored procedures in MUMPS. But, with dcTables you get the rapid development and ease of use of relational databases too. Furthermore, all your data – dcDb and dcTables – can reside in one database. Easy to administer (setup, backup and restore) and very helpful for developers. Your stored procedures can access not only your NoSQL (dcDb) data but also your dcTables data – all in the same routine using only standard MUMPS commands. For those occasions when data in NoSQL refers to data dcTables (or vice versa) nothing beats the convenience and speed of having all your data in one place.
In this series we’ll review how to write stored procedures, both for querying data and for updating data. We’ll be using the stored procedures from the dcTest Package mentioned in the previous post on getting connected.
To follow this post you’ll need to have DivConq downloaded and configured, see Getting Connected with DivConq. You’ll also need a working knowledge of M, at least the concepts covered up through Introduction to MUMPS part 3.
The main purpose of our open-source DivConq Framework is to let Java developers quickly harness the power of MUMPS-compatible “NoSQL” databases. The real power of MUMPS comes not just from its flexible data structures, but in a large part from its stored procedures. To that end, DivConq Framework provides a reasonably easy and intuitive approach to utilize MUMPS stored procedures.
In the MUMPS world the stored procedures are call MUMPS routines, but for those coming from a SQL background just think “rich language for stored procedure coding”. MUMPS (M) has a rich ability for working with data structures not often found in SQL or NoSQL solutions. To learn more about coding MUMPS routines look to our Introduction to MUMPS series on this site.
This post will guide you through setting up your M and Java environments and testing connectivity.
In part one of this series I presented a summary of how the DivConq database connector for M (MUMPS) will work. Then we covered how to install M (GT.M software) and how to get to the M prompt.
In part two of this series I presented a review of the basics of the M programming language.
In this third part we’ll examine how data is persisted in M why the M programming language is well suited to data access.
Jonathan Lampe and Andy White will be presenting “Next Generation Web Servers” at the popular IT-oriented Pecha Kucha Happy Hour at the University of Wisconsin today. This presentation format will involve 20 slides, each only displayed for 20 seconds, and will quickly cover Nginx, Jetty, Kayak and lighttp’s roles as logical replacements for IIS and Apache in elastic architecture.
If you cannot see this presentation in person, you may want to view an earlier recording of this topic here, or read the original “Web Server Threading Models” article.
By now you’ve been deluged by advertising extolling the benefits of cloud computing: use only what you need, scale up or scale down and take advantage of widely, someday geographically, distributed computers and networks.
However, two simple facts often get swept under the rug:
1) Most cloud providers are trying to lock you in to their stack of application and data providers.
Amazon provides an application stack (EC2 and more) and data stack (S3, SimpleDB, etc.) that isn’t compatible with Microsoft’s application stack (.NET w/ Azure) and data stack (SQL Azure, etc.), and neither are compatible with other clouds such as those from IBM, Google and others.
When you develop an application for a specific stack of cloud application and cloud data storage infrastructure, you tie yourself to the viability and good behavior (pricing, availability, etc.) of that specific, nonportable technology.
2) When you scale up/down you do so at the prices your cloud provider sets.
Unless you are a high-usage customer of a particular vendor’s cloud services you will have little ability to negotiate a price with your cloud. Even if you are a high-usage customer, your leverage to negotiate will be significantly reduced by the fact that you will be heavily dependent on (locked in by) the application and data stack of you cloud provider.
Developing Cloud Portable Applications
Make no mistake: cloud computing IS an important movement and companies and developers need to start taking advantage of it NOW. However, there are technologies and architectures you can use to protect yourself from cloud lock-in. By developing on cross-platform, cloud-ready technologies like Cassandra, Nginx and lighttp rather than the proprietary technologies offered directly by cloud vendors, you gain the ability to:
1) pick up and move your critical applications if you current cloud provider fails to meet its service level agreement (SLA)
2) shop around for price and put pressure on your cloud provider to give you discounts on your hosted services
3) host simultaneously on multiple clouds or your own equipment for the exactly the right combination of worldwide availability and price for your enterprise
DivConq Provides A Bridge to Cloud Portability
In our founding post, we dedicated ourselves to technology discussions that involved “highly distributed, heterogeneous systems”. If you solve that challenge, and two or more of your systems are clouds, you’ve effectively solved cloud portability. Please stay tuned as we continue to explore and explain the generation of technology that will bridge the cloud portability gap.
Well…I have to admit that I am a bit of a fan of Frank Capra’s work.
In my roles as a solution architect or network auditor I have seen or written thousands of network and software architecture diagrams. I’m probably not the first person to note the visual similarity to between groups of rectangular technologies standing on either side of a “DMZ” and diagrams of great military battles fought before CRTs.
The name of this site is, in part, an homage to Frank Capra’s 1943 (US) propaganda film entitled “Why We Fight: Divide and Conquer.”
The logo is similarly inspired by the well-animated diagrams in that movie that simplify complex military movements. In particular, this animated diagram about 45 minutes in:
…which paid off the entire premise of the movie. (Divided entities were individually isolated and then conquered by a calculating foe. )
