The first thing I would review is whether or not you really need a Java service. Chances are, you do not. Thus, you likely can have a FLOW service that does the work it needs, which then invokes a JDBC adapter service. This would be the preferred approach, unless you absolutely must use Java to do what is needed (highly unlikely–at a minimum the part that needs to be Java can probably be reduced greatly in scope).
Another approach is to use the Service.doInvoke method within your Java service to call a JDBC adapter service. You can review the Java API docs from Developer under Help | Java API Reference.
Your Java service can accept the name of the adapter service to invoke, and if you pass through the pipeline, then you won’t need to explicitly read the inputs or write the outputs–but the service that calls your Java service will need to put the right vars in the pipeline, call your service, then assume which output vars are present (based on the JDBC service signature).
Can you elaborate on what your service needs to do? Perhaps you’re pursuing a solution path that is more difficult than it needs to be.
#Adapters-and-E-Standards#webMethods#Integration-Server-and-ESB