IPC method to use

[tech02]

Hi, We are developing a CF app which is to allow a mobile device to query
data on a remote
server via a custom API over http (as opposed to SQL server, Web service).
The mobile
device will store the data locally on SQL CE database. We have decided to
put the business logic in a separate process. This will query, get data from
server and update the database.

The UI is to be in a separate process so as to allow potentially differrent
UI's to access the business logic. But we were wondering how best to do the
IPC from UI to business logic on
CF. Anyone got any ideas?



__________ Information from ESET Smart Security, version of virus signature database 4078 (20090515) __________

The message was checked by ESET Smart Security.

http://www.eset.com

 

[Paul G. Tobey [eMVP]]

Tell us what communication you need. If all you need to do is notify the UI
that something, anything has changed, a simple named event would be fine.

Paul T.

 

[Paul G. Tobey [eMVP]]

Tell us what communication you need. If all you need to do is notify the UI
that something, anything has changed, a simple named event would be fine.

Paul T.

 

[tech02]

Thanks Paul, well we need to read the data from the local sql ce 3.5
database in to objects, these are
going to be serialized and then we send this database data back to the UI
same the other way. Data wont be massive but could be few hundred K.
We are using CF 2.0 and Vs2008 for development.

As the engine code could be accessed by one more than one process it needs
to be
doen using some IPC

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:%[email protected]...

 

[tech02]

Thanks Paul, well we need to read the data from the local sql ce 3.5
database in to objects, these are
going to be serialized and then we send this database data back to the UI
same the other way. Data wont be massive but could be few hundred K.
We are using CF 2.0 and Vs2008 for development.

As the engine code could be accessed by one more than one process it needs
to be
doen using some IPC

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:%[email protected]...

 

[Chris Tacke, eMVP]

I'd probably use a P2P message queue.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

Thanks Paul, well we need to read the data from the local sql ce 3.5
database in to objects, these are
going to be serialized and then we send this database data back to the UI
same the other way. Data wont be massive but could be few hundred K.
We are using CF 2.0 and Vs2008 for development.

As the engine code could be accessed by one more than one process it needs
to be
doen using some IPC

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:%[email protected]...

Tell us what communication you need. If all you need to do is notify the
UI that something, anything has changed, a simple named event would be
fine.

Paul T.

 

[Chris Tacke, eMVP]

I'd probably use a P2P message queue.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

Thanks Paul, well we need to read the data from the local sql ce 3.5
database in to objects, these are
going to be serialized and then we send this database data back to the UI
same the other way. Data wont be massive but could be few hundred K.
We are using CF 2.0 and Vs2008 for development.

As the engine code could be accessed by one more than one process it needs
to be
doen using some IPC

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:%[email protected]...

Tell us what communication you need. If all you need to do is notify the
UI that something, anything has changed, a simple named event would be
fine.

Paul T.

 

[Paul G. Tobey [eMVP]]

Why? That seems like a bad idea. Why put a garden hose between the
database data and the UI? It seems like having two clients for the same
database, one the business logic process, if you like, and one showing the
UI, makes more sense. This allows the UI code to properly take advantage of
its knowledge about the data store to get good performance and, maybe, limit
the amount of data that it has to get from the database. If you want to
have these 'objects' be the representation of the data at run-time for the
UI application, foregoing the advantage of having the UI application limit
how much data it gets, if it doesn't want all of the details, you can still
build a layer on top of the database access in the UI application to create
those objects from what's in the database.

You could prototype a point-to-point message queue and just see how long
serializing and deserializing all of your data is going to take. I wouldn't
assume that all will be well and build my whole application around P2P
message queues without running those tests on the target hardware, though.

Paul T.

Thanks Paul, well we need to read the data from the local sql ce 3.5
database in to objects, these are
going to be serialized and then we send this database data back to the UI
same the other way. Data wont be massive but could be few hundred K.
We are using CF 2.0 and Vs2008 for development.

As the engine code could be accessed by one more than one process it needs
to be
doen using some IPC

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:%[email protected]...

Tell us what communication you need. If all you need to do is notify the
UI that something, anything has changed, a simple named event would be
fine.

Paul T.

 

