Re: Deserializing SDOs using scoped registries

[Raymond Feng]

Please see my further comments.

Thanks,
Raymond
----- Original Message ----- 
From: "Ron Gavlin" <[EMAIL PROTECTED]>
To: <tuscany-user@ws.apache.org>
Sent: Friday, May 26, 2006 11:45 AM
Subject: Re: Deserializing SDOs using scoped registries


Raymond,

Thanks for the input. See comments below.

- Ron

----- Original Message ----
From: Raymond Feng <[EMAIL PROTECTED]>
To: tuscany-user@ws.apache.org
Sent: Friday, May 26, 2006 1:04:29 PM
Subject: Re: Deserializing SDOs using scoped registries


Hi,

I have some comments as well.

Thanks,
Raymond

----- Original Message ----- 
From: "Ron Gavlin" <[EMAIL PROTECTED]>
To: <tuscany-user@ws.apache.org>
Sent: Friday, May 26, 2006 9:44 AM
Subject: Re: Deserializing SDOs using scoped registries


Frank,

My model is similar to the one listed below. The http://example.org/ord
namespace is statically registered while the
http://example.org/info/zipcode  and http://example.org/info/street
namespaces are dynamically registered. In my application, add'l "info"
namespaces maybe registered/de-registered on the fly so the "info"
namespaces can't be statically registered up front.

In both the client and server JVMs, the "ord" namespace is statically
registered and the "info" namespaces are dynamically registered. I am
attempting to pass (serialize/de-serialize) a DataGraph containing the
"Sample Instance" DataObject below between the client and server JVMs.

Currently, neither Tuscany SDO nor EMF/SDO out of the box appear to
support this "mixed" static/dynamic type of model (note how InfoType in
the "ord" namespace is extended in each of the "info" namespaces). I
subclassed several Tuscany and EMF classes (including XSDEcoreBuilder) to
add this support. With these enhancements, XMLHelper.INSTANCE.load()
successfully loads the "Sample Instance" as a DataObject using this
"mixed" model. I'm currently investigating whether I can contribute these
modifications back to Tuscany SDO and EMF.


<rfeng>This is an interesting topic. The basic question is: "Do we want to
honor the static model if its namespace is referenced by the XSD when
XSD2Ecore is performed?" . For example, your XSD has something like 
<element
name="customer" type="customer:Customer"/> and you already have a static
model registered for customer. I have some similar code as you
described.<rfeng>

<rg> Yes, you have described a more mainstream case. Our model in whiich a 
"dynamic" type extends a "static" type is probably less common and more 
demanding on the XMLLoader. <rg>

Now let me respond to your questions.

