Distributed Elevator system using EJB 3

I'm developing a distributed elevator system using EJB 3 and JSP. Can anybody help me in deciding the overall architecture of the system?
The system consists of an individual controller for each elevator and there is a central remote controller which controls the whole system as well.
I'm in a dilemma how to start making a 4 tier architecture.......
Can anybody guide me?

Digging more into the problem it seem when there are “JMX invoke” calls in the call stack the NameNotFoundException occurs for EnitityManager lookups.
Caused by: javax.naming.NameNotFoundException: java:comp/env/ribPersistenceUnit/EntityManager not found in Rib Admin GUI
     at com.oracle.naming.J2EEContext.getSubContext(J2EEContext.java:225)
     at com.oracle.naming.J2EEContext.lookup(J2EEContext.java:172)
     at com.evermind.server.ApplicationContext.lookupInJavaContext(ApplicationContext.java:308)
     at com.evermind.server.ApplicationContext.unprivileged_lookup(ApplicationContext.java:232)
     at com.evermind.server.ApplicationContext.lookup(ApplicationContext.java:197)
     at javax.naming.InitialContext.lookup(InitialContext.java:351)
     at com.retek.rib.domain.hospital.dao.toplink.ToplinkSessionDispenser$CMTToplinkSessionEntityManager.lookupEntityManager(ToplinkSessionDispenser.java:148)
In our case
Servler/JSP -> JMX MBeans -> TimerThread -> SLSB Ejb -> Calls Context.lookup("java:comp/env/ribPersistenceUnit/EntityManager").
I get the exception as shown above.
If I make the Servlet/JSP call the TimerThread directly bypassing the JMX call it works fine.
Our application is fully manageble by JMX so I cannot remove the JMX layer. What can I do to fix the issue?
Prantor

Similar Messages

How can I develop a web application using EJB design pattern?

I have searched over the web and found quite a lot of tutorials on how to use the EJB design pattern.
I know that there will be a home interface, EJB object interface and a SessionBean.
But the tutorials often only cover a single class, this made me unable to get a complete picture of how EJB design pattern can be implemented into a whole system.
I am now required to devleop an online shopping web application using EJB and JSP page.
I think I will need to create a lot of classes: Member, ShoppingCart, Product...etc.
What I want to ask is that, do I need to create a home interface, EJB object interface and a SessionBean for each of these classes?
I really need some ideas on how to develop this system using EJB + JSP pages.
Many thanks to you all.

For every EJB that you want to create, you will need to code a home and remote interface and a bean class.
You could start getting your ideas here
http://www.theserverside.com/books/wiley/masteringEJB/
http://www.coreservlets.com

Use EJB client to communicate between 2 systems

I have 2 systems A and B located in separate machine.
A will pass an XML Request String to B, and B will return
an XML Response string to A.
My friend told me to write an EJB client sitting between
A and B, maybe there is a method called process() in EJB Client.
A can call XML_Response = EJB.process(XML_Request);
XML_Response process(XML_Request)
XML_Response = B.process(XML_Request)
return XML_Response
My question is how to get started? My understanding is EJB client
will use EJB Beans. Any ideas??

I would use entity beans on both, and then use Message Driven as facades, the message driven beans would communicate between each of the servers.

Why use EJB?

I am somewhat new to Enterprise Computing and I am a little unclear about these technologies.
Could someone please let me know why should we use EJB classes in web applications instead of normal classes for executing business logic?
Thanks and regards.
Soham

