Home » Modeling » EMF » EMF for EJB's (RMI / IIOP and Web service)
| | |
| Re: EMF for EJB's (RMI / IIOP and Web service) [message #421992 is a reply to message #421948] |
Wed, 20 August 2008 08:26   |
 Andrew H
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Hi Ed
See inline
Ed Merks wrote:
> Andrew,
> Comments below.
> Andrew H wrote:
>> We'd like to pass EMF based domain objects in and out of EJB's.
>>
>> We want to be able to access these EJB's via both:
>> - RMI / IIOP &
>> - Web Services
>>
>> I've read a number of threads that relate to Java Serialisation and
>> web services but I'm still not sure exactly what the state of play is
>> here.
> It seems to me that most people end up taking advantage of the ability
> to serialize to XML and then transfer that XML to resurrect the object
> on the other side. Even the SDO's EDataObjectImpl's support for
> java.io.Serializeable takes advantage of that approach. If you generate
> a model for SDO, as long as you put your objects in a DataGraph, they
> will directly support java.io.Serializeable.
I haven't really had time to evaluate SDO but from what I did read it
seemed to be more relevant in a pre hibernate world. I think much of what
it seemed to be trying to solve was limitations in EJB2.1 and earlier.
This may just be an out of date article. So I'm not sure what the case for
SDO is today.
Either way I was hoping that EJB & Webservices with EMF was possible
without needing to adopt SDO.
The advantage of something like EJB (or spring remoting etc.) is that you
don't have to get involved in the low level plumbing. I'd rather not have
to do a whole bunch of plumbing simply to be able to pass my domain
objects to / from remote RMI or SOAP services.
The RMI path is normally largely for free. You simply implement
Serializalble and viola your domain model can be passed around. Since this
tends to be lighter weight and easier to work with I would be very
reluctant to lose this.
The Web Services path can be a bit more involved but these days you can
get a basic web service up by adding a few more annotations to the same
EJB. If you want to get a better XSD then you may need to tweak the
mapping.
I did some reading today and, unfortunately, it looks like JEE Webservices
are hard wired to JAXB. i.e. we couldn't plug in a custom serialiser to
got to / from EMF which is a pain.
That leaves us with a couple of possibilities:
- We use our Java classes generated from ecore in our EJB service
contracts and get it to generate our schemas. Not ideal but could be
viable.
- We try to generate JAXB mappings between the EMF generated Java classes
and the EMF generated XML Schema. Not sure if this is possible and if so
how hard. But in theory then we might be able to get the Java models in
EMF with a schema we are happy with.
Are you aware of anyone attempting either of these?
>>
>> Would appreciate it if someone point out the steps involved in doing
>> this?
> I'd be interest to hear from anyone who's supported what Andrew is
> asking about without using SDO. I've always been interested to look at
> ways to support java.io.Serializeable without SDO. I can imagine it
> would be possible to use the same techniques as used in SDO, but to
> serialize and transfer all the resources in the resource set of the
> object...
Can you elaborate on what you mean here?
I think you may be talking about something different to what I am after. I
simply want to be able to use all my EMF generated Java classes in the
methods of remote services (preferrably EJB's), accessed via both RMI /
IIOP and SOAP.
How do Resources fit into that?
How does SDO Java Serialisation work? Does DataGraph implement the
standard readObject & writeObject and then do custom serialisation of the
whole EMF tree?
If so then thats not really what I am after either. I want to be able to
use any EMF domain object directly.
e.g.
public interface BookService {
public EList<Book> getBooks(Author a);
public void addBook(Book b, Author a);
}
Then I want to be able to remotely access a service that implemented an
interface like this via both RMI / IIOP and SOAP.
For that to work BookImpl & AuthorImpl and all the stuff that hangs off
them needs to implement Serializable.
The EMF generated classes don't implement Serializable by default. I fixed
that easily by creating a SerializableEObject that extends EObject and
Serializable and then put that as the base interface in the gen model.
That worked for the classes that I have created directly in Ecore. But the
ecore model I had generated from the industry XSD's ended up using in
built EMF data types like XMLCalendar which are not Serializable.
So that leaves us with either needing:
- to change the ecore model (or genmodel??) to change these types to
standard java.util.Date which should be Serializable.
- or to subclass EObjectImpl with custom serialisation
- or to have a top level class that has custom serialisation that is
responsible for serialising the whole EMF tree. Don't like this option.
Any thoughts on which path would be more likely to work?
It may be that the second & third options are the only viable ones if
there is a bunch of stuff in EObjectImpl that should be marked transient
but isn't. Any thoughts there?
Incidentally, why is it hard to "support java.io.Serializeable without
SDO"? Isn't it just a matter of changing EObject and your built in data
types to implement Serializable and making sure that things that should
not serialize are marked transient?
Or are you talking about Serializing it via Resource's with the same
"cross document" concept supported.
IMO that latter may be desirable, but the former almost essential.
|
|
| | |
| Re: EMF for EJB's (RMI / IIOP and Web service) [message #422002 is a reply to message #421992] |
Wed, 20 August 2008 09:37 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Andrew,
Comments below.
Andrew H wrote:
> Hi Ed
>
> See inline
>
> Ed Merks wrote:
>
>> Andrew,
>
>> Comments below.
>
>> Andrew H wrote:
>>> We'd like to pass EMF based domain objects in and out of EJB's.
>>>
>>> We want to be able to access these EJB's via both:
>>> - RMI / IIOP &
>>> - Web Services
>>>
>>> I've read a number of threads that relate to Java Serialisation and
>>> web services but I'm still not sure exactly what the state of play
>>> is here.
>> It seems to me that most people end up taking advantage of the
>> ability to serialize to XML and then transfer that XML to resurrect
>> the object on the other side. Even the SDO's EDataObjectImpl's
>> support for java.io.Serializeable takes advantage of that approach.
>> If you generate a model for SDO, as long as you put your objects in a
>> DataGraph, they will directly support java.io.Serializeable.
>
> I haven't really had time to evaluate SDO but from what I did read it
> seemed to be more relevant in a pre hibernate world.
No, though I've never found SDO to be all that relevant given it's
effectively just a facade over EMF that hides much of EMF's power...
> I think much of what it seemed to be trying to solve was limitations
> in EJB2.1 and earlier. This may just be an out of date article. So I'm
> not sure what the case for SDO is today.
>
> Either way I was hoping that EJB & Webservices with EMF was possible
> without needing to adopt SDO.
Yes, it's not my favorite thing. But it's interesting how
java.io.Serializeable support was implemented because it could be
applied directly to EMF...
>
> The advantage of something like EJB (or spring remoting etc.) is that
> you don't have to get involved in the low level plumbing. I'd rather
> not have to do a whole bunch of plumbing simply to be able to pass my
> domain objects to / from remote RMI or SOAP services.
Yes, leave the plumbing to the plumbers. Of course EJBs are far from my
favorite thing as well...
>
> The RMI path is normally largely for free. You simply implement
> Serializalble and viola your domain model can be passed around. Since
> this tends to be lighter weight and easier to work with I would be
> very reluctant to lose this.
It only appears free. The tricky thing is often how much of your model
is dragged along because you want to pass just one object. But since
it's transparent what's going on, you might not have noticed you dragged
along everything including the kitchen sink...
>
> The Web Services path can be a bit more involved but these days you
> can get a basic web service up by adding a few more annotations to the
> same EJB. If you want to get a better XSD then you may need to tweak
> the mapping.
>
> I did some reading today and, unfortunately, it looks like JEE
> Webservices are hard wired to JAXB. i.e. we couldn't plug in a custom
> serialiser to got to / from EMF which is a pain.
There was a thread in the WTP newsgroup about using EMF. JEE seems to be
this ever expanding web of complexity with always yet another new
complex thing to make it simpler...
>
> That leaves us with a couple of possibilities:
> - We use our Java classes generated from ecore in our EJB service
> contracts and get it to generate our schemas. Not ideal but could be
> viable.
>
> - We try to generate JAXB mappings between the EMF generated Java
> classes and the EMF generated XML Schema. Not sure if this is possible
> and if so how hard. But in theory then we might be able to get the
> Java models in EMF with a schema we are happy with.
>
> Are you aware of anyone attempting either of these?
I know there as a WTP newsgroup thread about this. I'd have to search
for it, but you could too...
>
>>>
>>> Would appreciate it if someone point out the steps involved in doing
>>> this?
>> I'd be interest to hear from anyone who's supported what Andrew is
>> asking about without using SDO. I've always been interested to look
>> at ways to support java.io.Serializeable without SDO. I can imagine
>> it would be possible to use the same techniques as used in SDO, but
>> to serialize and transfer all the resources in the resource set of
>> the object...
>
> Can you elaborate on what you mean here?
If you have an EObject x, you can use x.eResource().getResourceSet() and
for each resource, it's very easy to call
save(<byte-array-output-stream>, null) to serialize it. Therefore it's
very easy to serialize and entire resource set. If you use
EcoreUtil.getURI(x) you'll have URI you can use to locate the original
object in that resource set. So some tricky implementations of write
replace on your EObjects and your ResourceSetImpl could solve the problem.
>
> I think you may be talking about something different to what I am
> after. I simply want to be able to use all my EMF generated Java
> classes in the methods of remote services (preferrably EJB's),
> accessed via both RMI / IIOP and SOAP.
> How do Resources fit into that?
Resources are the unit of Serialization in EMF; in true RESTful style,
all data is stored as resources.
>
> How does SDO Java Serialisation work? Does DataGraph implement the
> standard readObject & writeObject and then do custom serialisation of
> the whole EMF tree?
So tricky uses of writeReplace effectively turn the problem into
serializing the data graph (like a resource set) as XML and keeping a
reference of the object within that XML.
>
> If so then thats not really what I am after either. I want to be able
> to use any EMF domain object directly.
It's not so hard to keep your objects in resources. And keep in mind
that things like book all by itself without the associated authors is
not all that useful.
>
> e.g.
>
> public interface BookService {
>
> public EList<Book> getBooks(Author a);
>
> public void addBook(Book b, Author a);
> }
>
It's easy to keep a BookService in a resource. It's also each to create
a resource to hold it if it doesn't already have one.
> Then I want to be able to remotely access a service that implemented
> an interface like this via both RMI / IIOP and SOAP.
>
> For that to work BookImpl & AuthorImpl and all the stuff that hangs
> off them needs to implement Serializable.
Yep.
>
> The EMF generated classes don't implement Serializable by default. I
> fixed that easily by creating a SerializableEObject that extends
> EObject and Serializable and then put that as the base interface in
> the gen model.
Yep. SDO.genmodel even uses some other tricks like Root Implements
Interface that uses an EClass with EOperations with body annotations to
mix in the necessary implementation of writeReplace.
> That worked for the classes that I have created directly in Ecore. But
> the ecore model I had generated from the industry XSD's ended up using
> in built EMF data types like XMLCalendar which are not Serializable.
I'd certainly consider making that Serializeable if it would help... Is
that the only problem? I'd been told that such an approach does
generally work
>
> So that leaves us with either needing:
> - to change the ecore model (or genmodel??) to change these types to
> standard java.util.Date which should be Serializable. - or to subclass
> EObjectImpl with custom serialisation
Or asking me to make them Serializeable. Perhaps providing a patch so
that it would get done even faster...
> - or to have a top level class that has custom serialisation that is
> responsible for serialising the whole EMF tree. Don't like this option.
I kind of do, because it has the advantage of not depending on
implementation classes and hence not relying so much on having exactly
the same versions of the classes on either side of the wire...
>
> Any thoughts on which path would be more likely to work?
If there are simple things like a few non-serializeable data types, I'd
be happy to fix those. I've always been interested in a more flexible
writeReplace approach too, but haven't the time.
>
> It may be that the second & third options are the only viable ones if
> there is a bunch of stuff in EObjectImpl that should be marked
> transient but isn't. Any thoughts there?
The impression I've been given is that it works okay to just make
EObjects serializeable, which kind of surprised me...
>
>
> Incidentally, why is it hard to "support java.io.Serializeable without
> SDO"? Isn't it just a matter of changing EObject and your built in
> data types to implement Serializable and making sure that things that
> should not serialize are marked transient?
I might well be wanting a fancy SDO-like solution when a brute force
plain old solution works fine.
> Or are you talking about Serializing it via Resource's with the same
> "cross document" concept supported.
Yep.
>
> IMO that latter may be desirable, but the former almost essential.
I could imagine doing them all...
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: EMF for EJB's (RMI / IIOP and Web service) [message #422053 is a reply to message #422002] |
Thu, 21 August 2008 04:36 |
Andrew H
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Ed
see inline
Ed Merks wrote:
> Andrew,
> Comments below.
> Andrew H wrote:
>> Hi Ed
>>
>> See inline
>>
>> Ed Merks wrote:
>>
>>> Andrew,
>>
>>> Comments below.
>>
>>> Andrew H wrote:
>>>> We'd like to pass EMF based domain objects in and out of EJB's.
>>>>
>>>> We want to be able to access these EJB's via both:
>>>> - RMI / IIOP &
>>>> - Web Services
>>>>
>>>> I've read a number of threads that relate to Java Serialisation and
>>>> web services but I'm still not sure exactly what the state of play
>>>> is here.
>>> It seems to me that most people end up taking advantage of the
>>> ability to serialize to XML and then transfer that XML to resurrect
>>> the object on the other side. Even the SDO's EDataObjectImpl's
>>> support for java.io.Serializeable takes advantage of that approach.
>>> If you generate a model for SDO, as long as you put your objects in a
>>> DataGraph, they will directly support java.io.Serializeable.
>>
>> I haven't really had time to evaluate SDO but from what I did read it
>> seemed to be more relevant in a pre hibernate world.
> No, though I've never found SDO to be all that relevant given it's
> effectively just a facade over EMF that hides much of EMF's power...
>> I think much of what it seemed to be trying to solve was limitations
>> in EJB2.1 and earlier. This may just be an out of date article. So I'm
>> not sure what the case for SDO is today.
>>
>> Either way I was hoping that EJB & Webservices with EMF was possible
>> without needing to adopt SDO.
> Yes, it's not my favorite thing. But it's interesting how
> java.io.Serializeable support was implemented because it could be
> applied directly to EMF...
Sure. If I had more time I might look into it. For now we are in planning
stage and really just need to know whether or not EMF is a good fit for
what we want to do.
>>
>> The advantage of something like EJB (or spring remoting etc.) is that
>> you don't have to get involved in the low level plumbing. I'd rather
>> not have to do a whole bunch of plumbing simply to be able to pass my
>> domain objects to / from remote RMI or SOAP services.
> Yes, leave the plumbing to the plumbers. Of course EJBs are far from my
> favorite thing as well...
I'm not a great fan either but it does a bunch of stuff that we need. We
don't have to use EJB but then we need another answer that is no worse for
those things. Remoting via RMI / IIOP and web services are two such things.
If we can't do these things with EJB + EMF then we need EMF + something
else to do those things no worse than the EJB route and we can't justify
alot of effort in building this plumbing that EJB was giving us out of the
box.
One interesting alternative is via Spring, but even then I'd feel more
comfortable if EJB wasn't stricken off the table because we went with EMF.
>>
>> The RMI path is normally largely for free. You simply implement
>> Serializalble and viola your domain model can be passed around. Since
>> this tends to be lighter weight and easier to work with I would be
>> very reluctant to lose this.
> It only appears free. The tricky thing is often how much of your model
> is dragged along because you want to pass just one object. But since
> it's transparent what's going on, you might not have noticed you dragged
> along everything including the kitchen sink...
I agree. Our business application is largely about capturing a whole bunch
of data relating to a transaction. So we really capture two sorts of
things:
- data that is the details about what is being transacted
- and how that transaction relates to other data in the system. e.g.
people, organisations etc.
Obviously the people etc are not islands but related to other entities. So
if we wired that "static" data into the transaction data then if you
dragged all the relationships with it you would end up with sending pretty
much the whole database across the wire.
Looking at the Resource stuff in EMF it seemed like it can offer a
possible solution to that by simply puting the "static" data in a
different resource to the transaction data.
So if someone can provide an implementation of standard Java Serialisation
that leveraged that and would work in an EJB environment then I would be
very interested in that.
However, that is an added bonus. If we just implemented our domain model
as a bunch of Java beans by hand then we would not have such a capability
by default. But we would have a model that we could serialise and use in
EJB.
For us EMF needs to offer at least that much. Any extra stuff is a bonus.
>>
>> The Web Services path can be a bit more involved but these days you
>> can get a basic web service up by adding a few more annotations to the
>> same EJB. If you want to get a better XSD then you may need to tweak
>> the mapping.
>>
>> I did some reading today and, unfortunately, it looks like JEE
>> Webservices are hard wired to JAXB. i.e. we couldn't plug in a custom
>> serialiser to got to / from EMF which is a pain.
> There was a thread in the WTP newsgroup about using EMF. JEE seems to be
> this ever expanding web of complexity with always yet another new
> complex thing to make it simpler...
Yeah I think they really stuffed up the developer experience. Spring can
trace much of its popularity to the poor developer experience that J2EE
created. The latest version of JEE does improve that somewhat.
But it is still an important standard, so IMO for EMF to be used in these
sorts of business applications it would really benefit from having a good
JEE story.
>>
>> That leaves us with a couple of possibilities:
>> - We use our Java classes generated from ecore in our EJB service
>> contracts and get it to generate our schemas. Not ideal but could be
>> viable.
>>
>> - We try to generate JAXB mappings between the EMF generated Java
>> classes and the EMF generated XML Schema. Not sure if this is possible
>> and if so how hard. But in theory then we might be able to get the
>> Java models in EMF with a schema we are happy with.
>>
>> Are you aware of anyone attempting either of these?
> I know there as a WTP newsgroup thread about this. I'd have to search
> for it, but you could too...
>>
>>>>
>>>> Would appreciate it if someone point out the steps involved in doing
>>>> this?
>>> I'd be interest to hear from anyone who's supported what Andrew is
>>> asking about without using SDO. I've always been interested to look
>>> at ways to support java.io.Serializeable without SDO. I can imagine
>>> it would be possible to use the same techniques as used in SDO, but
>>> to serialize and transfer all the resources in the resource set of
>>> the object...
>>
>> Can you elaborate on what you mean here?
> If you have an EObject x, you can use x.eResource().getResourceSet() and
> for each resource, it's very easy to call
> save(<byte-array-output-stream>, null) to serialize it. Therefore it's
> very easy to serialize and entire resource set. If you use
> EcoreUtil.getURI(x) you'll have URI you can use to locate the original
> object in that resource set. So some tricky implementations of write
> replace on your EObjects and your ResourceSetImpl could solve the problem.
Right so (as you mention below) the Java Serialisation would then use XML
serialisation under the covers.
So this would technically solve the problem but would be as inefficient as
sending XML.
I wonder if there is a way to implement writeObject & readObject in
EObjectImpl that could serialise as efficiently as normal Java
Serialisation but leveraged the ResourceSets in the process.
In our case I would only want to send the one resource (i.e. the
transaction data) but with references (proxies) to the "static" data in
other resources. That implies that recipients of the "transaction" data
had a mechanism to resolve the linked "static" data if they needed. Of
course I'm basing this on my newbie idea of how all this works so this may
not make sense.
An alternative is the hibernate model wiht its lazy loading proxies.
>>
>> I think you may be talking about something different to what I am
>> after. I simply want to be able to use all my EMF generated Java
>> classes in the methods of remote services (preferrably EJB's),
>> accessed via both RMI / IIOP and SOAP.
>> How do Resources fit into that?
> Resources are the unit of Serialization in EMF; in true RESTful style,
> all data is stored as resources.
I hadn't made the REST connection with the resources, but seems obvious
now you mention it.
A good REST story is a good thing too. But in our world Web Services is
the anointed stack regardless of its merits or otherwise. So for us a good
Web Service story is essential.
>>
>> How does SDO Java Serialisation work? Does DataGraph implement the
>> standard readObject & writeObject and then do custom serialisation of
>> the whole EMF tree?
> So tricky uses of writeReplace effectively turn the problem into
> serializing the data graph (like a resource set) as XML and keeping a
> reference of the object within that XML.
>>
>> If so then thats not really what I am after either. I want to be able
>> to use any EMF domain object directly.
> It's not so hard to keep your objects in resources. And keep in mind
> that things like book all by itself without the associated authors is
> not all that useful.
Yes that's true but the data sets may be too large to carry around all the
time. The only place that has access to the full data set in our world is
the database. e.g. within a hibernate session. Other tiers will always
work with a small subset of the data that they fetch and cache.
That's why I'm interested in a way to wire the transaction data to the
static data but then only serialise effectively foreign keys to that
static data. When we hit the persistence tier I'd want to wire that into
the real persistent entity. In that world we could traverse the full model.
>>
>> e.g.
>>
>> public interface BookService {
>>
>> public EList<Book> getBooks(Author a);
>>
>> public void addBook(Book b, Author a);
>> }
>>
> It's easy to keep a BookService in a resource. It's also each to create
> a resource to hold it if it doesn't already have one.
I'm not sure I follow that. How would that work if BookService is a proxy
for a remote service accessed over either RMI / IIOP or SOAP?
>> Then I want to be able to remotely access a service that implemented
>> an interface like this via both RMI / IIOP and SOAP.
>>
>> For that to work BookImpl & AuthorImpl and all the stuff that hangs
>> off them needs to implement Serializable.
> Yep.
>>
>> The EMF generated classes don't implement Serializable by default. I
>> fixed that easily by creating a SerializableEObject that extends
>> EObject and Serializable and then put that as the base interface in
>> the gen model.
> Yep. SDO.genmodel even uses some other tricks like Root Implements
> Interface that uses an EClass with EOperations with body annotations to
> mix in the necessary implementation of writeReplace.
Do you mean that the root class is set up to be special and therefore
handle the serialisation of the entire tree?
>> That worked for the classes that I have created directly in Ecore. But
>> the ecore model I had generated from the industry XSD's ended up using
>> in built EMF data types like XMLCalendar which are not Serializable.
> I'd certainly consider making that Serializeable if it would help... Is
> that the only problem? I'd been told that such an approach does
> generally work
Yes that would help enormously as would a patch. Would greatly appreciate
that.
I worked through the example I'd tripped over yesterday till it worked.
Obviously this is probably only the tip of the iceberg but its a start at
least.
There were 3 things that I tripped over that all need to implement
Serializable:
1/ EObject
2/ XMLCalandar
3/ EStructuralFeatureImpl$ContainmentUpdatingFeatureMapEntry
Note: I got past 2 & 3 by avoiding them as a short term hack. I changed
the type in the ecore model from XMLDate to EDate and went into the
generated source that had the FeatureMap and marked the field transient.
So it may be more involved than just making these things implement
Serializable.
Also I have not looked inside EObjectImpl etc to see if there is stuff
that should be marked transient. Obviously any event listeners etc should
not get serialised.
All the custom data types would need to be serialisable. As would all the
collections and core model code. All the core Java types are probably
already Serializable.
thanks a lot for your help
|
|
| |
| Re: EMF for EJB's (RMI / IIOP and Web service) [message #422058 is a reply to message #422053] |
Thu, 21 August 2008 06:10 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------090209050205050602020704
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Andrew,
Comments below.
Andrew H wrote:
> Ed
>
> see inline
>
> Ed Merks wrote:
>
>> Andrew,
>
>> Comments below.
>
>> Andrew H wrote:
>>> Hi Ed
>>>
>>> See inline
>>>
>>> Ed Merks wrote:
>>>
>>>> Andrew,
>>>
>>>> Comments below.
>>>
>>>> Andrew H wrote:
>>>>> We'd like to pass EMF based domain objects in and out of EJB's.
>>>>>
>>>>> We want to be able to access these EJB's via both:
>>>>> - RMI / IIOP &
>>>>> - Web Services
>>>>>
>>>>> I've read a number of threads that relate to Java Serialisation
>>>>> and web services but I'm still not sure exactly what the state of
>>>>> play is here.
>>>> It seems to me that most people end up taking advantage of the
>>>> ability to serialize to XML and then transfer that XML to resurrect
>>>> the object on the other side. Even the SDO's EDataObjectImpl's
>>>> support for java.io.Serializeable takes advantage of that
>>>> approach. If you generate a model for SDO, as long as you put your
>>>> objects in a DataGraph, they will directly support
>>>> java.io.Serializeable.
>>>
>>> I haven't really had time to evaluate SDO but from what I did read
>>> it seemed to be more relevant in a pre hibernate world.
>> No, though I've never found SDO to be all that relevant given it's
>> effectively just a facade over EMF that hides much of EMF's power...
>>> I think much of what it seemed to be trying to solve was limitations
>>> in EJB2.1 and earlier. This may just be an out of date article. So
>>> I'm not sure what the case for SDO is today.
>>>
>>> Either way I was hoping that EJB & Webservices with EMF was possible
>>> without needing to adopt SDO.
>> Yes, it's not my favorite thing. But it's interesting how
>> java.io.Serializeable support was implemented because it could be
>> applied directly to EMF...
>
> Sure. If I had more time I might look into it. For now we are in
> planning stage and really just need to know whether or not EMF is a
> good fit for what we want to do.
Yes, wouldn't more time be nice.
>
>>>
>>> The advantage of something like EJB (or spring remoting etc.) is
>>> that you don't have to get involved in the low level plumbing. I'd
>>> rather not have to do a whole bunch of plumbing simply to be able to
>>> pass my domain objects to / from remote RMI or SOAP services.
>> Yes, leave the plumbing to the plumbers. Of course EJBs are far from
>> my favorite thing as well...
>
> I'm not a great fan either but it does a bunch of stuff that we need.
> We don't have to use EJB but then we need another answer that is no
> worse for those things. Remoting via RMI / IIOP and web services are
> two such things.
>
> If we can't do these things with EJB + EMF then we need EMF +
> something else to do those things no worse than the EJB route and we
> can't justify alot of effort in building this plumbing that EJB was
> giving us out of the box.
>
> One interesting alternative is via Spring, but even then I'd feel more
> comfortable if EJB wasn't stricken off the table because we went with
> EMF.
I've not worked with RMI/IIOP so I'm not sure all the possible
alternatives for how you might package up what you need to send across.
Certainly EObject -> String -> EObject is a fairly straight forward
problem to solve. I.e., given that you can produce an XML serialization
for pretty much any instance and read it back in it's merely a matter of
orchestration...
>
>>>
>>> The RMI path is normally largely for free. You simply implement
>>> Serializalble and viola your domain model can be passed around.
>>> Since this tends to be lighter weight and easier to work with I
>>> would be very reluctant to lose this.
>> It only appears free. The tricky thing is often how much of your
>> model is dragged along because you want to pass just one object. But
>> since it's transparent what's going on, you might not have noticed
>> you dragged along everything including the kitchen sink...
>
> I agree. Our business application is largely about capturing a whole
> bunch of data relating to a transaction. So we really capture two
> sorts of things:
> - data that is the details about what is being transacted
> - and how that transaction relates to other data in the system. e.g.
> people, organisations etc.
EMF's change model can be quite useful from a transaction point of
view. It can be used to keep track of what changed, represent that as a
change description which is just another model instance that can be
serialized and transmitted.
>
> Obviously the people etc are not islands but related to other
> entities. So if we wired that "static" data into the transaction data
> then if you dragged all the relationships with it you would end up
> with sending pretty much the whole database across the wire.
>
> Looking at the Resource stuff in EMF it seemed like it can offer a
> possible solution to that by simply puting the "static" data in a
> different resource to the transaction data.
Yep. You'd just be transmitting proxy URIs could could be resolve or
not at the other end. For example, you might send some data to a
client, they modify it while change recording, and then send a change
description back. The change description only contains proxy references
to the original objects that were modified, so they aren't transmitted
back; only the minimal delta representation of the changes...
>
> So if someone can provide an implementation of standard Java
> Serialisation that leveraged that and would work in an EJB environment
> then I would be very interested in that.
Maybe one day I'll have more time for that...
>
> However, that is an added bonus. If we just implemented our domain
> model as a bunch of Java beans by hand then we would not have such a
> capability by default. But we would have a model that we could
> serialise and use in EJB.
>
> For us EMF needs to offer at least that much. Any extra stuff is a bonus.
>
>>>
>>> The Web Services path can be a bit more involved but these days you
>>> can get a basic web service up by adding a few more annotations to
>>> the same EJB. If you want to get a better XSD then you may need to
>>> tweak the mapping.
>>>
>>> I did some reading today and, unfortunately, it looks like JEE
>>> Webservices are hard wired to JAXB. i.e. we couldn't plug in a
>>> custom serialiser to got to / from EMF which is a pain.
>> There was a thread in the WTP newsgroup about using EMF. JEE seems to
>> be this ever expanding web of complexity with always yet another new
>> complex thing to make it simpler...
>
> Yeah I think they really stuffed up the developer experience. Spring
> can trace much of its popularity to the poor developer experience that
> J2EE created. The latest version of JEE does improve that somewhat.
>
> But it is still an important standard, so IMO for EMF to be used in
> these sorts of business applications it would really benefit from
> having a good JEE story.
Of course when JEE sinks under its own weight, I'd hate to go down with
that ship. :-P
>
>>>
>>> That leaves us with a couple of possibilities:
>>> - We use our Java classes generated from ecore in our EJB service
>>> contracts and get it to generate our schemas. Not ideal but could be
>>> viable.
>>>
>>> - We try to generate JAXB mappings between the EMF generated Java
>>> classes and the EMF generated XML Schema. Not sure if this is
>>> possible and if so how hard. But in theory then we might be able to
>>> get the Java models in EMF with a schema we are happy with.
>>>
>>> Are you aware of anyone attempting either of these?
>> I know there as a WTP newsgroup thread about this. I'd have to
>> search for it, but you could too...
>>>
>>>>>
>>>>> Would appreciate it if someone point out the steps involved in
>>>>> doing this?
>>>> I'd be interest to hear from anyone who's supported what Andrew is
>>>> asking about without using SDO. I've always been interested to
>>>> look at ways to support java.io.Serializeable without SDO. I can
>>>> imagine it would be possible to use the same techniques as used in
>>>> SDO, but to serialize and transfer all the resources in the
>>>> resource set of the object...
>>>
>>> Can you elaborate on what you mean here?
>> If you have an EObject x, you can use x.eResource().getResourceSet()
>> and for each resource, it's very easy to call
>> save(<byte-array-output-stream>, null) to serialize it. Therefore
>> it's very easy to serialize and entire resource set. If you use
>> EcoreUtil.getURI(x) you'll have URI you can use to locate the
>> original object in that resource set. So some tricky implementations
>> of write replace on your EObjects and your ResourceSetImpl could
>> solve the problem.
>
> Right so (as you mention below) the Java Serialisation would then use
> XML serialisation under the covers.
>
> So this would technically solve the problem but would be as
> inefficient as sending XML.
I think you're assuming Java serialization is efficient when I think
it's not even remotely efficient.
>
>
> I wonder if there is a way to implement writeObject & readObject in
> EObjectImpl that could serialise as efficiently as normal Java
> Serialisation but leveraged the ResourceSets in the process.
I think it's possible to do it drastically more efficiently, but that's
just a theory...
>
> In our case I would only want to send the one resource (i.e. the
> transaction data) but with references (proxies) to the "static" data
> in other resources. That implies that recipients of the "transaction"
> data had a mechanism to resolve the linked "static" data if they
> needed. Of course I'm basing this on my newbie idea of how all this
> works so this may not make sense.
I can see that EMF would be attractive for that.
>
> An alternative is the hibernate model wiht its lazy loading proxies.
Teneo supports Hibernate. You might also find the CDO story interesting.
>
>>>
>>> I think you may be talking about something different to what I am
>>> after. I simply want to be able to use all my EMF generated Java
>>> classes in the methods of remote services (preferrably EJB's),
>>> accessed via both RMI / IIOP and SOAP.
>>> How do Resources fit into that?
>> Resources are the unit of Serialization in EMF; in true RESTful
>> style, all data is stored as resources.
>
> I hadn't made the REST connection with the resources, but seems
> obvious now you mention it.
>
> A good REST story is a good thing too. But in our world Web Services
> is the anointed stack regardless of its merits or otherwise. So for us
> a good Web Service story is essential.
I though good web services were RESTful. :-P
>
>>>
>>> How does SDO Java Serialisation work? Does DataGraph implement the
>>> standard readObject & writeObject and then do custom serialisation
>>> of the whole EMF tree?
>> So tricky uses of writeReplace effectively turn the problem into
>> serializing the data graph (like a resource set) as XML and keeping a
>> reference of the object within that XML.
>>>
>>> If so then thats not really what I am after either. I want to be
>>> able to use any EMF domain object directly.
>> It's not so hard to keep your objects in resources. And keep in mind
>> that things like book all by itself without the associated authors is
>> not all that useful.
>
> Yes that's true but the data sets may be too large to carry around all
> the time. The only place that has access to the full data set in our
> world is the database. e.g. within a hibernate session. Other tiers
> will always work with a small subset of the data that they fetch and
> cache.
>
> That's why I'm interested in a way to wire the transaction data to the
> static data but then only serialise effectively foreign keys to that
> static data. When we hit the persistence tier I'd want to wire that
> into the real persistent entity. In that world we could traverse the
> full model.
Sounds like the change description kind of approach.
>
>>>
>>> e.g.
>>>
>>> public interface BookService {
>>>
>>> public EList<Book> getBooks(Author a);
>>>
>>> public void addBook(Book b, Author a);
>>> }
>>>
>> It's easy to keep a BookService in a resource. It's also each to
>> create a resource to hold it if it doesn't already have one.
>
> I'm not sure I follow that. How would that work if BookService is a
> proxy for a remote service accessed over either RMI / IIOP or SOAP?
A resource is just a container in which to put an object so that it can
be addressed via the URI of that resource and serialized in the style
supported by that resource. It's possible to put every object in it's
own resource as have all references to other objects serialized as
proxies where those proxies are just URI-based references to the URI of
the resource containing the other object.
>
>>> Then I want to be able to remotely access a service that implemented
>>> an interface like this via both RMI / IIOP and SOAP.
>>>
>>> For that to work BookImpl & AuthorImpl and all the stuff that hangs
>>> off them needs to implement Serializable.
>> Yep.
>>>
>>> The EMF generated classes don't implement Serializable by default. I
>>> fixed that easily by creating a SerializableEObject that extends
>>> EObject and Serializable and then put that as the base interface in
>>> the gen model.
>> Yep. SDO.genmodel even uses some other tricks like Root Implements
>> Interface that uses an EClass with EOperations with body annotations
>> to mix in the necessary implementation of writeReplace.
>
> Do you mean that the root class is set up to be special and therefore
> handle the serialisation of the entire tree?
The generator finds the EClass associated with the Root Implements
Interface (by looking for a EClass with the named class as it's
instanceClassName). That EClass is treated the same as if the model
explicitly extends it. So the EOperations of the class will generate
stubs in the generated AbcImpl and if the operation has a body
annotation, that stub is generated in the AbcImpl. That's how this
method ends up in every generated SDO object:
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public Object writeReplace() throws ObjectStreamException
{
return SDOUtil.writeReplace(this);
}
>
>>> That worked for the classes that I have created directly in Ecore.
>>> But the ecore model I had generated from the industry XSD's ended up
>>> using in built EMF data types like XMLCalendar which are not
>>> Serializable.
>> I'd certainly consider making that Serializeable if it would help...
>> Is that the only problem? I'd been told that such an approach does
>> generally work
>
> Yes that would help enormously as would a patch. Would greatly
> appreciate that.
Please open a bugzilla feature request.
>
> I worked through the example I'd tripped over yesterday till it
> worked. Obviously this is probably only the tip of the iceberg but its
> a start at least.
That's not what I'd heard... :-P
>
> There were 3 things that I tripped over that all need to implement
> Serializable:
>
> 1/ EObject
No, only the implementation classes for your model need to be
serializeable. You could accomplish that using GenModel settings the
way that SDO.genmodel does.
> 2/ XMLCalandar
I think this should be directly supported by the EMF runtime.
> 3/ EStructuralFeatureImpl$ContainmentUpdatingFeatureMapEntry
This gets a little bit more murky. It implies BasicFeatureMapEntry must
be serializeable and that has a reference to the Ecore model. Its not
going to be correct simply to serialize an entire Ecore model so that
the receiver ends up with a clone of what was on the client side. So
models with feature maps are going to be problematic. Of course we
could serialize references to static generated Ecore models using
EcoreUtil.getURI and resolving the result using the
EPackage.Registry.INSTANCE, but there are also dynamic models to consider...
>
> Note: I got past 2 & 3 by avoiding them as a short term hack. I
> changed the type in the ecore model from XMLDate to EDate and went
> into the generated source that had the FeatureMap and marked the field
> transient. So it may be more involved than just making these things
> implement Serializable.
>
> Also I have not looked inside EObjectImpl etc to see if there is stuff
> that should be marked transient. Obviously any event listeners etc
> should not get serialised.
And that's part of the issue with something as general as EMF. Some
clients may well have adapters that are serializeable and which they
want to have transmitted. So it's hard within EObjectImpl used by
everyone to build a one-size-fits-all solution, especially considering
that changes there might break existing clients who have rolled their own...
>
> All the custom data types would need to be serialisable. As would all
> the collections and core model code. All the core Java types are
> probably already Serializable.
Yes.
>
> thanks a lot for your help
>
--------------090209050205050602020704
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Andrew,<br>
<br>
Comments below.<br>
<br>
<br>
Andrew H wrote:
<blockquote
cite="mid:f5ba64bb27cfd3454b7e20505534d6ca$1@www.eclipse.org"
type="cite">Ed
<br>
<br>
see inline
<br>
<br>
Ed Merks wrote:
<br>
<br>
<blockquote type="cite">Andrew,
<br>
</blockquote>
<br>
<blockquote type="cite">Comments below.
<br>
</blockquote>
<br>
<blockquote type="cite">Andrew H wrote:
<br>
<blockquote type="cite">Hi Ed
<br>
<br>
See inline
<br>
<br>
Ed Merks wrote:
<br>
<br>
<blockquote type="cite">Andrew,
<br>
</blockquote>
<br>
<blockquote type="cite">Comments below.
<br>
</blockquote>
<br>
<blockquote type="cite">Andrew H wrote:
<br>
<blockquote type="cite">We'd like to pass EMF based domain
objects in and out of EJB's.
<br>
<br>
We want to be able to access these EJB's via both:
<br>
- RMI / IIOP &
<br>
- Web Services
<br>
<br>
I've read a number of threads that relate to Java Serialisation and web
services but I'm still not sure exactly what the state of play is here.
<br>
</blockquote>
It seems to me that most people end up taking advantage of the ability
to serialize to XML and then transfer that XML to resurrect the object
on the other side.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: EMF for EJB's (RMI / IIOP and Web service) [message #422102 is a reply to message #422058] |
Fri, 22 August 2008 03:38 |
Andrew H
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Ed
see inline
>> One interesting alternative is via Spring, but even then I'd feel more
>> comfortable if EJB wasn't stricken off the table because we went with
>> EMF.
> I've not worked with RMI/IIOP so I'm not sure all the possible
> alternatives for how you might package up what you need to send across.
> Certainly EObject -> String -> EObject is a fairly straight forward
> problem to solve. I.e., given that you can produce an XML serialization
> for pretty much any instance and read it back in it's merely a matter of
> orchestration...
RMI / IIOP just piggybacks of standard Java Serialisation. i.e. as a
programmer you don't need to do anything special for the IIOP (corba) bit
really, you just make sure that your classes serialise acceptably. For
many classes thats just implementing Serializable.
This does though include the Externalisable option too though I believe
http://java.sun.com/javase/6/docs/platform/serialization/spe c/serial-arch.html#7185
>>
>> Looking at the Resource stuff in EMF it seemed like it can offer a
>> possible solution to that by simply puting the "static" data in a
>> different resource to the transaction data.
> Yep. You'd just be transmitting proxy URIs could could be resolve or
> not at the other end. For example, you might send some data to a
> client, they modify it while change recording, and then send a change
> description back. The change description only contains proxy references
> to the original objects that were modified, so they aren't transmitted
> back; only the minimal delta representation of the changes...
Some interesting possibilities here.
>> But it is still an important standard, so IMO for EMF to be used in
>> these sorts of business applications it would really benefit from
>> having a good JEE story.
> Of course when JEE sinks under its own weight, I'd hate to go down with
> that ship. :-P
I don't think you need to be a JEE flag bearer, just work with it :-)
>> So this would technically solve the problem but would be as
>> inefficient as sending XML.
> I think you're assuming Java serialization is efficient when I think
> it's not even remotely efficient.
It may not win any awards for efficiency but at least its a binary
protocol. XML & Web services are very verbose in comparison. Sure there
are compression tricks but plain RMI will send lots less over the wire
than with XML
>> A good REST story is a good thing too. But in our world Web Services
>> is the anointed stack regardless of its merits or otherwise. So for us
>> a good Web Service story is essential.
> I though good web services were RESTful. :-P
That could get somewhat religious, but from a practical point of view the
WSDL, SOAP etc stack is the one that is hard to avoid in organisations
like mine.
>>>>
>>>> public interface BookService {
>>>>
>>>> public EList<Book> getBooks(Author a);
>>>>
>>>> public void addBook(Book b, Author a);
>>>> }
>>>>
>>> It's easy to keep a BookService in a resource. It's also each to
>>> create a resource to hold it if it doesn't already have one.
>>
>> I'm not sure I follow that. How would that work if BookService is a
>> proxy for a remote service accessed over either RMI / IIOP or SOAP?
> A resource is just a container in which to put an object so that it can
> be addressed via the URI of that resource and serialized in the style
> supported by that resource. It's possible to put every object in it's
> own resource as have all references to other objects serialized as
> proxies where those proxies are just URI-based references to the URI of
> the resource containing the other object.
Let me see if I follow. So if I wanted to fetch the books for Auther "Fred
Flintstone" from the server I would do something like
Resource svcResouce = resourceSet.getResource(<uri for service>);
BookService bookSvc = svcResource.getBookService();
return bookSvc.getBooks(fred);
then if fred lives in another resource somehow the serialisation process
would send a URI to fred rather than fred itself. Am I even close to what
you are getting at here?
>> Do you mean that the root class is set up to be special and therefore
>> handle the serialisation of the entire tree?
> The generator finds the EClass associated with the Root Implements
> Interface (by looking for a EClass with the named class as it's
> instanceClassName). That EClass is treated the same as if the model
> explicitly extends it. So the EOperations of the class will generate
> stubs in the generated AbcImpl and if the operation has a body
> annotation, that stub is generated in the AbcImpl. That's how this
> method ends up in every generated SDO object:
> /**
> * <!-- begin-user-doc -->
> * <!-- end-user-doc -->
> * @generated
> */
> public Object writeReplace() throws ObjectStreamException
> {
> return SDOUtil.writeReplace(this);
> }
I hadn't forgotten about the writeReplace method. That does create
interesting possibilities. In that case I could still have a BookService
interface with the domain models in it like above but what is actually
sent across the wire is deltas.
What does it send though when I create a new Book and want to send that
across the wire? Surely the Book then needs to be serialised or does it
avoid that too somehow?
Maybe I need to look more closely at SDO. I thought it forced me to create
service contracts like
void addBook(DataGraph graph)
but maybe I misunderstood it. The doco seems largely geared around the
editor which doesn't fit what I am doing. I guess that's kind of the norm
for all the EMF related stuff ;)
>>
>>>> That worked for the classes that I have created directly in Ecore.
>>>> But the ecore model I had generated from the industry XSD's ended up
>>>> using in built EMF data types like XMLCalendar which are not
>>>> Serializable.
>>> I'd certainly consider making that Serializeable if it would help...
>>> Is that the only problem? I'd been told that such an approach does
>>> generally work
>>
>> Yes that would help enormously as would a patch. Would greatly
>> appreciate that.
> Please open a bugzilla feature request.
OK I'll register and do that soon.
>>
>> There were 3 things that I tripped over that all need to implement
>> Serializable:
>>
>> 1/ EObject
> No, only the implementation classes for your model need to be
> serializeable. You could accomplish that using GenModel settings the
> way that SDO.genmodel does.
Yeah either works for me. As the impls implement the EObject interface
then that's pretty straight forward too.
It would have been nice if it was in EObjectImpl itself as otherwise I
need to edit all the genmodels. Guess I'll live though
>> 2/ XMLCalandar
> I think this should be directly supported by the EMF runtime.
>> 3/ EStructuralFeatureImpl$ContainmentUpdatingFeatureMapEntry
> This gets a little bit more murky. It implies BasicFeatureMapEntry must
> be serializeable and that has a reference to the Ecore model. Its not
> going to be correct simply to serialize an entire Ecore model so that
> the receiver ends up with a clone of what was on the client side. So
> models with feature maps are going to be problematic. Of course we
> could serialize references to static generated Ecore models using
> EcoreUtil.getURI and resolving the result using the
> EPackage.Registry.INSTANCE, but there are also dynamic models to consider...
To be honest I don't like all the FeatureMap bits in the model. They are
there cause of the schemas that we imported, but we will likely refactor
the model and get rid of them. What's important to us is having a nice
domain model, the schema is secondary.
>>
>> Note: I got past 2 & 3 by avoiding them as a short term hack. I
>> changed the type in the ecore model from XMLDate to EDate and went
>> into the generated source that had the FeatureMap and marked the field
>> transient. So it may be more involved than just making these things
>> implement Serializable.
>>
>> Also I have not looked inside EObjectImpl etc to see if there is stuff
>> that should be marked transient. Obviously any event listeners etc
>> should not get serialised.
> And that's part of the issue with something as general as EMF. Some
> clients may well have adapters that are serializeable and which they
> want to have transmitted. So it's hard within EObjectImpl used by
> everyone to build a one-size-fits-all solution, especially considering
> that changes there might break existing clients who have rolled their own...
I hadn't considered that there was a use case for sending the listeners
around.
In that case we may need our own base class that implements writeObject
(or possibly the writeReplace approach) and cleans out this stuff.
Would be nice to have some support in the framework here that maybe
delegates the serialisation to some strategy object with some default
strategies like the one I'm after in there too. I might add that to the
issue. You did sound like you weren't very busy :-)
|
|
|
| Re: EMF for EJB's (RMI / IIOP and Web service) [message #422112 is a reply to message #422102] |
Fri, 22 August 2008 09:43 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Andrew,
Comments below.
Andrew H wrote:
> Ed
>
> see inline
>
>>> One interesting alternative is via Spring, but even then I'd feel
>>> more comfortable if EJB wasn't stricken off the table because we
>>> went with EMF.
>> I've not worked with RMI/IIOP so I'm not sure all the possible
>> alternatives for how you might package up what you need to send
>> across. Certainly EObject -> String -> EObject is a fairly straight
>> forward problem to solve. I.e., given that you can produce an XML
>> serialization for pretty much any instance and read it back in it's
>> merely a matter of orchestration...
>
> RMI / IIOP just piggybacks of standard Java Serialisation. i.e. as a
> programmer you don't need to do anything special for the IIOP (corba)
> bit really, you just make sure that your classes serialise acceptably.
> For many classes thats just implementing Serializable.
>
> This does though include the Externalisable option too though I believe
> http://java.sun.com/javase/6/docs/platform/serialization/spe c/serial-arch.html#7185
>
Oh. :-)
>
>>>
>>> Looking at the Resource stuff in EMF it seemed like it can offer a
>>> possible solution to that by simply puting the "static" data in a
>>> different resource to the transaction data.
>> Yep. You'd just be transmitting proxy URIs could could be resolve or
>> not at the other end. For example, you might send some data to a
>> client, they modify it while change recording, and then send a change
>> description back. The change description only contains proxy
>> references to the original objects that were modified, so they aren't
>> transmitted back; only the minimal delta representation of the
>> changes...
>
> Some interesting possibilities here.
>>> But it is still an important standard, so IMO for EMF to be used in
>>> these sorts of business applications it would really benefit from
>>> having a good JEE story.
>> Of course when JEE sinks under its own weight, I'd hate to go down
>> with that ship. :-P
>
> I don't think you need to be a JEE flag bearer, just work with it :-)
I might feel cheap and dirty. :-P
>
>>> So this would technically solve the problem but would be as
>>> inefficient as sending XML.
>> I think you're assuming Java serialization is efficient when I think
>> it's not even remotely efficient.
>
> It may not win any awards for efficiency but at least its a binary
> protocol. XML & Web services are very verbose in comparison. Sure
> there are compression tricks but plain RMI will send lots less over
> the wire than with XML
>
>>> A good REST story is a good thing too. But in our world Web Services
>>> is the anointed stack regardless of its merits or otherwise. So for
>>> us a good Web Service story is essential.
>> I though good web services were RESTful. :-P
>
> That could get somewhat religious, but from a practical point of view
> the WSDL, SOAP etc stack is the one that is hard to avoid in
> organisations like mine.
Indeed.
>
>>>>>
>>>>> public interface BookService {
>>>>>
>>>>> public EList<Book> getBooks(Author a);
>>>>>
>>>>> public void addBook(Book b, Author a);
>>>>> }
>>>>>
>>>> It's easy to keep a BookService in a resource. It's also each to
>>>> create a resource to hold it if it doesn't already have one.
>>>
>>> I'm not sure I follow that. How would that work if BookService is a
>>> proxy for a remote service accessed over either RMI / IIOP or SOAP?
>> A resource is just a container in which to put an object so that it
>> can be addressed via the URI of that resource and serialized in the
>> style supported by that resource. It's possible to put every object
>> in it's own resource as have all references to other objects
>> serialized as proxies where those proxies are just URI-based
>> references to the URI of the resource containing the other object.
>
> Let me see if I follow. So if I wanted to fetch the books for Auther
> "Fred Flintstone" from the server I would do something like
>
> Resource svcResouce = resourceSet.getResource(<uri for service>);
> BookService bookSvc = svcResource.getBookService();
> return bookSvc.getBooks(fred);
>
> then if fred lives in another resource somehow the serialisation
> process would send a URI to fred rather than fred itself. Am I even
> close to what you are getting at here?
Yes, that's the idea. Though you'd use resource.getContents(). And any
references in that resource to objects not in the resource would be
proxies that are resolved automatically and transparently if or when
they are needed.
>
>
>>> Do you mean that the root class is set up to be special and
>>> therefore handle the serialisation of the entire tree?
>> The generator finds the EClass associated with the Root Implements
>> Interface (by looking for a EClass with the named class as it's
>> instanceClassName). That EClass is treated the same as if the model
>> explicitly extends it. So the EOperations of the class will generate
>> stubs in the generated AbcImpl and if the operation has a body
>> annotation, that stub is generated in the AbcImpl. That's how this
>> method ends up in every generated SDO object:
>
>> /**
>> * <!-- begin-user-doc -->
>> * <!-- end-user-doc -->
>> * @generated
>> */
>> public Object writeReplace() throws ObjectStreamException
>> {
>> return SDOUtil.writeReplace(this);
>> }
>
> I hadn't forgotten about the writeReplace method. That does create
> interesting possibilities. In that case I could still have a
> BookService interface with the domain models in it like above but what
> is actually sent across the wire is deltas.
>
> What does it send though when I create a new Book and want to send
> that across the wire? Surely the Book then needs to be serialised or
> does it avoid that too somehow?
In SDO, it walks up the the DataGraph, serializes the whole data graph,
which is effectively like a resource set with a main resource for the
root DataObject and possibly some more to represent dynamic models, and
then serialized the URI of the starting object so that the object can be
located within the XML.
>
> Maybe I need to look more closely at SDO. I thought it forced me to
> create service contracts like
> void addBook(DataGraph graph)
>
> but maybe I misunderstood it. The doco seems largely geared around the
> editor which doesn't fit what I am doing. I guess that's kind of the
> norm for all the EMF related stuff ;)
The editor is just an example to show how to work with it in the UI. I
think the most interesting thing about SDO are some of the
implementation tricks used there.
>
>>>
>>>>> That worked for the classes that I have created directly in Ecore.
>>>>> But the ecore model I had generated from the industry XSD's ended
>>>>> up using in built EMF data types like XMLCalendar which are not
>>>>> Serializable.
>>>> I'd certainly consider making that Serializeable if it would
>>>> help... Is that the only problem? I'd been told that such an
>>>> approach does generally work
>>>
>>> Yes that would help enormously as would a patch. Would greatly
>>> appreciate that.
>> Please open a bugzilla feature request.
>
> OK I'll register and do that soon.
>
>>>
>>> There were 3 things that I tripped over that all need to implement
>>> Serializable:
>>>
>>> 1/ EObject
>> No, only the implementation classes for your model need to be
>> serializeable. You could accomplish that using GenModel settings the
>> way that SDO.genmodel does.
>
> Yeah either works for me. As the impls implement the EObject interface
> then that's pretty straight forward too.
>
> It would have been nice if it was in EObjectImpl itself as otherwise I
> need to edit all the genmodels. Guess I'll live though
It's possible to write a plugin to make the changes to the GenModel
instance with a single click (like the Set SDO Defaults action).
>
>>> 2/ XMLCalandar
>> I think this should be directly supported by the EMF runtime.
>>> 3/ EStructuralFeatureImpl$ContainmentUpdatingFeatureMapEntry
>> This gets a little bit more murky. It implies BasicFeatureMapEntry
>> must be serializeable and that has a reference to the Ecore model.
>> Its not going to be correct simply to serialize an entire Ecore model
>> so that the receiver ends up with a clone of what was on the client
>> side. So models with feature maps are going to be problematic. Of
>> course we could serialize references to static generated Ecore models
>> using EcoreUtil.getURI and resolving the result using the
>> EPackage.Registry.INSTANCE, but there are also dynamic models to
>> consider...
>
> To be honest I don't like all the FeatureMap bits in the model.
They kind of suck in general.
> They are there cause of the schemas that we imported, but we will
> likely refactor the model and get rid of them. What's important to us
> is having a nice domain model, the schema is secondary.
This blog might help if there are substitution group issues:
http://ed-merks.blogspot.com/2007/12/winters-icy-grip.html
>
>>>
>>> Note: I got past 2 & 3 by avoiding them as a short term hack. I
>>> changed the type in the ecore model from XMLDate to EDate and went
>>> into the generated source that had the FeatureMap and marked the
>>> field transient. So it may be more involved than just making these
>>> things implement Serializable.
>>>
>>> Also I have not looked inside EObjectImpl etc to see if there is
>>> stuff that should be marked transient. Obviously any event listeners
>>> etc should not get serialised.
>> And that's part of the issue with something as general as EMF. Some
>> clients may well have adapters that are serializeable and which they
>> want to have transmitted. So it's hard within EObjectImpl used by
>> everyone to build a one-size-fits-all solution, especially
>> considering that changes there might break existing clients who have
>> rolled their own...
>
> I hadn't considered that there was a use case for sending the
> listeners around.
I've seen every wacky thing you might imagine...
>
> In that case we may need our own base class that implements
> writeObject (or possibly the writeReplace approach) and cleans out
> this stuff.
>
> Would be nice to have some support in the framework here that maybe
> delegates the serialisation to some strategy object with some default
> strategies like the one I'm after in there too. I might add that to
> the issue. You did sound like you weren't very busy :-)
Note the time this is being posted? :-P
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: EMF for EJB's (RMI / IIOP and Web service) [message #422128 is a reply to message #422123] |
Fri, 22 August 2008 11:10 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Mario,
Thanks for sharing your experience and giving some excellent advice.
Often simple solutions are the best ones...
Mario Winterer wrote:
> Andrew, Ed!
>
> We're working with EMF in our RCP application since years and also
> using EMF model objects as transfer objects between client and (j2ee)
> server.
> For that purpose we're using a (non-emf) "carrier object" that
> transports a single or a list of model objects from server to client
> and vice versa.
>
> for example, our article session bean looks like follows:
> ...
> public TransferObject<Article> findArticles(String nameWithWildcards);
> public void addArticle(TransferObject<Article> articleTO);
> ...
>
> The EMF-specific implementation of the TransferObject-interface (so,
> the EMFTransferObject) implements the Externalizable interface and
> serializes all its model objects using EMF XML serialization directly
> into the underlying output stream.
>
> Although this solution is not very sophisticated, it works fine and it
> is far more tolerant concerning model incompatibilities between server
> and client than standard java serialization.
>
> Mario
>
>
> Ed Merks schrieb:
>> Andrew,
>>
>> Comments below.
>>
>> Andrew H wrote:
>>> We'd like to pass EMF based domain objects in and out of EJB's.
>>>
>>> We want to be able to access these EJB's via both:
>>> - RMI / IIOP &
>>> - Web Services
>>>
>>> I've read a number of threads that relate to Java Serialisation and
>>> web services but I'm still not sure exactly what the state of play
>>> is here.
>> It seems to me that most people end up taking advantage of the
>> ability to serialize to XML and then transfer that XML to resurrect
>> the object on the other side. Even the SDO's EDataObjectImpl's
>> support for java.io.Serializeable takes advantage of that approach.
>> If you generate a model for SDO, as long as you put your objects in a
>> DataGraph, they will directly support java.io.Serializeable.
>>>
>>> Would appreciate it if someone point out the steps involved in doing
>>> this?
>> I'd be interest to hear from anyone who's supported what Andrew is
>> asking about without using SDO. I've always been interested to look
>> at ways to support java.io.Serializeable without SDO. I can imagine
>> it would be possible to use the same techniques as used in SDO, but
>> to serialize and transfer all the resources in the resource set of
>> the object...
>>>
>>>
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
Goto Forum:
Current Time: Thu Apr 25 16:01:42 GMT 2024
Powered by FUDForum. Page generated in 0.04987 seconds |
] 
Search
Help
Register
Login
Home
