Nicholas (crossposting to jboss-user, because it could be of interest for
other people, too),

Your second option, the value-object thingy (using xdoclet or pattern
support), is IMHO most often used these days because it is the most default
thing to hide your entities from any web-layer.
 
Since I´m in love with the idea of having a web-service layer not optionally
to the web-presentation layer, but mandatory in between application and
web-presentation layer, I built in already some support for your first
option.

Doing a UserTransaction around the session bean call is exactly what the
JBoss.net TransactionHandlers (one for the request flow starting a
usertransaction if not yet started, rolling it back in the case of failures,
and one for the response flow that commits the tx) are dedicated to. Using
find/create-calls on the entity home in order to generate entity references
is what the EntityBeanDeserializer does for you (still a bit unhandy,
because restricted to basic primary key classes, I won´t be able to commit
my extensions to that before March, I fear however ... But if you are a
taker and want to help out, I can send you the code directly).

There is the "store" example in the testsuite of jboss.net which already
demonstrates the interplay of these features, especially how to configure a
custom request/responseflow and connect it to your web-service.

My vision is that the web-service layer provides through the right
(de-)serialization logic a kind of client-specific "view" onto the complex
logic/data model of session-beans/entity-beans whereas the bean level does
not care about
Client-specific needs. E.g., instead of having custom value classes for
"long view" and "short view", the business level
always returns the same entity bean and the installed
serializers/deserializers determine the schema that comes out.

Hope I could help,
CGJ
 

-----Ursprüngliche Nachricht-----
Von: Nicholas [mailto:[EMAIL PROTECTED]] 
Gesendet: Freitag, 10. Januar 2003 21:20
An: [EMAIL PROTECTED]
Betreff: Axis EJBProvider - Trouble With CMR


Christoph;

Iam working with JBoss 3.0.4 and Axis 1.0. I have a
series of business facade session beans fronting
CMP/CMR entity beans. Now that I am exposing the
session beans in  Axis, it has been pretty simple so
far, expecially with your EJBProvider.

However, I have run into one serious issue. When a I
retrieve a local remote of an entity bean via the
session bean, the BeanSerializer in Axis does an
excellent job of serializing it, except when there are
CMR calls in the object. When there are, the bean
searialzier calls the getXXX() in order to retrieve a collection of related
objects, and the container throws an error saying that CMR calls must occur
within the same transaction.

So I am considering two options:

1. Rewrite EJBProvider to [optionally] start a
UserTransaction so that the BeanSerializer executes
all its calls in one transaction. (I would simply
extend it, but I have not figured out the <service
name="XXXXX" provider="java:EJB"> in the WSDD maps to
the EJBProvider class.......)

2. Use a mix of Remote remotes and Local Remotes
and/or a series of value objects so that I can
retrieve serialized remotes without invoking the CMR
methods.

Do you have any insight into this ?

Thanks for your help.

//Nicholas

=====
Nicholas Whitehead
Home: (973) 377 9335
Cell: (201) 615 2716
Work: (212) 622 5639
[EMAIL PROTECTED]
###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/


-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to