While I agree that most people using EJB's could have
built a better solution, I think both of the above
posters are completely wrong.
Not at all... You just don't get the point...
Most problems to which EJBs are applied are not problems to which EJBs should ever have been applied at all.
Before answering your question though, keep in mind
there are at least 3 types of EJB's, and all are
completely different. So I can only answer your
question at a high level. Here are the reasons people
might use EJB's:
And according to the specs you use them all or you don't use EJB...
They are container managed.Granted
They offer transactional awareness in your app.So can other solutions.
They are secure.Only as secure as you make them.
And you then tie yourself into a security system that may not be at all compatible with the ones you have already requiring expensive work to link several disparate systems together.
They are pooled, which makes them fast and eliminates
excessive object creation/deletion.There's many other things that are pooled.
They scale well in clustered/distributed environments
(as mentioned above).Clustered environments are indeed the only places where EJB have a definite advantage.
They abstract you from database access (yeah!).So do other technologies
They decouple you from the database so you can switch
from Oracle to MySQL with little or no impact and/or
changes to code (only driver changes).
That's exactly the same reason as above.
I've written my own abstraction layer once which worked faster and simpler than EJB.
We're now using another abstraction layer which does the same.
Use any ORM tool and you have an abstraction layer that's a lot easier to use than EJB, and a lot better performant.
I could go on and on, but don't have time. :-)You don't have a clue you mean. You're just spouting the party line as presented by the EJB priests.

How to use ejbs for accessing Function Module.

Hi,
I want to call ABAP function module using ejb(Since I want to expose them as web service on different server). I know how to do that using Models, but dont know how to go ahead using ejbs.
Could you please guide me on this?
Regards,
Abhijeet.