[Paul G. Tobey [eMVP]]

Why? That seems like a bad idea. Why put a garden hose between the
database data and the UI? It seems like having two clients for the same
database, one the business logic process, if you like, and one showing the
UI, makes more sense. This allows the UI code to properly take advantage of
its knowledge about the data store to get good performance and, maybe, limit
the amount of data that it has to get from the database. If you want to
have these 'objects' be the representation of the data at run-time for the
UI application, foregoing the advantage of having the UI application limit
how much data it gets, if it doesn't want all of the details, you can still
build a layer on top of the database access in the UI application to create
those objects from what's in the database.

You could prototype a point-to-point message queue and just see how long
serializing and deserializing all of your data is going to take. I wouldn't
assume that all will be well and build my whole application around P2P
message queues without running those tests on the target hardware, though.

Paul T.

Thanks Paul, well we need to read the data from the local sql ce 3.5
database in to objects, these are
going to be serialized and then we send this database data back to the UI
same the other way. Data wont be massive but could be few hundred K.
We are using CF 2.0 and Vs2008 for development.

As the engine code could be accessed by one more than one process it needs
to be
doen using some IPC

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:%[email protected]...

Tell us what communication you need. If all you need to do is notify the
UI that something, anything has changed, a simple named event would be
fine.

Paul T.

 

[tech02]

Thanks Paul, im not sure if i was clear but we need the UI in a separate
process to the database, as there is a requirement for the engine to be
accessed
by more than one UI application (third party ones possibly).

We will prototype as you suggested. One thing we weren't sure of though if
the
engine process has been killed off for some reason whats the best way to
handle
this scenario, where the UI has lots its IPC partner, do we need to
continously
monitor if its still there and restart it if isnt or is there some event
that will inform if
a process has been shut down, im thinking off low memory scenarios where the
OS will close stuff.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:eF20l9%[email protected]...

Why? That seems like a bad idea. Why put a garden hose between the
database data and the UI? It seems like having two clients for the same
database, one the business logic process, if you like, and one showing the
UI, makes more sense. This allows the UI code to properly take advantage
of its knowledge about the data store to get good performance and, maybe,
limit the amount of data that it has to get from the database. If you
want to have these 'objects' be the representation of the data at run-time
for the UI application, foregoing the advantage of having the UI
application limit how much data it gets, if it doesn't want all of the
details, you can still build a layer on top of the database access in the
UI application to create those objects from what's in the database.

You could prototype a point-to-point message queue and just see how long
serializing and deserializing all of your data is going to take. I
wouldn't assume that all will be well and build my whole application
around P2P message queues without running those tests on the target
hardware, though.

Paul T.

Thanks Paul, well we need to read the data from the local sql ce 3.5
database in to objects, these are
going to be serialized and then we send this database data back to the
UI
same the other way. Data wont be massive but could be few hundred K.
We are using CF 2.0 and Vs2008 for development.

As the engine code could be accessed by one more than one process it
needs to be
doen using some IPC

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message news:%[email protected]...

Tell us what communication you need. If all you need to do is notify
the UI that something, anything has changed, a simple named event would
be fine.

Paul T.

Hi, We are developing a CF app which is to allow a mobile device to
query data on a remote
server via a custom API over http (as opposed to SQL server, Web
service). The mobile
device will store the data locally on SQL CE database. We have decided
to put the business logic in a separate process. This will query, get
data from server and update the database.

The UI is to be in a separate process so as to allow potentially
differrent UI's to access the business logic. But we were wondering
how best to do the IPC from UI to business logic on
CF. Anyone got any ideas?


__________ Information from ESET Smart Security, version of virus
signature database 4078 (20090515) __________

The message was checked by ESET Smart Security.

http://www.eset.com

 

[tech02]

Thanks Paul, im not sure if i was clear but we need the UI in a separate
process to the database, as there is a requirement for the engine to be
accessed
by more than one UI application (third party ones possibly).

We will prototype as you suggested. One thing we weren't sure of though if
the
engine process has been killed off for some reason whats the best way to
handle
this scenario, where the UI has lots its IPC partner, do we need to
continously
monitor if its still there and restart it if isnt or is there some event
that will inform if
a process has been shut down, im thinking off low memory scenarios where the
OS will close stuff.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:eF20l9%[email protected]...

