Roland Barcia

Worklight can run on a server like Tomcat, however, by default, it comes with a Liberty Profile and can install on top of Traditional WAS ND. When running on WebSphere, we have additional integration for example, using WebSphere Security like LTPA and such. In addition, we can invoke Java Code running in WAS from JS. if Worklight is sitting on different servers from your WebSphere Business Logic, than it can make Web Service or REST calls to get data.

Question 1.)

Depends what you mean by integration. The Server component of Worklight runs on top of WebSphere Application Server, and there are a few integration patterns. Worklight Adapters (Serverside code written in JavaScript) can call local Java Code because we use Rhino on the server, which is a serverside JavaScript engine written in Java. In addition, WL adapters can call any REST service. The client side piece of WL (runs on the device) can call anything via adapters or direct REST calls.



Question 2.)

The WebSphere Liberty Profile is much more aggressive in adoption of standards. For example, we have a Beta that supports WebSockets: (http://www-01.ibm.com/support/knowledgecenter/was_beta_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/cwlp_websockets.html).

We do cover third party libraries on the client side (Browser and device), so we have an example using backbone.js, require.js, and others. We do not cover as much on the server.

They key here, is the UI frameworks have moves from server side rendering to client side rendering. As such, following the modern architecture in the book, it is probably a question of how well JavaScript frameworks work in a browser or mobile shell. The server drives API's across channels, weather you use angular JS, jquery, objective-c, or swift.

Thanks

Do you find customers asking for a markup based approach to building Dojo Apps. I noticed in the dojox package, the Wires framework is an option. Any thoughts

Does your book discuss strategies for how a web designer using some non-developer centric tool, hands off design to a dojo developer and what strategies a dojo developer may take?

What have you seen out in the field?

Thank you for having me. Congrats to the winners. I enjoyed the questions and the comments.

Originally posted by Padmarag Lokhande:
We generally say that such and such framework will allow us to have portability.
But how many times does it happen when we really change database? or for that matter our ORM/persistence provider.
In my company we use hibernate but still have iBatis for oracle stored procedures.

So there is application portability and db portability. I think persistence frameworks are getting good at the application portability.

DB portability is usually harder. I would say though that if you can be like 80%-90% portable, then you are in good shape.

SQL frameworks actually become harder to port because SQL developers get good at writing database tuned SQL (Usually have some DBA do the tuning). A framework like iBatis which externalizes SQL can be good for this.

Originally posted by Cameron Wallace McKenzie:
I know that the authors of this book include widely respected WebSphere specialists. As WebSphere 7 hits the market, I was wondering if there were any persistence mechanisms that Big Blue was tending to get behind a little more than the others.

WebSphere 7 Beta - Early Adopters Program

I understand that as a JEE5 compliant application server, WebSphere 7 will support all of the major persistence mechanisms, but IBM does have a tendency to train up their technical support in a few key areas.

For example, with Portal Server, IBM initially pushed the Struts Portlet, which they still support, but as Portal matured, IBM provided more and more support for the JSF portlet within their portal. Of course, you can do anything inside a WebSphere Portlet, be it Struts, JSF, Spring or whatever, but IBM clearly liked JSF as time went on.

So, is there any leaning that you can see? Or is there simply an IBM implementation of JPA that the WebSphere 7 Application Server will use?

Just curious.

-Cameron McKenzie

IBM's JPA implementation is based on Apache OpenJPA. This is the JPA implementation we ship with (Both the WebSphere EJB 3 Feature Pack for WAS 6.1 and WAS 7.0 App Server have this).

WAS 7 should allow you to work with other JPA implementations (tolerate), but we will support what we ship because we have developers on as committers on open source projects we ship to help fix bugs. Not all open source projects allow others to be committers.

So we will tend to favor our JPA implementation. We will also have support for pureQuery as an SQL based framework. I have gone to a few customers who just do not want to do ORM and love to control their own SQL. pureQuery will work well for those customers.

I would not say EJB is a failure. I would say Entity Beans may have been a failure. We cover JPA, which I think will have success because it takes into account patterns used by TopLink, Hibernate, JDO, and others.

The book is on the persistence layer, so we do not focus alot on EJB 3. We discuss how using JPA in a managed environment like EJB 3 can make things easier in some scenarios, by allowing automatic propagation of the Persistence Context. I know other frameworks like Spring can give you similar advantages. But in general, I feel EJB 3 is a good thing.

Originally posted by Anil Vupputuri:
Apart from these. How good ORM is at reading/writing blob's?

Most ORM's have a Blob mapping today. I know Hibernate and JPA do, and they seem to do an ok job.

Originally posted by kelahcim kela:
Hello guys,

I have gone through the content of your book briefly and I can see that you focus on few, well known ORMs. In this context, I'd like to ask a question regarding sub-queries and left/right outer joins.

So in the book, we do have a left outer join mapping for loading the customer (along with an open order[we had a constraint on one open order at a time], line items with product, if it exists).

With JDBC, IBatis, and pureQuery, the SQL looked like this:

SELECT c.CUSTOMER_ID,c.OPEN_ORDER,c.NAME,c.BUSINESS_VOLUME_DISCOUNT,c.BUSINESS_PARTNER,c.BUSINESS_DESCRIPTION,c.RESIDENTIAL_HOUSEHOLD_SIZE,c.RESIDENTIAL_FREQUENT_CUSTOMER,c.TYPE,o.ORDER_ID,o.STATUS,o.TOTAL,l.PRODUCT_ID,l.ORDER_ID,l.QUANTITY,l.AMOUNT,p.PRODUCT_ID,p.PRICE,p.DESCRIPTION FROM CUSTOMER c LEFT OUTER JOIN (ORDERS o LEFT OUTER JOIN (LINE_ITEM l JOIN PRODUCT p ON l.PRODUCT_ID = p.PRODUCT_ID)ON o.ORDER_ID = l.ORDER_ID) ON c.OPEN_ORDER = o.ORDER_ID WHERE c.CUSTOMER_ID = #value#

I found that using a query that I specified was the most efficient way.

For JPA, I used mapping to try to achieve the same, but found it difficult to get the exact SQL to match the above.

On the AbstractCustomer class, I had:


@OneToOne(fetch=FetchType.EAGER,cascade = {CascadeType.MERGE,CascadeType.REFRESH},optional=true )
@JoinColumn(name="OPEN_ORDER", referencedColumnName = "ORDER_ID")
protected Order openOrder;

On the Order class I had:
@ManyToOne(fetch=FetchType.LAZY)
@JoinColumn(name="CUSTOMER_ID", referencedColumnName = "CUSTOMER_ID")
protected AbstractCustomer customer;

@OneToMany(cascade=CascadeType.REMOVE,fetch=FetchType.EAGER,mappedBy="order" )
protected Set<LineItem> lineitems;

One The LineItem, I had:

@ManyToOne(fetch = FetchType.EAGER)
@JoinColumns({
@JoinColumn(name="PRODUCT_ID", referencedColumnName = "PRODUCT_ID")})
protected Product product;

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumns({
@JoinColumn(name="ORDER_ID", referencedColumnName = "ORDER_ID")})
protected Order order;

Putting Eager on mappings I wanted to load when the customer got accessed and lazy where not. I got close to the SQL, but ORM still added extra joins back to the tables in some cases (Both JPA and Hibernate).

In general, I found the SQL approach the best for this type of query.

If you have this type of query less often (20% or less). Then using an ORM that allows you to drop down to native SQL is good. So JPA and Hibernate allowed for both. If you are doing this type of query more often in your app, an SQL based framework seems better.


These queries, usually, take a huge amount of time for a Object-Relational mapping tools. I haven't used any of these (apart from JDBC) for quite some time thus I have a question. Which ORM would you suggest for such a queries? Which one makes a best deal when it comes to efficiency/elegance of code relation.


While presenting examples, do you base on simple queries that are fairly simple to implement or do you show examples that involve multiple tables during query execution?

Another question is. What would you suggest (which ORM environment) for tree based structures stored in database - I am focusing on the performance here.

Cheers and thanks in advance for the answers

Michal

So I have a more detailed example I use for customers that did not make the book. I extended the Products and added the notion of Category. The Category is a tree structure and I was able to get what I wanted with JPA and dropping down to native queries.

Thanks for the post. In addition to Geoff's comments, many books on persistence cover the "How do I use?" Our book is more along the lines of "Why and When" to use which framework of feature in the framework?

I have used TopLink, and it is a capable ORM as well. We discuss TopLink in the 1st chapter, and us choosing not to cover it as a chapter in the template does not mean it is not a good technology.

Anyone can apply the principals in the book with any ORM and there were other technologies that we wished we had time to cover.

Originally posted by Cameron Wallace McKenzie:
Actually, I was somewhat disappointed. I thought maybe Roland and Kyle had merged into one super, cyber-Java-organism called a Kyle Barcia, but alas, it was a typo at amazon.

Welcome Kyle and Roland!

-Cameron McKenzie

This book had 5 authors in general..The Kindle edition has that mistake, but the general entry I think is OK.

We should also welcome Geoffrey Hambrick, who may be on the forum this week as well.