Finally – we have XPages in Bluemix. It is currently “Experimental” which means nothing is guaranteed to function as expected, it is basically a good Alpha made available to early adopters for testing. This means that at any time, things could change. The model, the process, the everything. So while there is much to learn, much to play with….
This is absolutely 100% NOT production ready
Here are the links to the documentation
- Building apps with the IBM XPages for Bluemix runtime
- Getting started with IBM XPages NoSQL Database for Bluemix
- The new OpenNTF ExtLib release
There is a lot to cover and I know a number of people are looking at it. XPages exists in Bluemix as two completely separate entities.
- The XPages runtime based on JSF
- The XPages NoSQL data store
Why are they not one NSF like normal??
Tony McGuckin explained it all to me in Orlando back In January. It was one of those surreal conversations where everything he said made sense as it came out of his mouth and yet at the end of the conversation I knew nothing more than – oooo that makes sense………and I am clearly now more stupid than I was 20 minutes ago. Hopefully he will be able to better explain to us some day.
So here is what I think I understood – it is to do with the way that Cloud Foundry underpins Bluemix. The runtime container which is running on top of Bluemix has to be able to run without the NoSQL data piece. For the sake of uptime failover, scaling and other fundamental aspects of Cloud Foundry I don’t entirely understand, they are separate. A side aspect of this means that the runtime is not dependent on the Notes NSF structure to create applications.
As normal – I have way more questions than answers – so let’s get rocking 🙂
Xomino 
Probably the biggest reason the 2 are separate has to do with being able to scale the application. If you want to scale your application horizontally (ie have more than 1 instance running with a load balancer infront of it) than you dont want each instance to have a separate copy of the DB. Now normally this is not a big deal for Domino apps as Domino has this nice feature called replication that will replicate data between all the DBs. Will consider the case where you are scaling your applicaiton because the application layer is the part that needs to be scaled not the DB layer. There is no need to scale the DB as well. I am also sure exposing the replication configuration in a PaaS environment would be a challenge as well.
I also think the separation of the DB and the application runtime is a good thing as it opens you up to using other DBs at the persistence layer rather than always using an NSF.
thanks Ryan. Someone should talk about that at a conference 😉