Why? That seems like a bad idea. Why put a garden hose between the
database data and the UI? It seems like having two clients for the same
database, one the business logic process, if you like, and one showing the
UI, makes more sense. This allows the UI code to properly take advantage
of its knowledge about the data store to get good performance and, maybe,
limit the amount of data that it has to get from the database. If you
want to have these 'objects' be the representation of the data at run-time
for the UI application, foregoing the advantage of having the UI
application limit how much data it gets, if it doesn't want all of the
details, you can still build a layer on top of the database access in the
UI application to create those objects from what's in the database.

You could prototype a point-to-point message queue and just see how long
serializing and deserializing all of your data is going to take. I
wouldn't assume that all will be well and build my whole application
around P2P message queues without running those tests on the target
hardware, though.

Paul T.

Thanks Paul, well we need to read the data from the local sql ce 3.5
database in to objects, these are
going to be serialized and then we send this database data back to the
UI
same the other way. Data wont be massive but could be few hundred K.
We are using CF 2.0 and Vs2008 for development.

As the engine code could be accessed by one more than one process it
needs to be
doen using some IPC

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message news:%[email protected]...

Tell us what communication you need. If all you need to do is notify
the UI that something, anything has changed, a simple named event would
be fine.

Paul T.

Hi, We are developing a CF app which is to allow a mobile device to
query data on a remote
server via a custom API over http (as opposed to SQL server, Web
service). The mobile
device will store the data locally on SQL CE database. We have decided
to put the business logic in a separate process. This will query, get
data from server and update the database.

The UI is to be in a separate process so as to allow potentially
differrent UI's to access the business logic. But we were wondering
how best to do the IPC from UI to business logic on
CF. Anyone got any ideas?


__________ Information from ESET Smart Security, version of virus
signature database 4078 (20090515) __________

The message was checked by ESET Smart Security.

http://www.eset.com

 

[Paul G. Tobey [eMVP]]

I don't think that will be a problem with SQL Compact Edition 3.5sp1. I'm
sitting here with three applications running on my device, all with the same
database open, inserting and querying the data.

Paul T.

Thanks Paul, im not sure if i was clear but we need the UI in a separate
process to the database, as there is a requirement for the engine to be
accessed
by more than one UI application (third party ones possibly).

We will prototype as you suggested. One thing we weren't sure of though if
the
engine process has been killed off for some reason whats the best way to
handle
this scenario, where the UI has lots its IPC partner, do we need to
continously
monitor if its still there and restart it if isnt or is there some event
that will inform if
a process has been shut down, im thinking off low memory scenarios where
the
OS will close stuff.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:eF20l9%[email protected]...

Why? That seems like a bad idea. Why put a garden hose between the
database data and the UI? It seems like having two clients for the same
database, one the business logic process, if you like, and one showing
the UI, makes more sense. This allows the UI code to properly take
advantage of its knowledge about the data store to get good performance
and, maybe, limit the amount of data that it has to get from the
database. If you want to have these 'objects' be the representation of
the data at run-time for the UI application, foregoing the advantage of
having the UI application limit how much data it gets, if it doesn't want
all of the details, you can still build a layer on top of the database
access in the UI application to create those objects from what's in the
database.

You could prototype a point-to-point message queue and just see how long
serializing and deserializing all of your data is going to take. I
wouldn't assume that all will be well and build my whole application
around P2P message queues without running those tests on the target
hardware, though.

Paul T.

Thanks Paul, well we need to read the data from the local sql ce 3.5
database in to objects, these are
going to be serialized and then we send this database data back to the
UI
same the other way. Data wont be massive but could be few hundred K.
We are using CF 2.0 and Vs2008 for development.

As the engine code could be accessed by one more than one process it
needs to be
doen using some IPC

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message
Tell us what communication you need. If all you need to do is notify
the UI that something, anything has changed, a simple named event would
be fine.

Paul T.

