Discussions

News: New Struts-based Toy Store Sample App from Oracle

  1. Oracle announces the availability of the Struts-based ADF Toy Store Demo sample application. It is accompanied by a detailed technical whitepaper that explains all of the interesting details of the Struts and Oracle ADF framework features used in its implementation.

    The ADF Toy Store Demo is an MVC-based web storefront application, implemented using best-practices J2EE design patterns, that fully leverages the developer-productivity boost that framework and framework-savvy visual tools can provide. It uses:

     -> Apache Struts for the controller layer
     -> JSP/JSTL for the view layer
     -> Oracle Application Development Framework (ADF) for the model layer

    The Oracle ADF framework's capabilities for simplifying end-to-end J2EE application development are used daily by over 2000 developers in the Oracle E-Business Suite team, as well as by hundreds of external customers. ADF's data binding layer is an early implementation of the declarative data binding facilities proposed in JSR-227.

    As part of explaining the implementation details, the whitepaper illustrates the rich set of features provided by the Oracle JDeveloper 10g IDE for working with the Struts and ADF frameworks using productive visual, declarative, and code-level tools.

    The demo can be deployed to Tomcat, Oracle Application Server, Oracle OC4J Standalone, or other J2EE-compliant application server.

    Threaded Messages (48)

  2. I was expecting something new and different, but this demo looks EXACTLY like the petstore demo. 5 categories, same interface features, same depth (category, product, item), same cart, same, same, same. Even the front page image map looks the same (5 categories surrounding a central image).

    Were we just sick of the pets or what? ;-)

    Cheers,
    Clinton
  3. atleast the code is provided[ Go to top ]

    could be worse, they could have said, "sorry, no source code. just take our word for it".
  4. Pretty useful, but...[ Go to top ]

    I found this demo and whitepaper to be really useful for trying to understand the ADF framework (there aren't very many good examples out there, nor is there good documentation, maybe because its so new). But it is missing an interface to administer the toy store, which I would've liked to see. I am currently trying to use the ADF framework for a project, we are having problems figuring out how to implement things like security and would like to see a more complex example dealing with issues like that.
  5. Is it just me, or is this the scariest Pet Store (read "Toy Store") to date?

    I don't own Oracle JDeveloper 10g, so reading through this code is an absolute nightmare. This starts into the first point: vendor lock in. At least in the case of Microsoft .Net we were locked in because it was a proprietary product (fine). In the case of "Toy Store", Oracle has taken a portable language (Java) and generic specifications (J2EE), and they've made certain that you will never be able to use it outside of an Oracle tool set. 71 of the 81 java files import oracle.* packages. If I'm going to be locked into a vendor, I might as well choose Microsoft .Net --at least it was designed for lock-in. ;-)

    Lock-in might not be too bad if the framework/tool was otherwise non-intrusive, which brings us to the second point: generated code. 49 of the 81 java files claim "File generated by Oracle Business Components for Java". Incidentally, JPetStore only has 40 Java files, so most of the Toy Store Java files are likely a result of generated framework code. Many of these files contain ominous warnings like "Generated method. Do not modify", and everyone's favorite: "//--[Begin Custom Code]--" and it's little friend "//--[End Custom Code]--". Generated code isn't always bad. Perhaps if it retains its readability, maintainability, portability etc. But in the case of Toy Store, you get this beauty:

    // Generated method. Do not modify.
    protected void setAttrInvokeAccessor(int index, Object value, AttributeDefImpl attrDef) throws Exception
      {
        switch (index)
          {
          case CATID:
            setCatid((String)value);
            return;
          case NAME:
            setName((String)value);
            return;
          case DESCN:
            setDescn((String)value);
            return;
          default:
            super.setAttrInvokeAccessor(index, value, attrDef);
            return;
          }
    }

    This case statement grows linearly with the number of properties on your business object. The OrdersImpl has 27 properties and therefore it's switch statement has 27 cases. But of course you need an getAttrInvokeAccessor to match the setAttrInvokeAccessor above, so you get not one but TWO of these beauties. If I'm going to generate anything, it will be configuration via XDoclet, not Java code via an IDE. This brings us to out next point: lines of code.

    I won't even mention the java source, despite my disappointment that there is still more Java code in this Toy Store than ANY version of JPetStore. Instead, I'll mention the utter shock I experienced when I saw that there was 2 lines of XML generated for every line of Java code. If these are design/code, or build time only XML to support the IDE, then my only complaint is that they shouldn't be in the /src directories. Otherwise, if my application depends on these, then my complaint becomes my typical complaint of: it's too much. There are 7563 lines of XML beside 4143 lines of Java code. Effort to create the application is one thing, but the effort to maintain it is another. Am I to trust that future versions Oracle JDeveloper 10g will maintain backward compatibility even just for 5 years? I'll extend my complaint in saying that generated code is NEVER as flexible as is required for real world projects, so tweaking by hand immediately becomes an issue. If I'm going to have to maintain legacy code 5 years from now, I'll do it with something that was designed to be coded by hand like any version of Hibernate or iBATIS.

    I guess in my opinion this Toy Store example is the worst of both worlds. It abuses the benefits of Java by eliminating the value proposition of portability and vendor independence. Meanwhile, it does nothing to improve the maintainability of the code. I would also say that it offers very little innovation to improve the design of the application. I'm also a bit skeptical as to why Oracle would build around BC4J instead of TopLink. TopLink is very flexible, portable, fairly non-intrusive and is probably more productive (even without generated code).

    Maybe it's just me. Have a look at the code to see if you agree.

    Cheers,

    Clinton Begin
    http://www.ibatis.com
  6. As I undestand it is designed for fast and dirty applications with very short life cycle (a few months). You do not need and you can not to maintain this kind of code, just drop it and implement a new one with new framework version.
  7. Short Lifecycle Applications[ Go to top ]

    As I undestand it is designed for fast and dirty applications with very short life cycle (a few months). You do not need and you can not to maintain this kind of code, just drop it and implement a new one with new framework version.
    This reminds me of my very FIRST application I wrote as a professional software developer after graduating. As a young punk right out of school, I was given the tiny little projects that were "too small" for anyone important to do. Furthermore, there was no chance that my employer was going to spend any great deal of time or ANY money whatsoever on these types of projects. So I was given the following toolset:

      * A retired Macintosh 75xx series computer (server!)
      * FileMaker Pro (ARRRGH the flashbacks!)
      * BlueWorld Lasso (the only fun part)
      * I was given 20 days to write the app
      * Upper management refused to pay for anything else

    The app I wrote was only to be used fo 6 months before it was supposed to be replaced by a 3rd party vendor product that was up for selection. The application was web based and had only 6 users. These users were distributed accross canada.

    When month 6 arrived, no vendor had been selected. Many more users were expecting a tool to use, and mine was the only one available (and it was snazzy if I do say so myself). Unfortunately the infrastructure choices were very limited. We were locked in to legacy products that were no longer standard to the company. The first question from upper management: "Why can't we scale this to N users?" Second question: "Why can't we store all of our XXXXX data in this system?" Third question: "Why won't it run on our standard $3 Million Big Iron boxes?".

    This crappy little mac/filemaker app lasted in some form for nearly two years, it was eventually exported to an excel spreadsheet before being used to populate the database for a properly architected J2EE application.

    PS: I'm not comparing this architecture to ADF. I'm only sharing the story of a "6 month" application lifecycle.

    Cheers,
    Clinton
  8. Short Lifecycle Applications[ Go to top ]

    Yes, this kind of stories is not something new for me too.
    Do you remember pragmatic data storage formats and year 2000 :)
  9. Clinton,

    The demo is patterned closely after the original Pet Store demo to make it easier for Java developers to understand the difference between a framework-based J2EE design patterns approach and a hand-coded J2EE design patterns approach. For obvious legal reasons, we don't use any of the Sun copyrighted artwork from the original Pet Store demo, but since you recognized the demo as similar to the petstore, our design approach had it intended effect of feeling familiar to you.

    The ADF Toy Store Demo and whitepaper is about understanding the developer productivity that a framework-based J2EE application approach can provide you. You apparently simply did a code/XML line count without appreciating which bits of those codes and XML are maintained for you by the visual tooling environment.

    Your comments focus on the components in the toystore.model.* package with your observations about generated code and XML. The only lines of code that were required to be written by a developer to implement the non-default functionality were the lines that fall between the:

    //--[Begin Custom Code]--

    and

    //--[End Custom Code]--

    which were added for instructional purposes so the developer reading the whitepaper could understand what code was added to support application-specific behavior and which was maintained code by the tool.

    Subtracting out the numerous lines of comments, and keeping in mind that as a sample application several parts of the demo include alternative implementations that show off different implementation techniques, there are 385 lines of custom Java code in the model layer (toystore.model.*), none of it related to persistence.

    Furthermore, a closer look at the code than you apparently have given it before writing your reply reveals that the generated code outside of these lines of custom code is mostly typesafe accessor code. This is required because ADF components can also work based solely on XML metadata if no developer customizations are required (and if the developer isn't interested in typesafe accessors).

    Oracle ADF uses best-practice techniques advocated by Rod Johnson in his "J2EE Design and Development" book (and implemented in other J2EE frameworks like Spring) to implement framework components as lightweight Java objects, constructed via factories, configured from XML metadata. All of the XML metadata (both for Struts and ADF artefacts) is handled by the visual design tool environment in JDeveloper 10g. Or, if desired, you can edit/generate the XML manually in compliance with its DTD/Schema via other techniques if one prefers.

    The block of generated code you chose to highlight with the switch statement for attribute getters is a performance-enhancing code-generation that JDeveloper maintains for you to avoid any runtime introspection for attribute access.

    I think that after reading the whitepaper, and following along with the visual developer productivity examples in JDeveloper that highlight the various aspects of its Struts and ADF implementation, you might have a different opinion that then one you've expressed here.

    If not, then as the original creator of IBATIS SQL Maps, your unwavering opinion about Oracle ADF would surely be understandable. As an Oracle employee and someone who works with and helps users understand the technical benefits of the Oracle JDeveloper 10g IDE and Oracle ADF J2EE framework for Java application development, readers will undoubtedly understand the origin of my point of view as well. :-)

    I'd also like to address your comment that, "I'm also a bit skeptical as to why Oracle would build around BC4J instead of TopLink." We definitely could have, as Oracle ADF's declarative data binding layer works with business services implemented in any back-end technology: POJO's (mapped with TopLink or mapped using third-party mapping technology if you choose), EJB's, Web Services, ADF Business Components, and others.

    The demo illustrates the selection of technology choices that we provide that delivers the most amount of pre-built application-building functionality for J2EE developers building business applications. It's the same set of technologies that over 2000 developers in Oracle Applications, and hundreds of external customers, use in building their applications (both with web and Swing interfaces). However, Oracle ADF and JDeveloper 10g themselves leave your technology choices open, and JDeveloper 10g provides rich, integrated support for performing TopLink mapping as well. The functionality of the former standalone TopLink Mapping Workbench is now integrated into JDeveloper in the 10g release.

    Our ADF Business Components layer is typically the one developers pick who want to leverage the most built-in application-building functionality. If developers prefer to code their own Java business objects, which they might do in order to derive their business layer components from custom application framework components that they already built themselves, and map their Java objects to database tables using TopLink, then JDeveloper 10g and Oracle ADF framework support that persistence approach as well.

    NOTE: When our ADF Faces JSF-compliant functionality that we demoed this year at JavaOne 2004 goes production, we'll update the demo to use a JSF front end as well.

    I hope J2EE developers (or .NET developers interested in J2EE) give the demo a spin inside Oracle JDeveloper 10g along with the whitepaper and consider it in the overall context of developer productivity and use this experience to draw their own conclusions on whether this approach might be useful for their next J2EE app.
  10. Thanks for your response Steve.
    You apparently simply did a code/XML line count without appreciating which bits of those codes and XML are maintained for you by the visual tooling environment.
    Absolutely! If the code is in my /src directory, and it's unique to my application, then it gets counted. Code is code, is code, is code. (IMHO)
    the generated code outside of these lines of custom code is mostly typesafe accessor code
    Perhaps I don't understand. Please explain what is _not_ typesafe about this accessor(from a JPetStore business object):

      public Product getProduct() {
        return product;
      }
    Oracle ADF uses best-practice techniques advocated by Rod Johnson in his "J2EE Design and Development" book (and implemented in other J2EE frameworks like Spring)
    So perhaps we should use spring then? After all, it's not bound to any IDE, it doesn't need as much XML (generated or not), and it's not only advocated by Rod Johnson, it's partially written by him. It seems like a pretty good value proposition given his book, the great documentation, developer support, the $0 price tag and yet another Pet Store demo. ;-)
    I think that after reading the whitepaper, and following along with the visual developer productivity examples in JDeveloper that highlight the various aspects of its Struts and ADF implementation, you might have a different opinion that then one you've expressed here.
    So my fears are confirmed then? Is this code useless without an expensive IDE and a 100+ page white paper?
    If not, then as the original creator of IBATIS SQL Maps, your unwavering opinion about Oracle ADF would surely be understandable.
    I don't know that iBATIS has anything to do with it. What does matter (I admit) is that I have a fundamental belief that:

      1) Code generation (beyond one-time generation, like getter/setter gen) is not in the best interests of developers.

      2) Binding to any vendor specific IDE (or framework used by the IDE) is not in the best interests of any organization.
    I hope J2EE developers (or .NET developers interested in J2EE) give the demo a spin inside Oracle JDeveloper 10g along with the whitepaper and consider it in the overall context of developer productivity and use this experience to draw their own conclusions on whether this approach might be useful for their next J2EE app.
    I agree. I have to be considered biased (for iBATIS and JPetStore). I also hope developers do try JDeveloper, and read the white paper.

    But I hope they also read the code.

    Cheers,
    Clinton
  11. J2EE Means Lots of Choices[ Go to top ]

    Clinton,

    Thanks for the followup. I definitely Rod's J2EE Design and Development book, so undoubtedly Spring is worth a look, too. One of the best things about J2EE is that there are a lot of choices for developers to evaluate! Also, in honesty, it's what can make J2EE daunting for many corporate developers, too, at least from my experience.

    For developers that prefer another model-layer implementation technology over our "ADF Business Components" library, they can instead use virtually any other implementation for their model layer (including the built-in support for Oracle TopLink persistence that I mentioned above), but not limited to that.But while some Java users want maximum choice, others want maximum out-of-box functionality. We try to cater to both of these camps with different, pluggable layers in ADF. In the JDeveloper team, we're big on both productivity and choice!

    The overall Oracle ADF framework and ADF design time extensions/plugins that accompany JDeveloper can still help with JSR-227-style declarative databinding by providing visual tooling -- leveraging standard EL expressions for your data binding -- as well as Struts page flow and JSP page design (among lots of Java and XML coder-level features, too). Pick a front-end technology you want to work with, pick a back-end business service layer implementation technology. No problem. The ADF Data Binding Primer and ADF/Struts Overview whitepaper gives several simple examples of simple Java-bean-based model layers and how to work with them.

    Some developers use the JDeveloper IDE without any of our ADF framework at all, and just use it for Java coding and visually designing XML Schemas, visually doing their Struts page flow, and visually designing their JSP pages. No problem, we're cool with choice.

    So, if your preferences steer you away from any or all of our framework technologies -- in preference for no framework or another J2EE framework -- you still might want to give the JDeveloper IDE itself a spin. Just use the "Extension Manager" under Tools | Preferences... to turn off the bits you don't plan to use. If you do give it a spin, I'd be glad to get an email from you with what you like and don't like about it so we can make it even better in the next release. It's free to try, and not as expensive as you imply to buy ($995) -- $0 for the framework bits.

    If none of the above, then we can both continue to be happy that we picked the J2EE platform where we can each use the technologies that make us most productive. Take care.
  12. Clinton,

    You are absolutely right that ADF/BC4J is vendor lock-in.

    I've been working as an independent contractor on a contract on which Oracle is the prime contractor. Oracle's management has dictated that we must use BC4J for persistence, but even their own Java consultants don't understand how to use it. Nor can their own people get answers to simple, basic questions from the BC4J team (Steve Muench, Diraj Metraja, et. al.) on simple basic questions like how to get the thing to release locks. This is an enterprise level client (several million dollars), but it took 30 days to get someone from the BC4J team on the phone for a critical problem. He couldn't answer it so we had to come up with a work around.

    In spite of these problems Oracle's management treats BC4J like it is a religous doctrine that has to be followed. It keeps them locked into the project because there is no one outside of one group in Oracle who can support the thing.

    Juozas is also right that this thing is intended for quick and dirty apps. written by people with a VB mentality. Take a look at the book "Oracle9i JDeveloper Handbook" which is the book Oracle's staff wrote to explain how to use BC4J. Everything is explained through the JDeveloper GUI: "click this", "choose this", "enter this". There is no discussion of BC4J as a framework independent of JDeveloper.

    BC4J pre-dates J2EE and it shows. Its architecture screams client-server. Enhancements made to bring it up-to-date appear to be ad-hoc. There is no specification document for it. It is whatever they want it to be at any given time. The documentation can be verbose without telling you what you want to know.

    BC4J provides a very tight, very brittle coupling to the database. Any small change to the database (i.e. dropping a constraint) causes runtime Exceptions even when you don't use the affected fields. There are a host of other problems we've run into with BC4J that kill developer productivity. It expects that your schema is completely stable before you begin creating your persistence layer. Keeping the BC4J layer in synch. with any database changes requires a dedicated developer and that your DBAs provide very careful and accurate diffs with previous versions of the database. This is very high development overhead.

    I've also run some comparisons with JDBC code. For lookups BC4J takes 3 times a long as straight JDBC code. Entity creation is expensive and useless for lookups.

    And support? Forget about it.
  13. Not Everyone's Experience[ Go to top ]

    Dean,

    I'm in contact daily with Oracle Consultants and Worldwide Support folks who are experts in using our ADF framework, so offline I'd appreciate your emailing me more details about specific issues you've run into so I can chase up the details and find out what happened (steve dot muench at oracle dot com).

    You're right that while it is theoretically possible to use ADF outside of the JDeveloper IDE environment -- artefacts are *.java and *.xml files -- most customers I know use it inside JDeveloper because of the superior developer productivity offered by that environment.

    Regarding your comments about changing database schema, we provide automatic support in the tool for synchronizing your ADF business components with changes made to the database. This online help topic describes the feature, in case it might come in handy in the future.

    Also, while most customers do happen to start with an existing schema, the tool and framework don't require you to. You can design your entity object components and then forward-generate basic tables if you want, as well as use the synchronize feature described above to react to changes. Of course if you radically change the schema then some manual steps might be necessary, using object editors in JDev.

    ADF Business Components view objects can do "raw" JDBC queries for read-only lookup data as well as updateable queries that interface automatically with backend business components. It's the developer's choice. I'd recommend using read-only view objects for lookup-only queries. If you Google for "view object performance" there are some articles that help understand when to use which features for your view objects.

    Oracle ADF (and its BC4J ancestor) has grown up with J2EE and always tried to deliver a set of technologies that made J2EE-compliant application-building easier. It supports web, two-tier and three-tier Swing apps, and other architectures, not only the two-tier client/server that you suggest.

    I'm humored by the suggestions that Oracle ADF is for applications with short lifetimes. Among other customers who are happy with it, we put our money where our mouth is and use it internally as the core J2EE framework for all of our Java-based Oracle Applications, with highly-functional self-service web front ends. Other customers I know have used it to implement large ERP-style applications with a Swing rich-client front ends, some two-tier, some three-tier deployments. Oracle ADF's robustness and application-building feature-set reflect this long, positive feedback loop we are lucky to have by given our large number of demanding internal and external users.
  14. Not Everyone's Experience[ Go to top ]

    I'm humored by the suggestions that Oracle ADF is for applications with short lifetimes.
    I said it and I have a reason to say it. If most of application code depends on framework or it is generated by framework then it means application can not live longer than framework itself. There are a lot of great UI framewoks, but all of them are usefull for applications with short life cycle only. Persistence framework life cycle is very short, UI framework life cycle is even more short. I think all legacy "component oriented programming" developers can say the same too. It is dead idea, is not it ?
  15. Not Everyone's Experience[ Go to top ]

    It is out of topic, but if we are talking about oracle frameworks then I want to ask why SQLj is dead ?
  16. SQLJ not dead[ Go to top ]

    It is out of topic, but if we are talking about oracle frameworks then I want to ask why SQLj is dead ?

    Turns out Oracle decided NOT to discontinue SQLJ, so it's still alive in 10g!
  17. Dependencies[ Go to top ]

    If most of application code depends on framework or it is generated by framework then it means application can not live longer than framework itself.
    Unless I've misunderstood this statement is not only true about all frameworks (including inhouse frameworks you might build yourself!), but can be applied to any class libraries (including the JDK itself!) on which your application depends. Said another way, if your application stands on the shoulders of class library X or framework Y (commercial, open-source, inhouse, or whatever), then your application continues to depend on these libraries going forward. No argument.

    In a sense, using anyone else's code is a bet that you make to avoid having to design, debug, write, maintain, and build custom tools for it yourself. If the creator of the libraries on which you depend is a dependable organization, with a committment to upward compatibility, and significant resources to dedicate to maintaining and enhancing that library and tools to support it, then it's usually a safe bet. As customers who've been using Oracle ADF in one form or another since 1999 know, this is the category of frameworks that Oracle ADF falls into.

    These days many developers don't have the luxury or inclination to write every layer and line of their technical stack themselves, so J2EE developers are inevitably picking and choosing the "bets" that they want to make about the dependencies in their technology stack.

    I believe you are suggesting that an effective strategy is to re-evaluate the "bets" you make on frameworks and class libraries for each new project you do. That seems like good advice to insure that you're always taking into account the latest advances.

    My comment above was that having this choice is both a blessing and a curse for practitioners on the J2EE platform. Having tons of choice means that implementations compete on quality, functionality, ease of use, etc. That part is great. For many of the millions of corporate developers that Sun, BEA, Oracle, and others want to bring into the fold to further broaden the use of the J2EE platform, this choice -- and the hectic pace at which new choices come on the scene and others exit -- make J2EE seem like a busy, 10-lane superhighway to cross for less expert.

    If they haven't already written their own J2EE frameworks, some companies will want to standarize on a dependable J2EE framework from a large vendor, that will be there for the long haul, evolve to embrace the latest J2EE standards, and ideally is one that the framework vendor uses itself inhouse in a significant way. For those companies, Oracle ADF is an ideal one to put on the short list to evaluate.
  18. Dependencies[ Go to top ]

    If most of application code depends on framework or it is generated by framework then it means application can not live longer than framework itself.
    Unless I've misunderstood this statement is not only true about all frameworks (including inhouse frameworks you might build yourself!)
    Steve,

    I have an application here that was written using ADF. I don't have an Oracle JDeveloper 10g license though, and I use a different IDE. Could you help me out and send me a link to where I can download the ADF binaries, source code and documentation?

    Thanks much,

    Clinton
  19. Dependencies[ Go to top ]

    I have an application here that was written using ADF. I don't have an Oracle JDeveloper 10g license though, and I use a different IDE. Could you help me out and send me a link to where I can download the ADF binaries, source code and documentation?
    http://otn.oracle.com/products/jdev/index.html

    The ADF runtime ships with JDeveloper 10g, which has a free developer's license when you download it from OTN. You can run the demo inside JDeveloper 10g on its embedded OC4J container, or deploy it to an external J2EE web container like Tomcat, JBoss, Oracle OC4J Standalone, or others.

    The Tools | ADF Runtime Installer menu pick will help you perform the ADF runtime installation.

    The doc is also online at:
    http://helponline.oracle.com/jdeveloper/help
  20. Dependencies[ Go to top ]

    Thank you for the link. Is source code available with a license?

    Cheers,
    Clinton
  21. Dependencies[ Go to top ]

    Is source code available with a license?
    Clinton,

    We ship the source code for most of the architectural layers of Oracle ADF already in the ./BC4J/src directory and ./adfc/src directories. This basically includes the source for all client and data-binding related layers.

    As Ted Farrell commented to TheServerSide at JavaOne -- see the "From the Pavilion - Ted Farrell on Oracle's Java Tools Suite" section in their Day 4 JavaOneCoverage...
    While Oracle isn't likely to be making JDeveloper or ADF open source any time soon, Oracle will be making the source code for ADF available to anyone who wishes to read it. This meets Oracle's goal of giving their customers transparency in the tools while avoiding the complex issues involved in running an open source community.
    We're working on the details at present to be able to release the remaining ADF source code that is not already included with the product to any licensed JDeveloper/ADF customers.
  22. Dependencies[ Go to top ]

    Dependancies are not equal. If I depend on some library then I write wrapper too, it adds more code (interface), but saves time. Forkable opensource code reduces this risk too.
    BTW these days many developers don't have any problems with frameworks as it was in 1999.
  23. Dependencies[ Go to top ]

    In a sense, using anyone else's code is a bet that you make to avoid having to design, debug, write, maintain, and build custom tools for it yourself. If the creator of the libraries on which you depend is a dependable organization, with a committment to upward compatibility, and significant resources to dedicate to maintaining and enhancing that library and tools to support it, then it's usually a safe bet. As customers who've been using Oracle ADF in one form or another since 1999 know, this is the category of frameworks that Oracle ADF falls into.
    One great problem I see with Oracle ADF and its high coupling with Oracle JDeveloper is that the enhancement of the various Oracle Frameworks and the associated tool support wasn't that stable as it IMHO has to be for real world projects.

    Let's take a look at the history of the Oracle Frameworks, as fare as I remember it:

    JDeveloper 2.x: Oracle Java Buisness Objects, the first name of BC4J aka ADF Business Components. (That's the reason for the package naming oracle.jbo.*...)

    JDeveloper 3.x: Oracle BC4J plus the Data Aware Control Framework (DACF) based on Suns Infobus class library.

    JDeveloper 9i: DACF is replaced by JClient because of the deprecation of Infobus. No support for the maintainance of DACF Applications via JDev 9i. Migration support for simple DACF applications, but as far as I know it was useless for real world applications. New JSP custom tag libraries (the JBO tag libs) to simplify the development of JSP-based web front ends for BC4J (see the "old" BC4J toy store demo). Furthermore JDeveloper now contains the UIX-Frameworks plus as extention of UIX to simplify the development of UIX-based web front ends for BC4J (BC4J-Tags).

    JDeveloper 10g: JBO tags for JSPs and BC4J extention for UIX is now deprecated and replaced by Oracle ADF. JDeveloper provides migration support, I'm curious if it works for real world projects. JDeveloper now containts WYSIWYG editors for JSPs and UIX Pages and a graphical struts page flow editor.

    Forsight next release: Oracle ADF UIX will be JSF compliant, and there should be a migration support for applications developed with JDev 10g.

    This isn't typical for Oracle ADF, but for the usage of frameworks, which advance in time. But the problem with Oracle ADF/JDev (and IMHO "VB-like" development in general) is the high coupling of the frameworks and the IDE. E.g. a newer version of the IDE tries to migrate a project developed with an older version (and you can't be sure that it will still work after that...) or the newer version of the IDE doesn't have all the wizards neccessary to edit the various components of the application anymore. A simple solution to this is to archive the exact version of the IDE together with the project so you can use that version for any maintenance tasks that might come...

    Steve, you mentioned that Oracle itself uses Oracle BC4J and UIX and JDeveloper for the development of different parts of the Oracle Application suite. Which releases of the frameworks and IDE do you use? Are you allready using JDeveloper 10g and Oracle ADF in its current 10g version? How do the development teams handle the migration issues regarding new releases of the frameworks? That would be very interesting for customers using JDev and Oracles J2EE frameworks for their projects.

    Regards
    Stefan
  24. We based our architecture on StatelessSession beans with CMT and BC4J for persistence. This is what your paper shows for an example of how to use BC4J in a J2EE application.

    The BC4J layer was running out of database connections because it was failing to release locks in the database. We opened a TAR which was escalated to the BC4J team (after several clueless responses). 30 days later we finally got a conference call with Diraj Mutreja. All he could say was that it should work.

    We were forced to "solve" this problem by turning off locking in the BC4J layer. Totally unacceptable for an enterprise application.

    You don't seem to have implemented transaction coordination between the OC4J/9iAS container and the BC4J layer. Nor do you seem to have even tested whether or not BC4J works with CMT SessionBeans as you claim.

    The sample code in your paper won't even compile. That should have been a red-flag, but Oracle management was adamant that we use this approach anyway.
    Regarding your comments about changing database schema, we provide automatic support in the tool for synchronizing your ADF business components with changes made to the database. This online help topic describes the feature, in case it might come in handy in the future..
    We are using JDeveloper 9.0.3 and the Synchronize feature only works when the changes to the schema are small. When the changes are large (i.e. moving fields form one table to another, dropping and adding several tables, dropping and adding several constraints after moving fields) the Synchronize button generates errors which are in the generated .xml files.

    We filed a TAR on this issue. The Oracle employee on site here who was handling this said that in order to investigate this problem he would have to send in exports of the previous version of the database, the modified version, and both sets of generated code. Even if this were feasible there's the problem of sensitive data in the database that would have to be removed first.

    We have over 200 tables in our schema. Trying to reproduce this problem in the scott/tiger schema is pointless. For this reason alone I would avoid JDeveloper/OC4J for enterprise use unless the schema is frozen.
    ADF Business Components view objects can do "raw" JDBC queries for read-only lookup data as well as updateable queries that interface automatically with backend business components. It's the developer's choice. I'd recommend using read-only view objects for lookup-only queries.
    Why create any extraneous objects for lookup? All you need is a Statement, and I assume that OC4J uses one behind the scenes so any View or Entity creation is useless overhead.

    This type of semi-mindless "just use our framework" attitude is what I expect from a VB developer, but its also typical of the responses I've gotten from Oracle's tech. support and BC4J team.
    Oracle ADF (and its BC4J ancestor) has grown up with J2EE and always tried to deliver a set of technologies that made J2EE-compliant application-building easier.
    We bought the J2EE compliance claims, much to our regret. BC4J is not certified to be J2EE compliant, but few things are so the lack of certifcation didn't bother us. However, BC4J calls commit inside of container managed transactions which is forbidden by J2EE.

    One Oracle developer who spent a few days on our project had noticed the same thing and pointed me to someone's blog (not yours) which showed how to turn off the table spill-over feature. Frankly, your claims to be J2EE compliant when by default your framework calls commit inside of a CMT is bogus.

    Ad-hoc docuentation, especially when it comes to what causes RuntimeExceptions in the application, is unacceptable.
    I'm humored by the suggestions that Oracle ADF is for applications with short lifetimes. Among other customers who are happy with it, we put our money where our mouth is and use it internally as the core J2EE framework for all of our Java-based Oracle Applications, with highly-functional self-service web front ends.
    That's the rational we got from Oracle's management when we couldn't get answers as to the problems we had using BC4J with CMT, as you claim can be done. How many of those application use CMT? How many are desktop or single user applications. Dropping names is no substitute for competent answers.

    Have you actually tested ADF with CMT SessionBeans to see if ADF releases locks properly, or are you no longer making the claim that ADF works with CMT?

    My experience with BC4J is that you make claims for it that you haven't tested.
  25. BC4J and CMT SessionBeans[ Go to top ]

    Dean,

    While most developers using BC4J that I encounter (in our OTN JDeveloper Discussion Forum) opt for the lightest-weight approach of using simple Java beans for their application module services -- leveraging the bean pooling, state management, and failover facilities that we provide -- when your components need to participate in a CMT transaction with other EJB's then the architecture you suggest is the one that is available and supported. As someone who spends a good deal of my day helping customers with technical questions, I feel your pain that it's a scantily documented use case, and I've filed documentation bug# 3765594 to get corrected.

    I reviewed the sample article last night and you're right that there are a couple of issues with it that I'll get corrected A.S.A.P. -- a member variable typo in the sample client class, and a tweak to where/how the you should call setRollbackOnly() -- but our CMT-transaction-participation is a supported and tested. I can hear you saying, "Then include your darn sample in your QA suite, why don't you!!" (Point taken!).

    In fact, our extensive Oracle Healthcare Transaction Base product provides a CMT StatelessSessionBean facade layer over a set of functionality implementing the Health Level Seven (HL7) standard information model, using aggregated application module components inside their CMT Session Beans to handle all the complicated database interactions needed.

    In the 9.0.3.4 maintenance release (released 30-JAN-2004) and beyond of BC4J, as well as in the broader Oracle ADF framework that comes with JDeveloper 10g, the so-called "view row spillover" feature is turned off by default, so no commits occur in the context of your EJB container's transaction, as mandated by the spec. Before the 9.0.3.4 maintenance release, you would have needed to disable the feature by setting a configuration property as noted in the Oracle Technology Network bulletin.

    In order for the transaction participation to work correctly, including having the appropriate rollback behavior so any row-level locks would be released, the trick is making sure you use a transaction-aware datasource. I've seen customers get into trouble when they use the datasource name corresponding to a non-transactional datasource and have had similar issues. I'll make sure this is better clarified in the documentation and the updated article on OTN.

    While I appreciate that this information doesn't do anything to reverse the particular negative experience you had on your project, I wanted to clarify that your issues don't imply in the large that BC4J cannot be used successfully and in compliance with the EJB spec inside CMT SessionBeans. Point taken that our sample and doc need to be much more clear on the right way to stitch the pieces together.

    Regarding the effectiveness of our support organization to steer you in the right direction on this particular issue, if you mail me the TAR # offline (steve dot muench at oracle dot com) I'll chase up what happened. I'm in touch with them frequently so I'm surprised that they didn't contact development at the outset if they were unclear on the approach or suspected an error in the sample.
  26. BC4J and CMT SessionBeans[ Go to top ]

    In order for the transaction participation to work correctly, including having the appropriate rollback behavior so any row-level locks would be released, the trick is making sure you use a transaction-aware datasource. I've seen customers get into trouble when they use the datasource name corresponding to a non-transactional datasource and have had similar issues. I'll make sure this is better clarified in the documentation and the updated article on OTN.
    Hmmm... It was nearly a year ago that we dealt with this so I don't remember which drivers we were using then. We may have been using the thin drivers, though.

    When you say transaction-aware datasource do you mean use the XA drivers? We are using the OCI drivers right now.

    We noticed the problem with failing to release locks when using Oracle 9iAS on RedHat Linux Enterprise 2.1 (which is the production environment that Oracle selected for this client). Our developer machines are Windows 2000 with OC4J and we didn't notice this problem here, but of course there is only one user on these machines and the OC4J gets shutdown and started several times a day so a held lock would not be likely to show up. All systems were running against the same database (Oracle 9i 9.2.0.1 on Redhat Linux Enterprise 2.1).

    I could see where using the thin drivers (if that's what we were doing) in a transactional system on an Enterprise OS could cause a problem. The thin drivers may not be tested as thoroughly on an Enterprise OS because most people who buy an Enterprise OS for a transactional system wouldn't use the thin drivers.
  27. Remeber Oracle Forms and Reports that were dominant in pure-Oracle shops back in the olden days of Client/Server? BC4J, ADF and JDeveloper 10g are the Java replacements for Forms runtime and the GUI app builder. For these Oracle shops they still prefer 100% Oracle toolset because they are not afraid of vendor lock-in for a variety of reason. Some people actaully have the "peace-of-mind" for only having to deal with a single vendor. These people are not concerned about overpaying Oracle for products and services. Typically these shops have very rigid development and product selection policies (most likely they are pharmacetical companies whose apps need to be validated by FDA, and Oracle is a name FDA automatically puts the stamp of approval). These guys can't use open-source frameworks like Hibernate and iBATIS, and TopLink is probably too complex for them to use, so JDeveloper 10g's drag-n-drop and code-generation funtionality is a natural fit for them.

    Also, if you buy a packaged product like Oracle e-Business Suite and you don't have to customize it yourself, then you don't have to worry what is running under the hood - be it BC4J or ASF. You know you will pay Oracle consulting to solve problems for you.

    Through its history Oracle has not established any creditable track-records for offering kicking-ass development frameworks and toolsets, no matter how hard it tries (both OC4J and TopLink are bought from someone else). This is because to Oracle everything should be dictated by the relational data model (this is fine for people who take a data-centric view of their apps). BC4J and ADF are attempts to use OO methodology so I give Oracle some points for trying. But if I am not an Oracle shop, I wouldn't touch these frameworks with an 8-feet pole.
  28. The facts[ Go to top ]

    Hey Clinton,

    I think it might be helpful to separate some terminology. Oracle ADF is a development framework with many facets. The one you have been focued on is tje ADF Business Components (fka BC4J), which is just one of them. On one hand, it has the most generated and Oracle-specific code, but on the other hand, it is doing the most work for you as it implements much of the business object management layer. Most of the frameworks talked about in this thread do not get into this depth. While none of the ADF framework requires JDeveloper, ADF BC would be the hardest to use without it.

    Looking at some of the other facets, you don't have to use ADF BC to get advantages with ADF. The other parts of ADF include Struts extensions for easy data binding and an implementation of the ADF model layer which provides a simple, lightweight service-oriented interface for binding from any source into any UI. These are just two other examples of parts ADF. You can pick-and-choose the parts of ADF you want to use. You could implement Steve's Toystore demo without using ADF BC but instead using EJB or POJO's and still get many benefits from ADF, with much fewer oracle.* imports. The idea is that you are *not* locked in to anything in the framework, but instead can choose the tradeoff between vendor-propritary code and functionality. This is no different than any other non-standard technology. We are also working very hard to get this technology submitted into the standards. JSR 227 is one example of this. Java Server Faces is another.

    As far as the source code questions goes, we ship a lot of the source with the product today, and are working on adding all of it. For some customers who want the source code, we have provided it to them as part of their license. As other posters have pointed out, not everyone cares about the low-level details, but others do. We also have customer accounts using ADF with a mix of both JDeveloper & Eclipse throughout their teams.

    Anyway, I thought some clarification might be in order. There have been a lot of statements made without all of the facts being exposed that I think might have caused some confusion. If you really are interested in the ADF technology and code, I would be happy to follow up with you and get you the information you need. Just send me an email. Hope this helps.

    Ted Farrell
    Oracle Corporation
    ted.farrell@oracle.com
  29. I mostly work with customers already using Oracle tools (developer/designer) and most of these customers are very excited about ADF.

    Why? Because most of them don't count lines of code. Here's what they count:
    - Lines actually coded,
    - Minutes used to create application.

    ADF promisses to make developers a lot more productive, eventhough you may actually create more lines of code.

    On a recent project i used xdoclet, hibernate, jstl and struts. It's productive and not tied to any IDE. But the customer's developers looked at the code, and asked if they could maintain the xdoclet and hibernate parts of it in jdeveloper using wizards and visual tools. When i said no, their first reaction was, can we replace it with Oracle's ADF business components?

    Most developers coming from an Oracle Developer/Designer background don't want all the flexibility and choice which open source components have to offer. Choosing the right component is difficult. They prefer oracle to say: this is what you use for OR mapping.
  30. You are spot on.
  31. But the customer's developers looked at the code, and asked if they could maintain the xdoclet and hibernate parts of it in jdeveloper using wizards and visual tools.
    Funny, I use a visual tool every day to maintain xdoclet, hibernate, iBATIS, JSP, Struts and many other frameworks.

    It's called IntelliJ IDEA.

    What is more, is that only half of our team uses IDEA. The other half uses Eclipse. Because we're not tied to any IDE, our developers are free to use their tool of choice. This means that they're more productive because they can work in an environment they're comfortable with.

    I'd rather spend $995 on a good chair than on an IDE. Just my opinion though...

    Cheers,
    Clinton

    http://www.intellij.com
    http://www.eclipse.org
  32. On this project i used Eclipse. It's a nice IDE. I also like IDEA. But they are not visual tools. If you are editing code it's not a visual tool. It's an enhanced text editor. Personally, i prefer using a good enhanced text editor, but many people do not. Remember those visual basic developers that Sun is currently targetting with their Sun Java Studio Creator? They want wizards and drag and drop.
  33. Neo: Do you always look at it encoded?
    Cypher: Well you have to. The image translators work for the construct program. But there's way too much information to decode...
    I would argue that IDEA is more visual than any other IDE out there. It lets you see and understand your code in ways that other IDEs could never begin to.

    On the other hand, there is NO wizard that will ever be able to describe my customer's needs in a way that would satisfy them. My customers are way too creative for that.

    Cheers,
    Clinton
  34. Most of Oracle's customers have been rather happy with Oracle Developer. It's a rather restrictive, mostly visual tool for creating data entry application. It may not be very flexible, but it's very productive. This is very much appreciated by a lot of people. Besides productivity, restrictiveness quite often also causes consistency, which is also valued, because consistency usually means user friendly. (Windows in itself is not very user friendly, but the fact that most applications work in the same way makes it kind of user friendly.)

    You can argue all you want, but fact is that most people and companies percieve wizards and drag and drop as easy and productive, and writing code as slow and difficult...
  35. It may not be very flexible, but it's very productive.
    “It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.”
    - Charles Darwin

    Unfortunately he didn't mention productivity. ;-)
    but fact is that most people and companies percieve wizards and drag and drop as easy and productive, and writing code as slow and difficult...
    Most? Steve can be quoted above as saying "The Oracle ADF framework's capabilities for simplifying end-to-end J2EE application development are used daily by over 2000 developers in the Oracle E-Business Suite team, as well as by *hundreds* of external customers."

    Hundreds? Plus Oracle. That's hardly "most". Hibernate alone has 27216 downloads of its latest version. Even if only 1 in 25 downloads results in a Hibernate user, that's still more than the maximum number that fits the description of "hundreds". Open source seems to win in the category of developer preference.
    You can argue all you want
    I'm not arguing, are you? We're each making points in favor of our chosen solutions within a given problem domain. I commonly refer to this as "debate" or "discussion".

    This is not an advertising board, it's a discussion forum. If the topic wasn't up for discussion, then it wouldn't be posted here.

    Cheers,
    Clinton
  36. “It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.” - Charles Darwin
    That darwin quote is actually quite appropriate. Many current Oracle customers made the choice to use Oracle Developer and Designer because it is very productive. However, the last few years Oracle has spend a lot of effort on Java tools and a lot less on Developer/Designer, and many customers are afraid that they'll have to migrate all their existing Oracle Forms applications to another platform. Ofcourse, Oracle's statement is that they'll support the Developer/Designer products forever, but who knows? They've also stated that the Designer product is in it's end-of-life phase, it will be certified with new versions of the database, but no new features will be implemented for Designer.

    So current customers will need to move to another platform/toolset if they want to create html web applications, create web services, create application for mobile devices, etc. So yes, they know what it's like to be locked in...

    Current Java developers are quite technical people, who know how to write code, create and scripts, setup and xdoclet, etc. But Oracle (and also Sun) are aiming for the Visual Basic/Oracle Developer/Designer type developers, who are not very good are writing code. These people need drag and drop and wizards.

    When Sun released project Rave they stated that there were about 3 million Java Developers (not sure, think it was 2 or 3), and with project Rave they were aiming at 8 million VB developers. Suppose that Sun achieves this goal. Do you still think that more Java developers will be using Hibernate than some wizard driven OR mapper? Do think think they'll actually know which OR mapper they'll be using?

    I made a mistake by saying arguing. English is not my first language, i thought arguing was more or less the same as discussing.
  37. I am one of those wretch souls who have been chasing the "industry standards" for last five years: CORBA, HTML, EJB1, 1st incarnation of the Servlet standard, AWT, Swing, XML, XSLT, JSP, Tags, Apache, Struts, etc. After all that I frankly have little to show for.

    What good are all these standards? Just about when I feel good about my implementation, someone comes up with another standard, instantly obsoleting my work.

    My management keeps telling me to get on with the latest standard, the latest being JSF and Hibernate, but what's the point?

    I much rather be locked in with a vendor and deliver something that works than keep chasing the rainbow. Although even MS does this, at least the lifetime of MS "standards" on the average seems to be a bit longer than J2EE's.

    To me, J2EE is a hodge-podge of "standards," none of which seems to stick. If I'm not mistaken, JSR has no fewer than 200 planned "standards." My head spins just trying to remember these darn JRS numbers and acrnyms. When is this gonna stop and people start doing some real work?

    The only people that chug along through all these seem to be those that stick with as little standards (Servelt with JDBC for example) as possible. Instead of focusing on some of these smart guys who work on demowares forever (and who have so much time on their hands to spend 4 hours a day writing to threads like this one), I would like to know which parts of the J2EE standards and design patterns Google, eBay, Amazon, and Yahoo use.

    Any ideas?


    Hu
  38. Yes I see no problems to use this kind of tools for applications with short lifetimes too. If you do not know app lifetime then it is not a tool problem.
  39. Visual tool .....[ Go to top ]

    On this project i used Eclipse. It's a nice IDE. I also like IDEA. But they are not visual tools. .... They want wizards and drag and drop.
    I known you've seen Collaxa, the BPEL tool Oracle bought recently. This buy also included a highly visual tool, which plugs-in into Eclipse to create definitions. My point is that Eclipse can be any tool you (or Oracle for that matter) like. Have a look at Exadel to see what they're doing. In my opinion, Oracle should drop JDeveloper and start writing plugins for the other Java IDE's out there, in order to make ADF a succes (maybe even donating ADF to the community). That is if they want to reach the Java community and not only customer who are already using much or all of Oracle's toolstack.
  40. Visual tool .....[ Go to top ]

    Yes, with plugins Eclipse can be any tool you like. Personally, i wouldn't complain if Oracle ported all their plugins to Eclipse. Point is, i think, that a lot of customers want rich, visual IDE's, not a basic IDE like the standard Eclipse.

    If Oracle would port ADF & BC4J to Eclipse, it would still generate the same code...
  41. Ant task for ADF generation[ Go to top ]

    Steve,

    One thing that we really wish we had when working with BC4J is the ability to generate the BC4J layer with an Ant task instead of having to mindlessly repeat the identical series of GUI steps every time the database changes. We were forced to do this over an over again as our schema evolved. (The synchronize feature of JDeveloper doesn't work when schema changes are large.)

    The ability to setup and customize an Ant task which does the same thing you would do with JDeveloper would be a big step forward.

    Dean
  42. Ant task for ADF generation[ Go to top ]

    One thing that we really wish we had when working with BC4J is the ability to generate the BC4J layer with an Ant task instead of having to mindlessly repeat the identical series of GUI steps every time the database changes. The ability to setup and customize an Ant task which does the same thing you would do with JDeveloper would be a big step forward.
    Dean, this is a great idea. I've filed enhancement request #3765538 to track it for a future release.

    We do provide a full design time API in the oracle.jbo.dt.objects.* package which is the same API that our IDE extensions catering to ADF Business Components facilities interact with to create and maintain framework component defintions. Other teams in Oracle, like the ones that build our UML modeling extensions, use these API's to provide our visual UML modeling feature for ADF Business Components as well. Our regression testing suite exercises these same API's to build and test framework components in a non-visual way based on an extended language syntax conceptually similar to XDoclet, but not using that exact approach for the language annotations at present. Some of the third party companies that have built addin "extensions" for JDeveloper (you can see them at the JDeveloper Extension Exchange have tapped into this API in their extensions to programmatically manipulate the ADF Business Components framework metadata, too. I've talked with companies interested in generating a middle-tier layer of ADF Business Components from higher-level "MDA"-style models using their company's modeling toolset. Again, this would be the API to interact with. JDeveloper itself offers a feature for doing such generation from Oracle Designer repository models captured using one of the other tools in the Oracle Tools family. This repository generation feature again exploits this same design-time objects metadata API.

    To be honest, I personally haven't tried building a custom Ant task before, but I imagine that an Ant task which tapped into these API's could get the job done with a little fiddling. It would be cool to provide something out of the box for Ant that did this...
  43. BC4J and POSTGRESQL[ Go to top ]

    Steve

    I would like to tell you our experince working with Bc4J and PostgreSQL.

    About three months ago our application reported passivation errors for certain
    collections asociated to some of the view objects we were working with. Wile reading
    the documentation of JDeveloper and a few articles published in OTN about temporay objects
    for controlling passivation we applied the mecanisms sugested by canceling passivation to database.
    Things were ok for a while but when databases in production enviroment began to grow we found
    frecuent crashs of the applicacion due to out of memory.

    My colleague Martin and I found out a kind of interface for implementation of a persistence manager
    called JDBCPersistManager but we didn't find any documentation in OTN about the subject.
    I agree with some people here about the lack of enough documentation of BC4J framework. Certainly our
    best source of information is your blog "Dive into BC4J and ADF". We sent many question about this issue
    to Metalink but we didnt't receive any answer.

    We think BC4J works ok with Oracle and DB2 but it has some problems for other databases. As well
    I think it's necesessary better documentation of the framework and support by Oracle. Your articles in
    "Dive in BC4J and ADF" are fine but we expect more from Oracle.

    We are interested in having some support or being in contact with you to help us to solve
    these problems.

    Thanks a lot, Ramiro
  44. BC4J and POSTGRESQL[ Go to top ]

    Ramiro, I'm the other Steve at Oracle working on ADF. One of my key goals is to make sure that it works better with all kinds of datasources. As you can imagine, it's a real challenge due to the variations between different datasources. I'd really like to talk with you more about your experiences with PostgreSQL. Can you please drop me a note at steven dot anderson at oracle dot com?

    Thanks,

         SteveA (AKA, the other Steve)
  45. BC4J and POSTGRESQL[ Go to top ]

    SteveA,

    I'm interested in knowing about a possible implementation of JDBCPersistManager for POSTGRES or you can give us some guides to develope it.

    Thank for your interest,

    Ramiro
  46. At what price ?[ Go to top ]

    Having completed my first Struts project 'by hand', I am interested in the productivity gains that JDeveloper offers, like easy forms<->database mapping.

    However, everything comes with a price. I would really like to know :

    1. Can JDeveloper be used with ANY database that has a JDBC interface?

    2. Which productivity benefits are forfeited if Oracle products are not used as the database and App Server?

    3. From the ADF FAQ on Oracle's website:
    "Oracle ADF is licensed as part of Oracle JDeveloper 10g. No separate runtime license from Oracle is required to deploy applications based on Oracle ADF."
    Does this mean that if I buy JDeveloper, I can distribute ADF to customers with any app that I create? If yes, is this situation likely to change?
  47. At what price ?[ Go to top ]

    I would really like to know :<br>
    1. Can JDeveloper be used with ANY database that has a JDBC interface?
    Yes, but due to the variations of JDBC drivers and SQL flavors, not all features will work with all databases.
    2. Which productivity benefits are forfeited if Oracle products are not used as the database and App Server?
    The short answer is that you won't lose much, if anything. For example, JDeveloper will work all J2EE compliant application servers. We include build-in deployment for serveral, including JBoss, but for some application servers you'll have to create a EAR or WAR file and use your application server's tools to deploy the application.

    The best way to find out is to test your environment using JDeveloper. It's free to download and use for this kind of testing.
    3. From the ADF FAQ on Oracle's website:"Oracle ADF is licensed as part of Oracle JDeveloper 10g. No separate runtime license from Oracle is required to deploy applications based on Oracle ADF."Does this mean that if I buy JDeveloper, I can distribute ADF to customers with any app that I create? If yes, is this situation likely to change?
    These are two very different questions.

    The first answer is yes, you can distribute your application created with ADF, and the ADF runtime libraries required for your application, to you customers just by buying JDeveloper. There is a separate license for Oracle TopLink, though.

    As far as future licensing goes, that's a question I just can't answer, but I can tell you that our JDeveloper's licensing has always been very competitive and developer friendly.

    -SteveA
  48. At what price ?[ Go to top ]

    Is it possible to use Hibernate instead of Toplink to bind user interface components to the persistence layer?
  49. Productive with ADF[ Go to top ]

    Dear Steve,
    Just Few months ago my boss gives me new expensive toy called Oracle JDeveloper 10g with its ADF. how to become productive with this expensive tool because I feel more productive with IBM Rational XDE for java?. Where can I get good and complete documentation or book about ADF?. The document that come with JDeveloper 10g did not help me.
    I can apply Rod Johnson’s best-practice without ADF.