Oracle Adapter Vs Use of Datasource for Data acesss in CAPS 6

I am looking for pros & cons of using Oracle Adapter over a simple Java style data source for a purpose for data access in an EJB service in Non-repository based JCAPS 6 project. Because I am not sure if the built-in adapter is providing any special feature for doing so.

Thanks Mark for the response.
But I don't think use of Oracle OTD out of JCAPS repository will save me from much coding. Though it gives you good IDE like eclipse.

Frankly, being an EAI guy for long time, I don't like to do coding for these kind of things which could be achieved simply by adapters. But JCAPS 6 doesn't leave you a choice because except BPEL2.0 everything here is java coding.
If we want to move out of Seebeyond repository then JCAPS 6 leaves you crawling in the code even if you want to develop a simple application which could read from a file & insert into database.
When most of the EAI technologies (webMethods etc.) are moving forward with GUI development languages, JCAPS 6 is asking us to write java code. And I am pretty sure that it is going increase the development time.

i personally disagree as much as i can to your post. whenver i am "disabled" though some gui elements thatare not really efficient i am really feeling lost. i personally have tried WM gui as well as TIBCO and i REALLY hated the grphical elements in almost all cases.
1 exception
DATA OTDs such as custom file or XML
those designers are great and would really be vey hard to code...

i would love if SUN would give us the freedom even in repo based approaches to just fetch the jdbc connection from the DB otd and do sometimes plain SQL sometimes prep statements etc etc ...
e.g. reading out connection params and so forth.

Hey Chris,
Though you disagree, I agree with few of your points. I agree that somethimes GUI based develpment tools comes with some limitations but I never found them a road block. The biggest strengths of those tools are Less time in development & easy maintenance which definately doesn't come when you r going to do plane java coding. You may disagree with that.
And you can always have the plain SQL statements in the adapter service (in wM) or OTDs (in JCAPS). You also have the facility of getting a connection from DB otd.But I am not very big fan of plain coding. I don't want to code something which could be provided as a packaged component & I could customize it as per my need. That's why I love Development platform of webMethods.
Now why I don't like JCAPS 6 when I want to work on out of Repository is because:
Though I can use adapters as I do to create OTD, I can't edit & update (if there are some changes in table itself) it as I could do in repository based projects.
I have to keep track of so many fields (150 in one of my oracle table) in coding which could be easier in GUI based development if I had been doing repository based development.

For external connectivity you can use eWays in Repository based projects, JCA Adaptors in Java EE, JDO JPA etc.. in Java EE or POJO, and of course Binding Components in JBI.

For business logic you have BPEL2, XSLT, JAVA EE(EJBs) POJOs and CAMEL (some of these I accept have not made it to JavaCAPS6 but cna be tried now and will be supported in the future)

Most of these things can be mixed and matched, all give differing levels of tooling and granularity.

Then the question becomes "which do I use" - well, its down to experience in the end - I will be giving a presentation at next weeks Horizons event in Europe on exactly this topic, it will be recorded and available on the Java CAPS Wiki thereafter - you might want to take a look.

One of the criticisms of previous versions of JavaCAPS is that too much functionality was hidden away under the covers, developers wanted the option of taking control of this - now they can - we cater for both use-cases.

So in a nutshell, JavaCAPS6 is not expecting you to write Java code - "file to DB" - why not use BPEL or XSLT (both graphical mapping) with Binding components, even check out Camel-SE as an alternative.

If you are doing a simple File-In and DB-out integration, it really depends if you want do something with the data in-between.

In addition to what Mark mentioned you have other options:
- If you want to do nothing, then you can use a direct FileBC to DatabaseBC connection.- If you want the data in the file to take part in a JavaEE application then you can use JavaEE JPA to persist the data.

It is clear that the JBI technology in CAPS6 has been more focussed on Service Oriented solutions. There are still the JCA adaptors for pure EAI solutions but, as you say, the tooling could do more to reduce the amount of coding. Its a known issue and Sun is working on an approach called IntegrationFlowLanguage to solve the problem. Its an EAI domain specific language with GUI front-end to quickly solve simple problems like you mention.