Hi, We are developing a CF app which is to allow a mobile device to
query data on a remote
server via a custom API over http (as opposed to SQL server, Web
service). The mobile
device will store the data locally on SQL CE database. We have
decided to put the business logic in a separate process. This will
query, get data from server and update the database.

The UI is to be in a separate process so as to allow potentially
differrent UI's to access the business logic. But we were wondering
how best to do the IPC from UI to business logic on
CF. Anyone got any ideas?


__________ Information from ESET Smart Security, version of virus
signature database 4078 (20090515) __________

The message was checked by ESET Smart Security.

http://www.eset.com

 

[Paul G. Tobey [eMVP]]

I don't think that will be a problem with SQL Compact Edition 3.5sp1. I'm
sitting here with three applications running on my device, all with the same
database open, inserting and querying the data.

Paul T.

Thanks Paul, im not sure if i was clear but we need the UI in a separate
process to the database, as there is a requirement for the engine to be
accessed
by more than one UI application (third party ones possibly).

We will prototype as you suggested. One thing we weren't sure of though if
the
engine process has been killed off for some reason whats the best way to
handle
this scenario, where the UI has lots its IPC partner, do we need to
continously
monitor if its still there and restart it if isnt or is there some event
that will inform if
a process has been shut down, im thinking off low memory scenarios where
the
OS will close stuff.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:eF20l9%[email protected]...

Why? That seems like a bad idea. Why put a garden hose between the
database data and the UI? It seems like having two clients for the same
database, one the business logic process, if you like, and one showing
the UI, makes more sense. This allows the UI code to properly take
advantage of its knowledge about the data store to get good performance
and, maybe, limit the amount of data that it has to get from the
database. If you want to have these 'objects' be the representation of
the data at run-time for the UI application, foregoing the advantage of
having the UI application limit how much data it gets, if it doesn't want
all of the details, you can still build a layer on top of the database
access in the UI application to create those objects from what's in the
database.

You could prototype a point-to-point message queue and just see how long
serializing and deserializing all of your data is going to take. I
wouldn't assume that all will be well and build my whole application
around P2P message queues without running those tests on the target
hardware, though.

Paul T.

Thanks Paul, well we need to read the data from the local sql ce 3.5
database in to objects, these are
going to be serialized and then we send this database data back to the
UI
same the other way. Data wont be massive but could be few hundred K.
We are using CF 2.0 and Vs2008 for development.

As the engine code could be accessed by one more than one process it
needs to be
doen using some IPC

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message
Tell us what communication you need. If all you need to do is notify
the UI that something, anything has changed, a simple named event would
be fine.

Paul T.

Hi, We are developing a CF app which is to allow a mobile device to
query data on a remote
server via a custom API over http (as opposed to SQL server, Web
service). The mobile
device will store the data locally on SQL CE database. We have
decided to put the business logic in a separate process. This will
query, get data from server and update the database.

The UI is to be in a separate process so as to allow potentially
differrent UI's to access the business logic. But we were wondering
how best to do the IPC from UI to business logic on
CF. Anyone got any ideas?


__________ Information from ESET Smart Security, version of virus
signature database 4078 (20090515) __________

The message was checked by ESET Smart Security.

http://www.eset.com

 

[tech02]

Ok you have a point, didn't realise this. Where do you place your database
file
when its shared by so many apps in the root or something.

We can then have just the code to do the HTTP access of the backend server
in the engine
process but we need to know if the engine process has died, can we be
signalled in
any way?

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:%[email protected]...

I don't think that will be a problem with SQL Compact Edition 3.5sp1. I'm
sitting here with three applications running on my device, all with the
same database open, inserting and querying the data.

Paul T.

Thanks Paul, im not sure if i was clear but we need the UI in a separate
process to the database, as there is a requirement for the engine to be
accessed
by more than one UI application (third party ones possibly).

We will prototype as you suggested. One thing we weren't sure of though
if the
engine process has been killed off for some reason whats the best way to
handle
this scenario, where the UI has lots its IPC partner, do we need to
continously
monitor if its still there and restart it if isnt or is there some event
that will inform if
a process has been shut down, im thinking off low memory scenarios where
the
OS will close stuff.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message news:eF20l9%[email protected]...