Hi,
In another thread with a similar question I found these references:
/people/kathirvel.balakrishnan2/blog/2005/07/26/remote-enable-your-rfchosttoip-to-return-host-ip-to-jco
Re: interfacing SAP with an existing java applications
And this code example:
 HashMap result = new HashMap();
 Object ret = new Object();
 JCO.Client mConnection = null;
 mConnection = getConnection();
 JCO.Repository mRepository;
 mRepository = new JCO.Repository("R3", mConnection);
 JCO.Function function =
 createFunction("Z_ISA_GET_ORDER_ITEM_INFO", mRepository);
 function.getImportParameterList().setValue(orderNum, "ORDER");
 if (function != null) {
 mConnection.execute(function);
 JCO.Table codes = function.getTableParameterList().getTable("INFO");
 for (int i = 0; i < codes.getNumRows(); i++) {
 codes.setRow(i);
 int tmp = new Integer(codes.getString("POSNN")).intValue();
 String tmpStr = new String(Integer.toString(tmp));
 ret = result.put(tmpStr, codes.getString("VBELN"));
 } else {
 System.out.print("Fxn call failed for Z_ISA_GET_ORDER_ITEM_INFO");
 JCO.releaseClient(mConnection);
Good luck,
Roelof

Using EJBs in Web Dynpro

I have recently started to develop Web applications using the Web Dynpro framework. Coming from a pure J2EE world, I must admit that Web Dynpro has a few innovative features that I find interesting for user interface development. The use of component & view contexts, for example, is not unlike the ActionForms that one may find in a Struts application, but pushed a bit further. No complaints here.
What I do have some problems with is the whole CommandBean paradigm that is put forth by SAP (refer to the document <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/webdynpro/using%20ejbs%20in%20web%20dynpro%20applications.pdf">Using EJBs in Web Dynpro</a>).
I do understand the usefulness of defining a model that will be used to generate and eventually bind to Context data structures. That's fine. What I do object to is the use of a so-called CommandBean to play that role. Again, coming from a J2EE world, I am familiar with the BusinessDelegate pattern - which would typically be used by a client application to invoke business logic on the server side. I would propose that a better, cleaner way of integrating EJBs with the Web Dynpro framework would be to use a BusinessDelegate for invoking business logic, and importing a separate and distinct ModelBean (instead of a CommandBean) to be used for defining and binding to Context data.
I have built one Web Dynpro application thus far. Instead of using a CommandBean, I created a ModelBean that extends my business object DTO (Data Transfer Object) (which is quite appropriate for that role, given that it implements all the get & set methods that are required for the business data that I need to model). My Web Dynpro application also makes use of an independant BusinessDelegate that is packaged with my EJB DC - this is a standard best practice on J2EE projects. I have been asked by the people working with me to modify this architecture to bring it more in line with the SAP way of doing things. I am open-minded and willing to learn and accept new ways of thinking and doing things. However, I fail to understand the usefulness of merging structure and behaviour by resorting to CommandBeans:
- It violates the MVC paradigm by having one object (the CommandBean) serve as both model AND controller as far as the Web Dynpro application is concerned. The CommandBean is obviously a model - since it is literally imported as such into the Web Dynpro application. It is ALSO a controller from the Web Dynpro's application perspective, since all calls to the back-end go thru the CommandBean via one or more of its execute_xxx methods. In contrast, the use of a business delegate by the Web Dynpro application clearly separates the model (the CommandBean... or rather, a more suitably named ModelBean) from the controller (BusinessDelegate).
- Doesn't carry its own weight. In other words, I haven't yet been provided with any valid justification for going thru the extra effort of coding the CommandBean's execute methods. It's been proposed to me that it somehow serves as an abstraction layer between the Web Dynpro application and the business logic. I would argue that it is the BusinessDelegate's role to abstract away the back-end logic from clients. If one does have a BusinessDelegate available, I would argue there's no need to code execute methods in a separate CommandBean. To prove my point, I would simply point out that all of the CommandBean examples that I have seen so far, either in How-To documents, or in production code, all follow the same pattern....
CommandBean.execute_doSomething() calls BusinessDelegate.doSomething()
Not a heck of an "abstraction" layer... I would in fact argue that it is worse than useless. If some major change occurs in the business logic that requires changing the doSomething() operation, we expect of course to modify the BusinessDelegate. The Web Dynpro client will also presumably need to be modified - that's to be expected, and unavoidable. But then, we'll also need to go about and change the CommandBean's execute_doSomething() method - again, extra work for no apparent benefit. Adding and removing business methods has the same implication. All this for an layer that simply adds the prefix execute_ in front of all business method calls... Is this "abstraction layer" worth the cost of creating and maintaining it ??
- Unnecessarily complicates error handling. I have been told that for technical reasons, it is recommended that all exceptions thrown by the CommandBean be of type WDException or WDRuntimException. But what if the client application needs to react differently to different failure scenarios ? When I create a business object, I might wish to provide the user with an error messages if connection is lost to the backend, and with a different error message if an object already exists in the database with the same attributes. In order to do that, I will have to catch the WDException, extract the cause, and continue processing from there... possible, yes, but clearly less standard and more labor intensive than the classical try/catch mechanism.
To say nothing about the fact that SAP's own API documentation clearly states that applications using Web Dynpro can reference and catch WDExceptions, but THEY MUST NOT THROW OR EXTEND IT !
- Produces unnecessary DCs. Page 6 of the aforementioned document presents an architectural view of a Web Dynpro project that uses a CommandBean. Why an extra DC for the CommandBean ?? I created my ModelBean class right inside the Web Dynpro project (in the Package view). That, to me, is where this class should reside, because it is created for no other reason that to be used by this particular Web Dynpro application. What is the benefit of placing it in its own independant DC ?
- Not a typical application of the Command pattern. The well-documented command pattern (Design Patterns - Gang of Four) has been devised mainly to enable encapsulation of request as objects, thereby making it possible to:
- specify, queue and execute requests at different times
- decouple execution of a command from its invoker
- support undo operations
- support logging changes so that they can be reapplied in case of system crash making it possible to assemble commands into composite commands (macros), thereby structuring a system around high-level operations built on primitive operations.
None of this applies to the way the SAP CommandBeans are being used. Not that much of an issue to people new to J2EE and/or OO development... but quite confusing for those already familiar with the classic Command pattern.
At this point, I fail to understand the advantage of merging structure (model) and behaviour (execute methods) through the use of a unique CommandBean object. Am I missing something ?

Thanks for your reply and your suggestion. I have posted in the Web Dynpro Java forum... and suggest those wishing to participate in this thread to refer to the Web Dynpro Java forum.
As for your answer, I'm afraid it doesn't satisfy me.
Reuse is hardly an issue, since the CommandBean is specifically tailor-made for the Web Dynpro application that needs to use it. I could hardly imagine building another application that would just happen to have the exact same needs as far as data structure and processing is concerned...
As for the right Eclipse environment... the CommandBean is not an EJB artifact - it is an EJB client. The aforementioned tutorial in fact suggests creating it in the Java perspective.
But thanks anyway for your time and suggestion

Using EJBs in Web Dynpro Applications

I have recently started to develop Web applications using the Web Dynpro framework. Coming from a pure J2EE world, I must admit that Web Dynpro has a few innovative features that I find interesting for user interface development. The use of component & view contexts, for example, is not unlike the ActionForms that one may find in a Struts application, but pushed a bit further. No complaints here.
What I do have some problems with is the whole CommandBean paradigm that is put forth by SAP (refer to the document <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/webdynpro/using%20ejbs%20in%20web%20dynpro%20applications.pdf">Using EJBs in Web Dynpro Applications</a>).
I do understand the usefulness of defining a model that will be used to generate and eventually bind to Context data structures. That's fine. What I do object to is the use of a so-called CommandBean to play that role. Again, coming from a J2EE world, I am familiar with the BusinessDelegate pattern - which would typically be used by a client application to invoke business logic on the server side. I would propose that a better, cleaner way of integrating EJBs with the Web Dynpro framework would be to use a BusinessDelegate for invoking business logic, and importing a separate and distinct ModelBean (instead of a CommandBean) to be used for defining and binding to Context data.
I have built one Web Dynpro application thus far. Instead of using a CommandBean, I created a ModelBean that extends my business object DTO (Data Transfer Object) (which is quite appropriate for that role, given that it implements all the get & set methods that are required for the business data that I need to model). My Web Dynpro application also makes use of an independant BusinessDelegate that is packaged with my EJB DC - this is a standard best practice on J2EE projects. I have been asked by the people working with me to modify this architecture to bring it more in line with the SAP way of doing things. I am open-minded and willing to learn and accept new ways of thinking and doing things. However, I fail to understand the usefulness of merging structure and behaviour by resorting to CommandBeans:
- It violates the MVC paradigm by having one object (the CommandBean) serve as both model AND controller as far as the Web Dynpro application is concerned. The CommandBean is obviously a model - since it is literally imported as such into the Web Dynpro application. It is ALSO a controller from the Web Dynpro's application perspective, since all calls to the back-end go thru the CommandBean via one or more of its execute_xxx methods. In contrast, the use of a business delegate by the Web Dynpro application clearly separates the model (the CommandBean... or rather, a more suitably named ModelBean) from the controller (BusinessDelegate).
- Doesn't carry its own weight. In other words, I haven't yet been provided with any valid justification for going thru the extra effort of coding the CommandBean's execute methods. It's been proposed to me that it somehow serves as an abstraction layer between the Web Dynpro application and the business logic. I would argue that it is the BusinessDelegate's role to abstract away the back-end logic from clients. If one does have a BusinessDelegate available, I would argue there's no need to code execute methods in a separate CommandBean. To prove my point, I would simply point out that all of the CommandBean examples that I have seen so far, either in How-To documents, or in production code, all follow the same pattern....
CommandBean.execute_doSomething() calls BusinessDelegate.doSomething()
Not a heck of an "abstraction" layer... I would in fact argue that it is worse than useless. If some major change occurs in the business logic that requires changing the doSomething() operation, we expect of course to modify the BusinessDelegate. The Web Dynpro client will also presumably need to be modified - that's to be expected, and unavoidable. But then, we'll also need to go about and change the CommandBean's execute_doSomething() method - again, extra work for no apparent benefit. Adding and removing business methods has the same implication. All this for an layer that simply adds the prefix execute_ in front of all business method calls... Is this "abstraction layer" worth the cost of creating and maintaining it ??
- Unnecessarily complicates error handling. I have been told that for technical reasons, it is recommended that all exceptions thrown by the CommandBean be of type WDException or WDRuntimException. But what if the client application needs to react differently to different failure scenarios ? When I create a business object, I might wish to provide the user with an error messages if connection is lost to the backend, and with a different error message if an object already exists in the database with the same attributes. In order to do that, I will have to catch the WDException, extract the cause, and continue processing from there... possible, yes, but clearly less standard and more labor intensive than the classical try/catch mechanism.
To say nothing about the fact that SAP's own API documentation clearly states that applications using Web Dynpro can reference and catch WDExceptions, but THEY MUST NOT THROW OR EXTEND IT !
- Produces unnecessary DCs. Page 6 of the aforementioned document presents an architectural view of a Web Dynpro project that uses a CommandBean. Why an extra DC for the CommandBean ?? I created my ModelBean class right inside the Web Dynpro project (in the Package view). That, to me, is where this class should reside, because it is created for no other reason that to be used by this particular Web Dynpro application. What is the benefit of placing it in its own independant DC ?
- Not a typical application of the Command pattern. The well-documented command pattern (Design Patterns - Gang of Four) has been devised mainly to enable encapsulation of request as objects, thereby making it possible to:
- specify, queue and execute requests at different times
- decouple execution of a command from its invoker
- support undo operations
- support logging changes so that they can be reapplied in case of system crash making it possible to assemble commands into composite commands (macros), thereby structuring a system around high-level operations built on primitive operations.
None of this applies to the way the SAP CommandBeans are being used. Not that much of an issue to people new to J2EE and/or OO development... but quite confusing for those already familiar with the classic Command pattern.
At this point, I fail to understand the advantage of merging structure (model) and behaviour (execute methods) through the use of a unique CommandBean object. Am I missing something ?

Hi Romeo,
You would be disappointed, this reply ain't anywhere nearby to what you are talking about...
I wanted to mail you, but you have not mentioned your email in your profile.
I am really impressed by your flair for writing. It would be far better had you written a blog on this topic. Believe me, it would really be better. There is a much wider audience waiting out there to read your views rather than on the forums. This is what I believe. To top it, you would be rewarded for writing something like this from SDN. On the blogs too, people can comment and all, difference being there you would be rewarded by SDN, here people who reply to you would be rewarded by you. Doesn't make much a difference.
Anyways the ball is still in your court
As far as I am concerned, it has still not been much time since I have started working on Web Dynpro. So can't really comment on the issue...
Bye
Ankur

How to use EJB in JSP...urgent!!!

hello,
i am novice programmer in EJB.
i am using weblogic 6.1 ...
my problem is how to use EJB in jsp page.
my code is as follow..but its not displaying any result.
<%@ page import="javax.naming.InitialContext,
javax.naming.Context,
java.util.Properties,
firstEJB.First,
firstEJB.FirstHome"%>
<%
 long t1 = System.currentTimeMillis();
 System.out.println(t1);
 Properties props = new Properties();
 p.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.TengahInitialContextFactory");
 props.put(Context.PROVIDER_URL, "localhost:7001");
 Context ctx = new InitialContext(props);
 FirstHome home = (FirstHome)ctx.lookup("FirstEJB");
 First bean = home.create();
 String time = bean.getTime();
 bean.remove();
 ctx.close();
 long t2 = System.currentTimeMillis();
%>
<html>
 <head>
 <style>p { font-family:Verdana;font-size:12px; }</style>
 </head>
 <body>
 Message received from bean = "<%= time %>". Time taken :
 <%= (t2 - t1) %> ms.
 </body>
</html>
please tell me the solution.

Hi, I don't know if it may be the cuase of your problems, but you should narrow the Object obtained doing the lookup, like this:
FirstHome home = (FirstHome) PortableRemoteObject.narrow(ctx.lookup("FirstEJB"), FirstHome.class);

Re: TransactionRolledbackLocalException using EJBs with Glassfish

Hi,
I originally tried to hijack someone else's abandoned forum thread
TransactionRolledbackLocalException using EJBs with Glassfish
to ask my own question because it is vaguely related (there's something about "Glassfish" with both of us) but thankfully a forum moderator has split my post away.
My question is ...
I am running two applications on a Glassfish domain (ear and war) on Glassfish version 3.1.2.2 and finding this error occurs after running for several hours and requires a Glassfish restart. So far I have been unable to reliably reproduce this issue and a server restart only appears to be a short term fix.
It seems that some sequence of events messes up container managed transactions within the ear. Any information or suggestions on how I could pinpoint the root cause would be greatly appreciated.
[#|2013-04-30T09:55:19.402-0700|WARNING|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=26;_ThreadName=Thread-2;|javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted
     at com.sun.ejb.containers.BaseContainer.useClientTx(BaseContainer.java:4722)
     at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4601)
     at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1914)
     at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:205)
     at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
     at $Proxy267.query(Unknown Source)
     at sun.reflect.GeneratedMethodAccessor308.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:144)
     at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)
     at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
     at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
     at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
     at com.sun.corba.ee.impl.protocol.SharedCDRClientRequestDispatcherImpl.marshalingComplete(SharedCDRClientRequestDispatcherImpl.java:126)
     at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:273)
     at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:200)
     at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
     at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)