1a. You are correct, the dynamic models on the client side are stored in
local TypeHelper
registries, but the CORBA RMI only has access to the global EMF registry.
(I solved this problem by stealing the dynamic EPackages from the
TypeHelper's ExtendedMetaData and registering them myself in the global
EMF registry. Ugly, but it worked.


<rfeng>When you say local type helper, is it the one assoicated with the
application classloader? If so, I believe CORBA code has access to it 
since
the global registry will delegate to it.</rfeng>

<rg> The "local" TypeHelper registry I am referring to is the 
"extendedMetaData" member variable within the Tuscany TypeHelperImpl 
instance. When CORBA code accesses the registry for de-serialization, does 
it know to how to navigate beyond the global registry into the 
"extendedMetaData" within this particular TypeHelperImpl instance?<rg>


<rfeng>I checked the Tuscany SDO code and it seems that each TypeHelper has 
its own registry which delegates (only get, not put) to 
EPackage.Registry.INSTNACE which is classloader-aware.In this case, I 
understand CORBA code cannot assess the model in your TypeHelper instance. 
It leads to an interesting question: What registry does the 
DataGraph/DataObject java deserialization use? So really, we need to have a 
scope-aware registry and SDO should provide such a pluggability so that it 
will resolve to the same TypeHelper for serialization and deserialization in 
a given context.</rfeng>


1b. Not quite. The server-side CORBA RMI code accesses the server-side,
statically-registered "ord" package w/out difficulty using the global
classloader-specific delegate registries. However, the dynamic models
stored in the TypeHelper registries on the server cannot be accessed by
the CORBA RMI code (same problem as in 1a above). However, the trick
described above didn't work on the server presumably because of the 
server
classloader-specific delegate registries.

First, do you have any ideas how problem "1b" can be solved?

Second, assume for the moment that I had a pure dynamic model, i.e., the
"ord" namespace was dynamically rather than statically registered. How
would the CORBA RMI code get a reference to the appropriate, local
TypeHelper registries to de-serialize the DataGraph and its child
DataObjects?


<rfeng>By my experience, I didn't have problems in CORBA
serialization/deserialization (passing DataObject over RMI/IIOP) with
dynamic model using EMF/SDO 1.0.</rfeng>

<rg> My server application is packaged as an ear with child ejb and war 
modules. The EMF/SDO jars are stored in the APP-INF/lib directory of the 
ear. A startupServlet in the war module registers the static and dynamic 
modules. Session beans in the ejb module pass DataGraphs to/from an 
RMI/IIOP client. It may be that the war housing the startupServlet has a 
different classloader than its peer ejb module doing the 
serialization/de-serialization. If so, this may be causing the problem 
described above in 1b. Does that make sense? I'll check my appserver 
documentation to confirm.<rg>

<rfeng>Again, I used the classloader-aware registry and that's why it worked 
for me.</rfeng>


Thanks in advance for your assistance,

- Ron


So, a couple more questions for you:
1) you mention that you have a combination of static and dynamic models,
but if I'm not sure I understand the scenario you're describing. If I
understand it right, you have two problems:
  a) dynamic models on the client side are stored in local TypeHelper
registries, but the CORBA RMI only has access to the global EMF registry
... is that right?
   b) the static (?) models on the server side are registered in the
global registry, but since it's running in the appserver environment, the
metadata is actually going to the classloader-specific delegate 
registries
... but presumably, the CORBA RMI code is not running in the same
classloader as the app that registered the metadata.
   Do I have the two problems straight?
2) If the answer to the first question is yes, then what you're 
describing
is a scenario where the server has statically generated classes for a
model that on the client side is manipulated dynamically. Is that right?
3) Can you give me more details on how/where the metadata is registered 
on
both sides?


BTW, I have The "EDataGraphImpl" I can't afford to statically register
them. during thdefined at runtime

Sample Instance (chapter04.xml)
<ord:order xmlns:ord="<http://example.org/ord>";
xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>";
xsi:schemaLocation="<http://example.org/ord> chapter04ord1.xsd">
<ord:number>123ABBCC123</ord:number>
<ord:customer>
<ord:name>Pat Walmsley</ord:name>
<ord:number>15465</ord:number>
<info xsi:type="ns1:InfoType" xmlns=""
xmlns:ns1="<http://example.org/info/zipcode>";>
<zipcode>21043</zipcode>
</info>
</ord:customer>
<ord:customer>
<ord:name>Priscilla Walmsley</ord:name>
<ord:number>15466</ord:number>
<info xsi:type="ns1:InfoType" xmlns=""
xmlns:ns1="<http://example.org/info/street>";>
<street>341 Duckworth Way</street>
</info>
</ord:customer>
<ord:items>
<product>
<number>557</number>
<name>Short-Sleeved Linen Blouse</name>
<size system="US-DRESS">10</size>
<color value="blue"/>
</product>
</ord:items>
</ord:order>

Schema Document 1 (chapter04ord1.xsd)

<xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;
          targetNamespace="<http://example.org/ord>";;
          xmlns="<http://example.org/ord>";;
          xmlns:prod="<http://example.org/prod>";;
          elementFormDefault="qualified">

<xsd:import namespace="<http://example.org/prod>";;
schemaLocation="chapter04prod.xsd"/>
<xsd:simpleType name="OrderNumType">
  <xsd:restriction base="xsd:string"/>
