I need to know the details how rest easy with jBoss handles multiple concurrent request for a webservice. For example I have made a webservice, which downloads a particular file. I need to check how the system will behave if say 100 or more people hit the service at the same time.
Is Resteasy framework handling own its own in multithreading or that needs to handled at our end. Or will the server handle it?
RestEasy is an implementation of the JAX-RS specification. According to JAX-RS for every new HTTP Request a new Rest Resource class is by default constructed (exceptions are e.g when you are inside other frameworks like Spring, which is very unlikely). Given that said, you are guaranteed that your code (actually state) in Rest Resources is thread-safe. But if you have some other code deeper, like something stored in your HTTP session, or some services that are used in your Rest Resources (directly or indirectly), then it is your task to make it thread-safe.
Related
I read a lot about why REST is preferred over SOAP and a lot of practical situations for that. But I could not find an article/answer on When SOAP can be preferred over REST. Can anyone please explain me a real time practical situation where SOAP can be preferred over REST?
NB - Please don't mark this question as duplicate without reading the question fully. This is not a duplicate of REST vs SOAP.
NB - Please don't mark this question as duplicate without reading the question fully. This is not a duplicate of REST vs SOAP.
when should you use SOAP? Representational State Transfer (REST) implements the standard HTTP/HTTPS as an interface allowing clients to obtain access to resources based on requested URIs. It is important to note that REST based services are stateless because http/https is natively stateless.
One of the many benefits for implementing HTTP/HTTPS as an interface is can be found in caching. Caching can be done on a web service much like caching is done on requested web pages. Caching allows for reduced web server processing and increased response times because content is already processed and stored for immediate access. Typical actions performed by REST based services include generic CRUD (Create, Read, Update, and Delete) operations and operations that do not require state.
Simple Object Access Protocol (SOAP) on the other hand uses a generic interface in order to transport messages. Unlike REST, SOAP can use HTTP/HTTPS, SMTP, JMS, or any other standard transport protocols. Furthermore, SOAP utilizes XML in the following ways:
Define a message
Defines how a message is to be processed
Defines the encoding of a message
Lays out procedure calls and responses
As REST aligns more with a Resource View, SOAP aligns more with a Method View in that business logic is exposed as methods typically through SOAP web service because they can retain state. In addition, SOAP requests are not cached therefore every request will be processed by the server.
As stated before Soap does retain state and this gives it a special advantage over REST for services that need to preform transactions where multiple calls to a service are need in order to complete a task. Additionally, SOAP is more ideal for enterprise level services that implement standard exchange formats in the form of contracts due to the fact that REST does not currently support this.
A real world example of where SOAP is preferred over REST can be seen in the banking industry where money is transferred from one account to another. SOAP would allow a bank to perform a transaction on an account and if the transaction failed, SOAP would automatically retry the transaction ensuring that the request was completed. Unfortunately, with REST, failed service calls must be handled manually by the requesting application.
References:
Francia, S. (2010). SOAP vs. REST. Retrieved 11 20, 2011, from spf13: http://spf13.com/post/soap-vs-rest
Rozlog, M. (2010). REST and SOAP: When Should I Use Each (or Both)? Retrieved 11 20, 2011, from Infoq.com: http://www.infoq.com/articles/rest-soap-when-to-use-each
I'm starting to choose a way to create my webservice, so i found 2 ways to do it:
1) Using the package javax.jws, with annotation #WebService:
#WebService(...)
public class MyServiceImpl {
2) The other way is using javax.ws, with annotation #Path:
#Path("/MyService")
public class MyServiceImpl
In my understand using the second solution is more simple, because when i need to create the Client i just need make a HTTP call (GET/POST). Using the first solution i need create a WSDL client, more complex solution.
So, I would like to know which is the advantage in use FIRST SOLUTION.
The SOAP/WSDL style is useful when a formal contract must be established to describe the interface that the web service offers.The Web Services Description Language (WSDL) describes the details such as messages, operations, bindings, and location of the web service.
Also the SOAP/WSDL style is useful when the application architecture needs to handle asynchronous processing and invocation (e.g. using JAX-WS the assynchronous clients can be created).
The disadvantages of SOAP/WSDL style are
its complexity: tools are required to create a client
heavier on Bandwidth : SOAP requires a heavy XML wrapper arround each request or response
complicated security rules
The advantages of REST style are
simplicity: REST client can be accessed from any browser (however, this is only true for GET method. Data creation request requires also the XML wrapper).
lighter on Bandwidth : data on the wire are usually bare xml elements (not wrapped within the <Envelope><Body> tags).
REST application security rules can be setup using the http standards: the administrator (or firewall) can discern the intent of each message by analyzing the HTTP command used in the request.
For example, a GET request can always be considered safe because it can't, by definition, modify any data.
The disadvantage of REST style is that it still doesn't cover all business requirements
There is no common standard accepted yet for the formal REST service description
REST requests (especially GET method) are not suitable for large amount of data
REST doesn't cover all web services standards, like Transactions, Security, Addressing, Trust, Coordination,
So, I have this old legacy JAX-WS service, that does a lot of IO per request, so each request takes quite a bit of time, but doesn't consume much CPU/RAM.
With amount of clients increasing lately, there's a huge problem of thread starvation.
At first, I thought about implementing JAX-WS builtin async support, but it requires clients to be aware of it, and thats a no in my situation. I cannot possibly force them all to update their code.
My current idea is to create special async servlet and manually parse SOAP request and encode the response, but I can't seem to find some good way to do that.
Is there any way to utilize Servlet 3.1 async support when handling JAX-WS requests?
I should clarify, that I cannot use some kind of queue, or otherwise "just return early", because request processing can fail, and client must get that failure.
I've found the solution that works perfectly for me, CXF Continuations API.
http://cxf.apache.org/docs/continuations.html
https://github.com/search?l=java&q=ContinuationProvider&type=Code&utf8=%E2%9C%93
I had to enable async for CXF Servlet, and add jboss module dependency to bundled CXF.
While the whole things feels somewhat like a hack, it allowed me to do proper asynchronous processing without changing service external API at all.
As a bonus, I can even decide whether to suspend request, or process it normally, which helps a lot in certain cases.
You could make use of workflow here where say you have webserver's workers accept the request, you handle it and places it in a queue which is shared by thread which will process this event asynchronously.
This would just mean that you have low wait time on client side and you process the client request asynchronously. In that way, you build your system scalable and can increase number of worker threads on either of the side i.e. webserver so you could accept multiple requests from client concurrently and at the same time multiple threads may be concurrently processing the events from client.
I'd like to synchronize the state to all the clients interested in particular entity changes. So I'd like to achieve something like:
exposing CRUD API on entity (via HTTP/REST and websockets)
and routing the response (of the modifying calls) to websockets topic
So technically, I'd be interested in ideas to mix spring-data-rest with spring websockets implementation to achieve something like spring-data-websocket.
There are a two solutions coming to my mind, and in fact both would be:
spring-data-rest to expose my entities via REST/HTTP API
websocket controllers (used for the modification calls on entities)
The websocket controllers would look like this:
#Controller
public class EntityAWebSocketController {
#MessageMapping("/EntityA/update")
#SendTo("/topic/EntityA/update")
public EntityA update(EntityA entityA) throws Exception {
// persist,....
return entityA;
}
}
Scenario 1: Websocket API called from REST/HTTP API
Rules:
client request is always REST/HTTP API
response is REST/HTTP API for all the operations
moreover for modifying operations the websocket message comes as well
Technically, could be achieved, by:
calling the websocket controllers from the spring-rest-data events (namely in the AfterCreateEvent, AfterSaveEvent, AfterLinkSaveEvent, AfterDeleteEvent)
Still the solution seems quite sick to me, as I'd need to go for:
client A --HTTP request--> Server (spring-data-rest controller)
Server (AfterXXXEvent in the spring-data-rest controller) --websocket message--> Spring websocket controller
Spring websocket controller --websocket message via topic--> all Clients interested in the topic
Server (spring-data-rest controller) --HTTP response--> client A
Scenario 2: Websocket API independent from REST API
Rules:
client request is REST/HTTP API for non-modifying operations only
response is REST/HTTP API for non-modifying operations only
client sends websocket message for all the modifying operations
websocket message is sent to client for all the modifying operations only
Well, if no other ideas come up, I'd go for the later one, but still, it would be great if I could have somehow generated C(R)UD methods exposed via websockets as well, something like spring-data-websockets and handle only the routes in my implementation.
As I feel like I'd have to manually expose (via *WebSocketControllers) all the CUD methods for all my entities. And I might be too lazy for that.
Ideas?
Scenario 2 talks about, in the last step, a single client.But I thought your requirement was for a topic since you wanted multiple clients.
If I wanted to complete 2 for your stated requirement, then you might want to maintain a list of clients and implement your own queue or use a ForkJoinPool to message all your clients listening in on your WebSockets. Having said that, A topic is definitely more elegant here but overall looks too complicated with different interfaces
For all messages from client to server, just go with a simple wire protocol and use a collection to parameterize, it could be
RParam1.......
At the server, you need a controller to map these to different requests(and operations). Somehow does not look like too much work.
Hope this helps.
The same architecture has bugged my mind for a while now and it will be a long story if I want to mention all the drawbacks and advantages of it so let me jump into the implementation.
The second scenario is valid, but as you mentioned its better to perform the crud actions on same websocket session. This shall remove the need for HTTP handshakes on every request, and reduces the body size of messages, therefore you will have better latency. Meanwhile, you already have a persisting connection to a server, so why not make good use out of it?
I searched around for a while and after 6 years from your question, I still couldn't find any websocket protocols that can make this happen, so I decided to work on that by myself cause I needed it for another dummy project.
Another advantage of such protocol could be that it doesn't require much changes to your already written controllers. So it should be able to support Spring Framework (for example) annotations and make websocket endpoints out of it.
The hard part about implementing such protocol in another framework like spring is that as its not nice to create ServletRequest and ServletResponse and convert them to your own websocket protocol, you loose some advantages. For example, any http filter you have written in your application till that moment, will be meaningless because its not really easy to pass your websocket messages through those filters.
About the protocol itself: I decided everything to be passed through json format, alongside a unique id for each request so we can map callbacks on client side to the request id. And of course there is a filter chain to add your filters to it.
Another hard to deal thing here is Spring Security as that too works like http filters in some cases. In my own lib I could finally handle annotations like #PreAuthorize but if you are using antMatchers in your HTTP Security Config, it would be a problem.
Therefore, creating websocket adapter to call http controllers will have many drawbacks.
You can check out the project here: Rest Over Websocket. Its written for Spring Boot.
I have been seeing SOAP is "Heavy Weight" and REST is "Light Weight". On what parameters, we are telling REST is lightweight than SOAP?
We were using IFW model web services in our company earlier. But our management told us to develop all the new APIs going forward in REST. We are backend service providers in my company.
How REST is best useful for us?
What does "lightweight" means in context?
This question seems like repetition but don't understand the terms used.
REST gives you a session less window into a system. It does not track you, it does not care about you. All you have done is send a request which contains..hopefully some id to verify that you can make it. It may return a HTTP status code, it may return some body but ultimately, once the request is complete you are forgotten.
SOAP is heavy in a sense that it describes a "contract" between the remote system and your client. In order for your client to communicate effectively it MUST implement its schema...this is the SOAP skeleton. It describes the calls you can make and the objects you can expect back.
The reason why SOAP is heavy is because of serialization. Upon each SOAP request you typically serialize a java object, send it over HTTP and get a serialized response which is deserialized into an object via reflection...this is heavy. It also means that if the endpoint changes how they work, you must change your contract. You don't have to do this with REST.
With SOAP you run into multi threaded issues.
To answer quickly..
they might mean that a REST service is "lightweight" because you do not need to release changes to clients. You simply make changes to your logic, retaining URLS and the response should remain the same.
With SOAP...if you added a new field to an object, you would have to get the client to implement the new schema. SOAP is pretty old had.
REST is lightweight in that it and relies upon the HTTP standard to do its work. It is great to get a useful web service up and running quickly. If you don't need a strict API definition, this is the way to go. Most web services fall into this category. You can version your API so that updates to the API do not break it for people using old versions(as long as they specify a version). REST essentially requires HTTP and is format-agnostic, so you can use XML, JSON, HTML etc).
But the SOAP will wrap the structure into a SOAP envelope (follows an XML standard). The complexity of the SOAP envelope is based on the used message version and additional Web Service protocols. SOAP is generally transport-agnostic, meaning you don't necessarily need to use HTTP.
It can be pointed out that SOAP was designed for a distributed computing environment whereas REST was designed for a point-to-point environment.
I wonder if it is OK to say that while SOAP gives more security, REST-based API s will be easier on the resources and more scalable? As an example, Twitter, Facebook, Google Drive, Blogger, etc all have REST-based APIs that clients can consume.
Generally REST reduces the size and scope of request payloads by mapping request semantics to the underlying HTTP protocol. For example, SOAP will usually add an envelope (of varying complexity) which utilizes a WSDL (a contract) for both request and response types and service mappings. REST will just use POST, GET, etc to a URL with some HTTP encoded parameters and thus lacks an enforced contract.
There are several aspects of lightweight. SOAP is XML only, while REST allows you to send any payload, such as JSON which is less verbose and simpler than XML. Generally speaking, it takes less memory and less bandwidth to deal with JSON than XML.
On another level, using SOAP you typically describe everything as services. So, you need to define a message schema/structure for each verb and noun i.e. "CreateOrder". In REST, you use the predefined HTTP methods such as POST and put the noun/"resource" in the URI which uses already existing constructs on the HTTP level - not reinventing them in XML.
Then there is the effort it takes to adapt to change. A small change in SOAP requires you to redefine the schema, redefine the wsdl and handle versions. In rest, in the best of worlds, there is a degree of dynamic coded into the API (links to referenced resources, among other things), so that some changes can be implemented and takes effect directly.
All the heavy weight strictness of SOAP of course has a valid reason for existence. It's less likely two implementations have different interpretations of the API, than in a loosely defined REST API. SOAP also allows you to implement skeleton code in various languages based on a WSDL. In some complex scenarios, this is actually almost the only productive way to work with SOAP. Marshalling and unmarshalling between objects and serialized XML is rather heavy and adds to the heavyness of SOAP.