Jave Open Client using ProxyGen versus OpenEdge Dynamic Open

Further, it looks to me that using OpenClient one can only Proxy a .P and not a .CLS file.

We want to gravitate towards more .CLS and it would be a shame to have to go back to .Ps.

I am leading a project that uses GWT/extGWT as frontend technology and using the OpenEdge AppServer and RDBMS as backend technology with a Java servlet sitting in the middle. We use both static ( based on a proxy ) and dynamic calls via the Java Open Client. You mention that you did not find any documentation. At the moment we are using OpenEdge 10.1c and it is very well documented in the product documentation. But -- I never tried it before OE 10.1c -- AFAIK the possibility to dynamically invoke a procedure on the AppServer with the open client technology has been introduced around OE10.1c ...

Static versus Dynamic:

There are pros and cons for both. We mostly use static because we use a generic interface utilizing ProDataSets ( dynamic on the Progress side ) and therefore have been able to strip it down to 3 API which are most widely used around the application: One to fetch the schema for a data object ( how we call it in Java ), one to fetch the actual data and one to save the changes back. Of course we could make these three dynamic too but I don't see any benefit plus it would force me to declare the schema of the Java SDO in the Java servlet which might not be so easy when you don't know what is coming. In the end using theses three API we are able to fetch any ProDataSet and save the changes back to OpenEdge side without a fuzz.

Classes:

It is not possible to instantiate classes on the AppServer directly ( AFAIK that is still true in OpenEdge 11 ), you always need a wrapper procedure. Whether that does make sence or not is subject to debate. We are using all our AppSevers in state-free operating mode and instantiating something on the AppServer would make it necessary to bind it to a specific client which, IMHO of course, compromises the state-free approach.

Hope that helps, Richard.

Jeg er væk fra kontoret indtil den 18. juni, og checker ikke altid mail og telefon regelmæssigt. Jeg vil dog svare på din mail så snart som muligt.

Hvis du har behov for support, kontakt venligst support@app-solutions.com, så vender vi tilbage så snart det er mnuligt.

Administrative henvendelser kan ske til : admin@app-solutions.com.

I am not in the office until June 18th 2012. I will not be checking my mail and phone on a regular basis, but will reply to your mail as soon as I can.

If you need support from appSolutions, please send your mails to support@app-solutions.com.

If you need Roundtable support, please send mails to :

support-europe@roundtable-tsms.com.

Med venlig hilsen / Regards

Thomas Hansen

appSolutions a/s

Richard,

Thank you for the very helpful answer!!!

Interestingly I also  was looking into using GWT/extGWT as a front end with direct connection to appserver via servlet.

We already do use extJS.

Some questions:

a.  Did you look at using something other than GWT.   There is somebody else using GWT with Java Open Client Proxy in PEG (he goes by realHeavyDude or something).

How has your experience been with GWT?  There has been some concern by others regarding a pure JavaScript based front end.

Did you consider JSF and Facelets as an alternative or some other framework?

Is your validation done at the JavaScript level also in order to cut down the calls back to the appserver.

There are so many options out there making the choice for us harder in the Java world since I come from a .NET world.

b.  As I can read from your other posts, there is a desire from the management to move to Java/Orace.

We have similar pressure from time to time here.    But we have so much invested in OpenEdge that it makes it tough to do it.

Have you or anyone considered a method to somehow use an incremental approach if pressure to migrate out of OpenEdge was intensified!  

c.  Are you doing anything special in your ServLet?

Thanks in advance,

Mike

When we did the asssement in the fall of 2010 we immediately ruled out any JavaScript framework because we are not a JavaScript shop - but we do have a lot of seasoned Java developers developing classic web pages utilizing Spring MVC. But these web pages obviously lack the "richness" users expect from todays web pages. The ability to develop in Java and have the GWT cross-compiler handle the JavaScript was perfect to us.

We started out with plain GWT but soon found out that the widgets provided by Google are not enough for what we were looking for - therefore we decided to use a widget-library on top of GWT. At the time of the assessment there were two major ones we considered - SmartGWT and extGWT ( a.k.a. GXT ) from Sencha which is a commercial product whereas SmartGWT is not. Having a closer look we found out that SmartGWT is in reality JavaScript objects from their already existing JavaScript framework with Java objects wrapped around them. ExtGWT essentially is also based on Sencha's extJS JavaScript framework but completely rebuilt in Java - no JavaScript anywhere. That was the reason we went for extGWT. Plus Dojo was no option at time as I expect to be a serious contender in the near future.

Our experience with GWT is excellent. From what I can tell there are some geniuses at work at Google ...

ExtGWT is another story: Basically we are pretty happy with it, but we are purely using the widgets and rolled our own data binding. It is a completely different thing to deal with data sets that contain just a few hundred records for which the data binding of extGWT might be sufficient than the large data sets we need to deal with that might contain billions of records. Batching and Paging ...

Most business logic validation is done on the OpenEdge AppServer. Only parts of the business logic that do not need access to the database are redundant in the client or the Servlet.

From our experience I can tell that the Java Open Client is a real beast and we are really happy with the combination - performance is really great ...

The servlet part is completely generic. It takes any JavaSDO ( the ProDataSet comes as JavaSDO ) converts into 2-dimensional arrays of Seriualizable which are handed out to the client. The generic data model on the client then hands it to the extGWT specific one which then converts the 2-dimensional arrays into extGWT specific objects of type BaseModel which are used by the extGWT widgets.

Forgot: The inability of the OpenEdge runtime and the OpenEdge AppServer to handle the SSL client certificate to do strong authentication forced us away from a pure ABL or .NET for ABL GUI.

Regards, Richard.

Richard,

Thanks for detailed reply.

Did you all consider the alternative of using Java Persistence API / Data Access Object (Hibernate etc.) to isolate the Progress Database from the business logic instead of using the Java Open Client API?

Any research results on that would be appreciated.

I am looking into it, and being that the volume of rows being at most in the 1000s, the Progress JDBC would suffice.

In your case of millions of rows being shunted around, that might have been the driver to use ProDataSet/SDO data transfer mechanism via native progress data access?

Our impetus is to allow us to switch to other data stores-- besides Progress-- in the future if we need to .... therefore the idea of using a data access object.

Thanks, Mike