Topic
  • 14 replies
  • Latest Post - ‏2013-07-19T14:33:33Z by JBASkeen
SystemAdmin
SystemAdmin
6195 Posts

Pinned topic calling EGL REST services via external Java

‏2011-02-09T17:21:06Z |
I was reading the help documentation today regarding the consumption of Services from external clients. Specifically I would like to consume an EGL REST service via native java. It looks like this isn't officially supported and I need to deploy my service as REST for my RUI client and SOAP for my java client.

I'm wondering if I could get additional detail on why and if there the potential for me to work around this limitation so that native java can consume and EGL REST service. Perhaps I can create and EGL java program that calls my rest service and expose that generated java externally?

Aaron Allsbrook
ClearBlade
Updated on 2012-07-20T15:33:29Z at 2012-07-20T15:33:29Z by markevans
  • dan_darnell
    dan_darnell
    973 Posts

    Re: calling EGL REST services via external Java

    ‏2011-02-11T17:32:28Z  
    Hi Aaron,

    I'm interested in this too. Where were you reading in the help about REST services not being officially supported for external Java calls?

    --Dan
  • jspadea
    jspadea
    156 Posts

    Re: calling EGL REST services via external Java

    ‏2011-02-11T18:11:59Z  
    Hi Aaron,

    Assuming you're using version 8.0.1 you could write an EGL called program that invokes the service, and use a Java wrapper to invoke the program from your hand-written Java code. The Java wrapper API is fully documented and handles all conversions between the EGL and Java data types.

    Disclaimer: I have not tried this, but I see no reason why it wouldn't work.

    Let me know if you have any questions on using Java wrappers.

    -Justin
  • dan_darnell
    dan_darnell
    973 Posts

    Re: calling EGL REST services via external Java

    ‏2011-02-11T18:50:57Z  
    • jspadea
    • ‏2011-02-11T18:11:59Z
    Hi Aaron,

    Assuming you're using version 8.0.1 you could write an EGL called program that invokes the service, and use a Java wrapper to invoke the program from your hand-written Java code. The Java wrapper API is fully documented and handles all conversions between the EGL and Java data types.

    Disclaimer: I have not tried this, but I see no reason why it wouldn't work.

    Let me know if you have any questions on using Java wrappers.

    -Justin
    Justin,

    That's an interesting idea but what would prevent one from going directly at the REST service from Java? What would make doing this "officially unsupported"?

    I'm thinking too of an instance here where we are currently using a VB app to access a SOAP service written in EGL. Any reason we couldn't (or shouldn't) consider using VB to access a REST service written in EGL?

    Aaron: Entirely possible I am getting your thread off track. If so, feel free to jerk it back into line and I will butt out.

    --Dan
  • SystemAdmin
    SystemAdmin
    6195 Posts

    Re: calling EGL REST services via external Java

    ‏2011-02-11T19:06:24Z  
    Perhaps I, like Dan, is getting this off track, excuse me if thats the case.

    I see no reason why EGL REST services could not be consumed by a Java client. I have never tried an EGL REST service, but I have good experience using Apache Wink in Java to do REST services both as a client and as a server

    I think I will give it a try ;-)

    /Thomas
  • scottpecnik
    scottpecnik
    99 Posts

    Re: calling EGL REST services via external Java

    ‏2011-02-11T19:23:34Z  
    Justin,

    That's an interesting idea but what would prevent one from going directly at the REST service from Java? What would make doing this "officially unsupported"?

    I'm thinking too of an instance here where we are currently using a VB app to access a SOAP service written in EGL. Any reason we couldn't (or shouldn't) consider using VB to access a REST service written in EGL?

    Aaron: Entirely possible I am getting your thread off track. If so, feel free to jerk it back into line and I will butt out.

    --Dan
    Hey Dan,

    So I think what Aaron is getting at here is that EGL's REST service implementation doesn't exactly conform to the original architecture described by Roy Fielding in his dissertation. REST bigots would describe "true REST" as a way to expose resources via the http protocol using a URI as an identifier. I could go on and on, but it basically comes down to the fact that EGL's implementation is much closer to Remote Program Call. This being said, there isn't really any "wrong" way to implement RESTful services. After all, REST is derived from an architecture, not a specification. This is the exact opposite from SOAP where there is a specification (WSDL) that programmers must conform to.

    This very fact makes REST very interesting. Since there is no "right" way to do things, you'll see many different flavors of exposing resources out there. For example, one of the biggest arguments is whether or not you should use path param's or query params.

    Path Param:
    www.ibm.com/customer/2

    Query Param:
    www.ibm.com/customer?id=2

    Both of the above URI's can map to the same resource, they just do so in a different way. There have been efforts to write a specification around REST (RSDL), but as far as I know none have really caught on. This is certainly an interesting story that I'm excited to watch unfold over the next couple years. I personally think it will default to what the big players decide. For example, I prefer using the Path Param style of creating URI's over Query Params. That being said, if Facebook/Twitter/LinkedIn and others go with Query Param's, I'd feel more comfortable going that route. If you were to ask Fielding though, he'd say Path Param's are the correct way :)

    Back to EGL, try creating a RUI page that calls a REST service. Using firebug or the dev tools in Chrome, notice how every time a service call is made it is always a POST. Even if you are simply retrieving data, which one would normally use a GET for. The fact that EGL is generating REST services and hiding these types of complexities from us, there isn't any way for it to know how to construct URI's that describe our data (our meaning everyone has different tables, etc.). I don't see how to consume an EGL Generated REST service from a language other than EGL itself.

    I would be all for supporting an RFE that added the ability to customize our REST URI's and http methods. See the JAX-RS spec, I believe it's jsr 311. In my opinion an excellent solution for creating "true REST" services in Java, while avoiding writing servlets.
    Scott Pecnik
    ClearBlade
  • markevans
    markevans
    2843 Posts

    Re: calling EGL REST services via external Java

    ‏2011-02-11T19:42:17Z  
    Hey Dan,

    So I think what Aaron is getting at here is that EGL's REST service implementation doesn't exactly conform to the original architecture described by Roy Fielding in his dissertation. REST bigots would describe "true REST" as a way to expose resources via the http protocol using a URI as an identifier. I could go on and on, but it basically comes down to the fact that EGL's implementation is much closer to Remote Program Call. This being said, there isn't really any "wrong" way to implement RESTful services. After all, REST is derived from an architecture, not a specification. This is the exact opposite from SOAP where there is a specification (WSDL) that programmers must conform to.

    This very fact makes REST very interesting. Since there is no "right" way to do things, you'll see many different flavors of exposing resources out there. For example, one of the biggest arguments is whether or not you should use path param's or query params.

    Path Param:
    www.ibm.com/customer/2

    Query Param:
    www.ibm.com/customer?id=2

    Both of the above URI's can map to the same resource, they just do so in a different way. There have been efforts to write a specification around REST (RSDL), but as far as I know none have really caught on. This is certainly an interesting story that I'm excited to watch unfold over the next couple years. I personally think it will default to what the big players decide. For example, I prefer using the Path Param style of creating URI's over Query Params. That being said, if Facebook/Twitter/LinkedIn and others go with Query Param's, I'd feel more comfortable going that route. If you were to ask Fielding though, he'd say Path Param's are the correct way :)

    Back to EGL, try creating a RUI page that calls a REST service. Using firebug or the dev tools in Chrome, notice how every time a service call is made it is always a POST. Even if you are simply retrieving data, which one would normally use a GET for. The fact that EGL is generating REST services and hiding these types of complexities from us, there isn't any way for it to know how to construct URI's that describe our data (our meaning everyone has different tables, etc.). I don't see how to consume an EGL Generated REST service from a language other than EGL itself.

    I would be all for supporting an RFE that added the ability to customize our REST URI's and http methods. See the JAX-RS spec, I believe it's jsr 311. In my opinion an excellent solution for creating "true REST" services in Java, while avoiding writing servlets.
    Scott Pecnik
    ClearBlade
    Hi,

    There is an open RFE to allow non-EGL clients to access EGL REST-RPC services.

    Please see this link to the RBD RFE Community site:

    http://www.ibm.com/developerworks/support/rational/rfe/execute?use_case=viewRfe&CR_ID=8604

    In this RFE, the description of the situation is as follows:

    EGL REST Services use standard HTTP methods for communication with the client, and standard JSON notation to encode the message between the client and the server. Due to the fact that EGL Services support multiple entry points (i.e. functions), it is necessary for the client to communicate with the service using a proprietary message format that we have defined. EGL clients that communicate with an EGL REST service are generated to send and receive messages in this format. In RBD 8.0.1 we have re-named EGL REST services to EGL REST-RPC services to further indicate that these are REST services using a proprietary message to communicate between the client and the server. This information will
    also be included in the 8.0.1 documentation.

    Further, we responded with the following to the RFE.

    We believe that you have a common use case. Therefore we plan to provide documentation of our EGL REST service interface, to make it a public API. When this documentation has been completed, we will add it to the online InfoCenter for V8, and we'll put it on the EGL Cafe for V7.5.x users.

    I don't know the time frame for this documentation to be completed.

    Until then, as Aaron and Justin suggested, an EGL program can be written to "wrap a service" and invoked via EGL Java Wrappers. Or use SOAP as the interface between non-EGL and EGL since it is a standard, published interface. The same service part can be exposed as a SOAP service for non-EGL clients and a REST service for EGL clients.
  • dan_darnell
    dan_darnell
    973 Posts

    Re: calling EGL REST services via external Java

    ‏2011-02-11T20:46:34Z  
    Hey Dan,

    So I think what Aaron is getting at here is that EGL's REST service implementation doesn't exactly conform to the original architecture described by Roy Fielding in his dissertation. REST bigots would describe "true REST" as a way to expose resources via the http protocol using a URI as an identifier. I could go on and on, but it basically comes down to the fact that EGL's implementation is much closer to Remote Program Call. This being said, there isn't really any "wrong" way to implement RESTful services. After all, REST is derived from an architecture, not a specification. This is the exact opposite from SOAP where there is a specification (WSDL) that programmers must conform to.

    This very fact makes REST very interesting. Since there is no "right" way to do things, you'll see many different flavors of exposing resources out there. For example, one of the biggest arguments is whether or not you should use path param's or query params.

    Path Param:
    www.ibm.com/customer/2

    Query Param:
    www.ibm.com/customer?id=2

    Both of the above URI's can map to the same resource, they just do so in a different way. There have been efforts to write a specification around REST (RSDL), but as far as I know none have really caught on. This is certainly an interesting story that I'm excited to watch unfold over the next couple years. I personally think it will default to what the big players decide. For example, I prefer using the Path Param style of creating URI's over Query Params. That being said, if Facebook/Twitter/LinkedIn and others go with Query Param's, I'd feel more comfortable going that route. If you were to ask Fielding though, he'd say Path Param's are the correct way :)

    Back to EGL, try creating a RUI page that calls a REST service. Using firebug or the dev tools in Chrome, notice how every time a service call is made it is always a POST. Even if you are simply retrieving data, which one would normally use a GET for. The fact that EGL is generating REST services and hiding these types of complexities from us, there isn't any way for it to know how to construct URI's that describe our data (our meaning everyone has different tables, etc.). I don't see how to consume an EGL Generated REST service from a language other than EGL itself.

    I would be all for supporting an RFE that added the ability to customize our REST URI's and http methods. See the JAX-RS spec, I believe it's jsr 311. In my opinion an excellent solution for creating "true REST" services in Java, while avoiding writing servlets.
    Scott Pecnik
    ClearBlade
    Hi Scott!

    Thanks for the additional info and clarifying points. I think that where I am coming from is that school of thought that says "there is no absolute right or wrong way to do a REST service". A while back we had a need to consume an EGL REST service directly from some JavaScript and it took some poking around with Firebug, WireShark, and the Poster plug-in for Firefox but once we sussed out the URI structure and the nature of the beast (every interaction being a POST, for example), we were able to create a working solution.

    Here is the outline for such a solution:

    
    var http = 
    
    new XMLHttpRequest();   var url = 
    "http://www.xxxxxxxxxxxxxx.com:8081/WebCall/restservices/WebServiceCall";   http.open(
    "POST", url, 
    
    false);   var data = 
    '{"bindingName":"WebServiceCall","method":"myServiceFunction","params":["blahblahblah"]}';   http.send(data);   var obj = jQuery.parseJSON(http.responseText);
    


    The statement I think that I would make is that while it is possible to consume an EGL generated REST service from a language other than EGL it would be better if we had the option to generate a REST service from EGL that conformed to Fielding or some other common specification (I'll stop short of saying "standard") -- at least for services destined for external consumption. Meanwhile, it sounds as though the EGL/Java wrapper would work for Java language consumers and simplify the solution in that realm.

    What I am now curious about is this: is it a mistake to go directly at an EGL REST service (like we did with JavaScript, for example)? Is the underlying generated EGL implementation something that is likely to change from release to release, therefore breaking the solution?

    --Dan
  • SystemAdmin
    SystemAdmin
    6195 Posts

    Re: calling EGL REST services via external Java

    ‏2011-02-12T17:48:21Z  
    Hi Scott!

    Thanks for the additional info and clarifying points. I think that where I am coming from is that school of thought that says "there is no absolute right or wrong way to do a REST service". A while back we had a need to consume an EGL REST service directly from some JavaScript and it took some poking around with Firebug, WireShark, and the Poster plug-in for Firefox but once we sussed out the URI structure and the nature of the beast (every interaction being a POST, for example), we were able to create a working solution.

    Here is the outline for such a solution:

    <pre class="jive-pre"> var http = new XMLHttpRequest(); var url = "http://www.xxxxxxxxxxxxxx.com:8081/WebCall/restservices/WebServiceCall"; http.open( "POST", url, false); var data = '{"bindingName":"WebServiceCall","method":"myServiceFunction","params":["blahblahblah"]}'; http.send(data); var obj = jQuery.parseJSON(http.responseText); </pre>

    The statement I think that I would make is that while it is possible to consume an EGL generated REST service from a language other than EGL it would be better if we had the option to generate a REST service from EGL that conformed to Fielding or some other common specification (I'll stop short of saying "standard") -- at least for services destined for external consumption. Meanwhile, it sounds as though the EGL/Java wrapper would work for Java language consumers and simplify the solution in that realm.

    What I am now curious about is this: is it a mistake to go directly at an EGL REST service (like we did with JavaScript, for example)? Is the underlying generated EGL implementation something that is likely to change from release to release, therefore breaking the solution?

    --Dan
    Hi Dan,

    In the past it would be a 'mistake' to go directly to an EGL REST RPC service because it was not a public interface and could be changed at any time. Now that it's matured to where we don't see a need to make changes we have accepted an RFE to document EGL REST RPC making it public interface (See Mark's post for details on the RFE).

    regards,
    Joe
  • haroldBuchman
    haroldBuchman
    30 Posts

    Re: calling EGL REST services via external Java

    ‏2011-11-14T07:40:55Z  
    Hi Scott!

    Thanks for the additional info and clarifying points. I think that where I am coming from is that school of thought that says "there is no absolute right or wrong way to do a REST service". A while back we had a need to consume an EGL REST service directly from some JavaScript and it took some poking around with Firebug, WireShark, and the Poster plug-in for Firefox but once we sussed out the URI structure and the nature of the beast (every interaction being a POST, for example), we were able to create a working solution.

    Here is the outline for such a solution:

    <pre class="jive-pre"> var http = new XMLHttpRequest(); var url = "http://www.xxxxxxxxxxxxxx.com:8081/WebCall/restservices/WebServiceCall"; http.open( "POST", url, false); var data = '{"bindingName":"WebServiceCall","method":"myServiceFunction","params":["blahblahblah"]}'; http.send(data); var obj = jQuery.parseJSON(http.responseText); </pre>

    The statement I think that I would make is that while it is possible to consume an EGL generated REST service from a language other than EGL it would be better if we had the option to generate a REST service from EGL that conformed to Fielding or some other common specification (I'll stop short of saying "standard") -- at least for services destined for external consumption. Meanwhile, it sounds as though the EGL/Java wrapper would work for Java language consumers and simplify the solution in that realm.

    What I am now curious about is this: is it a mistake to go directly at an EGL REST service (like we did with JavaScript, for example)? Is the underlying generated EGL implementation something that is likely to change from release to release, therefore breaking the solution?

    --Dan
    Dan -
    Thanks for posting that code outline.
    This bit of javaScript was successful in invoking an EGL REST-RPC service:

    var http = new XMLHttpRequest();
    var url = "http://localhost:9081/RestServices/restservices/CatchPostback";
    http.open("POST", url, false);
    http.setRequestHeader("Content-type", "application/jsonrequest; charset=utf-8");
    var data = '{"method":"reply","params":}';
    http.send(data);
  • SystemAdmin
    SystemAdmin
    6195 Posts

    Re: calling EGL REST services via external Java

    ‏2012-07-20T14:43:49Z  
    Dan -
    Thanks for posting that code outline.
    This bit of javaScript was successful in invoking an EGL REST-RPC service:

    var http = new XMLHttpRequest();
    var url = "http://localhost:9081/RestServices/restservices/CatchPostback";
    http.open("POST", url, false);
    http.setRequestHeader("Content-type", "application/jsonrequest; charset=utf-8");
    var data = '{"method":"reply","params":}';
    http.send(data);
    Hi All,

    I am not able to call EGL Rest service from javascript code mentioned above.
    The code is not able to execute statement "http.send(data)"

    below is the code i am using.

    var http = new XMLHttpRequest();
    var url = "http://XXXXX/MyProject/restservices/InvokeiSeriesProgRESTSVC";
    http.open("POST", url, true);
    http.setRequestHeader("Content-type", "application/jsonrequest; charset=utf-8");
    var data = '{"method":"mymethod","params":1060529}';
    http.send(data);
    var obj = jQuery.parseJSON(http.responseText);

    Is there any other way to call EGL rest service from java?

    If possible ,Kindly provide the code snippet to do the same
    Thanks
    Sneha Sharma
  • markevans
    markevans
    2843 Posts

    Re: calling EGL REST services via external Java

    ‏2012-07-20T15:33:29Z  
    Hi All,

    I am not able to call EGL Rest service from javascript code mentioned above.
    The code is not able to execute statement "http.send(data)"

    below is the code i am using.

    var http = new XMLHttpRequest();
    var url = "http://XXXXX/MyProject/restservices/InvokeiSeriesProgRESTSVC";
    http.open("POST", url, true);
    http.setRequestHeader("Content-type", "application/jsonrequest; charset=utf-8");
    var data = '{"method":"mymethod","params":1060529}';
    http.send(data);
    var obj = jQuery.parseJSON(http.responseText);

    Is there any other way to call EGL rest service from java?

    If possible ,Kindly provide the code snippet to do the same
    Thanks
    Sneha Sharma
    Hi,

    Take a look at this information in the EGL helps.

    http://publib.boulder.ibm.com/infocenter/rbdhelp/v8r0m0/topic/com.ibm.egl.pg.doc/topics/pegl_service_rest_message.html
  • JBASkeen
    JBASkeen
    137 Posts

    Re: calling EGL REST services via external Java

    ‏2013-07-18T00:30:43Z  
    • markevans
    • ‏2011-02-11T19:42:17Z
    Hi,

    There is an open RFE to allow non-EGL clients to access EGL REST-RPC services.

    Please see this link to the RBD RFE Community site:

    http://www.ibm.com/developerworks/support/rational/rfe/execute?use_case=viewRfe&CR_ID=8604

    In this RFE, the description of the situation is as follows:

    EGL REST Services use standard HTTP methods for communication with the client, and standard JSON notation to encode the message between the client and the server. Due to the fact that EGL Services support multiple entry points (i.e. functions), it is necessary for the client to communicate with the service using a proprietary message format that we have defined. EGL clients that communicate with an EGL REST service are generated to send and receive messages in this format. In RBD 8.0.1 we have re-named EGL REST services to EGL REST-RPC services to further indicate that these are REST services using a proprietary message to communicate between the client and the server. This information will
    also be included in the 8.0.1 documentation.

    Further, we responded with the following to the RFE.

    We believe that you have a common use case. Therefore we plan to provide documentation of our EGL REST service interface, to make it a public API. When this documentation has been completed, we will add it to the online InfoCenter for V8, and we'll put it on the EGL Cafe for V7.5.x users.

    I don't know the time frame for this documentation to be completed.

    Until then, as Aaron and Justin suggested, an EGL program can be written to "wrap a service" and invoked via EGL Java Wrappers. Or use SOAP as the interface between non-EGL and EGL since it is a standard, published interface. The same service part can be exposed as a SOAP service for non-EGL clients and a REST service for EGL clients.

    Mark,

    First, I apologize for replying to such an old thread. I came across this thread recently because I need to call EGL from non-EGL java. The two pieces live on different WAS servers (the non-EGL Java runs in JRE 1.4).  Has any progress been made on the effort to allow for EGL REST-RPC to be callable from non-EGL java? I have had no luck so far finding any resources and my efforts are full of error messages. I am going to attempt the two things mentioned in this thread:

    1. Non-EGL Java  -->  EGL Program and Java Wrapper

    2. Non-EGL Java  -->  EGL SOAP Service

    Like others, I need to create a service that is call-able from both EGL and Non-EGL Java. However, I am no Java expert so the Non-EGL Java call to the EGL is the hardest part for me.

    Thanks,

    James Skeen

    RBD 8.5.1

  • dan_darnell
    dan_darnell
    973 Posts

    Re: calling EGL REST services via external Java

    ‏2013-07-18T20:59:39Z  
    • JBASkeen
    • ‏2013-07-18T00:30:43Z

    Mark,

    First, I apologize for replying to such an old thread. I came across this thread recently because I need to call EGL from non-EGL java. The two pieces live on different WAS servers (the non-EGL Java runs in JRE 1.4).  Has any progress been made on the effort to allow for EGL REST-RPC to be callable from non-EGL java? I have had no luck so far finding any resources and my efforts are full of error messages. I am going to attempt the two things mentioned in this thread:

    1. Non-EGL Java  -->  EGL Program and Java Wrapper

    2. Non-EGL Java  -->  EGL SOAP Service

    Like others, I need to create a service that is call-able from both EGL and Non-EGL Java. However, I am no Java expert so the Non-EGL Java call to the EGL is the hardest part for me.

    Thanks,

    James Skeen

    RBD 8.5.1

    Hi James,

    I've had success recently calling EGL-based REST services from Non-EGL Java code. In my case, I was developing for Android and the stuff I needed was a part of the Android SDK but you can use the same support in any Java application by adding in a couple of libraries.

    For HTTP client support, I used this Apache project (See HTTP Components Client):

    http://hc.apache.org/

    For JSON support, I used this open-source project:

    http://json-lib.sourceforge.net/

    Here is the basic code:

                    HttpClient httpclient = new DefaultHttpClient();
                        HttpPost request = new HttpPost(
                                MainActivity.getAppServerUrl() + "/MyWebApp/restservices/AALibService");

                        JSONObject j1 = new JSONObject();
                        j1.put("GPDEVID", Integer.parseInt(MainActivity.deviceID));
                        j1.put("GPLAT", location.getLatitude());
                        j1.put("GPLON", location.getLongitude());
                        j1.put("GPDIST", distance);

                        JSONObject j2 = new JSONObject();
                        j2.put("succeeded", false);
                        j2.put("statusCode", 0);
                        j2.put("message", " ");

                        JSONArray ja = new JSONArray();
                        ja.put(j1);
                        ja.put(j2);

                        JSONObject j0 = new JSONObject();
                        j0.put("bindingName", "IAALibService");
                        j0.put("method", "AddLogEntry");
                        j0.put("params", ja);

                        StringEntity s = new StringEntity(j0.toString());
                        s.setContentEncoding(new BasicHeader(HTTP.CONTENT_TYPE,
                                "application/json"));
                        request.setEntity(s);

                        HttpResponse response;
                        response = httpclient.execute(request);

                        if (response.getStatusLine().getStatusCode() == HttpStatus.SC_OK) {
                            Log.d(TAG, "Good");
                            completionStatus = "Host Update: Good";
                        } else {
                            Log.d(TAG, "Failed (1)");
                            completionStatus = "Host Update: Failed (HTTP Code="
                                    + response.getStatusLine().getStatusCode()
                                    + ")";
                        }
     

    Note that this example is for a one-way interaction ... I invoke a REST-based service and pass it some data but I'm not expecting data back. If you get data back you will need to get the response body and use the JSON support to parse it. Mark's link will point you in the direction of what the JSON looks like when it comes back to you.

    http://publib.boulder.ibm.com/infocenter/rbdhelp/v8r0m0/topic/com.ibm.egl.pg.doc/topics/pegl_service_rest_message.html

    Other helpful (I hope) hints:

    1. I sometimes use Wireshark to "see" the interaction between my RUI client and a host service. The data in the HTTP request is JSON formatted in the same way that I need to structure the request in my Java code.

    2. Before I start coding away in Java I use a Firefox plug-in called Poster to play with my rest service and get my JSON formatting down. Then it is a matter of translating what I've done manually in Poster into code.

    So it is possible to consume a EGL-created REST-based service from Java but not exactly easy.

    You might be happier with the other two options you mentioned. I've never used a Java wrapper over an EGL program but I do know that it is far easier to consume a service in EGL than it is in hand-coded Java. Also, most of your decent Java tools (see MyEclipse, for example) have wizards that will take a WSDL file and generate all of the code you need to consume a SOAP-based service -- so even if you are hand-coding the Java it could be better to go the SOAP route.

    Hope this helps.

    Dan

     

     

     

  • JBASkeen
    JBASkeen
    137 Posts

    Re: calling EGL REST services via external Java

    ‏2013-07-19T14:33:33Z  

    Hi James,

    I've had success recently calling EGL-based REST services from Non-EGL Java code. In my case, I was developing for Android and the stuff I needed was a part of the Android SDK but you can use the same support in any Java application by adding in a couple of libraries.

    For HTTP client support, I used this Apache project (See HTTP Components Client):

    http://hc.apache.org/

    For JSON support, I used this open-source project:

    http://json-lib.sourceforge.net/

    Here is the basic code:

                    HttpClient httpclient = new DefaultHttpClient();
                        HttpPost request = new HttpPost(
                                MainActivity.getAppServerUrl() + "/MyWebApp/restservices/AALibService");

                        JSONObject j1 = new JSONObject();
                        j1.put("GPDEVID", Integer.parseInt(MainActivity.deviceID));
                        j1.put("GPLAT", location.getLatitude());
                        j1.put("GPLON", location.getLongitude());
                        j1.put("GPDIST", distance);

                        JSONObject j2 = new JSONObject();
                        j2.put("succeeded", false);
                        j2.put("statusCode", 0);
                        j2.put("message", " ");

                        JSONArray ja = new JSONArray();
                        ja.put(j1);
                        ja.put(j2);

                        JSONObject j0 = new JSONObject();
                        j0.put("bindingName", "IAALibService");
                        j0.put("method", "AddLogEntry");
                        j0.put("params", ja);

                        StringEntity s = new StringEntity(j0.toString());
                        s.setContentEncoding(new BasicHeader(HTTP.CONTENT_TYPE,
                                "application/json"));
                        request.setEntity(s);

                        HttpResponse response;
                        response = httpclient.execute(request);

                        if (response.getStatusLine().getStatusCode() == HttpStatus.SC_OK) {
                            Log.d(TAG, "Good");
                            completionStatus = "Host Update: Good";
                        } else {
                            Log.d(TAG, "Failed (1)");
                            completionStatus = "Host Update: Failed (HTTP Code="
                                    + response.getStatusLine().getStatusCode()
                                    + ")";
                        }
     

    Note that this example is for a one-way interaction ... I invoke a REST-based service and pass it some data but I'm not expecting data back. If you get data back you will need to get the response body and use the JSON support to parse it. Mark's link will point you in the direction of what the JSON looks like when it comes back to you.

    http://publib.boulder.ibm.com/infocenter/rbdhelp/v8r0m0/topic/com.ibm.egl.pg.doc/topics/pegl_service_rest_message.html

    Other helpful (I hope) hints:

    1. I sometimes use Wireshark to "see" the interaction between my RUI client and a host service. The data in the HTTP request is JSON formatted in the same way that I need to structure the request in my Java code.

    2. Before I start coding away in Java I use a Firefox plug-in called Poster to play with my rest service and get my JSON formatting down. Then it is a matter of translating what I've done manually in Poster into code.

    So it is possible to consume a EGL-created REST-based service from Java but not exactly easy.

    You might be happier with the other two options you mentioned. I've never used a Java wrapper over an EGL program but I do know that it is far easier to consume a service in EGL than it is in hand-coded Java. Also, most of your decent Java tools (see MyEclipse, for example) have wizards that will take a WSDL file and generate all of the code you need to consume a SOAP-based service -- so even if you are hand-coding the Java it could be better to go the SOAP route.

    Hope this helps.

    Dan

     

     

     

    Dan,

    Thanks so much for your reply, that is some great info. I really like your methods of examining the flow, I have been doing something similar with Firebug on the client to try and peek into the behind-the-scenes and that has helped some. Your info will help me do the same on the back-end.

    Your code sample doesn't look that bad to me so I will do some exploring with it. I successfully got an EGL SOAP service up and running and I am calling that from both EGL-java Dedicated Services and hand-coded non-EGL Java. However, I know that I will need the REST solution soon.

    Thanks again for your always helpful replies,

    James