BA372 — XML and Web Services
BA372 — Portability (RR: still relevant, but quickly losing relevance)
transferring a software product to another 'platform.'
- Hardware / OS.
- Different Web stack; e.g., LAMP, .NET, Java, etc.
- Backend server software; e.g., ERP system which supports multiple core RDBMS.
- (Human) language; e.g., Windows/Mac OS for X languages; should
TeachEngineering have an English/Spanish switch?).
- 'Ownership' —> open source vs. proprietary.
- Interoperability; e.g., multiple data formats for import/export; e.g., XML vs. JSON; MA-Ms ODF controversy.
- TeachEngineering (TE):
- 1.0: Hosted on LAMP (Until Apr. 28th, 2016; now (2.0) Windows/Azure/RavenDB) — AMP supported on multiple platforms; e.g., Linux, Windows, OSX.
- TE 1.0 Development mostly Windows.
- 'TE 1.0 Spider' in Java; (supported on both Linux & Windows).
- TE 1.0: MySQL (supported on both Linux & Windows); TE 2.0: RavenDB is .NET or Java.
- TE 1.0:
- Some use of Linux shell scripting ≠ Windows batch/powershell scripting.
- Linux crontab ≠ Windows scheduler.
- Browsers are not all the same —> must support multiple browsers on multiple OS's on multiple display formats —> lots of testing.
- File permissions/security models are quite different.
- System monitoring utilities are not cross platform.
- All open source except one or two (very important) third party, platform-specific development tools.
- Overall: was relatively easy port to Windows.
- Hohmann (p. 115): "Marketects
and tarchitects alike often pursue portability with a fiery passion."
- 'Claimed' motivations to port:
- Supporting multiple platforms provides access to additional markets.
- TeachEngineering (May 5th, 2016 - 30 days):
- Chrome (54%); Safari (22%); IE/Edge (9%); Firefox (8%);
- Desktop (69%); Mobile (24%); Tablet (7%)
- 2014 — Reengineered TE 1.0 to nicely render on mobile devices?
- Supporting multiple platforms shows that we can meet customer needs.
- Portability paradox:
"Customers choose a platform because
of its unique features and perceived benefits, but most portable
applications are explicitly designed to avoid platform-specific
- Similar to standard vs. vendor-specific SQL.
- Or most other things in life: specialization vs. generalization
- 'Real' motivations to port:
- Writing portable software is interesting and neat (compare with
- One or two, early key customers want the tool on different
platforms (need for revenue causes early porting).
- "Portability is ALWAYS about money." (p. 118):
- Train and maintain developers on multiple platforms.
- Purchase and maintenance of multiple platforms.
- RR Note: OS virtualization and platform simulators all but eliminate the 'purchase' factor.
- Development, testing and QA on multiple platforms.
- Entropy reduction on multiple platforms.
- Management of release cycles on multiple platforms.
- !!! Web-based apps help a LOT !!!
- The Java 'craze' in 1993/94
- Recall the differences between compiled, interpreted and byte-compiled languages?
- Portability does not compensate for a poor product.
- Good products do not necessarily HAVE to be portable (Pfizer/Sun example on p. 118).
- Carefully compare revenue/platform with cost/platform.
- Technologies; i.e., tools such as RDBMS, web servers and browsers, word processors, etc. tend to have higher need/market for portability
than end-user applications (p. 117):
- Technologies are mostly built with portability in mind:
modular, stubs for drivers, configuration files, etc.
- If you (really!!) have/want to port; how to do it?
- A priori instead of ex post; i.e., build it portable in the first place.
- Use interpreted languages where possible:
- Need an interpreter for each platform.
- Single code base.
- Compiled languages:
- Compiler for each platform.
- Only write 'portable,' 'cross-platform'
- Nonetheless; often minor code variations across platforms; e.g.,
content of system() or exec()-like calls.
- Write standards-based codes; e.g.,
ANSI (Standard) SQL rather than X-company SQL; ANSI C rather than X-company C.
- Note: PL/SQL, T-SQL. etc. stored procedures are (typically) not portable to other DB platforms.
- Use standard, text-based data formats such as XML or JSON for data communications rather than
have applications share memory or have applications directly communicate binary data.