Q: Is embedding Java bad practice in BPEL?

Question: Is using a java embedding in BPEL considered bad practice, and why if so?

In my job I frequently use Java embeddings as BPEL components in order to get certain work done. It can be very easy stuff which is just comfortable for me in Java, or things that are impossible (in my knowledge) to do with other components in BPEL.

Example of simple java embedding in 12c BPEL source:

<bpelx:exec name="TruncateBlankNamespace" language="java" version="1.5">
  <![CDATA[String origHeader = (String)getVariableData("randomHeader"); try { String replacedvalue = origHeader.replaceAll(" xmlns=\"\"", ""); setVariableData("randomHeader_something", replacedvalue) ;} catch (Exception exception) { exception.printStackTrace(); }]]>
</bpelx:exec>

Another example that I use it for is to encode and decode payloads into base64 and back,

Example of base64 ecoding embedding in 11c BPEL source:

 <bpelx:exec import="oracle.soa.common.util.Base64Encoder"/>
 <variables> 
      <variable name="DecodedMessage" type="xsd:string"/>
      <variable name="EncodedMessage" type="xsd:base64Binary"/>
 <variables/>
 <bpelx:exec name="EncodePayload" language="java" version="1.5">String decodedMessage = (String)getVariableData("DecodedMessage"); try { String encodedMessage = Base64Encoder.encode(decodedMessage.getBytes()); setVariableData("EncodedMessage", encodedMessage);} catch (Exception exception) { exception.printStackTrace(); }</bpelx:exec>

Now I find embeddings very useful tools in working around certain problems, and fixing issues quickly without having to do the additional homework in the tool you are using. However it has been brought to my attention that using java embeddings in Oracle Soa suite/BPEL is bad practice.

I am a beginner middleware developer, and new to stack overflow, so please excuse me if I'm not being thorough, please point out everything wrong with this post, and feel free to edit :D!

Thank you very much!

Jesper

If it is bad practice, then what is the better practice you're supposed to be using instead?

I can see how embedding actual Java code in XML might seem ugly. But embedding this language in that language is something developers do all the time.

• We are all familiar with embedding JavaScript into HTML attribute values because we've been doing it forever, e.g., <button onclick="getElementById('date').innerHTML = Date()">.
• The ReactJS JSX language lets you embed HTML anywhere in JavaScript.
• Embedding SQL commands in Java strings is totally normal and accepted.
• Elasticsearch queries can embed scripts written in the "Painless" language.
• Every regular expression is a mini-program written in the regular expression language embedded in a larger program.
• Shell scripts and build systems in particular tend to be mishmashes of languages.

These capabilities exist because they are necessary. At some point they enabled somebody to get something done. Getting things done counts for a lot.

I would ask yourself a few questions:

• Is embedding Java in your BPEL the simplest thing that could possibly work? The people objecting to your embedded Java might expect you to call services instead. But if the logic is trivial and you only have it in one or two places, then the cost of building and maintaining a separate server just to provide this logic might not make it a practical alternative.
• Does embedding Java tend to make your application harder--or easier--to maintain?
• What are the alternatives? Would they require less effort or more? If the alternatives require a lot more effort then you have to question if they are in fact better. What's the payback for the extra effort?
• Does embedding Java in the BPEL cause you to lose some of the benefits of your SDLC process? Is the embedded Java outside of source control, for example? Does the SDLC of the Java logic match that of the BPEL it's embedded in?
• What bad things will happen if you just leave it alone?

People who cite best practices (or bad practices or "antipatterns") should be able to explain their reasoning. This is engineering, after all.