Programatic access
5 views
Skip to first unread message
Alex
Oct 12, 2009, 4:10:01 AM10/12/09
to EsiObjects Community
Hi all,
Are the EsiObjects "library" types for creating and modifying
EsiObject class definitions.
I'm wondering whether it is possible to do something with POJO for
EsiObjects.
Can a java service be created that given a JAR / directory of java
class files can read through the defintions and create corresponding
EsiObject proxies.
I can't see any facility to mix internal mumps methods with externally
projected java methods.
Cheers
Alex
Are the EsiObjects "library" types for creating and modifying
EsiObject class definitions.
I'm wondering whether it is possible to do something with POJO for
EsiObjects.
Can a java service be created that given a JAR / directory of java
class files can read through the defintions and create corresponding
EsiObject proxies.
I can't see any facility to mix internal mumps methods with externally
projected java methods.
Cheers
Alex
Terry L. Wiechmann
Oct 12, 2009, 9:45:42 AM10/12/09
to EsiOb...@googlegroups.com
Clearly we need to develop the Java interface more extensively. We have
the Java proxy generation capability, why not the reverse?
Since I usually develop a rash when dealing with the Java complexity, I
will defer these questions to Jerry or anyone else who has that knowledge.
PS: After look at some POJO documentation, am I correct in assuming it
is an attempt to wrap and hide that complexity?
Terry L. Wiechmann
978-779-0257
http://www.esitechnology.com
the Java proxy generation capability, why not the reverse?
Since I usually develop a rash when dealing with the Java complexity, I
will defer these questions to Jerry or anyone else who has that knowledge.
PS: After look at some POJO documentation, am I correct in assuming it
is an attempt to wrap and hide that complexity?
Terry L. Wiechmann
978-779-0257
http://www.esitechnology.com
Jerry Goodnough
Oct 13, 2009, 3:57:26 PM10/13/09
to EsiOb...@googlegroups.com
Alex,
I believe that it would be very simple to read compiled Java class and
using reflection create proxies for plain old java objects (POJOs). Can
you flesh out what your requirements for the proxies would be ? As it
stands now the existing proxies actually forward all requests back to
the server - I've often wanted them to offer cache forwarding. Also I
would expect that when you ran the tool against the POJOs (or Beans for
that matter) you would want EO classes generated. Another issue would be
if you want some form of generic data holder on the EO side that can
hold any POJO be dynamically proxied the gateway to the pojo - This is
technically possible but is a more complex problem.
Jerry
I believe that it would be very simple to read compiled Java class and
using reflection create proxies for plain old java objects (POJOs). Can
you flesh out what your requirements for the proxies would be ? As it
stands now the existing proxies actually forward all requests back to
the server - I've often wanted them to offer cache forwarding. Also I
would expect that when you ran the tool against the POJOs (or Beans for
that matter) you would want EO classes generated. Another issue would be
if you want some form of generic data holder on the EO side that can
hold any POJO be dynamically proxied the gateway to the pojo - This is
technically possible but is a more complex problem.
Jerry
Alex Woodhead
Oct 13, 2009, 5:55:24 PM10/13/09
to EsiOb...@googlegroups.com
Hi Jerry,
Thanks for your suggestions and recommendations.
I've been communicating with Terry about a design pattern in appengine that goes in the opposite direction to POJO.
Actually there are a few vendors already doing this besides google.
Using the DataNucleus Access platform:
... basically takes a compiled java class and enhances the byte code to work with your data store.
So effectively build a data provider plugin for datanucleus could make EsiObjects / GT.M a pluggable object store. So one can host with google or host with GT.M. Its a deployment choice.
Its also nice in that a Java developer doesn't need to learn any EsiObjects or GT.M and they just use Eclipse and existing familar JDO tools.
With regard to cache forwarding I think there is the idea of connected and disconnected objects in datanucleus object lifecycle:
I'm thinking longer term one could set up a GT.M sandbox service for prospects to sign up and try out. Maybe host on EC2 infrastructure?
Needs a little web management viewer, to manage objects and bulk uploads. Could use GWT as the UI?
Of course this is all theory at the moment.
Needs real Java skills to make this one happen.
Cheers
Alex
Terry
Oct 14, 2009, 11:08:23 AM10/14/09
to EsiObjects Community
A little background regarding this message. Alex and I started
discussing uses for the EsiDB package I've developed outside of this
group. It evolved into a possible application for EsiObjects. I've
included the core of our discussions below the ----- line.
Bottom line: Use EsiObjects as a persistent Object Store within
Google's appengine. Put EsiObjects on GT.M in the cloud and provide a
way for Java (later C#) programmers to generate the store via POJO's.
They would create and use it without any knowledge of EsiObjects. This
is an extremely interesting application for EO. I think it would be
competitive from a performance perspective. It would make a nice add-
on business for existing businesses.
On Oct 13, 5:55 pm, Alex Woodhead <alexatwoodh...@googlemail.com>
wrote:
I know that you have looked at EWD as a web front for EsiObjects
applications. An alternative is the open source google web tool kit.
Here all the developer needs to know is Java.
* By deploying on appengine there is no sql / tables / stored
procedures to write.
* By using GWT the client side of the application is compiled from
Java into JavaScript.
There is no generating of html server side. The client side of the
application is delivered in a single static compressed JavaScript
file. It is cached on the client browser. All JavaScript code is
obfuscated into very compact code. The default remoting of "Java"
objects for GWT is also more efficient than JSON.
If you like Events in EsiObjects, think of all those great anonymous
event handlers that get translated into safe JavaScript. I couldn't
compete with JavaScript coding by hand.
I think the days of server pages for new web apps (not websites) has
reached a point of decline. Silverlight is now in its third release
and is a real contender for Flash and Flex. Like GWT these depend on
pre-compiled proxy cached static content delivery.
--------------------
I know that you have looked at EWD as a web front for EsiObjects
applications. An alternative is the open source google web tool kit.
Here all the developer needs to know is Java.
* By deploying on appengine there is no sql / tables / stored
procedures to write.
* By using GWT the client side of the application is compiled from
Java into JavaScript.
There is no generating of html server side. The client side of the
application is delivered in a single static compressed JavaScript
file. It is cached on the client browser. All JavaScript code is
obfuscated into very compact code. The default remoting of "Java"
objects for GWT is also more efficient than JSON.
If you like Events in EsiObjects, think of all those great anonymous
event handlers that get translated into safe JavaScript. I couldn't
compete with JavaScript coding by hand.
I think the days of server pages for new web apps (not websites) has
reached a point of decline. Silverlight is now in its third release
and is a real contender for Flash and Flex. Like GWT these depend on
pre-compiled proxy cached static content delivery.
By implementing the JDO interface as a link to EsiObjects / GT.M you
make appengine apps portable to use EsiObjects.
What is the selling point? GoogleBigTable is write consistent but is
is relatively slow at saving data. A GT.M store would have a much
higher throughput.
Its taking a specific set of developer skills and saying, if you have
these skills but need an app written in that technology to behave
better with respect to data that is updated regularly, has a lot of
writes, then GT.M could be a deployment option.
I might have said this one before but here goes anyway:
Oracle has a cloud backup option. As part of the standard backup tools
you can backup and restore from an Amazon storage bucket. This would
be interesting from a specific mumps database vendor point of view.
I brought up a statement that indicated everyone was required to use
BigTable within the app engine.
Yes. If a person has written an appengine product and hosts it on
Google it may only use Appengine datastore (BigTable) / memcache
(temp / volatile).
However an appengine application is portable being a servlet and the
storage is plugable being JDO.
Google has implemented a "plugin" for data nucleus as their gateway to
bigtable.
http://www.datanucleus.org/
This is an Apache 2 license framework. There are other object oriented
databases that use this framework.
Instead of implementing database objects and then exporting a Java
projection, this is working in the other direction.
This is a tool aimed at a Java programmer with no time to think about
the database. They just want to persist their objects and run object
queries.
When a user develops their application locally on their development
workstation the eclipse plugin learns how the user, uses their data
and generates automatic indexes. When the developer uploads their
application from the Eclipse IDE to google, the index hints are also
uploaded.
A user can tweak indexes in this file as they learn more and have the
inclination to speed things up. But the initial impact is that it is
quick to start with. :)
The JDOQL implementation provided by Google is very simple because of
the type of underlying data store. It should be relatively straight
forward to emulate these simple queries against globals.
A selling point should be that a Java developer just uses their
existing toolset (Eclispse IDE) and running with EsiObjects + GT.M is
just a deployment option.
Obviously one can offer more complex queries then Google appstore so
leads a prospect down the GT.M path?
The only different things I'd expect a prospect to have to learn would
be a slightly different jdo config file and sign-up for a GT.M data
sandbox.
I think the really clever thing about appengine is the security
context for Java that they have implemented. This ensures no one may
run Java malware on their infrastructure.
There is an example of a site that uses both Google appengine and
Amazon EC2 hosted services.
For simple queries against a very large dataset they use appengine
data store.
For complex work / queries the application uses EC2.
A limitation of out bound connections from appengine is one has to
return results within 10 seconds. Factor in HTTPS and network latency
this generates a need for fast response times for queries, or
asynchronous behaviours.
Perhaps a market here is no need to learn more than JDO, if you use a
GT.M object database service.
* Provide a good interface for bulk uploads and downloads.
* Provide an admin web interface to inspect your object store.
I think developing a DataNucleus plugin for EsiObject / GT.M is a
possible plan?
More...
Just looking in "Programming Google App Engine" in Rough Cuts on
O'Reilly Safari Books online.
Chapter 8. The Java Persistence API.
Mentions: [The] Access Platform hooks up the persistence plumbing to
your JPA data classes in a post-compilation process that it calls
"enhancement."
So basically this is saying that the DataNucleus tool takes an
existing compiled Java class and enhances the bytescode to work with
the specific persistence plugin.
http://www.datanucleus.org/products/accessplatform_1_1/bytecode_enhancement.html
Hence it operates in opposite direction to EsiObjects / Cache java
projection.
By implementing the JDO interface as a link to EsiObjects / GT.M you
make appengine apps portable to use EsiObjects.
What is the selling point? GoogleBigTable is write consistent but is
is relatively slow at saving data. A GT.M store would have a much
higher throughput.
Its taking a specific set of developer skills and saying, if you have
these skills but need an app written in that technology to behave
better with respect to data that is updated regularly, has a lot of
writes, then GT.M could be a deployment option.
I might have said this one before but here goes anyway:
Oracle has a cloud backup option. As part of the standard backup tools
you can backup and restore from an Amazon storage bucket. This would
be interesting from a specific mumps database vendor point of view.
I brought up a statement that indicated everyone was required to use
BigTable within the app engine.
Yes. If a person has written an appengine product and hosts it on
Google it may only use Appengine datastore (BigTable) / memcache
(temp / volatile).
However an appengine application is portable being a servlet and the
storage is plugable being JDO.
Google has implemented a "plugin" for data nucleus as their gateway to
bigtable.
http://www.datanucleus.org/
This is an Apache 2 license framework. There are other object oriented
databases that use this framework.
Instead of implementing database objects and then exporting a Java
projection, this is working in the other direction.
This is a tool aimed at a Java programmer with no time to think about
the database. They just want to persist their objects and run object
queries.
When a user develops their application locally on their development
workstation the eclipse plugin learns how the user, uses their data
and generates automatic indexes. When the developer uploads their
application from the Eclipse IDE to google, the index hints are also
uploaded.
A user can tweak indexes in this file as they learn more and have the
inclination to speed things up. But the initial impact is that it is
quick to start with. :)
The JDOQL implementation provided by Google is very simple because of
the type of underlying data store. It should be relatively straight
forward to emulate these simple queries against globals.
A selling point should be that a Java developer just uses their
existing toolset (Eclispse IDE) and running with EsiObjects + GT.M is
just a deployment option.
Obviously one can offer more complex queries then Google appstore so
leads a prospect down the GT.M path?
The only different things I'd expect a prospect to have to learn would
be a slightly different jdo config file and sign-up for a GT.M data
sandbox.
I think the really clever thing about appengine is the security
context for Java that they have implemented. This ensures no one may
run Java malware on their infrastructure.
There is an example of a site that uses both Google appengine and
Amazon EC2 hosted services.
For simple queries against a very large dataset they use appengine
data store.
For complex work / queries the application uses EC2.
A limitation of out bound connections from appengine is one has to
return results within 10 seconds. Factor in HTTPS and network latency
this generates a need for fast response times for queries, or
asynchronous behaviours.
Perhaps a market here is no need to learn more than JDO, if you use a
GT.M object database service.
* Provide a good interface for bulk uploads and downloads.
* Provide an admin web interface to inspect your object store.
I think developing a DataNucleus plugin for EsiObject / GT.M is a
possible plan?
More...
Just looking in "Programming Google App Engine" in Rough Cuts on
O'Reilly Safari Books online.
Chapter 8. The Java Persistence API.
Mentions: [The] Access Platform hooks up the persistence plumbing to
your JPA data classes in a post-compilation process that it calls
"enhancement."
So basically this is saying that the DataNucleus tool takes an
existing compiled Java class and enhances the bytescode to work with
the specific persistence plugin.
http://www.datanucleus.org/products/accessplatform_1_1/bytecode_enhancement.html
Hence it operates in opposite direction to EsiObjects / Cache java
projection.
discussing uses for the EsiDB package I've developed outside of this
group. It evolved into a possible application for EsiObjects. I've
included the core of our discussions below the ----- line.
Bottom line: Use EsiObjects as a persistent Object Store within
Google's appengine. Put EsiObjects on GT.M in the cloud and provide a
way for Java (later C#) programmers to generate the store via POJO's.
They would create and use it without any knowledge of EsiObjects. This
is an extremely interesting application for EO. I think it would be
competitive from a performance perspective. It would make a nice add-
on business for existing businesses.
On Oct 13, 5:55 pm, Alex Woodhead <alexatwoodh...@googlemail.com>
wrote:
> Hi Jerry,
> Thanks for your suggestions and recommendations.
>
> I've been communicating with Terry about a design pattern in appengine that
> goes in the opposite direction to POJO.
> Actually there are a few vendors already doing this besides google.
>
> Using the DataNucleus Access platform:
>
> http://www.datanucleus.org/products/accessplatform/bytecode_enhanceme...
> Thanks for your suggestions and recommendations.
>
> I've been communicating with Terry about a design pattern in appengine that
> goes in the opposite direction to POJO.
> Actually there are a few vendors already doing this besides google.
>
> Using the DataNucleus Access platform:
>
>
> ... basically takes a compiled java class and enhances the byte code to work
> with your data store.
>
> So effectively build a data provider plugin for datanucleus could make
> EsiObjects / GT.M a pluggable object store. So one can host with google or
> host with GT.M. Its a deployment choice.
>
> Its also nice in that a Java developer doesn't need to learn any EsiObjects
> or GT.M and they just use Eclipse and existing familar JDO tools.
>
> With regard to cache forwarding I think there is the idea of connected and
> disconnected objects in datanucleus object lifecycle:
>
> http://www.datanucleus.org/products/accessplatform/object_lifecycle.html
>
> I'm thinking longer term one could set up a GT.M sandbox service for
> prospects to sign up and try out. Maybe host on EC2 infrastructure?
>
> Needs a little web management viewer, to manage objects and bulk uploads.
> Could use GWT as the UI?
>
> Of course this is all theory at the moment.
>
> Needs real Java skills to make this one happen.
>
> Cheers
>
> Alex
--------------------
> ... basically takes a compiled java class and enhances the byte code to work
> with your data store.
>
> So effectively build a data provider plugin for datanucleus could make
> EsiObjects / GT.M a pluggable object store. So one can host with google or
> host with GT.M. Its a deployment choice.
>
> Its also nice in that a Java developer doesn't need to learn any EsiObjects
> or GT.M and they just use Eclipse and existing familar JDO tools.
>
> With regard to cache forwarding I think there is the idea of connected and
> disconnected objects in datanucleus object lifecycle:
>
> http://www.datanucleus.org/products/accessplatform/object_lifecycle.html
>
> I'm thinking longer term one could set up a GT.M sandbox service for
> prospects to sign up and try out. Maybe host on EC2 infrastructure?
>
> Needs a little web management viewer, to manage objects and bulk uploads.
> Could use GWT as the UI?
>
> Of course this is all theory at the moment.
>
> Needs real Java skills to make this one happen.
>
> Cheers
>
> Alex
I know that you have looked at EWD as a web front for EsiObjects
applications. An alternative is the open source google web tool kit.
Here all the developer needs to know is Java.
* By deploying on appengine there is no sql / tables / stored
procedures to write.
* By using GWT the client side of the application is compiled from
Java into JavaScript.
There is no generating of html server side. The client side of the
application is delivered in a single static compressed JavaScript
file. It is cached on the client browser. All JavaScript code is
obfuscated into very compact code. The default remoting of "Java"
objects for GWT is also more efficient than JSON.
If you like Events in EsiObjects, think of all those great anonymous
event handlers that get translated into safe JavaScript. I couldn't
compete with JavaScript coding by hand.
I think the days of server pages for new web apps (not websites) has
reached a point of decline. Silverlight is now in its third release
and is a real contender for Flash and Flex. Like GWT these depend on
pre-compiled proxy cached static content delivery.
--------------------
I know that you have looked at EWD as a web front for EsiObjects
applications. An alternative is the open source google web tool kit.
Here all the developer needs to know is Java.
* By deploying on appengine there is no sql / tables / stored
procedures to write.
* By using GWT the client side of the application is compiled from
Java into JavaScript.
There is no generating of html server side. The client side of the
application is delivered in a single static compressed JavaScript
file. It is cached on the client browser. All JavaScript code is
obfuscated into very compact code. The default remoting of "Java"
objects for GWT is also more efficient than JSON.
If you like Events in EsiObjects, think of all those great anonymous
event handlers that get translated into safe JavaScript. I couldn't
compete with JavaScript coding by hand.
I think the days of server pages for new web apps (not websites) has
reached a point of decline. Silverlight is now in its third release
and is a real contender for Flash and Flex. Like GWT these depend on
pre-compiled proxy cached static content delivery.
By implementing the JDO interface as a link to EsiObjects / GT.M you
make appengine apps portable to use EsiObjects.
What is the selling point? GoogleBigTable is write consistent but is
is relatively slow at saving data. A GT.M store would have a much
higher throughput.
Its taking a specific set of developer skills and saying, if you have
these skills but need an app written in that technology to behave
better with respect to data that is updated regularly, has a lot of
writes, then GT.M could be a deployment option.
I might have said this one before but here goes anyway:
Oracle has a cloud backup option. As part of the standard backup tools
you can backup and restore from an Amazon storage bucket. This would
be interesting from a specific mumps database vendor point of view.
I brought up a statement that indicated everyone was required to use
BigTable within the app engine.
Yes. If a person has written an appengine product and hosts it on
Google it may only use Appengine datastore (BigTable) / memcache
(temp / volatile).
However an appengine application is portable being a servlet and the
storage is plugable being JDO.
Google has implemented a "plugin" for data nucleus as their gateway to
bigtable.
http://www.datanucleus.org/
This is an Apache 2 license framework. There are other object oriented
databases that use this framework.
Instead of implementing database objects and then exporting a Java
projection, this is working in the other direction.
This is a tool aimed at a Java programmer with no time to think about
the database. They just want to persist their objects and run object
queries.
When a user develops their application locally on their development
workstation the eclipse plugin learns how the user, uses their data
and generates automatic indexes. When the developer uploads their
application from the Eclipse IDE to google, the index hints are also
uploaded.
A user can tweak indexes in this file as they learn more and have the
inclination to speed things up. But the initial impact is that it is
quick to start with. :)
The JDOQL implementation provided by Google is very simple because of
the type of underlying data store. It should be relatively straight
forward to emulate these simple queries against globals.
A selling point should be that a Java developer just uses their
existing toolset (Eclispse IDE) and running with EsiObjects + GT.M is
just a deployment option.
Obviously one can offer more complex queries then Google appstore so
leads a prospect down the GT.M path?
The only different things I'd expect a prospect to have to learn would
be a slightly different jdo config file and sign-up for a GT.M data
sandbox.
I think the really clever thing about appengine is the security
context for Java that they have implemented. This ensures no one may
run Java malware on their infrastructure.
There is an example of a site that uses both Google appengine and
Amazon EC2 hosted services.
For simple queries against a very large dataset they use appengine
data store.
For complex work / queries the application uses EC2.
A limitation of out bound connections from appengine is one has to
return results within 10 seconds. Factor in HTTPS and network latency
this generates a need for fast response times for queries, or
asynchronous behaviours.
Perhaps a market here is no need to learn more than JDO, if you use a
GT.M object database service.
* Provide a good interface for bulk uploads and downloads.
* Provide an admin web interface to inspect your object store.
I think developing a DataNucleus plugin for EsiObject / GT.M is a
possible plan?
More...
Just looking in "Programming Google App Engine" in Rough Cuts on
O'Reilly Safari Books online.
Chapter 8. The Java Persistence API.
Mentions: [The] Access Platform hooks up the persistence plumbing to
your JPA data classes in a post-compilation process that it calls
"enhancement."
So basically this is saying that the DataNucleus tool takes an
existing compiled Java class and enhances the bytescode to work with
the specific persistence plugin.
http://www.datanucleus.org/products/accessplatform_1_1/bytecode_enhancement.html
Hence it operates in opposite direction to EsiObjects / Cache java
projection.
By implementing the JDO interface as a link to EsiObjects / GT.M you
make appengine apps portable to use EsiObjects.
What is the selling point? GoogleBigTable is write consistent but is
is relatively slow at saving data. A GT.M store would have a much
higher throughput.
Its taking a specific set of developer skills and saying, if you have
these skills but need an app written in that technology to behave
better with respect to data that is updated regularly, has a lot of
writes, then GT.M could be a deployment option.
I might have said this one before but here goes anyway:
Oracle has a cloud backup option. As part of the standard backup tools
you can backup and restore from an Amazon storage bucket. This would
be interesting from a specific mumps database vendor point of view.
I brought up a statement that indicated everyone was required to use
BigTable within the app engine.
Yes. If a person has written an appengine product and hosts it on
Google it may only use Appengine datastore (BigTable) / memcache
(temp / volatile).
However an appengine application is portable being a servlet and the
storage is plugable being JDO.
Google has implemented a "plugin" for data nucleus as their gateway to
bigtable.
http://www.datanucleus.org/
This is an Apache 2 license framework. There are other object oriented
databases that use this framework.
Instead of implementing database objects and then exporting a Java
projection, this is working in the other direction.
This is a tool aimed at a Java programmer with no time to think about
the database. They just want to persist their objects and run object
queries.
When a user develops their application locally on their development
workstation the eclipse plugin learns how the user, uses their data
and generates automatic indexes. When the developer uploads their
application from the Eclipse IDE to google, the index hints are also
uploaded.
A user can tweak indexes in this file as they learn more and have the
inclination to speed things up. But the initial impact is that it is
quick to start with. :)
The JDOQL implementation provided by Google is very simple because of
the type of underlying data store. It should be relatively straight
forward to emulate these simple queries against globals.
A selling point should be that a Java developer just uses their
existing toolset (Eclispse IDE) and running with EsiObjects + GT.M is
just a deployment option.
Obviously one can offer more complex queries then Google appstore so
leads a prospect down the GT.M path?
The only different things I'd expect a prospect to have to learn would
be a slightly different jdo config file and sign-up for a GT.M data
sandbox.
I think the really clever thing about appengine is the security
context for Java that they have implemented. This ensures no one may
run Java malware on their infrastructure.
There is an example of a site that uses both Google appengine and
Amazon EC2 hosted services.
For simple queries against a very large dataset they use appengine
data store.
For complex work / queries the application uses EC2.
A limitation of out bound connections from appengine is one has to
return results within 10 seconds. Factor in HTTPS and network latency
this generates a need for fast response times for queries, or
asynchronous behaviours.
Perhaps a market here is no need to learn more than JDO, if you use a
GT.M object database service.
* Provide a good interface for bulk uploads and downloads.
* Provide an admin web interface to inspect your object store.
I think developing a DataNucleus plugin for EsiObject / GT.M is a
possible plan?
More...
Just looking in "Programming Google App Engine" in Rough Cuts on
O'Reilly Safari Books online.
Chapter 8. The Java Persistence API.
Mentions: [The] Access Platform hooks up the persistence plumbing to
your JPA data classes in a post-compilation process that it calls
"enhancement."
So basically this is saying that the DataNucleus tool takes an
existing compiled Java class and enhances the bytescode to work with
the specific persistence plugin.
http://www.datanucleus.org/products/accessplatform_1_1/bytecode_enhancement.html
Hence it operates in opposite direction to EsiObjects / Cache java
projection.
Reply all
Reply to author
Forward
0 new messages