I am writing a Rest Web Services.
I am not great at designing.
At present i wanted to know the service handler should be singleton or static.
#RequestMapping(value="/{input}" ,method=RequestMethod.GET)
public String getOutput(#PathVariable String input){
ResourceRestService.getInstance().outPutService().getOutput(input);
}
Is using singleton instance of ResourceRestService or OutputService correct in this case?
Does it cause any performance overhead when the number of requests increases if yes then what should be the solution?
What you have done is a standard, no issues. Since it is a singleton and non thread safe, the class should not maintain state, all it has to do is to get request and send response. If the number of requests increase, you may have to use clustered environment(apache mod_jk etc.,)
You Service method should not be a singleton unless there is a specific need for you to do you like in case of making it Thread Safe or so,
You should rather make it static.
When no of requests increases there are quite a few scenarios that you may need to consider for you to scale, A non-exhaustive list is as below
1. Is it due to database layer? no of records, db performance etc etc
2. Is it due to service layer? amt of processing at service layer due to various reason
3. Is it due to server capability? Max no of requests it could handle
so on..
Related
I have the task of scheduling & executing a lot of web-request, in java 8, with the following conditions:
each web-request belongs to exactly one of distinct groups
the group a web-request belongs to is an immutable and deterministic property of the request (i.e. is not a result of some (pseudo-)random logic), e.g. imagine the user on behalf the request is being made
the web-service is tracking the quota usage of web-requests it receives, for each of these distinct group
a web-request may receive an HTTP 429 (Too Many Requests) at any given moment, indicating that the quota for that group is full
when this happens, no more web-requests of the same group are allowed to be made until the stated time indicated by the Retry-After header of the response, such futile requests still count as part of the quota
web-requests of a non-throttled group can, and should be processed regardless of some other groups being throttled
some requests are more equal then others, therefore eligible requests should be processed in some priority order
the number of these distinct quota groups is in the few hundreds (for now)
at any given moment a new group may be born, e.g. a new user joins the organization
I've been collecting some ideas, none of which I am satisfied with:
The most obvious is that each group could be handled by their very own ThreadPoolExecutor consuming from a respective PriorityBlockingQueue
Simplicity has its virtues, but I kind of dislike running hundred instances of ThreadPoolExecutors (even if each and every one of them is using a single thread for execution).
I could (try to) go down the tedious and quite error-prone path of implementing my own BlockingQueue, with a PriorityQueue maintained for each group
the number of interface methods in BlockingQueue is not that many, but the designers of that concurrency library saw fit to extend Collection and Queue interfaces, and just the amount of time to implement all those methods and test them too sounds like a (dangerous) waste of time to me
I could also go and relax the goal of letting non-throttled groups&requests to progress, and just block all requests until stated time
this may not be as bad as it sounds, I will still have to check how easy it is to hit the quota limit and what the time penalty is - 5 minutes blackout ever other week sounds almost acceptable, half an hour every midnight is definitely not OK
Another idea is to have ThreadPoolExecutor with a single PriorityBlockingQueue (PBQ) with a map of throttled group -> request-lists on the side
on several occasions (on submit, on consuming from main PBQ, and even on just having received an HTTP 429 response), the group of the request would be tested for being throttled, and if it's that the case, the request would be put to that throttled group -> request list map
but normally, requests would just be consumed by the ThreadPoolExecutor
of course, whenever some throttling period indicated by Retry-After header of the HTTP 429 response has ended, the respective group would wake up and all it's requests would be re-submitted to the main PBQ
I've also been reading up on RxJava, but none of the delay, throttle or backpressure facilities are suitable - or at least I coulnd't see how.
At this point I really don't expect any pseudo-code (well, unless it's actually shorter that way), but I am most interested in better ideas or perhaps pointers to existing facilities.
(Btw, the web-service is the Microsoft Graph API, in case anyone wonders.)
I did a search on the board and there were some threads related to what I will ask but the other questions were not exactly like my situation.
I want to implement a service (ejbs) and different clients (rest api, webservice, jsf managed beans and maybe some other client) are going to use this service. My question is: in this scenario, where should data validation occur?
Seems reasonable to me to do it inside my business control (ejbs),- since I don't want to implement one validator type for each client- but I don't see people doing it...
best regards,
Oliver
The general advice would be: Every component, which exposes functionality to the outside should validate the input it receives. It should not hope for the best that it will in all cases receive valid input. Additionally, as you said, it keeps the validation at one place.
On the other hand it may be a reasonable decision when you have both sides under your control to decide for an early validation on the client and document the expected/required valid input data.
You have a similar problem when designing a relational database structure - you can have all sorts of constraints to ensure valid input data or you can check validity in the component storing the data in the database.
And, not to forget, whenever you validate in a deeper layer, all higher layers have to handle the exceptions or error messages when validation fails.
Regarding your specific question, the usage of the same service from different clients advises to validate within the service.
I'm looking for a possiblity to monitor all messages in a SOA enviroment with an intermediary, who'll be designed to enforce different rule-sets over the message's structure and sequences (e.g., let's say it'll check and ensure that Service A has to be consumed before B).
Obviously the first idea that came to mind is how WS-Adressing might help here, but I'm not sure if it does, as I don't really see any mechanism there to ensure that a message will get delivered via a given intermediary (as it is in WS-Routing, which is an outdated proprietary protocol by Microsoft).
Or maybe there's even a different approach that the monitor wouldn't be part of the route but would be notified on request/responses, which might it then again make somehow harder to actively enforce rules.
I'm looking forward to any suggestions.
You can implement a "service firewall" either by intercepting all the calls in each service as part of your basic servicehost. Alternatively you can use 3rd party solutions and route all your service calls to them (they will do the intercepting and then forward calls to your services).
You can use ESBs to do the routing (and intercepting) or you can use dedicated solutions like IBM's datapower, XML firewall from Layer7 etc.
For all my (technical) services I use messaging and the command processor pattern, which I describe here, without actually calling the pattern name though. I send a message and the framework finds to corresponding class that implements the interface that corresponds to my message. I can create multiple classes that can handle my message, or a single class that handles a multitude of messages. In the article these are classes implementing the IHandleMessages interface.
Either way, as long as I can create multiple classes implementing this interface, and they are all called, I can easily add auditing without adding this logic to my business logic or anything. Just add an additional implementation for every single message, or enhance the framework so it also accepts IHandleMessages implementations. That class can than audit every single message and store all of them centrally.
After doing that, you can find out more information about the messages and the flow. For example, if you put into the header information of your WCF/MSMQ message where it came from and perhaps some unique identifier for that single message, you can track the flow over various components.
NServiceBus also has this functionality for auditing and the team is working on additional tooling for this, called ServiceInsight.
Hope this helps.
I have to implement a SOA solution with web services. I have to transfer large objects (ex: Invoices of 25~30mb of XML data) and I wonder what's the best approach...
Should I:
A. transfer parts of this objects separately (ex: header first, then items one by one, regardless of the fact that there could be 1000 of them) in several WS calls and then organize them in "server side" dealing with retries and errors.
Or ...
B. Should I transfer the entire payload in one single call and try to optimize it (and not to "burn" Http connections)?
I'm using .Net's WCF to expose services layer. I accept recommended readings and considerations.
The idea would be to maximize the load and minimize the number of calls. This isn't always simple since - in a one shot call - firewalls or the web service itself could limit the payload size and your message might not make it, or - in case of multiple calls - as you mentioned yourself, you have to deal with errors and retries (basically doing WS-ReliableMessaging).
So perhaps, instead of concentrating on the message of an usual call, you might try changing how you perform the respective call, and maybe have a look at MTOM (Message Transmission Optimization Mechanism) with WCF, or maybe use streaming.
hoping some of you clever people can help me out here!
We have an ASP.NET web service app, using Entity Framework 1 and EFPocoAdapter. The mem usage of the app pool running this web service keeps growing on every web service call. We currently monitor its mem usage and once it starts to get over 1GB we recycle the app pool to free up the memory.
We instantiate the object context in each web method in a 'using' statement so that doesn't leave open object contexts (observed with efprof).
So I used Ants memory profiler 7 to track whats going on and after the first call to the web service (at this point the EF framework generates its view, etc), I've taken a snapshot. Then make the same call and take another snapshot. Ants shows that the new objects created since the last snapshot are pretty much all related to System.Data.Common.QueryCache.QueryCacheManager.
I know the point of the cache is to improve performance, but in our case I think we need to NOT cache every query plan as the likelihood of repeating those calls is minimal due to the nature of our main app / business.
So, my question..... is there a way of turning off this caching, or am I barking up the wrong tree here and there's something else going on I'm unaware of?
I've searched all over the web for an answer to this, and all I can find is the MergeOption property which seems to be related more to entity tracking for speed / performance improvements.
If you don't modify the data just select it, you can simply turn off object modification tracking:
datacontext.ObjectTrackingEnabled = false;
It worked for me in a similar situation with Linq2SQL.