Comments on: EJB 3.1: No-interface view feedback

By: Stephen Riesenberg

Stephen Riesenberg — Fri, 23 May 2008 01:44:07 +0000

+1 for optional local interface. Having to code a local view and a remote view is tedious, and having the flexibility to switch seamlessly between local and remote versions of the bean is beneficial.

-1 for optional remote interface. Remote clients should program against an interface of my bean, not my bean itself. Not to mention, private/public access is a stupid way to define which methods are accessible to remote “users” of my bean. That’s why interfaces exist. To decouple systems, and allow concrete agreements between users and implementations. Interfaces allow me to remain conscious of the design of my application, and how outside users view it. Also, did someone say unit testing?

While Mike’s idea of combining the interfaces is quite brilliant, I say don’t bother. Internally, I don’t mind programming against my bean directly. Again, that’s not what interfaces are for. But remotely… mmhmm! Interfaces!

By: alexandre

alexandre — Sun, 30 Sep 2007 09:31:15 +0000

I like the previous comment but would like it more with:
@Stateless
public class StockTrader {
public void create() {} //call back
public String foo() {} //nothing special
@Local public void bar(){} //local
@Remote public void trudy(){} //Remote
}

the call back if not called “void create()” could then have a @create annotation.
a “@IsManaged private Boolean isManaged = false;” could be set to true by the container if the container is taking care of the bean.
alex

By: Daoud AbdelMonem Faleh

Daoud AbdelMonem Faleh — Sat, 29 Sep 2007 22:34:42 +0000

-1 optional Remote||Local interfaces.
Programming to interfaces is a good practice and should be encouraged as it allow good patterns and clean design.
I do agree with Mike idea of making both @Remote and @Local a single interface (one single business interface) and allow them to be overridden at method level.
Although Session Beans are a mean to implement web services they still should be treated separately and annotations like “@InvoationLayers(SOAP,REST,RMI,IIOP,JSON,WHATEVER)” like suggested by Andy IMHO are not very consistent with the actual programming model at least.
One last thing please more aop.

Daoud AbdelMonem Faleh.

By: José Freire

José Freire — Thu, 27 Sep 2007 17:00:47 +0000

Remote no-interface views?

How about:

@Stateless
public class StockTrader {

/*
* This one is local
*/
public void buySpecial(Stock, int quantity, other special parameter for local access) {}

/*
* These are remote
*/
@Remote
public void buy(Stock stock, int quantity) {…}

@Remote
public void sell(Stock stock, int quantity) {…}
}

By: chuck

chuck — Thu, 27 Sep 2007 16:19:31 +0000

+1 on optional local interface (anything public is exposed *anyway*), but -1 on optional remote interfaces.

By: Mark Bakker

Mark Bakker — Thu, 27 Sep 2007 13:41:29 +0000

Hi,

I realy like the Idea not having to implement te interfaces.
But an @Remote or @Local tag on a class makes sense for me.

Kind regards,

Mark

By: Andy

Andy — Thu, 27 Sep 2007 01:32:41 +0000

I think interfaceless is good. there are many times when the interface is just filler. I guess it means that everything will have to be done by dynamic subclass (which is of course badmojo), cglib, javassist or whatever…but many times I’m just looking for transactions.. . I’m more interested in turning pooling off though. Pooling ala SLSBs is totally lame/pointless/sucky.

@ISimplyWantATransactionalBeanWithNoFluff(pool=off) //which should be default for TJB’s (TransactionalJavaBeans)
public class MyBean {
@TransactionAttribute(TransType.REQUIRES_NEW)
public void sendBillHatFromCheetah() {
// …
}

}

public class MyOtherBean {
@TJB
MyBean bean;
…
bean.sendBillHatFromCheetah();
…
}

These “simpleBeans” or (TransactionalJavaBean) might be a subclass proxying to a container with the so-called “Bridge” pattern. Or they might be directly injected *gasp* without the “container” as subclasses with the @TX stuff or whatever injected. Really I’d just like a lot less silly shit when all I want to do is demarcate transactions, manage @EntityMangager (aka the session) etc. Most “Enterprise” applications don’t really need a whole lot more than IoC, TX management and Session management.

As for web services, I never got why SOAP is such a special transport. That is just invocation, why does it need special treatment? Maybe I have annotations saying @InvoationLayers(SOAP,REST,RMI,IIOP,JSON,WHATEVER) or maybe that stays outside. I agree that a special web service interface is the lamest thing ever.

-Andy

By: dhartford

dhartford — Wed, 26 Sep 2007 13:21:49 +0000

I like Mike’s comment – Allow a single interface to allow @Local and @Remote (@Webservice, others?). One interface, with method-level adjustments to ‘visibility’, for all ways the actual implementation(s) could be exposed.

Instead of saying ‘no interface for this scenario, but allow it for others’, improve by simply having one interface file for all ways to expose actual implementations (instead of multiple interfaces).

By: Tim Shaw

Tim Shaw — Wed, 26 Sep 2007 09:23:28 +0000

Why not provide annotation of classes/methods : @Remote and @Local?
If the EJB class implements an I/face, the I/face can be annotated and each method in it will ‘have’ that annotation. Interfaces should be allowed to have both annotations.
If the class is annotated, all get/set methods will be exposed.
If methods are annotated, this will override the Class level annotation.
Something akin to @Transient should be added – @Container/@Hidden (?) – which will restrict these.
My 2c.

By: Mike

Mike — Wed, 26 Sep 2007 07:25:36 +0000

-1 on optional interfaces, but allow a single interface to be both @Local and @Remote at the same time by adding a simple way to choose the interface type for injected dependencies, for example @EJB(type = InterfaceType.LOCAL|REMOTE). A possible further enhancement would be the possibility to override local/remote visibility for each business method individually by applying @Local/@Remote again.