When is it appropriate to use Java Callout? Docs offer conflicting advice.

Not applicable

The Java Callout documentation explicitly says not to use Java Callout for file I/O:

http://apigee.com/docs/api-services/reference/java-callout-policy

"System calls, for example network I/O, filesystem read/writes, current user info, process list, and CPU/memory utilization are not permitted by the security model. Although some such calls may be functional, they are unsupported and liable to be actively disabled at any time. For forward compatibility, you should avoid making such calls in your JavaCallout."

But then, Apigee documentation elsewhere suggests exactly the opposite:

http://apigee.com/docs/api-services/cookbook/use-java-customize-api

"More advanced use cases for JavaCallout include implementing blocking or non-blocking behavior for I/O intensive operations like doing file I/O, calling remote services, cache handling, and others. These advanced cases will be explored further in future cookbook examples.”

So: When is it recommend to use JavaCallout? It seems there are no – or very few – use cases that makes sense for JavaCallout. Further, if support may disappear, I'm not comfortable doing anything too low-level in JavaCallout - which then further prompts the question whether to use it at all.

Thanks in advance!

Solved Solved
2 2 666
1 ACCEPTED SOLUTION

Good question, David.

First, it looks like you've uncovered an inconsistency in the documentation for the product. We'll get that sorted. I'll provide my perspective on your question here, but don't take my statement here as 100% official. It may change slightly as interested parties within Apigee consider all aspects of the issue. I'll update here when we get it clear.

First, the JavaCallout capability itself will not disappear; we won't withdraw support for running JavaCallout policies. Second, let's talk about the statement in the doc that you highlighted -- "System calls, for example network I/O, filesystem read/writes, current user info, process list, and CPU/memory utilization are not permitted by the security model." This is a pretty conservative position that we have taken, in my opinion, in order to protect the multi-tenant cloud service for Edge. In some cases, code running on shared services may disrupt the service level for other tenants, and we want to be able to manage that. Also, code that misbehaves, for example code that when run for a long time fills up the filesystem, will disrupt YOUR OWN service. And again we want to help protect against that.

Also, remember that there are two models for running Apigee Edge: one, in the Apigee public cloud as a multi-tenant system, and another, as a private-cloud system, where the customer controls everything about the system. In the latter case, the code run in JavaCallouts is entirely the responsibility of the customer. They're responsible for verifying the integrity of the code, verifying that the code won't disrupt their own private cloud service. So for sure, in the private cloud scenario, JavaCallouts are fully powered and none of that will ever go away.

In sum I'd say be prudent with what you do in JavaCallouts. Remote calls are no problem. Be thoughtful about filesystem I/O in the Apigee Public cloud because there's no guarantee that your code will run on the same node, from day to day or even hour to hour. You probably shouldn't need to do system queries, like examining the list of processes or otherwise spelunking into OS issues. I don't think that is possible in the public cloud, nor should it be. If you think you have a need to do that in the public cloud, give Apigee Support a call, and discuss it. Maybe there's a better way to accomplish what you want.

Finally please do continue to use JavaCallouts. They're a great option when you have Java code that does just what you want.

View solution in original post

2 REPLIES 2

The doc team is following this to get a definitive answer as well.

Good question, David.

First, it looks like you've uncovered an inconsistency in the documentation for the product. We'll get that sorted. I'll provide my perspective on your question here, but don't take my statement here as 100% official. It may change slightly as interested parties within Apigee consider all aspects of the issue. I'll update here when we get it clear.

First, the JavaCallout capability itself will not disappear; we won't withdraw support for running JavaCallout policies. Second, let's talk about the statement in the doc that you highlighted -- "System calls, for example network I/O, filesystem read/writes, current user info, process list, and CPU/memory utilization are not permitted by the security model." This is a pretty conservative position that we have taken, in my opinion, in order to protect the multi-tenant cloud service for Edge. In some cases, code running on shared services may disrupt the service level for other tenants, and we want to be able to manage that. Also, code that misbehaves, for example code that when run for a long time fills up the filesystem, will disrupt YOUR OWN service. And again we want to help protect against that.

Also, remember that there are two models for running Apigee Edge: one, in the Apigee public cloud as a multi-tenant system, and another, as a private-cloud system, where the customer controls everything about the system. In the latter case, the code run in JavaCallouts is entirely the responsibility of the customer. They're responsible for verifying the integrity of the code, verifying that the code won't disrupt their own private cloud service. So for sure, in the private cloud scenario, JavaCallouts are fully powered and none of that will ever go away.

In sum I'd say be prudent with what you do in JavaCallouts. Remote calls are no problem. Be thoughtful about filesystem I/O in the Apigee Public cloud because there's no guarantee that your code will run on the same node, from day to day or even hour to hour. You probably shouldn't need to do system queries, like examining the list of processes or otherwise spelunking into OS issues. I don't think that is possible in the public cloud, nor should it be. If you think you have a need to do that in the public cloud, give Apigee Support a call, and discuss it. Maybe there's a better way to accomplish what you want.

Finally please do continue to use JavaCallouts. They're a great option when you have Java code that does just what you want.