Now that PowerBuilder 2019 and its new C# development capabilities are in beta, we are starting to get questions about the future of PowerScript desktop apps. Specifically, does Appeon recommend developers to move away from PowerScript desktop apps? And related to this point, will Appeon be enhancing or just maintaining the features of PowerScript desktop apps?
A quick look at the PowerBuilder roadmap page and it is obvious we have put much focus on the C# language, open standards, and cloud architecture. Increasingly, most new .NET projects have such high-level requirements. Perhaps this is why the .NET framework is radically different these days – the .NET Core framework is open source, cross OS, and targeted for cloud deployment. And unfortunately, we could not use any of the .NET stuff Sybase did because it didn’t meet these requirements. So certainly, we had to put a lot of focus on non-client/server features.
Now let’s assume for the sake of argument that the cloud is the future and focus on if and how a PowerScript desktop app fits into such future. A native UI technology (e.g. PowerScript desktop app) has certain advantages over HTML (e.g. ASP.NET page) and vice versa. However, for most line-of-business apps we believe a native UI technology offers the best set of tradeoffs. Key industry players like Microsoft seem to be recognizing the shortcomings of HTML and trying to lessen this gap with Progressive Web Apps (PWAs). At Appeon, we think it makes more sense to “cloudify” the PowerScript desktop app than replace it with some other technology.
In fact, we began to “cloudify” the PowerScript desktop app the second we took over PowerBuilder, which we did on top of its existing C++ runtime and PowerScript language. Starting with PowerBuilder 2017, we introduced an all-purpose HTTP client, a REST-specific client, an OAuth2 client (with support for tokens), and JSON handling (parsing, generating, packaging). And in PowerBuilder 2019, we have significantly enhanced all of these features, especially how they integrate with the DataWindow to minimize the amount of coding you do.
But of course, there is still more work for Appeon to do with the PowerScript desktop app to make it attractive for new projects, no matter they are client/server or cloud based. This is exactly why in every single release for the foreseeable future we have planned to bring major new features to the desktop target. For example, in PowerBuilder 2019 we will revamp the UI of desktop apps. And in PowerBuilder 2021 we plan to revamp deployment of desktop apps (from the cloud). Beyond that, it would be silly of us to say now, and most vendors wouldn’t even say this much.
PowerBuilder 2017 R2, released in January 2018, added TLS 1.2 support in the new HTTP Client and RESTful Client components. Both objects have a property named SecureProtocol that can be set to a value of five (5) to ensure only TLS 1.2 protocol is utilized. TLS 1.2 takes advantage of the use of the higher SHA-256 encryption standard and the client and server’s ability to specify the accepted hash and signature algorithms. TLS 1.2 also supports authenticated encryption, TLS extensions, and AES cipher suites.
PowerBuilder 2017 R3, released in July 2018, upgrades PowerBuilder to support the new OAuth 2.0 specification – often just commonly referred to as OAuth2. With the inclusion of OAuth2 features, application developers and their resulting applications can take advantage of the security features of OAuth2. Before the average developer utilizes the new OAuth2 features of PowerBuilder, it helps if you understand the concepts behind the OAuth2 implementation.
OAuth2 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service. Many popular third-party HTTP services use OAuth2, such as GitHub, Google, Facebook, etc. – just to name a few. OAuth2 works by delegating user authentication to the service that hosts the user account and authorizing third-party applications to access that user account. The OAuth2 system provides authorization flows for web, mobile and desktop applications. It does this by using four OAuth2 roles, which are: Resource Owner, Client, Resource Server and Authorization Server. The OAuth2 framework defines these roles as:
Resource Owner is the user who authorizes an application to access their account.Resource Server is the server hosting protected data (for example Google hosting your profile and personal information).Client is any application requesting access to a resource server. Before it may do so though, it must be authorized by the user, and the authorization must be validated.Authorization Server is a server issuing access token to the client. This token will be used for the client to request the resource server. This server can be the same as the authorization server (same physical server and same application) as this is often the case.
High Level Flow