Hi guys,

I'm trying to figure out if we can integrate webORB into our existing code base which is heavily reliant upon the entity framework.

We need to be able to implement a data management service which lets us use our own DAO and models, much like LiveCycle Data Services offers with it's Data Management Service. I've been dissecting the code that is generated by WDMF in an attempt to piece together the mechanics of how your data management system works and I think I've got a pretty firm grasp upon what is going on. Unfortunately, it seems like it's setup to communicate with SQL directly and there is no way around that.

We have three requirements:
1. We MUST be able to use our entity framework DAO to perform CRUD operations
2. We MUST be able to synchronize a set of objects between connected clients
3. We need to be able to communicate with the service from both Flex and C# clients

To accomplish this we need to be able to extend the TDataMapper class to utilize the synchronization methods and the raiseAffected method, but not require it to communicate with the database directly

Is this possible at all? If not, is there another solution you can offer to manage a set of data and synchronize the clients connected?

We are still in the testing stage of webORB and as such this is the real make or break component for us at the moment for whether or not we will commit to this product. LiveCycle DataServices is out of our budget, but there are many open source solutions we can use in lieu of that. The problem with those solutions is they only really work with flex clients, and we need to be able to implement C# clients as well. You guys seem very promising for that, but if you are requiring that we communicate using SQLConnections we can't justify moving to this platform...

Microsoft's entity framework

I did some further research into what it is we are trying to accomplish and basically we want to be able to utilize the client synchronization aspects that remote shared objects offer, while maintaining the strongly typed aspects of data management...I have a feeling I'm looking for some happy median that might not be available haha

If we have to, we can fall back on RSOs I think, it's just not ideal because it appears that all of the data is stored in memory on the server side and some of our lists can get extremely lengthy (such as our timesheet management system which has 100,000+ records for the last few years)