at $Proxy267.queryWell it seems that there is some (EJB?) method somewhere called 'query' that is blowing up. I would start by putting a debugging breakpoint there and seeing which line is causing an exception.

JNLP app using ejb - OutOfMemoryError

I have an application, fully signed, that connects to a
database on the same intranet, using ejb's.
When the user clicks on icons, the system loads data from the database into various tables. each data object type does a separate access to the database.
When the app is run in Oracle 9i JDeveloper it works fine but when I deploy over JNLP I get an out of mem error after the first access. This first access seems to work fine.
I have tried to increase the initial and max heap sizes in the jnlp file but all this does is take longer for the out of mem error to be thrown.
There doesnt seem to be any problem with loading up classes and Im stumped.
Below is some sample code used for one of the entity objects, used to access the ejb's.
public Vector getArisingList(String aircraftID)
    try
      Vector v = getEjb().getArisingList(aircraftID);
      clearEjb();
      return v;
    catch (Throwable e)
      e.printStackTrace();
    return null;
} and get/clearejb() go like this.. private ArisingService1 getEjb()
    if (ejb == null)
      try
         ejb = lookupHome().create();
      catch(Throwable e)
        e.printStackTrace();
    return ejb;
private ArisingService1Home lookupHome()
    ArisingService1Home home = null;
    String ejbUrl = "ArisingService";
    try
      Context ctx = new nazca.NazcaRemoteContext().getContext();
      home = (ArisingService1Home)ctx.lookup(ejbUrl);
    catch (Throwable e)
      e.printStackTrace();
    return home;
