Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've never used SOAP or EJB. I read about SOAP and can't grasp one (maybe the main) point.
Question: Why should one use remote interfaces instead of simple request/responce scheme?
My considerations: SOAP allows us to invoke methods of remote services. It uses XML. But why it's better than just use SOA (service oriented approach) and send an JSON request -> get JSON response. I do so in my application with help of WebSockets and JSON. Moreover, SOAP is slow, seems it is slower than approach that I need.
I suppose the advantage of the remote interface is that you wouldn't have to parse any XML. When you receive your reply from a remote interface an object is constructed that you are able to use without any further processing. However SOAP seems to be a more popular method currently as you are not restricted to a particular environment. For instance you have to use java on the client to use the remote interface but with SOAP any client can accept and process the XML
The reason for this is SOAP takes a contract-first approach. This also allows us to build classes from these contracts so we have classes that can be built by a WSDL. This is very useful because it means we don't have to build classes representing the web service endpoint, however, if the endpoints signature changes we need to update our associated generated WSDL classes.
SOAP, in my humble opinion, is much more useful for say .NET or Java because of the classes that can be generated from it and the help your IDE can bring by instantly allowing you to access these classes. When I've used php, I always found it felt like SOAP wasn't quite as easy to work with as REST because of having to build up XML responses when all you want to actually send is "something=true".
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Background:
I work in a organisation, uses hundreds of software systems, we identify which system owns which category of data, then carefully select the data we want to expose to the other systems. then pull them into a single Oracle database.AKA master data.
then each system read the status of the other system through this shared database pattern.
Problem:
access control, data handling, and lack of event notification, logic routing caused us lots of time and effort. We want to add a ESB layer in front of the
Potential Solution:
we are looking at SOA at moment, in specific Enterprise Service Bus Pattern.
we aware there are options like Camel, Mule and ServceMix. But I wander is there any resource, can assists our implementation?
is there any project been done the same way, e.g ESB fronting a Oracle database access?
I don't think you'll find much in this strict sense. ESB is basically made for transferring messages between enterprise services. A DB is not an enterprise service. In this case you'd need processing beans that handle your specific need.
What you could do, however, is to put a service in front of your DB. This service could then expose the DB in some format. For example, SOAP over JMS seems fitted to your use case. SOAP can handle security and access, JMS gives you asynchrousness and exactly-once delivery guarantee, which will be needed if working with a DB. ESB frameworks can handle JMS and SOAP very well.
So instead of looking for a "ESB backed database", as you called it, this service may be something that you can look for on the market, and then you can route client services by using an ESB, which makes sense.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'am writing an android app that needs some data from the server. I am also writing the server side in Java.
What is the best way to pass data from the server to the android device: with REST or Sockets (like Kryonet)?
In what format: XML/JSON (for REST) or plain Java objects?
Thanks in advance.
"Best" is very subjective, I think a very good way to communicate with a RESTful api is via Square's Retrofit library, which can be found here:
http://square.github.io/retrofit/
There is also Volley from Google,
http://developer.android.com/training/volley/index.html
Agree with nPn, "Best" depends on lot of app and user considerations. That said,
REST is preferred as it is most widely used and you have access to stable and optimized client libraries. Most of the these libraries support all kinds of use-cases and customizations. Web Sockets are well suited for real time or live content. If you have a different use-case , REST is strongly recommended.
With Android, JSON is well supported. There is a core JSON API included with Android that you can use without any client libraries. XML can be helpful if you plan to expose your APIs for public consumption (some platforms eg: JAVA, windows have strong XML legacy).
REST + JSON seems to be most commonly used combination in recent times, and lot of client libraries usually enable this use-case.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am new to Java environment. I have to create a java utility to extract information from an external application using web-services.For that I need to send an XML request and receive the response. I am browsing around the web and couldn't find any better article. I want to know how to send a XML request and print the request and the response using Java. Any good reference should also help.
Given that you are using Java, you should check out the Java specifications for
JAX-RS: Spec for Java REST services
JAX-WS: Spec for Java XML Web services (this roughly is the SOAP spec)
Both of these topics are extensive. FWIW REST seems to be the style-of-choice today. SOAP was prevalent several years back, but for several reasons (simplicity, ease of implementation), REST has surpassed SOAP. Of course if you have a target web service in mind, the style of the service makes the REST/SOAP choice for you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'd like to create some kind of location search during user input. The webservice should be contacted during typing of the user input, eg a location name.
So it's clear that there might be lot's of queries one after the other.
The response should only contain a couple of data for each found location, like an id, a fullname and geoCoordinates.
Would you create a SOAP or REST service for this purpose, and why?
Compared to XML, JSON is light weight. We have the flexibility of choosing responses in REST API's from normal string, XML to JSON, where as in case of SOAP always it will be SOAP XML. So i would prefer to go with REST.
Coming to differences between REST and SOAP, REST supports only HTTP where as SOAP supports other protocols also apart from HTTP. It always better to go with REST if your protocol is HTTP.
Sounds like this service is going to be used on some mobile devices. Also since it is a relatively straight forward request response I would go for REST here with JSON as the protocol.
JSON is much more lightweight than XML thus saving on the bandwidth required to request and respond. Data usage is still expensive in some countries on mobile.
Its a simple service so it really does not warrant the overhead of creating a WSDL and modelling the XSD in the case of a top down approach. Keep it simple so less things can break.
However without really understanding your requirements these are just hunches.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am exploring various ways that allow Java to connect and communicate with NodeJS. An example of what I am trying to achieve, is for example call Java methods from NodeJS, while allowing the Java method to manipulate Javascript objects. I know the JSObject class is helpful for this purpose. I have also heard so far of Dnode and ZeroMQ. Have you heard of or do you have experience in doing something similar? Would you suggest a way on how this communication Java to NodejS can be done?
I would go with an agnostic implementation.
A rest server on node js, maybe using restify listening for messages
A http client on the java side as httpclient to send messages to node.
this will also make it dead easy to test node implementation with curl and static requests; will enable you to implement authentication later on using any standard mechanism from oauth to basic and will let you change the client and the dispatcher independently later on
also you will be able to put any kind of standard load balancer in between, should you need the node app to scale.