This years Elevate 2018 Conference is now fast approaching so it is time to register to benefit from the significant amount of technical sessions scheduled.  The technical sessions should be of interest no matter you are primarily maintaining an app or looking to elevate your apps to the next level. The conference itself this year is scheduled for November 5-7, 2018 in Philadelphia at the Sheraton Philadelphia Society Hill Hotel, and your registration fee covers the 60+ hours of technical sessions, breakfasts and lunches, and admission to a special evening networking event.

The conference will start out with an information-packed keynote address that will cover many exciting items about PB 2017 R3, the upcoming PB 2018, and the latest updates to the product roadmap. The keynote will also address the new C# features of PB 2018 with valuable information, such as: 

How PowerBuilder 2018 fits in the .NET ecosystem?How PowerBuilder 2018 takes your apps to the cloud?How will PowerBuilder modernize the UI of your apps?What are the latest updates to the PowerBuilder roadmap?

Many technical sessions are planned related to the key features and technologies of PB 2018 such as:  .NET Core framework direction, n-tier REST based architecture, the new C# DataStore/ModelMapper, and so on. Following the keynote address, various daily technical sessions will commence focusing on hot topic areas such as: C# with PowerBuilder, Modernizing your UI/UX, Cloudify Existing App, Integration, Design & Best Practices, and Development Productivity. In between these sessions, you will be able to schedule time to meet one-on-one with the Appeon Product Team or Appeon staff to discuss your specific project questions or challenges.

Building on the excellent feedback from last years Elevate 2017 conference, you will be excited to hear that many of last years presenters will also be returning to Elevate 2018 to present fresh new topics for this year. On the Appeon side, the Elevate 2018 conference will also have the pleasure of key people from the Appeon Product Team, including Appeon CTO John Qi and Appeon product manager Julie Jiang, and of course other Appeon staff. Many of the returning conference presenters are also well-known Appeon MVPs such as: Bruce Armstrong, Marco Meoni, Michael Kramer, and Matt Balent, just to mention a few. There will also be a host of presentations from real-life Appeon customers who will educate you how they overcame project challenges or used new features of PowerBuilder.

The daily agenda will start with a continental breakfast at 8:00am followed by Education Sessions from 9:00am to 12:00pm, where afterwards lunch will be served. Following lunch, the Education Sessions will continue from 1:00pm through until 5:00pm. On the last day, the Education Sessions will conclude earlier at 3:00pm for those wanting to catch an early flight or drive back home.

The movement from SOAP-based web services towards RESTful-based web services is another evolutionary journey for PowerBuilder developers and their related applications. Originally, Sybase added SOAP (Simple Object Access Protocol)-based features in PowerBuilder version 8.0. The original SOAP features were aligned with the Java implementation of EasySOAP and provided a messaging protocol specification for exchanging structured information in the implementation of web services across computer networks. Sybase enhanced the web service feature in PowerBuilder version 9.0 to include the ability to handle more complex SOAP interactions. In PowerBuilder version 11.0, Sybase then added support for Microsoft’s .NET-based web service framework as well. This greatly improved the web service interaction possibilities in that era of PowerBuilder. The .NET web service feature was tweaked again in PowerBuilder version 11.5 (and latter PowerBuilder versions) to support the newer releases of the .NET framework.

Since PowerBuilder 11.5 though, the basic SOAP-based architecture has been PowerBuilder’s “go to” vehicle for web service interactions. However, the IT industry moved onward with newer REST (Representational State Transfer) web service technology, which has now become a de facto architectural style used by most modern web services. The REST approach defines a set of constraints and properties based on the HTTP protocol that provides greater interoperability between computer systems on the Internet today. By REST using a stateless protocol and standard operations, REST systems can have faster performance, reliability, and the ability to grow, by re-using components that can be managed and updated without affecting the system, even while it is running.

There are six guiding constraints that define a RESTful system. These constraints restrict the ways that the server may process and respond to client requests so that, by operating within these constraints, the service gains performance, scalability, simplicity, modifiability, visibility, portability, and reliability. If a service violates any of the required constraints, it cannot be considered RESTful. The formal REST constraints are as follows:

Client–server architectureStatelessnessCache-abilityLayered systemCode on demandUniform interface

The focus of a RESTful service is on resources and how to provide access to these resources. A resource can easily be thought of as an object as in OOP (object-oriented programming). A resource can consist of other embedded resources as well. While designing a system, the first thing to do is identify the resources and determine how they are related to each other. This is like the first steps of designing a database: identify entities and relations. Once we have identified our resources, the next thing we need is to find a way to represent these resources in our system. You can use any format for representing the resources, as REST does not put a restriction on the format of a representation.

The client and service talk to each other via messages. Clients send a request to the server, and the server replies with a response. Apart from the actual data, these messages also contain some metadata about the message. It is important to have some background about the HTTP request and response formats for designing RESTful Web services. REST requires each resource to have at least one URI (Uniform Resource Identifier). A RESTful service uses a directory hierarchy like human readable URIs to address its resources. The job of a URI is to identify a resource or a collection of resources. The actual operation is determined by an HTTP verb. The URI should not say anything about the operation or action. This enables us to call the same URI with different HTTP verbs to perform different operations.