</xsd:simpleType>

<xsd:complexType name="InfoType"/>

<xsd:complexType name="CustomerType">
  <xsd:sequence>
    <xsd:element name="name" type="CustNameType"/>
    <xsd:element name="number" type="xsd:integer"/>
    <xsd:element name="info" type="InfoType" form="unqualified"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:simpleType name="CustNameType">
  <xsd:restriction base="xsd:string"/>
</xsd:simpleType>

<xsd:element name="order" type="OrderType"/>
<xsd:complexType name="OrderType">
  <xsd:sequence>
    <xsd:element name="number" type="OrderNumType"/>
    <xsd:element name="customer" type="CustomerType"
maxOccurs="unbounded"/>
    <xsd:element name="items" type="prod:ItemsType"/>
  </xsd:sequence>
</xsd:complexType>

</xsd:schema>

Schema Document 2 (chapter04infozipcode.xsd)
<xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;
          xmlns:ord="<http://example.org/ord>";;
          xmlns="<http://example.org/info/zipcode>";;
          targetNamespace="<http://example.org/info/zipcode>";;
          elementFormDefault="unqualified">
<xsd:import namespace="<http://example.org/ord>";;
schemaLocation="chapter04ord1.xsd"/>
<xsd:complexType name="InfoType">
    <xsd:complexContent>
       <xsd:extension base="ord:InfoType">
          <xsd:sequence>
             <xsd:element name="zipcode" type="xsd:string"/>
          </xsd:sequence>
       </xsd:extension>
    </xsd:complexContent>
</xsd:complexType>

</xsd:schema>

Schema Document 3 (chapter04infostreet.xsd)
<xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;
          xmlns:ord="<http://example.org/ord>";;
          xmlns="<http://example.org/info/street>";;
          targetNamespace="<http://example.org/info/street>";;
          elementFormDefault="unqualified">
<xsd:import namespace="<http://example.org/ord>";;
schemaLocation="chapter04ord1.xsd"/>
<xsd:complexType name="InfoType">
    <xsd:complexContent>
       <xsd:extension base="ord:InfoType">
          <xsd:sequence>
             <xsd:element name="street" type="xsd:string"/>
          </xsd:sequence>
       </xsd:extension>
    </xsd:complexContent>
</xsd:complexType>

</xsd:schema>

Schema Document 4 (chapter04prod.xsd)
<xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;
          xmlns="<http://example.org/prod>";;
          targetNamespace="<http://example.org/prod>";;
          elementFormDefault="unqualified">

<xsd:complexType name="ItemsType">
  <xsd:sequence>
    <xsd:element name="product" type="ProductType"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="ProductType">
  <xsd:sequence>
    <xsd:element name="number" type="xsd:integer"/>
    <xsd:element name="name" type="xsd:string"/>
    <xsd:element name="size" type="SizeType"/>
    <xsd:element name="color" type="ColorType"/>
  </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="SizeType">
  <xsd:simpleContent>
    <xsd:extension base="xsd:integer">
      <xsd:attribute name="system" type="xsd:string"/>
    </xsd:extension>
  </xsd:simpleContent>
</xsd:complexType>

<xsd:complexType name="ColorType">
  <xsd:attribute name="value" type="xsd:string"/>
</xsd:complexType>

</xsd:schema>

----- Original Message ----
From: Frank Budinsky <[EMAIL PROTECTED]>
To: tuscany-user@ws.apache.org
Sent: Friday, May 26, 2006 8:51:35 AM
Subject: re: Deserializing SDOs using scoped registries


Ron,

I'm not sure I can answer your questions. I think this is something that
nobody has tried yet with the Tuscany code (If somebody else knows 
better,
please chime in :-)

That said, if you want to keep feeding me more details, we can try to 
work
it out together, and at the same time help us to design the scoping
mechanism right in Tuscany SDO.

So, a couple more questions for you:

