Java Reference
In-Depth Information
Figure 10.17
Trying to buy some foreign food—part 1
Figure 10.18
Trying to buy some foreign food—part 2
Oh dear. Clearly there's something wrong here; your purchase should be able to pro-
ceed, but it fails. The reason for this is simple, and it has to do with your database. You
may remember that you've been using a local, in-memory database. Hopefully, you'll
remember that you copied your datasource bundle into both the local and the remote
framework. Doing this did let you get up and running more quickly, but it also created
a second copy of your database, which definitely isn't good for your application!
Fortunately, the fix for this situation is simple. You need to build a new version of your
datasource bundle that speaks to a remote database, rather than creating a local one.
10.5.1
Setting up your remote database connections
A huge number of powerful, scalable, network-enabled database implementations
exist, any one of which would be more than capable of handling your new require-
ments. For simplicity you'll stick with the Apache Derby database, but you should feel
free to use another if you fancy an extra challenge.
Setting up datasources for a remote Derby instance will require some changes to the
Blueprint for your datasource bundle. Because there's no code in your datasource bun-
dle, it's nontrivial to say what the new version of your datasource bundle should be. Our
view is that moving the database to a remote machine, making it possible for a number
of clients to concurrently share access, and making the database persistent is a major
change, and therefore warrants an increment to the major version of the bundle.
The changes to your Blueprint are simple. You can leave the
service
elements
untouched; what you need to do is to make some changes to the beans that they refer-
ence. In listing 10.6, you can see that all you need to do is to change the implementation
class of your beans and supply some additional properties to indicate where your Derby