// for use after each call to getEjb so the session is cleared on the server
private void clearEjb()
    try
      ejb.remove();
    catch(Throwable e)
      System.err.println("Cound not call ejb.remove()");
    ejb = null;
}   Does anyone know what is going wrong?
Should I be clearing up some ejb stuff that im not?
Thanks in anticipation

Hello,
Dit you take a look at :
http://forum.java.sun.com/thread.jsp?forum=38&thread=181307
You also seem to be writing to the standard output.

Using EJB vs Socket : expensive satellite line

We are migrating a bank system from Clipper to Java(J2EE). One of the requisites is to save the bandwidth through the satellite line. Some developers came with a idea to make an object in bank store that talks with the central server through sockets, and in the central server a thread is created to handle that call and call the session bean. Anyone know how big (in bytes) is a EJB call??? (not the jndi lookup neither home finding), just a method to a session bean. How many bytes are added to the parameters data??? It could be a good idea to change from EJB to sockets through the satellite??? Another point is that the satellite has a 1.22 sec delay. Should it be used messages??? And the same question I make for messages, how big would be (in bytes) to send a message using JMS???

Greetings,
We are migrating a bank system from Clipper to
Java(J2EE). One of the requisites is to save the
bandwidth through the satellite line. Some developers
came with a idea to make an object in bank store that
talks with the central server through sockets, and inUltimately, this developer is just "reinventing the wheel". All synchronous network technologies communicate over sockets. This is the job of the object stubs through which EJBs (as well as other component models: CORBA, DCE, DCOM, etc.), communicate. In essence, this developer is suggesting communication client and server "objects" to take the place of a communication "stub" and "skeleton" pair. Only, in this case it would really only add to the complexity of the issue by adding an additional communication framework (aka "point of failure") - over-satellite client/server pair - in front of the framework that must still be used - EJB stub/skeleton pair (additionally, EJB skeletons are optional and may not even be used by your particular vendor). Furthermore, this solution will also require the creation of a new protocol to be communicated over the satellite decorators (an additional maintenance piece; aka "added complexity"). This solution may save some up-front bandwidth (largely depending on the implemented protocol), but the increased latency and maintenance complexity in your application may simply negate it (increased possibility for transmission repeats, session failures, protocol errors, etc.).
the central server a thread is created to handle that
call and call the session bean. Anyone know how big
(in bytes) is a EJB call??? (not the jndi lookup
neither home finding), just a method to a session
bean. How many bytes are added to the parameters
data??? It could be a good idea to change from EJB toAn EJB sits atop a communication layer which may be implemented using a vendor's protocol of choice. Such may be JRMP (RMI), IIOP (CORBA), or proprietary (e.g. WebLogic's 'T3'). The answer to this question, therefore, depends upon the (packet size of) the actual protocol in use.
sockets through the satellite??? Another point is thatDepends... the added complexity of this approach will add the TCO of your application in other ways. The real question is "which is more - maintenance cost, or bandwidth cost?" Some things to keep in mind:
* An effective socket implementation requires: invention of a stable and robust protocol; proper state management; a scalable threading model; and let's not forget - its own full lifecycle of DDTM: design, development, testing, and maintenance.
* Current component models - EJB most certainly included :) - already have, and have undergone, the previous.
the satellite has a 1.22 sec delay. Should it be usedAdjust your server's timeout parameters.
messages??? And the same question I make for messages,Depends if your application needs synchronous or asynchronous communication, and if asynchronous, 1-way or 2-way. If synchronous (response must follow request), then "socket-based" communication is required - whether it's through EJB or direct. If asynchronous 1-way (response not required), then JMS or low-level datagram-based communication may be used; both may also be used for 2-way (anytime response), but both, of course, also have their own sets of pros and cons depending on your application and following many of the same arguments as above...
how big would be (in bytes) to send a message using
JMS???As with EJB, depends on the protocol implementor.
Regards,
Tony "Vee Schade" Cook

