Embedded Applications vs Wrapped Applications
Embedded Applications vs Wrapped Applications
How do you guarantee that an application written in a scripting language will work the same on every deployed system?
Join the DZone community and get the full member experience.Join For Free
Have you ever wondered what’s typically most important when it comes to application distribution? Is it app security, stability, license indemnification, no active GPL/GNU in the license, royalty free options, or all of the above? It’s safe to say that most companies want it all, and that’s what they get with ActiveState’s OEM solutions. OEM versions of ActivePerl, ActivePython, and ActiveTcl make it really seamless and simple for organizations to create cool and innovative applications, and start shipping without a hassle.
There a few ways to go about this: you can either embed the interpreter in your application, or you can wrap your app and distribute a single executable file. But why would you pick one option over the other?
Check out our new datasheet highlighting the two options, but let’s compare a few key considerations for now:
- Application Performance
- Embedded applications have fewer layers that they need to deal with before the application is launched. This saves time and resources and results in a performance advantage. No one likes waiting for their app to open or to perform a task!
- Wrapped applications run slower at startup, mostly due to the app needing to be unwrapped during the startup process.
- Embedded applications have fewer moving parts, which means there are fewer things that need coordinating (speeding up performance) which also mean that fewer things can go wrong.
- It is much easier to find and fix security-related issues with embedded applications because you don’t need to drill down through the wrapped layers to explore all the nooks and crannies to locate the root cause.
- The techniques used to wrap applications can be similar to those used by viruses, leading to mistaken identity [of wrapped apps] by antivirus software programs; this may scare your end users away from running your app. Embedded apps never have false positives with antivirus software.
- False positives from antivirus software may result in the application not being able to run at all, depending on the user’s admin privileges and antivirus setup.
- Editing Applications (whether for dev or troubleshooting)
- Because the code is visible in embedded applications, it’s much easier to make changes.
- Unwrapping applications [and rewrapping] to access/fix source code is time-consuming and not always possible.
- It’s not possible to turn on a debugger at the interpreter level with wrapped applications which makes troubleshooting tricky and more difficult than with embedded.
- The exposed code in embedded applications makes it easier to find and fix issues, compared to wrapped applications where troubleshooting can be more difficult and time-consuming.
- There is a lot more potential and opportunity to customize your application as custom content (i.e.modules), and custom interpreters can be easily added to embedded apps.
- Customization is severely limited due to the wrapping process itself and the strict constraints it imposes on the interpreter with wrapped applications.
So which option is best? When should you embed, and when is it best to wrap? Let’s look at a few examples:
- Example 1 Wrapping A GUI is required to make it simpler for non-technical users to add records to a database. A scripting language is chosen for ease and speed of development, but it’s also desirable to conceal the mechanics of connecting to the database and harden the scripts against tampering. The coding task is well-defined, and most edge cases have already been seen before, so debugging only during active development isn’t a problem. Once this GUI is working, it’s likely that changes to the scripts will be infrequent. Wrapping is a good option in this case.
- Example 2 Embedded A system is designed to provide GUIs that reflect the status of smart infrastructure across a network. Users are very technical, but not software engineers, and they need a way to filter out noise, and be alerted to important status changes in a consistent manner, regardless of the type of equipment reporting an issue. Every customer for this system is likely to have a different mix of gear from other customers, so customization is needed when the system will be installed and users must be able to modify both the displays and the back-end talking to the network over the life of the system as the mix of gear on the network evolves. Users also want smart reporting that they can customize and extend for forecasting and capacity planning. The system must be flexible, as it is expected to be changing over its entire life-cycle. Scripting languages are easily understood by part-time developers, and changes are simple to deploy. Embedded is the ideal solution for this use case, providing more flexibility over the product’s life.
For companies that need a dependable scripting language like Perl, Python or Tcl to power or extend their living applications, an ActiveState OEM license is going to be the best option. Our OEM agreement covers all the important details that organizations should be concerned with, while simplifying the process of delivering a solution powered by scripting languages.
For more detail on this topic, please read our datasheet titled "Benefits of Embedded Applications."
Published at DZone with permission of Kathy Thomas , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.