1) you mention that you have a combination of static and dynamic models,
but if I'm not sure I understand the scenario you're describing. If I
understand it right, you have two problems:
   a) dynamic models on the client side are stored in local TypeHelper
registries, but the CORBA RMI only has access to the global EMF registry
... is that right?
   b) the static (?) models on the server side are registered in the
global registry, but since it's running in the appserver environment, the
metadata is actually going to the classloader-specific delegate 
registries
... but presumably, the CORBA RMI code is not running in the same
classloader as the app that registered the metadata.
   Do I have the two problems straight?
2) If the answer to the first question is yes, then what you're 
describing
is a scenario where the server has statically generated classes for a
model that on the client side is manipulated dynamically. Is that right?
3) Can you give me more details on how/where the metadata is registered 
on
both sides?

Thanks,
Frank.

Ron Gavlin <[EMAIL PROTECTED]> wrote on 05/25/2006 11:54:07 AM:

Frank,

Thanks for explaining the current Tuscany SDO scoping
nuances. Specifically, I am having CORBA
MARSHALLING/deserialization problems. Let me be more
specific and maybe you can help.

I have a model with a mixture of static and dynamic
schemas/registries. My client application is
attempting to pass Datagraphs back and forth via RMI
to a session bean in an appserver.

Currently, when I pass datagraphs composed of
dynamically typed dataobjects, I receive CORBA
MARSHALLING exceptions stating that specific "dynamic"
EPackages cannot be found. On the client-side, I fixed
this by extracting the dynamic EPackage from the
Tuscany scoped registry and registering it in the EMF
global registry. I am using a TypeHelperImpl subclass
that exposes the scoped registry for this purpose.

This technique doesn't seem to work on the server-side
presumably due to complexities introduced by the
appserver classloader infrastructure. On the
appserver, the global registry doesn't appear to be
really "global". As expected, if I set the appserver's
JVM property
"org.eclipse.emf.ecore.EPackage.Registry.INSTANCE" to
"org.eclipse.emf.ecore.impl.EPackageRegistryImpl",
DataGraph deserialization within the appserver
perfectly. But, removing the delegating classloader
registry within the appserver is not a good idea.

In particular, is there a way currently (w/out
disabling the delegating classloader registry) to
register dynamic packages in the appserver such that
they are available during datagraph deserialization? I
presume this works on WebSphere. Does WebSphere have
special hooks to support this EMF deserialization?

Furthermore, how will the datagraph deserializer in
the final Tuscany SDO implementation know how to
navigate through the various scopes to find the
registries needed to deserialize dynamically/typed
data?

Thanks in advance for all your help.

- Ron

--- Frank Budinsky <[EMAIL PROTECTED]> wrote:

> Ron,
>
> The current Tuscany implementation is a bit of a
> mess, including the
> GLOBAL registry limitation, but the plan is to fix
> it in the near future.
>
> Currently in Tuscany it works like this:
>
> - Each TypeHelper instance represents a unique scope
> which encapsulates
> its own local EPackage registry.
> - Any metadata registered via XSDHelper.define or
> TypeHelper.define will
> be in this local scope.
> - Local registries currently delegate to the EMF
> GLOBAL registry for types
> that are not found in the local registry.
> - Statically generated classes (which currently use
> the EMF generator
> patterns) are registered in the GLOBAL registry.
> - As in EMF, the GLOBAL registry, when running
> standalone (not in Eclipse)
> actually delegates to another classloader-specific
> delegate registry.
> - The net of all this is that there is a sort of a
> spider registry
> configuration currently, with the EMF global
> registry in the middle (with
> nothing actually in it).
>
> The plan, moving forward, is to make generated
> classes register their
> metadata in scope specific registries (the
> TypeHelper-local ones), instead
> of using the EMF GLOBAL registry. This is actually
> part of a bigger effort
> to change the generated class pattern to not have
> EMF dependencies.
>
> We're also planning to allow TypeHelper's
> (registries) to be configured
> (wired) any way you want to support nesting of
> scopes, etc.
>
> I hope this answers your question.
>
> Frank.
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]