AXI DB2 distributed sap systems and rsh

Hello,
we are running sap with aix 5.3 and db2 v9. our application server, central instance and database are running on different servers. Until now we are using rsh to start the distibuted systems. security colleagues asked us to change to ssh. we have seen, that it is possible to start db2 with ssh. but it is also possible in a distributed sap system to set rlogin=false and doesn't use rsh anymore?
thanks
alexander

Not sure what you are asking about - indeed, to use ssh for DB2 is of importance for DPF systems (i.e. BW-based SAP systems in multi-partition environments).
If you are asking how to enable ssh for starting SAP systems, then I guess the approach is to replace 'rlogin' by 'ssh' in your scripts. Of course, you need to ensure before that ssh is working as intended. E.g. if you expect the process to work without providing passwords, then you need to ensure that ssh can login without a password. You can find related information in the net e.g. searching with keywords
ssh automatic login
If all this does not help, or address your issue, please provide more exact information, e.g. the scripts you use.

Could I use EJB in mission-critical task,like telecom realtime billing?

We will begin a project about telecom billing.The key point of the project is the realtime billing,which is must be processed with high speed and efficiency.We have a plan to use Tuxedo on which to run some services coded by c lanaguage.Other management facilities and interfaces with other system could be built by java(EJB).
Now ,I am wonder why couldn't we using EJB in billing task ? Is there any success story about using EJB model to build mission-citical system? or is EJB good for that?
thanks

