Rollin onj Rubyv3

Editor's Notes

• #21: The Java version is tightly integrated with Java to allow both to script any Java class and to embed the interpreter into any Java application.
• #23: Integration with Java libraries JRuby classes can extend Java classes implement a single Java interface add methods to existing Java classes (visible from JRuby, but not Java) Native threads JRuby uses native threads, Ruby uses green threads can result in different behaviors between JRuby and Ruby Portability JRuby runs on any machine with a JVM Unicode support JRuby uses the unicode support in Java Ruby has some support for unicode, but it’s not built-in
• #25: When you start JRuby  starting Java – based ruby interpreter on a JVM. C based or J based Ruby doesn’t care which one (due to how Jruby is implemeted) Rack provides a minimal, modular and adaptable interface for developing web applications in Ruby. By wrapping HTTP requests and responses in the simplest way possible, it unifies and distills the API for web servers, web frameworks, and software in between (the so-called middleware) into a single method call. • An abstract interface on top of HTTP allows for • code reuse • easier testing • new ways of combining code/applications
• #26: The general architecture for Ruby DBI uses two layers: The database interface (DBI) layer. This layer is database independent and provides a set of common access methods that are used the same way regardless of the type of database server with which you're communicating. The database driver (DBD) layer. This layer is database dependent; different drivers provide access to different database engines. There is one driver for MySQL, another for PostgreSQL, another for InterBase, another for Oracle, and so forth. Each driver interprets requests from the DBI layer and maps them onto requests appropriate for a given type of database server. ADO (ActiveX Data Objects) DB2 Frontbase mSQL MySQL ODBC Oracle OCI8 (Oracle) PostgreSQL Proxy/Server SQLite SQLRelay The database drivers are each hand crafted to access a specific database. They have different method names from each other, meaning that if you switch back end databases, you'll need to rewrite substantial portions of your program. The only reason to use the database specific drivers is to take advantage of database specific features, and possibly to make the program run a little faster and use a little less memory. With the database specific drivers, you manipulate the database by passing SQL statements as strings via the interface methods. Ruby-DBI is a wrapper around all the database drivers, giving you a united method set to do the majority of your database activities. The only remaining database dependencies are caused by the fact that the different databases support slightly different SQL syntaxes. With DBI, you manipulate the database by passing SQL statements as strings via the interface methods. Whereas the database drivers and DBI provide a simple vehicle to use an SQL statement, the ActiveRecord technique provides database access without the need for SQL statements. The ActiveRecord techniques match objects to database rows. The advantages are almost zero database dependencies within the subset of capabilities provided by ActiveRecord, and a set of defaults (such as automatic naming of tables based on class names) that make coding a database app much quicker and easier. If you know SQL, you can pretty much write an app using database drivers or DBI today. With ActiveRecord, you'll need to learn a new set of skills, complete with a set of methods specific to Ruby's ActiveRecord class. You wouldn't do this to create a one-off app, but if you are or plan to be a frequent Ruby programmer and you plan to frequently hit databases from your Ruby programs, learning ActiveRecord will benefit you greatly.  Ruby on Rails uses ActiveRecord for the vast majority of its database access, so if you use or plan to use Ruby on Rails, ActiveRecord is a must.
• #27: Database.yml – only config file.. Just fill in the value and go! Here you've only scratched the surface of Active Record. It's a powerful framework—much more powerful than other frameworks that implement the Active Record design pattern. It leverages the strengths of the Ruby framework—a simple syntax, metaprogramming, and the ability to open and manipulate classes at run time—to form a marvelously effective and productive environment for green-field development. But Active Record is not for every application. It does not handle legacy schemas nearly as well. For those, you need a mapping framework, not one that merely wraps tables with simple classes. Active Record also is prone to performance problems for those who don't have the discipline or skill to tune it properly. Active Record, and the Ruby on Rails framework, represent what founder David Heinemeier-Hannsen calls opinionated software. Rails, and Active Record by extension, represents hundreds of compromises, with most of them favoring a beautiful, productive programmer experience.
• #33: Solve WAR file,
• #40: Oracle TopLink 11g includes EclipseLink 1.0.1 JPA: Object-Relational JPA 1.0 with advanced persistence Simplified configuration of advanced features using annotations and/or XML All leading RDMS with platform specific features, best ORM for the Oracle Database MOXy: Object-XML Binding JAXB and advanced native SDO: Service Data Objects EIS using JCA Resource Adapters Containers WebLogic, OracleAS, WebSphere, GlassFish/SunAS, JBoss
• #41: This is an example of a scalability problem that can be encountered in JEE applications, and that Coherence can help address.
• #42: Oracle TopLink 11g (11.1.1.0.0) introduced in 2008 includes the new TopLink Grid feature that addresses the potential scalability problem discussed on the prior slide. TopLinkGrid which offers tight integration with Oracle Coherence that marries the standardization and simplicity of application development using the Java Persistence API (JPA) with the scalability and distributed processing power of Oracle’s Coherence Data Grid. This feature is integrated and included with WebLogic Suite. Developers can use TopLink Grid to easily leverage the Coherence grid as their primary storage for Entities as well as using direct connectivity with the backing data store for some Entity types of for specific operations. This flexibility allows application to easily adjust their usage of Coherence to meet changing requirements and usage patterns. The real focus of TopLink Grid is the delivery of functionality where a developer can easily configure TopLink JPA to use Coherence as the primary data store, execute queries against the grid, and choose to have Coherence manage the persisting of new and modified Entities. This integrated solution involves a layer between JPA and the data store where the grid can be leveraged in order to off-load direct database calls from every application instance and therefore offer these clustered application deployments the capability of scaling beyond and database bound operations. http://www.oracle.com/technology/products/ias/toplink/technical/toplink_grid_intro.html