Why? That seems like a bad idea. Why put a garden hose between the
database data and the UI? It seems like having two clients for the same
database, one the business logic process, if you like, and one showing
the UI, makes more sense. This allows the UI code to properly take
advantage of its knowledge about the data store to get good performance
and, maybe, limit the amount of data that it has to get from the
database. If you want to have these 'objects' be the representation of
the data at run-time for the UI application, foregoing the advantage of
having the UI application limit how much data it gets, if it doesn't
want all of the details, you can still build a layer on top of the
database access in the UI application to create those objects from
what's in the database.

You could prototype a point-to-point message queue and just see how long
serializing and deserializing all of your data is going to take. I
wouldn't assume that all will be well and build my whole application
around P2P message queues without running those tests on the target
hardware, though.

Paul T.

Thanks Paul, well we need to read the data from the local sql ce 3.5
database in to objects, these are
going to be serialized and then we send this database data back to the
UI
same the other way. Data wont be massive but could be few hundred K.
We are using CF 2.0 and Vs2008 for development.

As the engine code could be accessed by one more than one process it
needs to be
doen using some IPC

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message
Tell us what communication you need. If all you need to do is notify
the UI that something, anything has changed, a simple named event
would be fine.

Paul T.

Hi, We are developing a CF app which is to allow a mobile device to
query data on a remote
server via a custom API over http (as opposed to SQL server, Web
service). The mobile
device will store the data locally on SQL CE database. We have
decided to put the business logic in a separate process. This will
query, get data from server and update the database.

The UI is to be in a separate process so as to allow potentially
differrent UI's to access the business logic. But we were wondering
how best to do the IPC from UI to business logic on
CF. Anyone got any ideas?


__________ Information from ESET Smart Security, version of virus
signature database 4078 (20090515) __________

The message was checked by ESET Smart Security.

http://www.eset.com

 

[tech02]

Ok you have a point, didn't realise this. Where do you place your database
file
when its shared by so many apps in the root or something.

We can then have just the code to do the HTTP access of the backend server
in the engine
process but we need to know if the engine process has died, can we be
signalled in
any way?

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:%[email protected]...

I don't think that will be a problem with SQL Compact Edition 3.5sp1. I'm
sitting here with three applications running on my device, all with the
same database open, inserting and querying the data.

Paul T.

Thanks Paul, im not sure if i was clear but we need the UI in a separate
process to the database, as there is a requirement for the engine to be
accessed
by more than one UI application (third party ones possibly).

We will prototype as you suggested. One thing we weren't sure of though
if the
engine process has been killed off for some reason whats the best way to
handle
this scenario, where the UI has lots its IPC partner, do we need to
continously
monitor if its still there and restart it if isnt or is there some event
that will inform if
a process has been shut down, im thinking off low memory scenarios where
the
OS will close stuff.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message news:eF20l9%[email protected]...

Why? That seems like a bad idea. Why put a garden hose between the
database data and the UI? It seems like having two clients for the same
database, one the business logic process, if you like, and one showing
the UI, makes more sense. This allows the UI code to properly take
advantage of its knowledge about the data store to get good performance
and, maybe, limit the amount of data that it has to get from the
database. If you want to have these 'objects' be the representation of
the data at run-time for the UI application, foregoing the advantage of
having the UI application limit how much data it gets, if it doesn't
want all of the details, you can still build a layer on top of the
database access in the UI application to create those objects from
what's in the database.

You could prototype a point-to-point message queue and just see how long
serializing and deserializing all of your data is going to take. I
wouldn't assume that all will be well and build my whole application
around P2P message queues without running those tests on the target
hardware, though.

Paul T.

Thanks Paul, well we need to read the data from the local sql ce 3.5
database in to objects, these are
going to be serialized and then we send this database data back to the
UI
same the other way. Data wont be massive but could be few hundred K.
We are using CF 2.0 and Vs2008 for development.

As the engine code could be accessed by one more than one process it
needs to be
doen using some IPC

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message
Tell us what communication you need. If all you need to do is notify
the UI that something, anything has changed, a simple named event
would be fine.

Paul T.

