7 Replies Latest reply on Jun 25, 2009 7:43 AM by Hodmi

    Java WebServices VS JAVA API SOAP

    krishna_p_p

      Hi All,

       

         We can use two ways of Java client Implementation to connect OutputService via SOAP Protocol.

      1) WSDL2JAVA : Create java classing using OutputServer?WSDL file.

      2) Use Connection parameters

          

              ConnectionProps.setProperty("DSC_DEFAULT_SOAP_ENDPOINT", http://localhost:8080);

       

       

              ConnectionProps.setProperty("DSC_TRANSPORT_PROTOCOL","SOAP");

       

      Which is the difference between the above two implemenations?

      What are advantages and disadvantages over one another?

       

      Regards

      Krishna.

        • 1. Re: Java WebServices VS JAVA API SOAP
          Rui Esteves Level 3

          If you use the Java WebServices API (if you use the WSDL file) you're accessing via SOAP to a w3c complient xml based webservice. 1)

           

          If you use the other way you are using EJB3.0 to connecto to Livecycle. 2)

           

           

           

          1) Pros

          - Its standard and platform independent.

          - The client is what you want it to be.

          - It uses standard ports to comunicate (80 & 443 if you set up your app server to provide https/ssl connections)

          - Your client won't import any Adobe library

           

          Cons

          - Slower connection

          - Slower marshling and unmarshing

          - If you don't use a friendly IDE you dev team will have to be savy with WebServices or your development time will sky rocket.

           

          2) Pros

          - Its EJB3.0 (easy, fast, reliable)

           

          Cons

          - If your client/consumer isn't Java you cannot use this

          - Not firewall friendly

          - You have to drag endless jar files (Adobe and app server ones)

          - Because of the above con, you're app is platform dependent.

           

           

          I use EJB3.0 whenever my client runs on the same network that the server and my client is Java.

          I use WebServices when i cannot use EJB3.0

          1 person found this helpful
          • 2. Re: Java WebServices VS JAVA API SOAP
            krishna_p_p Level 1

            Thanks for your answer but my question is

             

            if i use below connection parameters, the communication between the ADOBE ES and client will be on SOAP protocol.

            I need not to create Java classes using WSDL2Java. am i correct?

             

            ConnectionProps.setProperty("DSC_DEFAULT_EJB_ENDPOINT", http://localhost:8080);

             

             

             

             

             

            ConnectionProps.setProperty("DSC_TRANSPORT_PROTOCOL","SOAP");

             

             

            ConnectionProps.setProperty("DSC_SERVER_TYPE", "JBoss");

             

             

            ConnectionProps.setProperty("DSC_CREDENTIAL_USERNAME", "administrator");

             

             

            ConnectionProps.setProperty("DSC_CREDENTIAL_PASSWORD","password");

             

             

            Regards

            Krishna...

             

            • 3. Re: Java WebServices VS JAVA API SOAP
              Rui Esteves Level 3

              The short answer: Yes, you're correct.

               

              But you'll still be using EJB3.0 instead of WebServices, regardles of the communication protocol.

              • 4. Re: Java WebServices VS JAVA API SOAP
                Hodmi Level 4

                Yes, you are correct - if you are able to use the Adobe supplied client jar files then you don't need to generate your own proxy classes.

                 

                You may want to check out the official docs at: http://livedocs.adobe.com/livecycle/es/sdkHelp/programmer/sdkHelp/wwhelp/wwhimpl/common/ht ml/wwhelp.htm?context=sdkHelp&file=invokingJava.22.3.html

                1 person found this helpful
                • 5. Re: Java WebServices VS JAVA API SOAP
                  krishna_p_p Level 1

                  Thank you, I have another question on this...

                   

                  When ADOBE EJB implementation(adding adobe Jar files) is capable of generating SOAP requests then why we have to struggle to create WebService requests. Webservice errors are very difficult to debug. 

                   

                  My Question is on ADOBE EJB generated SOAP requests,

                       Are these requests are startandard SOAP requests?

                       will those requests pass all firewalls?

                  • 6. Re: Java WebServices VS JAVA API SOAP
                    Rui Esteves Level 3

                    Your first question isn't related to Adobe, its a basic difference between EJB and WebServices. My take on this (to keep this simples, because we could be here all day discussing this) is use EJB if your request doesn't leave a controlled and restricted network ans your consumer is Java, use WS otherwise.

                     

                    The difficulty of using WS is relative, it depends on your IDE. Using Netbeans and jdk 1.5 or higher, consuming Adobe Livecycle WS is as simples as eating an apple (after you figure out that you need to add the parameter &blob=base64 to your WSDL url).

                     

                    And its portable code.

                     

                    Using EJB3.0 is not portable and that really sucks. If you make a EJB based application that connects to a JBoss deployed LC:ES and then try to connect to a WebSphere deployed LC:ES you'll have to make revisions to your app and so on.

                     

                    As for being FW friendly, i never tried it that way, so i don't know how it will behave.

                    • 7. Re: Java WebServices VS JAVA API SOAP
                      Hodmi Level 4

                      The Adobe supplied client jars are built for JDK 1.5.x.  If you are using a different JDK (1.4 or 1.6) then they may not work and you would need to generate your own proxy classes.

                       

                      As far as I know they are generating standard SOAP requests (I think they use DIME attachments for sending binary objects) and work with firewalls (as long as the ports are opened).