First things first

In order to communicate with an EOEditingContext through a web service, the first step is to create a Java object to wrap it, say BAEditingContext.java. Mine, looks like:

public class BAEditingContext {
   public EOEditingContext eoec;
   public BAEditingContext() {
      super();
      eoec = new EOEditingContext();
   }
   public String test(){
      return eoec.toString();
   }
}

We can check that initialisation was correct through the test method (recall how to publish a method in Consuming Calculator): add a line of the form

NSLog(@"eoec = %@",[BAEditingContextService test]);

and you will receive in your console something like

... eoec = com.webobjects.eocontrol.EOEditingContext@998537

The question now is: how to consume Enterprise Objects?
as serialised objects?
as dictionaries?

Let us see how does EOCustomObject traverses the service...

Cannot publish an EOEditingContext

While publishing, trough a WebService, an EOEditingContext (or a "son" of it), and trying to get the description of the service via

Szamitogep# /Developer/Tools/WSMakeStubs
   -x ObjC
   -name BAEditingContext
   -url  http://192.168.1.8:51123/cgi-bin/WebObjects/
      EditingContextService.woa/ws/BAEditingContext?wsdl

I got the following error:
- The class java.lang.Class is defined in a java or javax package and cannot be converted into an xml schema type. An xml schema anyType will be used to define this class in the wsdl file.
- The class com.webobjects.eocontrol.EOKeyValueUnarchiver does not contain a default constructor, which is a requirement for a bean class. The class cannot be converted into an xml schema type...
- The class java.lang.Number is defined in a java or javax package and cannot be converted into an xml schema type...
- The class com.webobjects.foundation.NSNotification does not contain a default constructor, which is a requirement for a bean class. The class cannot be converted into an xml schema type...
- The class java.lang.Throwable is defined in a java or javax package and cannot be converted into an xml schema type...
...

(o sea de que como quien dice)
¡NOT GOOD!

Let us try by wrapping it...

So far, no good solution

Long time with out writing... but I had not found nothing, good enough, to bring back EOF to the Desktop.
Andrew Lindesay claims that he is developping his own JSON-RPC to this end, but I had not found it easy to use, and, to be honest, I am not sure it is "the right way"; but, if you want to give it a try, go to lindesay.co.nz.

The main obstruction, so far, to substitute Cocoa EOF with WO Services has been that I had not found how to publish an EOEditingContext easily... let us try again...

What's NeXT?

The next step to successfully use Web Services to substitute Cocoa EOF is to publish into a service an EOEditingContext. In this way, Core Data should be able to use EOF, via those services offered by the Editing Context, as a persistence media.

I am not quite sure where to put the line (the service); on top of the Editing Context? or, even below it?
To transfer Enterprise Objects? or, shall I transfer Dictionaries?... it will depend in the performance... we will see.

By the moment, the idea is to have, in the server side, the persistence mechanisms offered by EOF; and in the client side, a Cocoa app running Core Data to manage Display Groups and all the consistency necessary in a complex db-model. For, the model will have to be duplicated in the two formats: .eomodeld and .xcdatamodel ...

... welcome to a new nightmare!