Hi, We are developing a CF app which is to allow a mobile device to
query data on a remote
server via a custom API over http (as opposed to SQL server, Web
service). The mobile
device will store the data locally on SQL CE database. We have
decided to put the business logic in a separate process. This will
query, get data from server and update the database.

The UI is to be in a separate process so as to allow potentially
differrent UI's to access the business logic. But we were wondering
how best to do the IPC from UI to business logic on
CF. Anyone got any ideas?


__________ Information from ESET Smart Security, version of virus
signature database 4078 (20090515) __________

The message was checked by ESET Smart Security.

http://www.eset.com

 

[Paul G. Tobey [eMVP]]

You can put it anywhere you want. As long as they all agree on where it
goes, it doesn't matter. I'd choose a built-in location, if there's enough
free storage, since you don't, in that case, have to worry about handling
the case of the user ejecting the storage card while you're trying to use
it. The test programs that I wrote just to verify that, as I thought,
3.5SP1 would handle multiple simultaneous clients, put it in the root, where
it's on a flash filesystem, yes.

You need a handle to the process that you want to detect the dieing of. You
can get that easily if you happen to be the one starting it, since creating
the process returns its handle. If you wait on that handle, it will be
signaled, just like an event, when the process exits. Otherwise, you'd have
to P/Invoke, probably, to OpenProcess(), after figuring out the process ID
you want, probably using ToolHelp to enumerate the processes.

I wouldn't make the UI process responsible for the back-end process's
health. I think that's backwards. Spend a lot of time on the stability of
the back-end process with the intent of preventing it from ever crashing on
a functional system (if the hardware fails, there's nothing you can do to
force an application to be reliable).

Paul T.

Ok you have a point, didn't realise this. Where do you place your database
file
when its shared by so many apps in the root or something.

We can then have just the code to do the HTTP access of the backend server
in the engine
process but we need to know if the engine process has died, can we be
signalled in
any way?

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:%[email protected]...

I don't think that will be a problem with SQL Compact Edition 3.5sp1. I'm
sitting here with three applications running on my device, all with the
same database open, inserting and querying the data.

Paul T.

Thanks Paul, im not sure if i was clear but we need the UI in a separate
process to the database, as there is a requirement for the engine to be
accessed
by more than one UI application (third party ones possibly).

We will prototype as you suggested. One thing we weren't sure of though
if the
engine process has been killed off for some reason whats the best way to
handle
this scenario, where the UI has lots its IPC partner, do we need to
continously
monitor if its still there and restart it if isnt or is there some event
that will inform if
a process has been shut down, im thinking off low memory scenarios where
the
OS will close stuff.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message
Why? That seems like a bad idea. Why put a garden hose between the
database data and the UI? It seems like having two clients for the
same database, one the business logic process, if you like, and one
showing the UI, makes more sense. This allows the UI code to properly
take advantage of its knowledge about the data store to get good
performance and, maybe, limit the amount of data that it has to get
from the database. If you want to have these 'objects' be the
representation of the data at run-time for the UI application,
foregoing the advantage of having the UI application limit how much
data it gets, if it doesn't want all of the details, you can still
build a layer on top of the database access in the UI application to
create those objects from what's in the database.

You could prototype a point-to-point message queue and just see how
long serializing and deserializing all of your data is going to take.
I wouldn't assume that all will be well and build my whole application
around P2P message queues without running those tests on the target
hardware, though.

Paul T.

Thanks Paul, well we need to read the data from the local sql ce 3.5
database in to objects, these are
going to be serialized and then we send this database data back to
the UI
same the other way. Data wont be massive but could be few hundred K.
We are using CF 2.0 and Vs2008 for development.

As the engine code could be accessed by one more than one process it
needs to be
doen using some IPC

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message
Tell us what communication you need. If all you need to do is notify
the UI that something, anything has changed, a simple named event
would be fine.

Paul T.

Hi, We are developing a CF app which is to allow a mobile device to
query data on a remote
server via a custom API over http (as opposed to SQL server, Web
service). The mobile
device will store the data locally on SQL CE database. We have
decided to put the business logic in a separate process. This will
query, get data from server and update the database.

