You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/01/26 16:35:47 UTC
[AltRMI] New Direct-Marshalled transport type
Folks,
I've coded another tranport type for AltRMI - "Direct-Marshalled"
Here is a comparison of three similar AltRMI types:
* Direct Marshalled Transport.
- marshalling takes place.
- instances passed by value between client and server may not be a
mutually visible classloader.
- does not need separate threads for client and server.
* Direct Transport
- no marshalling takes place in Direct Transport.
- instances passed by value between client and server must be a
mutually visible classloader.
- does not need separate threads for client and server.
* Piped Transport
- marshalling takes place.
- instances passed by value between client and server may not be a
mutually visible classloader.
- needs separate threads for client and server.
I have coded it for Alt-EJB (now named "Enterprise Object Broker" and
hosted on sourceforge and 10% coded).
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] New Direct-Marshalled transport type
Posted by Paul Hammant <Pa...@yahoo.com>.
Juozas,
> Yes I see it is possible to solve problems this kind.
> I need transparent distributed objects in my projects, It is because I
> speak a lot about ARMI. I am afraid this
> can be difficult to understand for my coworkers, but will fink a lot
> about this before next project. I think
> Transparent Persistence will be the first revolution in my company.
:-)
> BTW. I am not kidding about ARMI over DCOM I have spend 2 year
> with this stuff ( ActiveX, win32, IUnknown, IDispatch , ......,"Ole
> Automation", .... )
> and I can help to implement this.
I am not sure what you are proposing.... AltRMI having DCOM transport
types?
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] New Direct-Marshalled transport type
Posted by Juozas Baliuka <ba...@mwm.lt>.
Hi,
Yes I see it is possible to solve problems this kind.
I need transparent distributed objects in my projects, It is because I
speak a lot about ARMI. I am afraid this
can be difficult to understand for my coworkers, but will fink a lot about
this before next project. I think
Transparent Persistence will be the first revolution in my company.
BTW. I am not kidding about ARMI over DCOM I have spend 2 year with
this stuff ( ActiveX, win32, IUnknown, IDispatch , ......,"Ole
Automation", .... )
and I can help to implement this.
At 11:21 AM 1/27/2002 +0000, you wrote:
>Juozas,
>
>><skip>
>>
>>>>But I don't know how to handle "By Value".
>>>>void myMethod( MyInterfaceType mt ){
>>>> mt.setSomething("X");//Don't understand how to handle this ( is X
>>>> set on copy of Object ? )
>>>> }
>>>
>>>
>>>X will be a copy of the object if pass by value or over the wire.
>>>I'm not quite sure what your asking here.
>>
>>
>>Yes, communication is my problem :(
>>I try to see framework or API as user .
>>I see two problems in "transparence". Distributed and Persistent objects
>>have problem with
>>"Fatal Errors" like "Connection is lost" and "By Value" then users code
>>tries to set something on copy of object.
>>Transparent objects doe's not implement any "Tag Interface" and doe's not
>>throw checked Exceptions
>>specific for way they are marshaled.
>>//////////////////////////////////////////////////////////////////////////
>>Problem 1 :
>>users code ("Fatal Errors specific for framework implementation" )
>>
>> void myMethodUsesTransparentObject( Transparent transparent ){
>> try{
>> transaction.begin();
>> transparent.doSometing();//throws some App Exception
>> transparent.setSomething();
>> .........................................
>> transaction.commit();
>>
>> }catch(SomeCheckedAppException sce){
>> log(sce);
>> transaction.rollback();
>> }
>> // I forgot to handle "Connection is lost " and compiler says nothing.
>> // My transaction is incomplete and it is very possible I have a
>> "Lock" forever on some resource.
>> // It can be impossible to find this bug for user. We need solution,
>> I don't have it.
>
>For the connection failures issue, the client-side user is informed via a
>AltrmiInvocationException. This can be caught in a number of places. My
>preference would be in a single nexus :
>
>void initialize() {
> try {
> // method calls
> }catch ( AltrmiInvocationException ae ) {
> if (transaction != null) { transaction.rolback(); }
> getLogger().error("blah",ae);
> throw ae; // or a new one.
> }catch (Throwable) {
> // something similar.
> } }
>
>Of course with a bean container a "policy" can be set for a bean, so that
>predictable actions take place.
>
>> }
>>
>>//////////////////////////////////////////////////////////////////////////
>>
>>Problem 2 :
>>
>>User calls my transparent objects he don't know marshaling stuff,
>>implements "callbacks" sets "Context" ... .
>>He knows :
>>virtual void my_cpp_method( transparent object )=0;// "By Value"
>>irtual void my_cpp_method1( transparent & object )=0;// "By Reference"
>>procedure MyPascalProcedure( var aObject : TTransparent ) virtual
>>abstract; (* "Always By Reference " *)
>>public void myJAVAMethod(Transparent transparent);// sometimes "By value"
>>? Transparent has no "Tag" interface
>>User knows usual stuff, and "Transparence" must become usual.
>
>In this case, the class containing the method myJAVAMethod() is a facade
>and proxyed to an equivalent on the server. You are worried about
>"Transparent" class and how AltRMI knows whether it is pas by value or by
>reference (a facade). Easy, at time of publication, the developer
>designates a number of additional interfaces as facades rather than pass
>by value. If it is known that Transparent has setter functions that could
>cause problems make it an addition facade. There is no need for a Tag
>(Marker?) interface. The downside is that Transparent.class needs to be
>an interface with one or more impls. But then that is the same rule taht
>RMI has for solving the same issue.
>
>>///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
>>
>>
>>Very possible to train users, write books, documentation, I don't know is
>>it solution or not.
>>I have no solution for this two problems.
>>It is because I trying to think as user, I must think about my team it is
>>my job.
>>I like transparence, but I think it can kill users project if will not
>>solve my problems.
>
>I hope I have addressed your concerns Juazos. I think you know yourself
>that you're little hard to understand. Sadly so I am, but I don't have
>the excuse of having English as a first language ;-)
>
>Regards,
>
>- Paul
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] New Direct-Marshalled transport type
Posted by Paul Hammant <Pa...@yahoo.com>.
Juozas,
> <skip>
>
>>> But I don't know how to handle "By Value".
>>> void myMethod( MyInterfaceType mt ){
>>> mt.setSomething("X");//Don't understand how to handle this ( is
>>> X set on copy of Object ? )
>>> }
>>
>>
>> X will be a copy of the object if pass by value or over the wire.
>> I'm not quite sure what your asking here.
>
>
> Yes, communication is my problem :(
> I try to see framework or API as user .
> I see two problems in "transparence". Distributed and Persistent
> objects have problem with
> "Fatal Errors" like "Connection is lost" and "By Value" then users
> code tries to set something on copy of object.
> Transparent objects doe's not implement any "Tag Interface" and doe's
> not throw checked Exceptions
> specific for way they are marshaled.
> //////////////////////////////////////////////////////////////////////////
>
> Problem 1 :
> users code ("Fatal Errors specific for framework implementation" )
>
> void myMethodUsesTransparentObject( Transparent transparent ){
> try{
> transaction.begin();
> transparent.doSometing();//throws some App Exception
> transparent.setSomething();
> .........................................
> transaction.commit();
>
> }catch(SomeCheckedAppException sce){
> log(sce);
> transaction.rollback();
> }
> // I forgot to handle "Connection is lost " and compiler says
> nothing.
> // My transaction is incomplete and it is very possible I have a
> "Lock" forever on some resource.
> // It can be impossible to find this bug for user. We need
> solution, I don't have it.
For the connection failures issue, the client-side user is informed via
a AltrmiInvocationException. This can be caught in a number of places.
My preference would be in a single nexus :
void initialize() {
try {
// method calls
}catch ( AltrmiInvocationException ae ) {
if (transaction != null) { transaction.rolback(); }
getLogger().error("blah",ae);
throw ae; // or a new one.
}catch (Throwable) {
// something similar.
}
}
Of course with a bean container a "policy" can be set for a bean, so
that predictable actions take place.
> }
>
> //////////////////////////////////////////////////////////////////////////
>
>
> Problem 2 :
>
> User calls my transparent objects he don't know marshaling stuff,
> implements "callbacks" sets "Context" ... .
> He knows :
> virtual void my_cpp_method( transparent object )=0;// "By Value"
> irtual void my_cpp_method1( transparent & object )=0;// "By Reference"
> procedure MyPascalProcedure( var aObject : TTransparent ) virtual
> abstract; (* "Always By Reference " *)
> public void myJAVAMethod(Transparent transparent);// sometimes "By
> value" ? Transparent has no "Tag" interface
> User knows usual stuff, and "Transparence" must become usual.
In this case, the class containing the method myJAVAMethod() is a facade
and proxyed to an equivalent on the server. You are worried about
"Transparent" class and how AltRMI knows whether it is pas by value or
by reference (a facade). Easy, at time of publication, the developer
designates a number of additional interfaces as facades rather than pass
by value. If it is known that Transparent has setter functions that
could cause problems make it an addition facade. There is no need for a
Tag (Marker?) interface. The downside is that Transparent.class needs
to be an interface with one or more impls. But then that is the same
rule taht RMI has for solving the same issue.
> ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
>
>
> Very possible to train users, write books, documentation, I don't know
> is it solution or not.
> I have no solution for this two problems.
> It is because I trying to think as user, I must think about my team it
> is my job.
> I like transparence, but I think it can kill users project if will not
> solve my problems.
I hope I have addressed your concerns Juazos. I think you know yourself
that you're little hard to understand. Sadly so I am, but I don't have
the excuse of having English as a first language ;-)
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] New Direct-Marshalled transport type
Posted by Juozas Baliuka <ba...@mwm.lt>.
<skip>
>>But I don't know how to handle "By Value".
>>void myMethod( MyInterfaceType mt ){
>> mt.setSomething("X");//Don't understand how to handle this ( is X
>> set on copy of Object ? )
>> }
>
>X will be a copy of the object if pass by value or over the wire. I'm not
>quite sure what your asking here.
Yes, communication is my problem :(
I try to see framework or API as user .
I see two problems in "transparence". Distributed and Persistent objects
have problem with
"Fatal Errors" like "Connection is lost" and "By Value" then users code
tries to set something on copy of object.
Transparent objects doe's not implement any "Tag Interface" and doe's not
throw checked Exceptions
specific for way they are marshaled.
//////////////////////////////////////////////////////////////////////////
Problem 1 :
users code ("Fatal Errors specific for framework implementation" )
void myMethodUsesTransparentObject( Transparent transparent ){
try{
transaction.begin();
transparent.doSometing();//throws some App Exception
transparent.setSomething();
.........................................
transaction.commit();
}catch(SomeCheckedAppException sce){
log(sce);
transaction.rollback();
}
// I forgot to handle "Connection is lost " and compiler says nothing.
// My transaction is incomplete and it is very possible I have a
"Lock" forever on some resource.
// It can be impossible to find this bug for user. We need solution, I
don't have it.
}
//////////////////////////////////////////////////////////////////////////
Problem 2 :
User calls my transparent objects he don't know marshaling stuff,
implements "callbacks" sets "Context" ... .
He knows :
virtual void my_cpp_method( transparent object )=0;// "By Value"
irtual void my_cpp_method1( transparent & object )=0;// "By Reference"
procedure MyPascalProcedure( var aObject : TTransparent ) virtual
abstract; (* "Always By Reference " *)
public void myJAVAMethod(Transparent transparent);// sometimes "By value" ?
Transparent has no "Tag" interface
User knows usual stuff, and "Transparence" must become usual.
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Very possible to train users, write books, documentation, I don't know is
it solution or not.
I have no solution for this two problems.
It is because I trying to think as user, I must think about my team it is
my job.
I like transparence, but I think it can kill users project if will not
solve my problems.
<skip>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] New Direct-Marshalled transport type
Posted by Paul Hammant <Pa...@yahoo.com>.
Juozas,
> It is very interesting, does somebody works on persistence ?
No yet. The example beans have no persistence. The idea is that the
developer chooses what type of persistence they need. File, Store,
JDBC, JDO.
> I know this stuff like JTA, JAAS, JDO ... .
Thats good.
Commons-Store would be cool for re-use in EOB.
> I work on persistence in the current project, I have plans to complete
> it next weak.
> Idea is like this : "User defines some interfaces and optional
> mappings". Container or application
> Manages persistence and transactions , user defined interfaces can
> be reused for "Value Objects","Remote/Local" ...
> I will use simplestore for cache.
:-)
> Do you need this kind of code ?
> But I don't know how to handle "By Value".
> void myMethod( MyInterfaceType mt ){
> mt.setSomething("X");//Don't understand how to handle this ( is X
> set on copy of Object ? )
> }
X will be a copy of the object if pass by value or over the wire. I'm
not quite sure what your asking here.
Consider :
interface StockPortfolio {
int getShareCount(String ticker);
void addToPortfolio(String ticker, shareCount);
void removeFromPortfolio(String ticker, shareCount);
String[] getStocksHeld();
}
class JDBCStockPortfilioImpl implements StockPortfolio {
// all those methods implemented like in classic entity bean
}
class CommonsStoreStockPortfolioImpl extends
org.apache.commons.simplestoreSynchronizedStore implements StockPortfolio {
// or 'has a' in stead of 'extends' as it is final.
// all those methods implemented and routing through to the store
methods.
}
>> I have coded it for Alt-EJB (now named "Enterprise Object Broker" and
>> hosted on sourceforge and 10% coded).
>
>
> I like this name :)
In spoken form -> 'Yob'
It is a name that Gerhard and I though up after discussing over a couple
of days
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] New Direct-Marshalled transport type
Posted by Juozas Baliuka <ba...@mwm.lt>.
Hi,
It is very interesting, does somebody works on persistence ?
I know this stuff like JTA, JAAS, JDO ... .
I work on persistence in the current project, I have plans to complete it
next weak.
Idea is like this : "User defines some interfaces and optional mappings".
Container or application
Manages persistence and transactions , user defined interfaces can
be reused for "Value Objects","Remote/Local" ...
I will use simplestore for cache.
Do you need this kind of code ?
But I don't know how to handle "By Value".
void myMethod( MyInterfaceType mt ){
mt.setSomething("X");//Don't understand how to handle this ( is X set
on copy of Object ? )
}
>I have coded it for Alt-EJB (now named "Enterprise Object Broker" and
>hosted on sourceforge and 10% coded).
I like this name :)
>Regards,
>
>- Paul H
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>