Support for exposing a single interface as @WebService, @Remote, and @Local

[David Blevins <da...@visi.com>]

Have a good chunk of this highly demanded feature implemented.  Still  
not quite there, but with the commit 765456 we have a slightly  
improved algorithm in the AnnotationDeployer that is capable if  
behaving the old way and now the current way which is to support an  
interface exposed as multiple "views" (local, remote, etc.)

Had to change up the way we bind proxies into JNDI internally just a  
bit.  We were bind essentially by "deploymentId +  
interfaceClassName".  We're still doing that, but we also binding with  
that plus "!remote" or "!local" to disambiguate when people do in fact  
expose the same interface as remote and local, etc.  The old way is  
still there as the Spring integration uses it as I suspect other code  
might in the future.

So, if you do expose the same interface as both local and remote, the  
idea is that if you are vague (say @EJB MyInterface foo) you will  
always get the local interface if possible.  Not fully implemented  
yet.  Still need some work to make the LocalInitialContextFactory  
favor the local version of the interface and the  
RemoteInitialContextFactory favor the remote version.

One hitch in this is that we are currently using the interface class  
to determine if the proxy is a local call, a remote call, or a web  
service call.  We won't be able to do that when people expose an  
interface as both say Remote and WebService, so we'll need to change  
the RpcContainer.invoke(...) method signature so that callers have to  
pass in something we can use to identify the type of call.  Seems like  
the org.apache.openejb.InterfaceType object might work.  Not a big fan  
of changing the invoke signature -- an absolute last resort action --  
but there doesn't seem to be any other way without the interface to  
rely on to tell us about the call.


-David

Re: Support for exposing a single interface as @WebService, @Remote, and @Local

[David Blevins <da...@visi.com>]

On Apr 17, 2009, at 8:33 PM, David Blevins wrote:

> On Apr 15, 2009, at 8:36 PM, David Blevins wrote:
>
>> One hitch in this is that we are currently using the interface  
>> class to determine if the proxy is a local call, a remote call, or  
>> a web service call.  We won't be able to do that when people expose  
>> an interface as both say Remote and WebService, so we'll need to  
>> change the RpcContainer.invoke(...) method signature so that  
>> callers have to pass in something we can use to identify the type  
>> of call.  Seems like the org.apache.openejb.InterfaceType object  
>> might work.  Not a big fan of changing the invoke signature -- an  
>> absolute last resort action -- but there doesn't seem to be any  
>> other way without the interface to rely on to tell us about the call.
>
> Still need to get this part in and we should be done with this  
> feature.

Ok this is in as well.  This feature is complete!  We can now support  
interfaces annotated with any combination of @Remote, @Local, and  
@WebService.

Re: Support for exposing a single interface as @WebService, @Remote, and @Local

[David Blevins <da...@visi.com>]

On Apr 15, 2009, at 8:36 PM, David Blevins wrote:

> So, if you do expose the same interface as both local and remote,  
> the idea is that if you are vague (say @EJB MyInterface foo) you  
> will always get the local interface if possible.  Not fully  
> implemented yet.  Still need some work to make the  
> LocalInitialContextFactory favor the local version of the interface  
> and the RemoteInitialContextFactory favor the remote version.

Got this part finished.

I split the internal openejb/ejb/ tree into two trees: openejb/local/  
and openejb/remote/.  One is for the LocalInitialContextFactory and  
the other is for the RemoteInitialContextFactory.  Both were looking  
at the same openejb/ejb/ tree before.  The business local and local  
home interfaces are not bound into the openejb/remote tree. The result  
is that if someone uses the same interface as the remote and local  
business interface the LocalInitialContextFactory will always give you  
the local view and the RemoteInitalContextFactory will always give you  
the remote view.

> One hitch in this is that we are currently using the interface class  
> to determine if the proxy is a local call, a remote call, or a web  
> service call.  We won't be able to do that when people expose an  
> interface as both say Remote and WebService, so we'll need to change  
> the RpcContainer.invoke(...) method signature so that callers have  
> to pass in something we can use to identify the type of call.  Seems  
> like the org.apache.openejb.InterfaceType object might work.  Not a  
> big fan of changing the invoke signature -- an absolute last resort  
> action -- but there doesn't seem to be any other way without the  
> interface to rely on to tell us about the call.

Still need to get this part in and we should be done with this feature.

-David