> If a standard API exists (ISO, OGC or JCP), I would like to push very > hard for using it. Finally the question of a standard API; if you have any suggestions I am open to them (hence my review of Future/Executor/Callable).
Other things to review: - ISO - I cannot review ISO standards; pay to play is not worth it on this one. I also trust that the OGC WPS spec will of mentioned related ISO specifications. Some ISO specs exist around SOA that may be interesting ... but my experience thus far has been to wait for something from TC211 - OGC - we have looked at the OGC WPS; this is where the requirement to report on progress comes from; mostly this specification contributes on the Parameter side of things. While we could copy this specificaiton as is; I would like to cater to the Java programmer a bit more. On the plus side the specification already provides a few geospatial specific ideas and examples. - W3C - xforms and a few other standards are related to these problems - OASIS - defines the BPEL standard, very successful format used mostly as an interchange format between vendors - JCP -- Service Component Architecture (SCA) and Service Data Objects (SDO) things have stalled since about 2003, I can find some recent activity in 2007. -- Message Drive Beans, an early attempt by J2EE to return to good old fashioned Objects; this one allows Enterprise beans to accept messages like a normal object Finally a bunch of specific technologies have been reviewed: - YAWL - Yet Another Workflow Language, seems to be the most complete (and surpasses BPEL in vigor and correctness) - Eclipse SOA Tools Platform (STP) - sadly these seems ahead of the JCP entries; the marvels of money - JBoss Process Manager (JBPM) - very weak on parameter definition, a lot better than last time I looked at it, cannot tell what there biggest need is (scripting web pages or message driven beans) > Creating our own API on our side add conceptual complexity: > developpers need to keep in their brain a wider range of relationships. > So why Process needs to be unrelated to Callable? The need for > reporting progress and supporting cancelation doesn't prevent us from > defining Process as a Callable specialisation as far as I can see. Agreed; see example in previous email of how Process can extend Callable. However I must insist we pay attention to the *design* of Callable; the design prevents the idea of a list of listeners directly on the Process. I also note that Callable is an example of how to cleanly extend Runnable for the activity of producing a single value. As such they make use of a specific method, ie Object call() throws Exception, rather than run(). I noticed when treating Callable as a good design: - allowing call to throw an Exception; since exception handling is a pain that gets away of someone writing a Callable quickly - forcing call to explicitly return an Object to ensure that the implementor actually produces something, and take away the responsibility of holding on to a property after execution has completed - I also note they Callable is documented as "similar to to Runnable", and go on to list the differences... - They also use the Executors class to adapt other interfaces to Callable as needed, all without showing the exact adapters used With this in mind I am much more comfortable making the Process interface narrow and exacting, indeed perhaps their have already been too many compromises. So how about this for a plan: - dial back Process and make the fun stuff come down to a single method - write a ProgressTask( Process ) that accepts a list of listeners and has a cancel method - stop thinking and move on - since we are out of time Jody ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