Joy Wind,
AFAIK, The answer is NO. Java itself is not "currently" suitable for real time applications.
However, there is a community process going on at http://www.rtj.org/.
There is also a reference implementation available which you can check out.
http://www.timesys.com/prodserv/java/index.cfm
I guess you can use it for proto-types and demos. However, if you want to use it in some mission critical application then you have to wait till it becomes a part of standard java.
hope this helps.
regards,
Abhishek.

EJB3 newbie - when to use EJB?

If I just want to build a reusable module that does not have any business critical actions, such as a login module, or a blog module, should I use EJB?
Also, am I correct that only EJBs can run on distributed servers, and that all other non-EJB components in a web applications can only run on a single server?

If I just want to build a reusable module that does
not have any business critical actions, such as a
login module, or a blog module, should I use EJB?
No. Any Java module can be made to be reusable, if designed to be so. Actually, by using EJBs, you'll be limiting the reusability of your modules, since those would need to run inside an EJB container.
Also, am I correct that only EJBs can run on
distributed servers, No, they can run in distributed as well as non-distributed environments.
and that all other non-EJB
components in a web applications can only run on a
single server?No. Not sure where you got that idea from. I think you're confusing multiple server environment (clusters) with distributed[i] business objects. You can cluster applications that collocate all their components in a single JVM.
There are actually very few cases where the use of EJB is to be considered (roughly 10% of cases):
- if you really need object distribution - this is not the norm
- if you need to use IIOP as the protocol for communication
- MDBs are a good solution for some applications heavily based on messaging

