Need to consume a third party web service exposed over SOAP. But the response is having too deep object graphs and the response time is very high: 40-60 sec.
JAXB marshalling and unmarshalling also add significant latency on top of it. Is there a way to reduce the latency using protobuf/thrift. Also some recent application modules are migrated to Vertx. While CXF has asychHttpClient built in, is there any equivalent module in Vertx. What is the advantage of using it over CXF client?
You're referencing 2 separate issues here.
1) The third party service takes 40-60 seconds to respond.
Most like there is no way for you to speed up the response so you have to deal with it as it is, and the choice you use just depends on your application. Vert.x may help in this regard because it is asynchronous by design.
2) The object graph of the response is large and JAXB deserialization has serious overhead.
Most likely Thrift or Protocol Buffers won't help you too much because they are completely different technologies than SOAP/XML. Probably the issue you are having is the fact that JAXB reads the entire message into memory and then creates a complete object graph for it, regardless of the amount of data you actually need. If you don't actually need all of the data, you should investigate using something like the Streaming API for XML (StAX) that is part of the Java platform. It allows you to parse an XML message without creating an object model for data that you do not need.
Related
I use ASP.NET 4.7 MVC 5 on an Azure App Service.
I currently get JSON response data by calling REST APIs directly from my .NET code and then deserialising this JSON using
var order = JsonConvert.DeserializeObject<Order>(json.ToString());
This works fine and is pretty good regarding speed. However I am now looking into Azure Logic Apps to see if this could be used to call 3rd party APIs which would then transform its native schema to my standard schema.
Would the use of Logic Apps slow down the retrieval of data from the API endpoints compared to my current native .NET approach. I have a feeling that it will as it may be much more asynchronous/fire and forget. I am hoping that I would just call into the Logic App and get the same response as if I had done it natively, but with greater flexibility and scalability.
Thanks.
EDIT: My question is about the use of Logic App versus native calling. So assume one job each. I confused the matter talking about transformation as well. Apologies
I think the easy answer is yes. The api call in your native code would be fired immediately and return the payload to your application directly, whereas a logic app step has all the plumbing required by activity orchestration and infrastructure costs. You could probably measure a difference, but it may not impact the quality of your application, depending on what it is trying to do.
The question I would ask is “does it matter”? What are you giving up by using logic apps over c# code? Is it worth the trade off to enjoy the benefits of serverless computing (scale out, no infrastructure to maintain, focus on the what instead of the how, etc)?
Say you have microservice A,B, and C which all currently communicate through HTTP. Say service A sends a request to service B which results in a response. The data returned in that response must then be sent to service C for some processing before finally being returned to service A. Service A can now display the results on the web page.
I know that latency is an inherent issue with implementing a microservice architecture, and I was wondering what are some common ways of reducing this latency?
Also, I have been doing some reading on how Apache Thrift and RPC's can help with this. Can anyone elaborate on that as well?
Also, I have been doing some reading on how Apache Thrift and RPC's can help with this. Can anyone elaborate on that as well?
The goal of an RPC framework like Apache Thrift is
to significantly reduce the manual programming overhead
to provide efficient serialization and transport mechanisms
across all kinds of programming languages and platforms
In other words, this allows you to send your data as a very compactly written and compressed packet over the wire, while most of the efforts required to achieve this are provided by the framework.
Apache Thrift provides you with a pluggable transport/protocol stack that can quickly be adapted by plugging in different
transports (Sockets, HTTP, pipes, streams, ...)
protocols (binary, compact, JSON, ...)
layers (framed, multiplex, gzip, ...)
Additionally, depending on the target language, you get some infrastructure for the server-side end, such as TNonBlocking or ThreadPool servers, etc.
So coming back to your initial question, such a framework can help to make communication easier and more efficient. But it cannot magically remove latency from other parts of the OSI stack.
I'd been using RestKit for the last two years, but recently I've started thinking about transition from these monolith framework as it seems to be really overkill.
Here's my pros for moving forward:
There is big need in using NSURLSession for background fetches and RestKit has only experimental branch for transition to AFNetworking 2.0. No actual dates when transition will be finished. (Main Reason)
No need for CoreData support in network library as no need for fully functional offline data storage.
Having headache with new concept of response/request descriptors as they don't support different parameters in path patterns (ex. access token parameter) and there is no way to create object request operation in one line with custom descriptor. Here I am loosing features of object manager as facade.
I. The biggest loss of RestKit for me in object mapping process.
Could you recommend standalone libraries that you use which shows themselves as flexible and stable?
II. And as I sad I need no fully functional storage but I still need some caching support in some places.
I've heard that NSURLCache has become useful in last OS release.
Did you use it and what's the strategy?
Does it return cached API responses when network connection is down?
III. Does anybody faces the same problems?
What solutions have you applied?
Maybe someone could give some piece of advice about architecture that he or she uses in multiple apps with pure AFNetworking?
I. In agreement with others who have commented, AFNetworking + Mantle is a simple and effective way to interact with a Restful API and to replace RestKit's object mapping process that you miss.
II. To answer the requirements of your caching support is highly dependent on the context. However, I have found for my recent functional requirements that caching a view model for a particular controller's screen and only caching reference data returned by APIs allows me to keep the application logic relatively simple whilst giving the user some continuity. A simple error notification for connectivity issues can be dealt with a cross-cutting manner.
III. One thought on the architecture relevant to this aspect is to ensure that the APIs the app is dependent on provides data according to the app experience. This allows your app to focus on what it is good at (a very slick user-experience) and moves logic into the API's closer to API dependencies such as data. This has a further benefit of reducing the chattiness of the app.
I have a service that exposes a JSON-over-HTTP API (that uses ServiceStack) and now I am writing a .NET client (dll) that abstracts away this API to basically provide a domain-specific object abstraction on top of it. This client will be used by apps that need to hit the service a lot so striving for high-throughput and low-latency is important. I've done quite a bit of optimization work on the service to get it to acceptable levels of throughput and latency (measured those using JMeter). Naturally I would like to make the client as fast as possible.
I would like to use ServiceStack's ServiceClient library to handle the communication with the service and have a couple of questions:
Is the JsonServiceClient thread safe?
Does the JsonServiceClient (or any of the *ServiceClientBase children) do some sort of connection pooling when they talk to HTTP v1.1 servers? Or do they open a separate connection for each request they are asked to perform?
I would also appreciate any suggestions on how to use ServiceClient or perhaps maybe another library in order to make the communication with the service optimal (client-side caching is part of my plan so that's already in the works).
I have a app in which I need to query a sharepoint site via services. The app will be under heavy usage so performance and scalability will be two of my priorities.
I started to investigate which service approach is better and from a perf point of view it seems that client object model is the one officially suggested, but when I came to scalability I personally found that actually web services seem more potent than client object model. This is because it seems that web services have async support for IO bound operations rather than client object model that doesn't. I say doesn't because as Stephen Toub said the ability to invoke a synchronous method asynchronously does nothing for scalability and I think BeginInvoke does just that.
I have to mention that I am using in my app C# 5 async/await feature in order to return the thread to the thread pool when queries are executed on the server.
My question is, what should weight more in order to take a decision?
Edit: It is worth to mention that I am not using the Silverlight CSOM, I am using the more generic .NET one.
This is an answer with no answer. :)
You are correct in that BeginInvoke is fake-asynchronous (i.e., it just issues the blocking call on a thread pool thread). So it would actually be worse, scalability-wise, than just invoking the blocking methods.
First, consider your scalability as compared to your Sharepoint server. If you're running on roughly equivalent hardware, then you probably don't need to scale any more than the Sharepoint server will. You would probably be fine with either solution.
If you do need to scale better (e.g., the Sharepoint server is a cluster or cloud, or if your machine is much lesser than the Sharepoint machine), then it requires more thought and likely testing.
The better performance in the client model is purely from its batching capabilities. So if your application won't use batching, then the (asynchronous) web services model would be better.
However, if your application uses batching and needs to scale better, then there isn't an answer. In this case, the only way to know is to build a test case both ways and measure it.
Actually, the client object model not only provides, but sometimes requires asynchronous access. You can find more info in the Data Retrieval Overview but the short version is that:
You create and load one or more queries in a ClientRuntimeContext then
Execute all loaded queries either synchronously with ClientRuntimeContext.ExecuteQuery or asynchronously with ClientRuntimeContext.ExecuteQueryAsync with two callbacks for success or failure
You don't have to use BeginInvoke anywhere.
In fact, the Client object model in Silverlight provides only the Async method in which case you are forced to execute the call asynchronously.
The syntax is quirky, but the client object model targets .NET 3.5 and Silverlight, so it wasn't possible to provide a Task based interface. You can even argue that callbacks are somewhat simpler than the Begin/End pattern and definitelly better that raising completion events.
EDIT
As #alexb noticed, ExecuteQueryAsync is available only in Silverlight. There are other ways to work asynchronously though.
You can take advantage of Sharepoint's OData support to query lists using WCF Data Services. The query scenario is a bit similar, as you submit your query and wait for a callback when the results come in. In the meantime, you get access to a DataServiceQuery object that represents the asynchronous query.
This method uses REST/Json and therefore lighter on the wire than the web services. The LINQ and ORM-like API are also easier to work with compared to the web services.
Sharepoint's support is described in Query SharePoint Foundation with ADO.NET Data Services and asynchronous querying is described in How to: Execute Asynchronous Data Service Queries (WCF Data Services)