I am working on a Corba client for some time. One problem that I run in is that I am not really able to define a timeout configuration.
I am using a Mico C++ orb but it seems to be a global problem because I found noone who could describe if there is a Corba defined method to configure a request timeout.
Does anyone know of such an interface or orb initialization?
The Messaging section of the CORBA spec defines RelativeRequestTimeoutPolicy and RelativeRoundtripTimeoutPolicy for that. You may look at the section named "Programming client timeouts" in http://www.cs.wustl.edu/~schmidt/PDF/C++-report-col19.pdf for more information.
I don't have experience with MICO, but it seems that it is supported since version 2.3.13
Policies are not real-time specific; policies permeate the core spec as well as optional features such as Real Time. The POA uses policies, as does the ORB itself, to configure different behaviors.
As Eric Malenfant already pointed out, there are two timeout policies that are part of the Messaging aspect of CORBA that will have an effect. However, there are also additional policies known as Sync Scope policies that affect the timeout policies as well. I'm not sure how much MICO implements any of those.
Related
I have been tasked to develop an interface layer that will be used internally by other developers as a means to access Google Cloud Storage (GCS). For me the process began by reading the online documentation. I am now at the point of making a decision as to which API we'll use. There are a couple of outstanding questions and that documentation mentions posting questions to SO, so here I am.
A quick tidbit of background seems in order. We are predominately a C house, though we do have means to build and invoke C++ methods from C. The internal users will write C code that invokes my C code, which in turn must provide access to GCS. So that's the high-level call stack. The question then becomes one of how do I provide that access in the best manner, with performance being the top criteria?
To answer that, I began by reading the online documentation regarding the different GCS options. There is an XML and a JSON REST API to be had. We have an internal HTTP mechanism that would enable the C code to invoke those JSON/XML API methods directly. The documentation states the following:
"...JSON API is RESTful...and is specifically intended to be used with the Google Cloud Client Libraries."
What are Google Cloud libraries I wondered. Reading the documentation gleaned that they are libraries that are written in a particular language and can be utilized to access GCS. The documentation seems to steer you in the direction of using one of these client libraries versus the JSON/XML ones.
So the first question I had was "what does the 'specifically intended" business mean exactly?" After more reading, I arrived at the notion that these client libraries are an abstraction of the RESTful interfaces. These libraries invoke the JSON API methods, just as you could do yourself through the JSON API directly. Is that correct? If so they seem like a means of convenience to interact with GCS. The documentation even states that the cloud libraries "...provide better performance and usability" versus the JSON HTTP interface.
In the end, I see two paths forward:
Invoke the JSON API directly from C using our HTTP mechanism
Use the bridge to invoke C++ methods from C. Those C++ methods then invoke methods in the client libraries, which ultimately (if the above is correct) invoke the JSON API.
Note that I've already written some C code in-house that uses the aforementioned internal HTTP mechanism to interact with the Apache WebHDFS API, which is also RESTful and for which there are no client libraries. Thus I could leverage a fair portion of that code to re-use in this new development. For me it boils down to a question of performance. The second option above seems rather circuitous in comparison to the first. Thus the first would seem to yield some performance improvement over the second. However Google mentions that the client libraries provide better performance than the RESTful APIs. How is that? The documentation states that the client libraries handle all of the low level communication with the server, including authentication. Is this part of the reason?
And so I am posing this question to those who are more experienced with GCS (and perhaps GCP for that matter): which route would provide better performance in your opinion? Invoking the JSON API directly or using the client libraries (C++ in our case)?
Thanks!
Disclaimer: I work on the C++ client libraries for Google Cloud, specifically the C++ GCS library.
However Google mentions that the client libraries provide better performance than the RESTful APIs. How is that?
The libraries are tuned to use the RPCs "well". They have good defaults for retry and backoff strategies, they pick the right RPC if two alternatives are available. They can recover efficiently from an interrupted download or upload. They may implement higher-level abstractions to improve performance.
If you are asking "how can running their code to call an RPC be more efficient than me calling the same RPC", then the answer is "probably it cannot". I do not think that is the interesting problem. For example, if you want to upload a large file (say multiple GiB) the most efficient way in GCS is to split the file in chunks, use several parallel uploads to different GCS objects, then compose the objects, and delete the intermediate objects. That would be several times faster than uploading the file sequentially. Could you do the same? Sure! Do you want to? Maybe not.
We also worry about resuming an interrupted download correctly. And verifying the integrity of your data as you upload and download it (you can turn off those features, of course).
Finally, we can change the protocol under the hood if there is a more efficient way to do things. For example, we already switch between XML and JSON when we both are equivalent and one seems to perform better than the other. We are also working on supporting gRPC instead of REST, which is showing good improvements over the REST baseline (unfortunately it is not GA yet, and I do not have an estimated date).
HTH
I like fast code execution (because of that I switched from Python to Go) and I do not like dependencies. Amazon recommends using SDK for simpler authentication (but in Lambda I can get tokens from IAM from environment variables) and because of built into SDK retry on errors (few lines of code, as I think). Yes it is faster to write my code using SDK, but what additional caveats about using pure HTTP API instead of SDK? Am I too crazy about milliseconds? Such optimizations worth it?
Anything you do with AWS is the result of an API call, whether executed by CLI, Web console, or SDK.
The SDKs make it easier to interact with those APIs. While you may be able to come up with some minor improvements for some calls, overall you will spend a lot of time doing it to very little benefit.
I think the stated focus on performance belies real trade-offs.
Consider that someone will have to maintain your code -- if you use an API, the test area is small, but AWS APIs might change or be deprecated; if you an SDK, next programmer will plug in new SDK version and hope that it works, but if it doesn't they'd be bogged down by sheer weight of the SDK.
Likewise, imagine someone needs to do a security review of this app, or to introduce something not yet covered by SDK (let's imagine propagating accounting group from caller role to underlying storage).
I don't think there is a clear answer.
Here are my suggestions:
keep it consistent -- either API or SDK (within given app)
consider the bigger picture (how many apps do you plan to write?)
don't be afraid to switch to the other approach later
I've had to decide on something similar in the past, with Docker (much nicer APIs and SDKs/libs). Here's how it played out:
For testing, we ended up using beta version of Docker Python bindings: prod version was not enough, and bindings (your SDK) were overall pretty good and clear.
For log scraping, I used HTTP calls (your API), "because performance", in reality comparative mental load using API vs SDK, and because bindings (SDK) did not support asyncio.
https://states-language.net/spec.html
Is there an API/library which I can use to process states as per this standard. I understand AWS resources are available; is there anything independent of AWS and in the java library that can be used?
There is complete lightweight microservice platform (probably fastest on the market) called light4j eventuate. One of subproject is https://github.com/networknt/light-workflow-4j which implements Amazon States Language completely.
As of now, there is no Java implementation/bindings outside AWS.
Netflix Conductor blog states:
Recently announced AWS Step Functions added some of the features we were looking for in an orchestration engine. There is a potential for Conductor to adopt the states language to define workflows.
So - since their decider component is a Java service - maybe that could become a Java implementation someday.
https://github.com/totherik/step is based on nodejs and focused on openwhisk compatibility.
If you are going to start the development of an API for your web application. Is there any kind of guidelines, best practices or standard to build web services. I have seen a few discussions in this topic and I will like to get more information.
At least get pointers on where to get the information.
Thanks in advance.
There exists a wide variety and latitude regarding "web services". I find it useful to make explicit note of what we are talking about:
web = transported over HTTP(S)
service = remote procedure call (RPC)
Note that the HTTP(S) portion of this merely specifies the transport medium, but not the content. Also note that the RPC portion of this merely specifies the behavior (essentially invoking remotely a named function with arguments that returns a result) but not the content.
A critical question that arises is whether you control both sides of the communication. If so, but especially if not, you need to be concerned about interoperability.
SOAP is a standard for implementing a web service that specifies using specificly-formatted XML for the content of the request and response. It is VERY heavy, and there are still problems with interoperability across various implementations.
There are lots of custom implementations, most of which are lighter, but you will almost certainly have interoperability issues.
Since any form of content can potentially be used to achieve a web service, I recommend picking something that is able to handle complex content (to varying degrees), standardized, lightweight, and robust.
I am recently leaning towards JSON for the content format. I recommend considering the same, especially if you are considering implementing AJAX.
Best wishes.
API 101
I am pasting this URL as a close approximation of the possible answer. Since I did not get any other answer, I think this is as close as it gets.
I will like to have more detail best practice outline, if someone find something better, let me know to mark their answer as accepted.
If you could answer some of these questions, you might get a more satisfactory answer.
who is the audience that will be consuming the the service?
What types of client technologies will be consuming the service
what assumptions/restrictions can you put on them (platforms, tooling, skill
set)?
How broad is you API - how many methods will it expose?
Is security a consideration - how secure do you need to be?
Do you need to support transactions?
I found a good description on wikipedia with a few reference links, but there may be better ones, please help me to find these!
To be clear, I am not looking for implementation for any language specific implementation guides, just the pure concept.
Guidelines for Building RESTful Web Services has all the info on the resources you need.
This is another useful blog entry:
The uniform interface constraints describe how a service built for the Web can be a good participant in the Web architecture. These constraints are described briefly as follows :
1) Identification of resources: A resource is any information item that can be named and represented (e.g. a document, a stock price at a given point in time, the current weather in Las Vegas, etc). Resources in your service should be identified using URIs.
2) Manipulation of resources via representations: A representation is the physical representation of a resource and should correspond to a valid media type. Using standard media types as the data formats behind your service increases the reach of your service by making it accessible to a wide range of potential clients. Interaction with the resource should be based on retrieval and manipulation of the representation of the resource identified by its URI.
3)Self-descriptive messages: Following the principles of statelessness in your service's interactions, using standard media types and correctly indicating the cacheability of messages via HTTP method usage and control headers ensures that messages are self descriptive. Self descriptive messages make it possible for messages to be processed by intermediaries between the client and server without impacting either.
4)Hypermedia as the engine of application state: Application state should be expressed using URIs and hyperlinks to transition between states. This is probably the most controversial and least understood of the architectural constraints set forth in Roy Fielding's dissertation. In fact, Fielding's dissertation contains an explicit arguments against using HTTP cookies for representing application state to hammer this point home yet it is often ignored.
Or you can get it straight from the horse's mouth, Architectural Styles and
the Design of Network-based Software Architectures
I read RESTful web services by O'Reilly and really enjoyed it.
I'm not sure how much detail you're looking for, but for a broad overview of what REST is all about I recommend Ryan Tomayko's How I Explained REST to My Wife.