The UI is to be in a separate process so as to allow potentially
differrent UI's to access the business logic. But we were wondering
how best to do the IPC from UI to business logic on
CF. Anyone got any ideas?


__________ Information from ESET Smart Security, version of virus
signature database 4078 (20090515) __________

The message was checked by ESET Smart Security.

http://www.eset.com

 

[Paul G. Tobey [eMVP]]

You can put it anywhere you want. As long as they all agree on where it
goes, it doesn't matter. I'd choose a built-in location, if there's enough
free storage, since you don't, in that case, have to worry about handling
the case of the user ejecting the storage card while you're trying to use
it. The test programs that I wrote just to verify that, as I thought,
3.5SP1 would handle multiple simultaneous clients, put it in the root, where
it's on a flash filesystem, yes.

You need a handle to the process that you want to detect the dieing of. You
can get that easily if you happen to be the one starting it, since creating
the process returns its handle. If you wait on that handle, it will be
signaled, just like an event, when the process exits. Otherwise, you'd have
to P/Invoke, probably, to OpenProcess(), after figuring out the process ID
you want, probably using ToolHelp to enumerate the processes.

I wouldn't make the UI process responsible for the back-end process's
health. I think that's backwards. Spend a lot of time on the stability of
the back-end process with the intent of preventing it from ever crashing on
a functional system (if the hardware fails, there's nothing you can do to
force an application to be reliable).

Paul T.

Ok you have a point, didn't realise this. Where do you place your database
file
when its shared by so many apps in the root or something.

We can then have just the code to do the HTTP access of the backend server
in the engine
process but we need to know if the engine process has died, can we be
signalled in
any way?

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:%[email protected]...

I don't think that will be a problem with SQL Compact Edition 3.5sp1. I'm
sitting here with three applications running on my device, all with the
same database open, inserting and querying the data.

Paul T.

Thanks Paul, im not sure if i was clear but we need the UI in a separate
process to the database, as there is a requirement for the engine to be
accessed
by more than one UI application (third party ones possibly).

We will prototype as you suggested. One thing we weren't sure of though
if the
engine process has been killed off for some reason whats the best way to
handle
this scenario, where the UI has lots its IPC partner, do we need to
continously
monitor if its still there and restart it if isnt or is there some event
that will inform if
a process has been shut down, im thinking off low memory scenarios where
the
OS will close stuff.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message
Why? That seems like a bad idea. Why put a garden hose between the
database data and the UI? It seems like having two clients for the
same database, one the business logic process, if you like, and one
showing the UI, makes more sense. This allows the UI code to properly
take advantage of its knowledge about the data store to get good
performance and, maybe, limit the amount of data that it has to get
from the database. If you want to have these 'objects' be the
representation of the data at run-time for the UI application,
foregoing the advantage of having the UI application limit how much
data it gets, if it doesn't want all of the details, you can still
build a layer on top of the database access in the UI application to
create those objects from what's in the database.

You could prototype a point-to-point message queue and just see how
long serializing and deserializing all of your data is going to take.
I wouldn't assume that all will be well and build my whole application
around P2P message queues without running those tests on the target
hardware, though.

Paul T.

Thanks Paul, well we need to read the data from the local sql ce 3.5
database in to objects, these are
going to be serialized and then we send this database data back to
the UI
same the other way. Data wont be massive but could be few hundred K.
We are using CF 2.0 and Vs2008 for development.

As the engine code could be accessed by one more than one process it
needs to be
doen using some IPC

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message
Tell us what communication you need. If all you need to do is notify
the UI that something, anything has changed, a simple named event
would be fine.

Paul T.

Hi, We are developing a CF app which is to allow a mobile device to
query data on a remote
server via a custom API over http (as opposed to SQL server, Web
service). The mobile
device will store the data locally on SQL CE database. We have
decided to put the business logic in a separate process. This will
query, get data from server and update the database.

The UI is to be in a separate process so as to allow potentially
differrent UI's to access the business logic. But we were wondering
how best to do the IPC from UI to business logic on
CF. Anyone got any ideas?


__________ Information from ESET Smart Security, version of virus
signature database 4078 (20090515) __________

The message was checked by ESET Smart Security.

http://www.eset.com