ADF 11, USING EJB, CALL STORE PROCEDURE, A PROBLEAM?

ADF 11, USING EJB, CALL STORE PROCEDURE, A PROBLEAM?
I have a store procedure:
CREATE OR REPLACE PACKAGE BODY PK_HR1
IS
FUNCTION FUNC04
RETURN CUR_RESULT
IS
X_CUR CUR_RESULT;
BEGIN
OPEN X_CUR FOR
select mako, tenko, diachiko from kho;
RETURN X_CUR;
EXCEPTION
WHEN OTHERS THEN
RAISE;
END FUNC04;
END PK_HR1;
In the entities class, I have a NamedStoredProcedureQuery:
@Entity
@NamedStoredProcedureQuery(name="Kho.FUNC04",
 resultClass=Kho.class,
 procedureName="PK_HR1.FUNC04" )
public class Kho implements Serializable {
In session bean, i have a method
public class SessionEJBBean implements SessionEJB, SessionEJBLocal
public void test() throws Exception{
try {
//code here ...
List<Kho> listKho = em.createNamedQuery("Kho.FUNC04").getResultList();
System.out.println("aaaa");
} catch (Exception ex) {
ex.printStackTrace();
} finally {
I try running, but always show errror
this errors:
Internal Exception: java.sql.SQLException: ORA-06550: line 1, column 7:
PLS-00221: 'FUNC04' is not a procedure or is undefined
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
Error Code: 6550
Call: BEGIN PK_HR1.FUNC04(); END;
Query: ReadAllQuery(jp.co.mfr.sgs.bean.Kho)
help help me?

You need to use a CallableStatement for this.
--olaf

Distributed Elevator system using EJB 3

Similar Messages

Maybe you are looking for