EJB and Web layer recompile

Why is it that when modifying the EJB layer (and redeploying), the Web layer must be redeployed again, even if there are no modifications on the interfaces?

this is because as of now deployment is done for the whole archive - this is something that will be looked into I guess

Similar Messages

  • Error during EAR deployment with EJB and web service

    I created a simple stateless EJB with one method called echo that returns a string.  I created a web service using the wizard, did a build and deployed.  The deployment did not report an error, but the logs in the visual administrator showed the follwoing message, and the web service did NOT deploy.
    Am I missing something related to EJB and web service security?
    PLEASE HELP ME.
    >>> Warning: delete security configuration [apps/com.areva/ear/ejb/security/com.areva~ejb.jar]
    [EXCEPTION]
    java.lang.Exception
         at com.sap.engine.services.security.server.PolicyConfigurations.unregisterPolicyConfiguration(PolicyConfigurations.java:153)
         at com.sap.engine.services.ejb.EJBAdmin.remove(EJBAdmin.java:2538)
         at com.sap.engine.services.deploy.server.application.RemoveTransaction.removeApplication(RemoveTransaction.java:294)
         at com.sap.engine.services.deploy.server.application.RemoveTransaction.prepare(RemoveTransaction.java:178)
         at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhasesOnOneServer(ApplicationTransaction.java:299)
         at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhases(ApplicationTransaction.java:321)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.makeGlobalTransaction(DeployServiceImpl.java:3028)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.remove(DeployServiceImpl.java:820)
         at com.sap.engine.services.deploy.server.DeployRuntimeControlImpl.remove(DeployRuntimeControlImpl.java:271)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:324)
         at com.sap.pj.jmx.introspect.DefaultMBeanInvoker.invoke(DefaultMBeanInvoker.java:58)
         at com.sap.pj.jmx.mbeaninfo.AdditionalInfoProviderMBean.invoke(AdditionalInfoProviderMBean.java:289)
         at com.sap.pj.jmx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:944)
         at com.sap.pj.jmx.server.interceptor.MBeanServerWrapperInterceptor.invoke(MBeanServerWrapperInterceptor.java:288)
         at com.sap.engine.services.jmx.CompletionInterceptor.invoke(CompletionInterceptor.java:400)
         at com.sap.engine.services.jmx.RedirectInterceptor.invoke(RedirectInterceptor.java:340)
         at com.sap.pj.jmx.server.interceptor.MBeanServerInterceptorChain.invoke(MBeanServerInterceptorChain.java:330)
         at com.sap.engine.services.jmx.MBeanServerSecurityWrapper.invoke(MBeanServerSecurityWrapper.java:287)
         at com.sap.engine.services.jmx.MBeanServerInvoker.invokeMbs(MBeanServerInvoker.java:157)
         at com.sap.engine.services.jmx.ClusterInterceptor.invokeMbs(ClusterInterceptor.java:220)
         at com.sap.engine.services.jmx.ClusterInterceptor.invoke(ClusterInterceptor.java:803)
         at com.sap.engine.services.jmx.MBeanServerInterceptorInvoker.invokeMbs(MBeanServerInterceptorInvoker.java:102)
         at com.sap.engine.services.jmx.connector.p4.P4ConnectorServerImpl.invokeMbs(P4ConnectorServerImpl.java:61)
         at com.sap.engine.services.jmx.connector.p4.P4ConnectorServerImplp4_Skel.dispatch(P4ConnectorServerImplp4_Skel.java:64)
         at com.sap.engine.services.rmi_p4.DispatchImpl._runInternal(DispatchImpl.java:291)
         at com.sap.engine.services.rmi_p4.DispatchImpl._run(DispatchImpl.java:183)
         at com.sap.engine.services.rmi_p4.server.P4SessionProcessor.request(P4SessionProcessor.java:119)
         at com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java:37)
         at com.sap.engine.core.cluster.impl6.session.UnorderedChannel$MessageRunner.run(UnorderedChannel.java:71)
         at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)
         at java.security.AccessController.doPrivileged(Native Method)
         at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:94)
         at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:162)

    I have the same message. I am running sp11.
    Does anyone have an answer for this?????
    >>> Warning: delete security configuration [apps/avalero.com/rtfa-ear/contextRoot]
    [EXCEPTION]
    java.lang.Exception
         at com.sap.engine.services.security.server.PolicyConfigurations.unregisterPolicyConfiguration(PolicyConfigurations.java:153)
         at com.sap.engine.services.servlets_jsp.server.container.WebContainerHelper.removeSecurityResources(WebContainerHelper.java:905)
         at com.sap.engine.services.servlets_jsp.server.container.WebContainerHelper.remove(WebContainerHelper.java:447)
         at com.sap.engine.services.servlets_jsp.server.container.RemoveAction.remove(RemoveAction.java:50)
         at com.sap.engine.services.servlets_jsp.server.container.WebContainer.remove(WebContainer.java:150)
         at com.sap.engine.services.deploy.server.application.RemoveTransaction.removeApplication(RemoveTransaction.java:294)
         at com.sap.engine.services.deploy.server.application.RemoveTransaction.prepare(RemoveTransaction.java:178)
         at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhasesOnOneServer(ApplicationTransaction.java:299)
         at com.sap.engine.services.deploy.server.application.ApplicationTransaction.makeAllPhases(ApplicationTransaction.java:323)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.makeGlobalTransaction(DeployServiceImpl.java:3033)
         at com.sap.engine.services.deploy.server.DeployServiceImpl.remove(DeployServiceImpl.java:821)
         at com.sap.engine.services.deploy.server.DeployRuntimeControlImpl.remove(DeployRuntimeControlImpl.java:271)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:324)
         at com.sap.pj.jmx.introspect.DefaultMBeanInvoker.invoke(DefaultMBeanInvoker.java:58)
         at com.sap.pj.jmx.mbeaninfo.AdditionalInfoProviderMBean.invoke(AdditionalInfoProviderMBean.java:289)
         at com.sap.pj.jmx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:944)
         at com.sap.pj.jmx.server.interceptor.MBeanServerWrapperInterceptor.invoke(MBeanServerWrapperInterceptor.java:288)
         at com.sap.engine.services.jmx.CompletionInterceptor.invoke(CompletionInterceptor.java:400)
         at com.sap.pj.jmx.server.interceptor.BasicMBeanServerInterceptor.invoke(BasicMBeanServerInterceptor.java:277)
         at com.sap.jmx.provider.ProviderInterceptor.invoke(ProviderInterceptor.java:255)
         at com.sap.engine.services.jmx.RedirectInterceptor.invoke(RedirectInterceptor.java:340)
         at com.sap.pj.jmx.server.interceptor.MBeanServerInterceptorChain.invoke(MBeanServerInterceptorChain.java:330)
         at com.sap.engine.services.jmx.MBeanServerSecurityWrapper.invoke(MBeanServerSecurityWrapper.java:287)
         at com.sap.engine.services.jmx.MBeanServerInvoker.invokeMbs(MBeanServerInvoker.java:157)
         at com.sap.engine.services.jmx.ClusterInterceptor.invokeMbs(ClusterInterceptor.java:220)
         at com.sap.engine.services.jmx.ClusterInterceptor.invoke(ClusterInterceptor.java:803)
         at com.sap.engine.services.jmx.MBeanServerInterceptorInvoker.invokeMbs(MBeanServerInterceptorInvoker.java:102)
         at com.sap.engine.services.jmx.connector.p4.P4ConnectorServerImpl.invokeMbs(P4ConnectorServerImpl.java:61)
         at com.sap.engine.services.jmx.connector.p4.P4ConnectorServerImplp4_Skel.dispatch(P4ConnectorServerImplp4_Skel.java:64)
         at com.sap.engine.services.rmi_p4.DispatchImpl._runInternal(DispatchImpl.java:294)
         at com.sap.engine.services.rmi_p4.DispatchImpl._run(DispatchImpl.java:183)
         at com.sap.engine.services.rmi_p4.server.P4SessionProcessor.request(P4SessionProcessor.java:119)
         at com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java:37)
         at com.sap.engine.core.cluster.impl6.session.UnorderedChannel$MessageRunner.run(UnorderedChannel.java:71)
         at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)
         at java.security.AccessController.doPrivileged(Native Method)
         at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:94)
         at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:162)

  • Deployment Aborted (EJB and Web Services)

    Hello All.
    In SAP Netweaber Developer Studio I created a Project with an Entity EJB and another Sesion EJB.
    The Sesion Bean uses the Entity Bean (persistence). After this, it generate a Web Services.
    After building the project ejb and project EAP. Within the Project EAP I took file Persistent_EAP.ear and to make respective deploy on the Server, in the Deploy out View I get the message 'Deploy Aborted'.
    The log of the message say,
    ++Sep 30, 2011 5:43:05 PM  Info: - Starting deployment -++
    ++Sep 30, 2011 5:43:05 PM  Info: Error handling strategy: OnErrorStop++
    ++Sep 30, 2011 5:43:05 PM  Info: Prerequisite error handling strategy: OnPrerequisiteErrorStop++
    Sep 30, 2011 5:43:05 PM  Info: Update strategy: UpdateAllVersions
    Sep 30, 2011 5:43:05 PM  Info: Starting deployment prerequisites:
    Sep 30, 2011 5:43:10 PM  Info: Loading selected archives...
    Sep 30, 2011 5:43:10 PM  Info: Loading archive 'C:\usr\sap\J2E\JC01\SDM\program\temp\temp38292Persistencia_Mod_EAP.ear'
    Sep 30, 2011 5:43:16 PM  Info: Selected archives successfully loaded.
    Sep 30, 2011 5:43:16 PM  Info: Actions per selected component:
    Sep 30, 2011 5:43:16 PM  Info: Update: Selected development component 'Persistencia_Mod_EAP'/'sap.com'/'localhost'/'2011.09.30.16.03.19'/'1' updates currently deployed development component 'Persistencia_Mod_EAP'/'sap.com'/'localhost'/'2011.09.30.16.03.19'/'0'.
    Sep 30, 2011 5:43:16 PM  Info: Ending deployment prerequisites. All items are correct.
    Sep 30, 2011 5:43:16 PM  Info: Saved current Engine state.
    Sep 30, 2011 5:43:16 PM  Info: Starting: Update: Selected development component 'Persistencia_Mod_EAP'/'sap.com'/'localhost'/'2011.09.30.16.03.19'/'1' updates currently deployed development component 'Persistencia_Mod_EAP'/'sap.com'/'localhost'/'2011.09.30.16.03.19'/'0'.
    Sep 30, 2011 5:43:16 PM  Info: SDA to be deployed: C:\usr\sap\J2E\JC01\SDM\root\origin\sap.com\Persistencia_Mod_EAP\localhost\1\2011.09.30.16.03.19\temp38292Persistencia_Mod_EAP.ear
    Sep 30, 2011 5:43:16 PM  Info: Software type of SDA: J2EE
    Sep 30, 2011 5:43:16 PM  Info: ***** Begin of SAP J2EE Engine Deployment (J2EE Application) *****
    Sep 30, 2011 5:46:13 PM  Info: Begin of log messages of the target system:
    11/09/30 17:43:16 -  ***********************************************************
    11/09/30 17:43:21 -  Start updating EAR file...
    11/09/30 17:43:21 -  start-up mode is lazy
    11/09/30 17:43:22 -  EAR file updated successfully for 922ms.
    11/09/30 17:43:22 -  Start updating...
    11/09/30 17:43:25 -  EAR file uploaded to server for 1594ms.
    11/09/30 17:46:13 -  ERROR: Not updated. Deploy Service returned ERROR:
                         java.rmi.RemoteException: Cannot deploy application sap.com/Persistencia_Mod_EAP..
                         Reason: Webservices common deployment exception! The reason is: Error occurred, trying to update web services for application sap.com/Persistencia_Mod_EAP. . Additional info: none; nested exception is:
                         +     java.lang.Exception: com.sap.engine.interfaces.webservices.server.deploy.WSDeploymentException: Webservices common deployment exception! The reason is: Error occurred, trying to update web services for application sap.com/Persistencia_Mod_EAP. . Additional info: none+
    I don't know what is wrong, when say: Error occurred, trying to update web services for application...
    Could someone please help me?
    Thanks in advanced,
    Esther

    Dear Esther,
    This exception usually happens when the application is not packaged properly.
    It seems that the J2EE engine web services deployment processor is looking for a descriptor which is absent in the jar file.
    This could happen for instance if you forget to save all the modified files before rebuilding.
    Unfortunately I cannot tell you which web service descriptor is missing, without looking at the packaged application.
    Try the following:
    1) Regenerate your virtual interfaces
    2) Save all modified files
    3) Rebuild the application
    4) Deploy the application again.
    Best Regards,
    Abhishek

  • EJBs and web services  in Application server  ??

    Hi all,
    I just wanted to ask for a help in a scenario that i am facing:
    I have a Application that relies on EJBs for Business Logic
    I basically use the Jboss A/s[4.2.2 GA] server for the same and now there is a need to Expose these bean methods through a web service
    so that our web team can make use of the same Business logic.
    Currently i have implemented a End point interface that my Bean class implements so that i can expose
    my bean methods to the web team
    Req:
    I want to create a separate Enterprise Bean which resides in the same JVM as my Application bean , and acts as a wrapper for my application bean
    Also,
    Further elaboration of the problem is as follows:
    THE existing Application beans Remote interface has all the business methods that i want to expose.
    The new bean should act as a delegate which intercepts the web clients call extracts the request from the call
    and passes it to the application bean methods.
    So this basically requires that new bean should be able to communicate with my application bean +(Which is BTW a stateless session bean)+
    and pass on clients requests to the same.
    Kindly provide suggestion for the same or any ideas as soon as possible
    thanks again
    veneet
    Edited by: RainaV on 14 May, 2009 6:49 PM
    Edited by: RainaV on 14 May, 2009 6:57 PM

    Let me make it more clear for everyone
    Let [A] be my application bean which has all the business Logic.
    is a new wrapper bean that needs to communicate to bean [A] for accessing the Business Logic
    The requirement for creating Bean[B] is two folds
    1) it will provide a wrapper class for breaking down the web client requests,
    which are in  XML format;
    into simpler data structure which can be passed as parameters to bean [A}.
    2)This bean [B] will send the response back to the web client who is in need of the service
    Now as pointed out by one of the guys why not create a Local interface that is not possible at this point as Most of the session bean methods have been declared to throw
    Remote Exceptions and i am faced with the issue that this Design mistake is irreversible due to the Size of the Code and other factors
    Now i have been looking and some Alternatives for the same .
    The problem is i have not been able to find any way to do the same and need suggestions and ideas if anyone has some on this issue
    i hope this clears the matter
    thanks again
    veneet

  • EJB and Web Services

    Hi,
    I have created a EJB project with Stateless Session Bean having just one method, Java persitence (connnection to MS SQL). I have added this project to the Enterprise project as well.From the context menu when I select to create Web Service. The method is not selectable.
    What is going wrong?
    Can somebody please help?
    Best regards,
    Dharmi

    Hi Dharmi,
    How did you do that? Create an EJB which connects to MS SQL?
    Are there specific jars or something that have to be added to the EJB?
    Did you also have to install a SQL server driver and such?
    Can you provide a step-by-step for the creation of an EJB which gathers data from MS SQL?
    Kind regards
    Allan

  • EJB accessing web application classes

    Hi,
    what is the right method to enable packaged EJB to access classes of a
    web application? Packaging both the EJB and web application in same
    ear is not possible in this situation. We are running WebLogic 6.0 and
    ejb is in
    wlserver6.0/config/mydomain/applications/EJB.jar
    and the classes it should use are in
    wlserver6.0/config/mydomain/applications/application_name/WEB-INF/classes,
    i.e. not packed into war -package. adding
    wlserver6.0/config/mydomain/applications/application_name/WEB-INF/classes
    to WebLogic's CLASSPATH enables the ejb to deploy but seems to screw
    other deployments.

    Please address calling and EJB from a JSP using the EJB to JSP tags...?I'm throwing
    ClassCast errros on Object...
    William Kemp <[email protected]> wrote:
    This is addressed numerous times in this newsgroup and others. So, if
    you are
    insterested in additional explanations, a search of the newsgroups will
    be
    productive.
    The WLS 6.x classloading scheme for enterprise apps, ejbs, and webapps
    does
    not permit and ejb to access webapp classes in the WEB-INF/classes directory
    unless those classes are placed in the java system classpath, which,
    you have
    found, creates other problems.
    If classes are needed by both webapp and ejb, place them in a utility
    jar file
    that is packaged in the ear with the ejb, or webapp, or both, and refer
    to
    them with the Class-Path manifest directive in the ejb jar file or the
    webapp
    war file.
    For the details, see:
    http://e-docs.bea.com/wls/docs61/programming/packaging.html#1029830
    and the 7.0 stuff is good, too:
    http://edocs.bea.com/wls/docs70/programming/classloading.html#1029830
    Bill
    janne wrote:
    Hi,
    what is the right method to enable packaged EJB to access classes ofa
    web application? Packaging both the EJB and web application in same
    ear is not possible in this situation. We are running WebLogic 6.0and
    ejb is in
    wlserver6.0/config/mydomain/applications/EJB.jar
    and the classes it should use are in
    wlserver6.0/config/mydomain/applications/application_name/WEB-INF/classes,
    i.e. not packed into war -package. adding
    wlserver6.0/config/mydomain/applications/application_name/WEB-INF/classes
    to WebLogic's CLASSPATH enables the ejb to deploy but seems to screw
    other deployments.

  • Oracle or MS SQL Server, EJB Models and Web Dynpro Application

    Hi
    I've a table in MS SQL database. I've created in Visual Admin, the datasource(jdbc/MyAlias) for the above. SQL Server has Employee Table with EmpId, FirstName, LastName and Description as its Columns.
    I want to display, modify , insert and delete entries from the Employee Table using web Dynpro. For this we have used JDBC method by which we create class file which will have JDBC connectivity and logic for getting data from backend. This class file then used for display, update and other operations. And the context is built at design time.
    This is not proper method, as this doesn't come under perview of MVC concept.
    I want to use EJB Models for this case. But I'm stuck with some problems.
    1. How do I implement EJB models in this scenario.
    2. How do EJB module (entity bean) connects to external database.
    3. What are the most logical steps to be used in this case.
    Any pointers for this will greatly appreciated with points?
    So far I was able to do create EJB module of Entity Bean type with all interfaces. But beyond this I'm not able to proceed. Do let me know the step wise procedure for this kind of scenario.
    Thanks
    Srikant

    Hi Srikant,
    I have worked on similar stuff, but the scenario was a little different. I worked on creating Web Services using EJBs, but the basic part was that, the web service was supposed to interact with the SQL Server database. So maybe I can help you...
    First thing which is needed is that you have created the JDBC Connector in your Visual Administrator correctly. If you wish to cross check, you can see my answer in the following thread:
    JDBC error
    In this thread itself I have given the code which is the solution to your problem (this is what i believe). I am pasting the code again:
    <b>InitialContext initialContext = new InitialContext();
    DataSource dataSource = (DataSource)initialContext.lookup("jdbc/MyAlias");
    java.sql.Connection connection = dataSource.getConnection();</b>
    You can use this code in the method of your EJB, and then you can easily use this connection object to access your database tables using SQL queries.
    And if by any chance you are looking for a step wise procedure for creating a web service from an EJB, then give me your email address, i will send you the doc.
    Bye
    Ankur
    Do reward points if it helps!!

  • (261680070) Q SYNCH-11 How do my web service methods accees EJBs and java classes?

    A<SYNCH-11> How do my web service methods accees EJBs and java classes?
    A<SYNCH-11> It is simple to use java classes, just do it as you would ordinarily.
    The .jws file really contains a simple class so you can program with it in the same
    way that you would use a regular Java class.
    To use an EJB you can go and access it directly as you would with any EJB remote
    client (lookup home stub, create, etc) or if the EJB is deployed to WLS you can use
    a control to provide a very simple wrapper to the EJB. We will see this in detail
    on Thursday in the ADVC module.

    Futher information about the possibility of callback:
    It may be possible for a synchronous only web service (i.e. MS .net) to even paticipant
    in the callback functionality of asynchronous web services. If the client implements
    the appropriate methods for the callback but listens for them on a different port
    or binding than the SOAP request, then web service may be able to build a response
    if the client's "callback URL" is submitted as the beginning part of a conversation.
    Watch the BEA developer forum (http://dev2dev.bea.com) for more information about
    this approach and other tips and techniques for building web services.
    "Adam FitzGerald" <[email protected]> wrote:
    >
    Q<SYNCH-03> I heard that MS .net only implements synchrnonus method? If
    this is true.
    Does it means my async methods will only work with J2EE clients?
    A<SYNCH-03> I do not know the limitations of .net but let me point out that
    is very
    difficult to provide asynchronous web service method invocation (this is
    different
    from an asynchronous web service). HTTP as a general communication protocol
    is based
    on a request and response paradigm so your client libraries will mostly
    likely be
    expecting a response even if it is empty (check the asynchronous example
    from today
    to see that the start method still returns an empty response). You must
    distinguish
    this from the notion of an asynchronous web service which is a business
    operation
    that occurs on the server whose return value/result is not directly associated
    with
    building response to the client. An asynchronous web service can (and generally
    will)
    be started and stopped with web service operations that are invoked synchronously.
    Thus MS .net clients can still be client to WLS hosted web services.

  • (261705413) Q RPCC-21 Can you compare a performance of "usual" RPC from EJB and RPC from Web Services?

    Q<RPCC-21> Can you compare a performance of "usual" RPC from EJB and RPC from Web
    Services?
    A<RPCC-21> There are additional performance overheads for invoking a web service
    when compared to straight EJB invocation. However, you should not think of web
    services as a way to replace your EJBs instead you should be willing to accept
    some performance decline for the massive gains in platform interoperability and
    the ability to exposure your services outside of you firewall.
    Additionally, performance decreases will be dependent on several factors. The
    most significant of which is the XML-Java and Java-XML translation of the SOAP
    message. This can be very fast if the XML structure is simple but if you web services
    requires a parameter that has a complex XML format you may see a more significant
    slow down.
    Adam

    Sorry if this sounds like I am new to this but I am.
    So, the extended version is the format that would be used if you were not utilizing the files that the wsdl2java function creates?
    And this is done to when you want more flexibiility for the user to call your service?
    So, you would push to have the stub files used when you want to control how the web service is used?
    thanks for the feedback.

  • 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:
    - <b>It violates the MVC paradigm</b> 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).
    - <b>Doesn't carry its own weight.</b> 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 ??
    - <b>Unnecessarily complicates error handling</b>. 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 !
    - <b>Produces unnecessary DCs</b>. 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 ?
    - <b>Not a typical application of the Command pattern</b>. 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:
    - <b>It violates the MVC paradigm</b> 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).
    - <b>Doesn't carry its own weight</b>. 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 ??
    - <b>Unnecessarily complicates error handling</b>. 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 !
    - <b>Produces unnecessary DCs</b>. 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 ?
    - <b>Not a typical application of the Command pattern</b>. 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

  • Passing blob from app layer to web layer

    Hi,
    We have some PDF files stored in Oracle database. I can retrieve them out using the ejb's from the app layer, but can not pass it to the web layer as a blob. I guess blob data type is not serializable. Appreciate any suggestions.
    Adam

    a blob is a specfic datatype and should not normally be exposed to the web tier. So try using a byte array or byteStream. Both work for me.
    -lp

  • EJB vs web services - architecture question

    I am about to be involved in architecting a new system that will have a very large amount of business rules. The application will be 3-tiered with the client application being a swing based java desktop application making requests of objects (ejb or other) to a j2ee application server.
    Im rather new to ejb development, having only built sample apps in the past. What im wondering is if there is a way to get around the RMI dependency for communitation between the client app and the server components. this is one reason im considering at least partial use of web services. ive become pretty good with apache soap, xml and seb services todate. however, i also need transaction support and im not sure if web services will do this yet. ive read about some work in this area.
    does anyone know of an (hopefully opensource) implentation of a SOAP-EJB and/or EJB-SOAP implementation layer ?
    The crux of the problem is that i need things like transactions and session management but i would like to communicate via soap and/or xml.

    Ive also seen a few examples of using a servlet as a request dispatcher to service the SOAP requests to EJB's. im just wondering if there was something available that will do this without having to roll my own so to speak. I want to be able to communicate with my ejb's over port 80, but in a secure way.
    Im also anxiously waiting for Apache Geronimo.

  • EJB and ASP

     

    Think of XSL and JSP as the X and Y axis. They approach solving an HTML (or
    XML) rendering problem in two different ways. Each has its benefits. When
    the primary input is a known flavor of XML, then XSL is definitely a better
    way to go.
    Cameron Purdy
    Tangosol
    "Argyn Kuketayev" <[email protected]> wrote in message
    news:[email protected]...
    I think the best approach would be to use XML and XSL. I didn't work on itfor
    production, but I'm going to try.
    I would call EJB's from servlet, then put returns in one or more XMLfiles, then
    take XSL and convert to anything, say HTML on the fly and send it back to
    client's browser.
    In this model web designer won't need to care about Java, JavaBeans andJSP tags,
    he will get my XML definition and make a XSL.
    Jason Jonas wrote:
    The best way we have found is:
    /->Database
    Client->Servlet->EJBs-->Legacy Systems
    ^ | \->Etcetera
    \ |
    \---JSP
    All client requests are handled by servlets. Servlets perform the
    brunt of Java work that would otherwise be in your JSP or a bean. The
    servlets, of course, make calls to EJBs. The EJBs carry out all
    business logic (e.g. talking to databases, legacy systems...). The
    servlets then set attributes in the request and forward the request to
    a JSP. The only responsibility the JSP has is presentation. We have
    found this reduces the required Java in a JSP down to a manageable
    subset that, in some cases, the HTML folks can handle. For instance,
    enumerating through a Vector to populate a list box... It doesn't
    always work this way, but most of the time.
    If client requests first hit a JSP, I would certainly encourage you to
    use JavaBeans in an effort to reduce the amount of Java in a JSP to a
    manageable amount.
    Jason
    On Tue, 08 Aug 2000 18:23:13 -0400, Argyn Kuketayev
    <[email protected]> wrote:
    one more option:
    in your JSP call servlets, and they will call EJBs and return java
    beans
    (simple containers like struct in C/C++) with data.
    in this case JSP will be your presentation layer, servlet - controllerand
    EJBs - model. you may prefer to wrap all entity EJB calls in astateless
    session beans, which will implement your business workflow.
    example:
    displayItems.jsp has a form with one text field "name" and a button
    "search".
    when you click a button, it will post a request to ItemListServlet. the
    servlet takes "name" parameter, and calls a ItemHome.findByName(String
    ItemName) method of Item session EJB. then it processes the returning
    Collection, and puts an array with myItems[] into a session andredirects to
    another page ItemList.jsp. now, ItemJsp takes an array and populates atable
    on the screen. here myItems is a simple java class with public fields,like
    C struct.
    in this option, your servlets are kind of dispatchers between jsp andEJBs.
    >>>
    Arda Mirek wrote:
    What is the recommended/proven architecture for accessing
    EJB through JSP (speed / ease of development / maintainability)?
    Is accessing EJBs through JSP a bad idea and is it better to provide
    another layer between the two like JavaBeans (JSP -> JavaBeans ->
    EJB) ?
    >>>>
    Speed and scalibility is very important (as usual :)
    Thanks.
    Arda Mirek

  • Move and redeploy application- and web-servers for Planing?

    Hi, all!
    Have Hyperion Planing ability to move application- and web-servers from unix-machine to another win-machine and after redeploy existing unix-installed planing on it?

    They are actually for for 2 different things. The Sun WAS is for enterprise applications, EJBs and the like.
    Tomcat is for simpler Servlet/JSP hosting.
    The Sun WAS actually uses the Tomcat server as its Servlet/JSP engine then adds EJBs on top.

Maybe you are looking for