I was recently working quite a lot on SOAP web services and one question bothers me in that context. What would be better?
A. Get the WSDL and store it locally on client side and then only make calls to the service
if server keeps backward compatibility the client will still work with the old WSDL even when server side provided new version (of service and WSDL).
you are not able to get endpoint URL from WSDL so if service endpoint location has changed (but WSDL not) you need to reconfigure the client.
no additional call to the server
B. Use WSDL location as remote resource (HTTP) and download WSDL each time client instance is created?
What are some pros and cons?
Which is better depends on your setup and your needs but personally I would prefer having the WSDL locally, inside the client for these reasons:
no extra call to the server to get the WSDL (as you mentioned);
if server keeps backward compatibility the local WSDL will still be OK to use (as you mentioned);
if the service WSDL changes in an incompatible way and your client suddenly starts to fail you still have the old WSDL locally and you can compare it with the new one to see what's different.
The following point is usually not an issue:
you are not able to get endpoint URL from WSDL so if service endpoint location has changed (but WSDL not) you need to reconfigure the client.
The endpoint URL in the WSDL is not always correct and even if it was, you normally have the WSDL accessible at the same URL as the service by just sticking a ?wsdl parameter after it so if the location changes you won't find the service but you wont find the WSDL either. The service endpoint URL needs to be configurable in your client anyways.
Related
I got a webservice endpoint and I stumple upon how to correctly implement it.
It seems to be an parameterized exe-file which returns an XML Reply.
There is no documentation.
I am used to soap, wcf and rest but this is completely unknown to me, has anyone a guide or a best case how to implement such a service?
I can consume it with a HTTP GET but there are some questions left to me:
I know the questions are quite broad... But I could not find anything about it in the interwebz.
Is there a secure way to publish exe files as webservice?
Are there any critical downsides implementing such an interface?
Make I myself a fool and this is just an alias?
Example Url:
http://very.exhausting.company/Version/SuperStrange.exe?parameter=String
Web servers
What you call a webservice endpoint is nothing else than a web server listening on some host (normally 0.0.0.0) and some port on a physical or virtual machine and responding with some HTTP response to HTTP requests sent to that host, port and URIs that the web server cares to process.
Any web server is itself an application or a static or dynamic component of an application as the following examples illustrate:
JBoss, Glassfish, Tomcat etc. are applications, known as application servers, into which containers/servlets/plugins implementing web servers and corresponding endpoints are deployed. These listen on some port exposing generic web servers routing requests to those containers and their servlets;
a fat jar started with java -jar on a JVM which deploys a vert.x verticle featuring a vert.x HttpServer listening on some port is nothing else than a web server;
an interpreter such as node.js parsing and executing JavaScript code based on the express module will most likely deploy a web server on some port;
finally, a statically or dynamically linked application written in languages such as C++ or Go can expose a web server listing on some port.
All of the above cases feature different deployment mechanisms, but what they deploy is essentially the same: a piece of software that listens for HTTP requests on some port, executes some logic based on request and returns HTTP responses to the caller.
Your windows exe file is most likely a statically linked application that provides a web server.
Protocols
So we know you have a web server as it reacts to an HTTP GET. How does it relate to REST, SOAP etc? Effectively, REST, SOAP etc are higher level protocols. TCP is the low level, HTTP is based on top of that and your server supports that. REST, SOAP and everything else that you mention are higher level protocols that are based, among others, on HTTP. So all you know is that your application (web server) supports HTTP, but you do not know which higher level data exchange protocol it implements. It definitely implements some, at least a custom one that its author came up with to exchange data between a client and this application.
You can try to reverse engineer it, but it is not clear how would you find out about all possible endpoints, arguments, payload structures, accepted headers etc. Essentially, you have a web server publishing some sort of an API, but there is no generic way of telling what that API is.
Security
The world around you does not have to know how the API is published. You can put any of the above 4 web server implementations behind exactly the same firewall or a reverse proxy with SSL termination exposing just one host and port over SSL. So there is no difference in security, with respect to the world, whether you deploy it as exe or as a war into JBoss. This is not to say, that your exe file is secure: depending on how it is implemented it may allow all sorts of attacks, but again, this is equally true for any mechanism.
I have deployed a custom UI5 app ( using external REST ful services--> service hosted in another Java stack system) in the front end server.
I used Ajax to call the service directly with the URL as shown below.
This app has run successfully when i use "proxy" in local host(eclipse).
-->Ajax Call code Snippet
So i replaced proxy with target url while deploying in front end. (http ://xxx.xxx:port)
When running from front end server i got cross origin error as shown below.
Error1:<http://xxx:port/xxx/ngservices/rest/query/ZQUE_WEBSERV_APPHISTORY/executeGet. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://xxx:port' is therefore not allowed access. The response had HTTP status code 401>
After enabling CORS plugin in chrome i got unauthorised error as shown below.
Error2:<http://xxx:port/xxx/ngservices/rest/query/ZQUE_WEBSERV_APPHISTORY/executeGet. Response for preflight has invalid HTTP status code 401>
I got the above errors initally while running from localhost.After that i used proxy and it got solved.
I just deployed the app in frontend server and ran it directly. I haven't done any other configurations.
Do i need to do any extra configurations for consuming these external services or kindly suggest any other suggestions.
Important info:
*Able to call external service from localhost(eclipse--> used proxy here) but not able to call service from frontend server.
*Front end architecture: Central hub deployement and connected to SRM,HR and CRM backends currently.
Regards
Phani Poorna
Both of these errors can be solved by creating and configuring a destination on your platform.
A destination is essentially a proxy: when you create it, you specify the backend URL, the authentication mechanism (Principal propagation/basic authentication etc). From your client, you just need to then connect to your destination to query the backend.
What do you mean by Fiori front end server? Are you referring to the Portal service hosted on HANA Cloud Platform?
If so, then you can create a destination by going to Connectivity - Destinations from your HCP account. From your Fiori application, you then need to connect your destination using the following URL pattern:
/destinations/<destination name>/<whatever you want to add to the URL the destination points to>
If you are using a different PaaS, I'm sure it will have some similar way of creating a proxy between your client and your backend. (Edit: I just saw you're using the Central hub deployment - I am not familiar with this system but it must have a very similar way of creating destinations).
Hope this helps, let me know if you have any questions.
In RESTful or any application versioning I see that versioning is done by adding version to URL of the endpoint, e.g.:
http://app/api/customers/1234
http://app/api/v3/customers/1234
http://app/api/v4/customers/1234
Does it mean that app is deployed to different servers and all three are maintained or how it is achieved?
It depends. It may be handled twofold:
Via the proxy server (e.g. nginx, apache) using the domain.
In this scenario proxy server recognizes the URL and using the version part of the domain decides where to forward the request. Basically, as far as I know, if the version is located in the path (e.g. http://app/api/v3/customers/1234) this scenario is rarely used. It's used more often if version is located in the domain (e .g. http://v3.app/api//customers/1234)
In the application itself.
Application exposes all the endpoints and handles the version resolution internally.
No matter how it's handled you still need to synchronize the resources internally - in DB e.g.
I am sending a Basic Auth Post request to neo4j REST
x.x.x.85:7474/db/data/transaction/commit
I am using unity www at x.x.x.15 which requires crossdomain.xml to be present at x.x.x.85:7474/crossdomain.xml. Where and how should I get crossdomain.xml at the desired location?
You can't add arbitrary resources to be served by Neo4j.
You could put it behind a HTTP server with reverse proxy capabilities (Apache HTTP Server, nginx) to serve the file and proxy the rest of the requests to Neo4j.
However, the real question is whether you should be exposing your database directly, to be used by a client browser (which is the reason why you need a crossdomain file) which could send any query, including MATCH(n) DETACH DELETE n, a.k.a. the new DROP TABLE (or DROP DATABASE).
I'm working in an GWT 2.4 project. I want to access to a SOAP service. I used wsdl2java to generate classes of the service (servicestub, servicelocator, ...). But this code is server side. How can I do to access the service on the client-side?
There are some problems in Calling Cross Domain Web Services in AJAX. You can read answer on this question: Accessing web Service from jQuery - cross domain. But you can call server method using RPC. And then server get data from SOAP and return to client.
Its really tricky to do that (I'm even not sure if its possible) and I would prefer to wrap the SOAP call into a server side service and call that from you client.