SQL reference bindings can satisfy the query service requirement unless you need to accept arbitrary SQL to execute at runtime. Of course, there are other things to worry about if you are arbitrarily executing SQL at runtime.
For the update service, you could use SQL as well.
Sort of depends on what you need to do in the enrichment service. If you have a good idea how the enrichment logic can be broken down into independent service calls, then I would model it and then look to see how each call maps to a binding and what the data objects look like. If it's unclear what the service view would be, then start with Java code and then take a step back and see if the code would benefit from being broken out into discrete services.
Thanks for your answer. The key thing is that these kind of services often benefict from caching, whether is from the JPA provider or a first level cache provided via ISPN/JBDG. I wouldn't like to be hitting the database for every request if it is not necessary.
I think that probably doing everything in a Java Component and only using SwitchYard to expose this services is a better pattern than using Database as a reference service.
Of course, this assertion depends on the desired goal of simplicity against performance.
In fact, I don't see any benefit of doing this service in SwitchYard. Maybe doing this service as an WS/EJB and accesing through SwitchYard if you need things like, transformation, throttling, rtGovernance,...