This discussion is archived
1 2 Previous Next 17 Replies Latest reply: Feb 17, 2013 10:14 AM by r035198x RSS

Communicating between two EAR

mlvenkatesh Newbie
Currently Being Moderated
Hi

i have two EAR deployed on to a application server. If i want to invoke a method in object of in EAR 2 what are the options?

Thanks
vnk
  • 1. Re: Communicating between two EAR
    r035198x Pro
    Currently Being Moderated
    Depends on what type of objects they are.
  • 2. Re: Communicating between two EAR
    Kayaman Guru
    Currently Being Moderated
    mlvenkatesh wrote:
    If i want to invoke a method in object of in EAR 2 what are the options?
    An EJB? What functionality are you trying to invoke?
  • 3. Re: Communicating between two EAR
    mlvenkatesh Newbie
    Currently Being Moderated
    i have deployed in two different ears the reason which is beyond the scope of this thread. I have a method (a business logic ) embedded in an object in EAR 2

    Can i use a Stateless session EJB in EAR 1? and in EAR 1 use a jndi look up to access the business logic.

    Thanks
    vnk
  • 4. Re: Communicating between two EAR
    r035198x Pro
    Currently Being Moderated
    Again it depends on the type of objects that are communicating and yes you can invoke EJBs between different ears, you can even invoke an EJB in an ear deployed on a completely different server remotely. You should devote time to thinking about what this kind of interaction means before picking the integration strategy. The options are local EJB call, remote EJB call, JMS and webservice call. Your requirements should help you chose the correct one.
  • 5. Re: Communicating between two EAR
    jtahlborn Expert
    Currently Being Moderated
    r035198x wrote:
    Again it depends on the type of objects that are communicating and yes you can invoke EJBs between different ears, you can even invoke an EJB in an ear deployed on a completely different server remotely. You should devote time to thinking about what this kind of interaction means before picking the integration strategy. The options are local EJB call, remote EJB call, JMS and webservice call. Your requirements should help you chose the correct one.
    if the OP is calling between ears, then local EJB calls should not be used. local EJBs should only be used within a deployed unit (i.e. an ear).
  • 6. Re: Communicating between two EAR
    r035198x Pro
    Currently Being Moderated
    jtahlborn wrote:

    if the OP is calling between ears, then local EJB calls should not be used. local EJBs should only be used within a deployed unit (i.e. an ear).
    If the ears are in the same VM then local can be used. Local is for same VM not same deployment unit. Whether that's a good idea or not is another matter.
  • 7. Re: Communicating between two EAR
    jtahlborn Expert
    Currently Being Moderated
    r035198x wrote:
    jtahlborn wrote:

    if the OP is calling between ears, then local EJB calls should not be used. local EJBs should only be used within a deployed unit (i.e. an ear).
    If the ears are in the same VM then local can be used. Local is for same VM not same deployment unit. Whether that's a good idea or not is another matter.
    local may work (somewhat) cross deployment in the same jvm, but it involves cross-classloader references which can get really messed up if you do something like, say, reload an ear. i repeat, local is for within a single deployment (ear) only . (do a google search on "ejb use local reference across ears" if you don't believe me).
  • 8. Re: Communicating between two EAR
    gimbal2 Guru
    Currently Being Moderated
    Indeed, generally an EAR is deployed in its own isolated corner of the JVM with its own classloader and its resources are not visible to the rest of the JVM unless you explicitly make it so. An EJB can be given a remote interface for example, or you can deploy a webservice so it becomes accessible through HTTP calls. Other than that there are server specific methods to influence the visibility of modules. You should design an EJB with a local interface to be visible only within the EAR it is deployed.
  • 9. Re: Communicating between two EAR
    r035198x Pro
    Currently Being Moderated
    jtahlborn wrote:
    >

    local may work (somewhat) cross deployment in the same jvm, but it involves cross-classloader references which can get really messed up if you do something like, say, reload an ear. i repeat, local is for within a single deployment (ear) only . (do a google search on "ejb use local reference across ears" if you don't believe me).
    Ya I know classloader configuration types on some servers may make reloads (even normal operation) unpredictable but I disagree that local is for single deployment.
    The spec doesn't define local to mean deployment. Deployments could be ejb-jars as well and all deployments within the server the jar is deployed to do not need to use remote semantics. The problems with classloaders are container configuration specific and indeed appservers are moving towards modules rather than hierarchical class loaders. It wouldn't be accurate to say that EJB forbids use of local accross multiple deployments. What is certain is that it doesn't work across mutiple VMs.

    A better solution here is to deploy an ejb-jar with the shared services and the other deployments simply use it. Even then, if the deployments are in the same VM they can access the EJBs locally. More and more people are using appservers for single VM deployments these days and for them there is no need to introduce remote semantics. Again, I'm not saying that's the best solution for the OP, just that if it's all going to ever be one VM then local is a valid approach to contrast with the alternatives.
  • 10. Re: Communicating between two EAR
    jtahlborn Expert
    Currently Being Moderated
    r035198x wrote:
    jtahlborn wrote:
    local may work (somewhat) cross deployment in the same jvm, but it involves cross-classloader references which can get really messed up if you do something like, say, reload an ear. i repeat, local is for within a single deployment (ear) only . (do a google search on "ejb use local reference across ears" if you don't believe me).
    Ya I know classloader configuration types on some servers may make reloads (even normal operation) unpredictable but I disagree that local is for single deployment.
    so your argument is basically "yeah it doesn't work, but sometimes you can configure certain appservers to make it work (sometimes)... but that doesn't mean it's against the spec". if something is defined by the spec, then it should work on any appserver. by your own admission, this doesn't. you can also start threads on some appservers, but that doesn't change the fact that it's against the spec.
  • 11. Re: Communicating between two EAR
    r035198x Pro
    Currently Being Moderated
    No this is very different! The spec defines APIs that you should not use. It never discourages using local across deployments . If it does point it out.
    It is incorrect to say that local in the spec implies local to the same deployment like you are advocating. It's not against the spec to use local on different deployments that are in the same JVM. If you say it is then just point out the section.
  • 12. Re: Communicating between two EAR
    jtahlborn Expert
    Currently Being Moderated
    Ejb 3.1 spec, section 3.2.2:
    Access to an enterprise bean through the local client view is only required to be supported for local cli-
    ents packaged within the same application as the enterprise bean that provides the local client view.
    Compliant implementations of this specification may optionally support access to the local client view
    of an enterprise bean from a local client packaged in a different application. The configuration require-
    ments for inter-application access to the local client view are vendor-specific and are outside the scope
    of this specification. Applications relying on inter-application access to the local client view are
    non-portable.
  • 13. Re: Communicating between two EAR
    r035198x Pro
    Currently Being Moderated
    I was already aware that it's not portable since it relies on container specific class loader configurations. There is nothing else here discouraging it besides that. If anything, it says it's compliant to provide the feature (and basically every app server out there provides it).
  • 14. Re: Communicating between two EAR
    jtahlborn Expert
    Currently Being Moderated
    r035198x wrote:
    Ya I know classloader configuration types on some servers may make reloads (even normal operation) unpredictable but I disagree that local is for single deployment. The spec doesn't define local to mean deployment.
    "Access to an enterprise bean through the local client view is only required to be supported for local clients packaged within the same application as the enterprise bean that provides the local client view."

    i think the spec pretty clearly says that local is only required to mean deployment (but may optionally support other things).
    I was already aware that it's not portable since it relies on container specific class loader configurations.
    you never stated as much until this point.
    There is nothing else here discouraging it besides that. If anything, it says it's compliant to provide the feature (and basically every app server out there provides it).
    i haven't used every app server out there, but on the ones i have used, it has always caused issues. granted, that was a few years back, so maybe times have changed. however, i would still stand by my assertion that you should use remote interfaces to anything outside your ear. if you get to a point where your application is not performing and the remote calls are the bottleneck, then by all means, look into vendor specific optimizations. just be aware of those choices when you make them . making recommendations to others without giving them the appropriate caveats is a bit disingenuous.
1 2 Previous Next

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points