Tag Archives: web services

Red Hat/OpenShift – Finding the silver lining

I have been in the Uniface business for longer than twenty years. I have experienced the GUI baby steps of Uniface 6 at around the same time Windows 95 saw the light. I could keep up with the new features that were presented with each new version of Uniface that was released. So, with regards to Uniface, I can proudly say that although I may look like a monkey, I am an old monkey. I know a lot of tricks.

The world is changing at a fast pace and it is necessary to keep my bag of tricks up to date. With Uniface moving into the direction of supporting cloud features, I feel that it is necessary to do a bit of homework to prepare myself for this mind shift.

As a first step, I joined a few colleagues at the Red Hat Openshift Roadshow that was held in Amsterdam. With many similar cloud-technology related events currently taking place and with Uniface being so strong in supporting multiple platforms, it seemed like a good idea to search for the silver lining at the Red Hat event.

Red Hat Cloud Blog

Why Red Hat?

Red Hat is just one of multiple platforms that Uniface supports. It is a leading enterprise Linux platform. It is supported on both Amazon Web Services and Microsoft Azure. These two providers are currently the preferred providers for Uniface cloud support. In addition, it is also open, reliable, secure and flexible for customers who have business-critical systems.

How does Red Hat align with the goal of supporting multiple platforms for Uniface?

At Uniface we are not in the business of putting one platform in front of the other. We want the client to make the decisions around the technologies that are going to be used and we want to fit into it. Red Hat is just one of the platforms that we as well as the cloud providers do support. What makes us strong, is the fact that we can confirm that Red Hat is one of the many platforms that are on our list that we can tick off.

What benefits does this bring?

As a result of our work, we now have the infrastructure in place to verify and test Uniface on cloud platforms, therefore enabling us to tick the box that Uniface is supported.  This means customers do not need to make changes to their application source code, because, we can deploy to Red Hat as well as other platforms in the cloud in the same way as if they were deploying to on premise operating systems.

What is OpenShift?

Before we understand what OpenShift is, we first need to understand a few other terms (in short of course).

  • Infrastructure as a Service (IaaS)

When a provider runs computers on demand with specified configurations. This is alternative to rack and stack hardware. You specify the amount of RAM, CPU, disk space and operating system and the provider starts up a machine that meets these specifications within minutes.

  • Software as a Service (SaaS)

Requires zero or very little maintenance or setup. You just sign up for a cloud based service and it is available for you to use. A simple example of SaaS is Gmail.

  • Platform as a Service (PaaS)

This falls between IaaS and SaaS. Currently it is targeted at application developers. With PaaS, all the necessary pieces of your application are spinned on a server up from either the command line or a web interface. These pieces can be applications and databases.

This is where OpenShift starts to play a role. OpenShift provides the command line/web interface for the developer to spin up everything. From one command, all the necessary networking and server installs are done and a Git repository is created. OpenShift administrators will update the operating system, manage the network and do other admin work so that the developer can focus on writing code. The interface also allows the user to scale his application and do some performance tuning.

What does this mean for Uniface?

The strategy of Uniface has always been to support multiple platforms/databases etc. Internally, we are currently using Ansible as part of our build processes rather than OpenShift, but we are always investigating new ways to improve our processes and we try not to focus on specific technologies or tools. Therefore, from a DevOps point of view, I do see that OpenShift could play a part for us.

By making use of Infrastructure as Code, we can spin up multiple processes in the cloud to assist us in our build and verification processes. In our case, our application(s) are our tests, and we can now run them in parallel. We are also able to research new platforms without making investments in new physical infrastructure. This is a micro services approach which is the magic of the cloud.

I see OpenShift as a possible tool that can be used by our users. It is very powerful and useful and could be used to deploy applications into cloud environments, and to scale or contract as required.

Every cloud has a silver lining. The new silver lining is the fact that the cloud opens up so many restrictions. With new tools released every day, it is important to stay informed so that we can also be as open minded as the cloud.

Using Palettes and Templates in Uniface 10

You may have seen and experienced quite a number of the advancements in the Uniface 10 product. I presented a Uniface 10 Deep Dive discussing the following:

  • Development objects
  • Containers (vs triggers)
  • Bulk activities
  • Drag and drop
  • Properties inspector
  • Viewable inheritance of ProcScript
  • Modelled components and properties.

Uniface 10 also introduces palettes, templates and snippets:

  • Palettes are development objects that can contain templates of objects and libraries of snippets.
  • Snippets can contain text, complex HTML and JavaScript as well as ProcScript.

Palettes and templates provide a formal mechanism to capture your organization’s standards and leverage your existing expertise in both business logic and presentation technology. Practices such as defining field characteristics and behavior can now be encapsulated into a single development object and dropped onto a structure. This greatly increases your productivity as a developer.

Rather than discussing palettes and templates it probably makes more sense to show exactly what can be done with them. I have put together a small workshop that walks you through, step-by-step the process of creating a palette, creating some templates and snippets and then using them to build some samples. The workshop will help you create Windows Forms components, Bootstrap based DSP’s and a sample RESTful implementation that can then be shared internally or to the community.

Uniface 10 Templates & Palettes
Uniface 10 Templates & Palettes

This and all subsequent materials will be posted in the Uniface Git repositories. This is the place where you can find new and interesting Uniface functionality but also and more importantly contribute to the Uniface community.

The workshop and its supporting materials are located at https://github.com/uniface/UF10_Palettes

The Future of Programming May Not Involve Coding

By Bola Rotibi, Research Director, Creative Intellect Consulting

Part 1 in a 2 part series

It is perhaps ironic that we live in a time when governments and many others are calling for young people to be better educated with regards to writing code, yet at the same time the software development industry is requiring developers to write less code. Microsoft’s Azure App Service or Salesforce.com’s Lightning are recent examples of new tools that aim to eliminate code writing from the process of developing an application (desktop or mobile).

The principle of this approach is not new and tools such as Uniface have long aimed to increase developer productivity and application quality by reducing the number of lines of code that need to be written. The terminology, approach and experiences have evolved and differ but the aim has remained the same.

Even in the world of code writing the popularity and growth in frameworks from .NET to JQuery have sought to reduce the amount of code written. As has tooling like Integrated Development Environments such as Visual Studio and Eclipse. For example, tools provide drag and drop controls with properties windows that mean a developer can add a control to a screen or web page without writing the underlying code. We saw this in Visual Studio, Adobe FlexBuilder and others. Perhaps the question is why it has taken so long for low-code development environments to see wider adoption?

Making the complex simple is a challenge for tooling

Part of the reason may be technology. It is inherently difficult to make the complex process of writing applications into something that can be done in a way that involves no or little code. Modern applications are incredibly complex, often using multi-tier architectures and integrated with other applications. Creating a visual development experience that can work with these complexities and provide the myriad possibilities that the modern developer requires is inherently challenging. Changes in technology have made it easier in recent years.

The wide spread adoption of the API economy and the proliferation of micro-services has changed application architectures and exposed capabilities in more simplistic and easy to consume ways. Let’s take a rather modern concept such as mobile Push notifications. Each mobile platform (iOS, Android and Windows Phone) implements this capability differently and it involves a degree of complexity and quite a bit of code to manually create. Instead there are a number of services exposed as APIs (Web Services) that abstract all of this complexity and allow developers access to the capability via a few simple calls.

By basing these APIs on common programming concepts such as RESTful Web Services and JSON formatted data it allows development tools to more easily create a further level of abstraction that means developers do not need to write the few lines of code required to work with them. SOAP made consuming any service from within a development tool even easier as the WSDL allowed tooling to auto introspect and understand any service. REST is not as simple but is now widely accepted as the way to build modern services. Modern tools are finding ways to make working with RESTful services very simple.

Part 2 (coming soon):  Developers: I’m better than you and I need my code

When thinking Desktop “first” still matters

By Clive Howard, Principal AnalystCreative Intellect Consulting

A few months back, I registered for Mobile World Congress 2015 in Barcelona. As an Analyst, there is a different registration process to the one used for regular attendees. This is so the organisers can validate that someone is a legitimate industry analyst. As well as entering a significant amount of personal data, additional information such as links to published work and document uploads are also required. Crucially, there are a number of screens to complete the registration and accreditation process. But more to the point, many different types of data must be entered – from single and multiple line text entry to file uploads. Some data (such as hyperlinks) requires cut and pasting.

I’m sure that I could have done this using a mobile phone but it would have taken a long time, been awkward and irritating and probably highly prone to mistakes. In short, I would never have considered doing something like this using my phone. Could I have used a tablet? Without a keyboard and mouse it would have been problematic, especially if the screen is small. Using a tablet only Operating System might also have had its problems in places: such as uploading documents from centrally managed systems. Actually I did use a tablet but one connected to a 20inch monitor, keyboard and mouse and running Windows. In that traditional desktop looking environment the process was relatively quick and painless.

Rumours of the desktop’s demise are greatly exaggerated

It is not just complex data entry scenarios such as this that challenge mobile devices. Increasingly I see people attach keyboards to their tablets and even phones. Once one moves beyond writing a Tweet or one line email many mobile devices start to become a pain to use. The reality of our lives, especially at work, is that we often have to enter data into complex processes. Mobile can be an excellent complement, but not a replacement. This is why we see so many mobile business apps providing only a tiny subset of functionality found in the desktop alternative; or they are apps that extend desktop application capabilities rather than replicate or replace them.

One vendor known for their mobile first mantra recently showed off a preview version for one of its best known applications. This upgrade has been redesigned from the ground up. When I asked if it worked on mobile the answer was no, they added (quite rightly) no one is going to use this application on a mobile device. These situations made me think about how over the last couple of years we have heard relentlessly about designing “mobile first”. As developers we should build for mobile and then expand out to the desktop. The clear implication has been that the desktop’s days are over.

This is very far from the truth. Not only will people continue to support the vast number of legacy desktop applications but will definitely be building new ones. Essentially, there will continue to be applications that are inherently “desktop first”. This statement should not be taken to mean that desktop application development remains business as usual. A new desktop application may still spawn mobile apps and need to support multiple operating systems and form factors. It may even need to engage in the Internet of Things.

The days of building just for the desktop safe in the knowledge that all users will be running the same PC environment (down to the keyboard style and monitor size) are gone in many if not the majority of cases. Remember that a desktop application may still be a browser based application, but one that works best on a desktop. And with the growth of devices such as hybrid laptop/tablet combinations, a desktop application could still have to work on a smaller screen that has touch capabilities.

It’s the desktop, but not as we know it

This means that architects, developers and designers need to modernise. Architects will need to design modern Service Orientated Architectures (SOA) that both expose and consume APIs (Application Programming Interfaces). SOA has been around for some time but has become more complex in recent years. For many years it meant creating a layer of SOAP (Simple Object Access Protocol) Web Services that your in-house development teams would consume. Now it is likely to mean RESTful services utilising JSON (JavaScript Object Notation) formatted data and potentially being consumed by developers outside of your organisation. API management, security, discovery, introspection and versioning will all be critical considerations.

Developers will equally need to become familiar with working against web services APIs instead of the more traditional approach where application code talked directly to a database. They will also need to be able to create APIs for others to consume. Pulling applications together from a disparate collection of micro services (some hosted in the cloud) will become de rigueur. If they do not have skills that span different development platforms then they will at least need to have an appreciation for them. One of the problems with mobile development inside enterprise has been developers building SOAP Web Services without knowing how difficult these have been to consume from iOS apps. Different developers communities will need to engage with one another far more than they have done in the past.

Those who work with the data layer will not be spared change. Big Data will affect the way in which some data is stored, managed and queried, while NoSQL data stores will become more commonplace. The burden placed on data stores by major increases in the levels of access caused by having more requests coming from more places will require highly optimised data access operations. The difference between data that is accessed a lot for read-only purposes and data which needs to be changed will be highly significant. We are seeing this with banking apps where certain data such as a customer’s balance will be handled differently compared to data involved in transactions. Data caching, perhaps in the cloud, is a popular mechanism for handling the read-only data.

Continuation of the Testing challenge

Testing will need to take into account the new architecture, design paradigms and potential end user scenarios. Test methodologies and tools will need to adapt and change to do this. The application stack is becoming increasingly complex. A time delay experienced within the application UI may be the result of a micro service deep in the system’s backend. Testing therefore needs to cover the whole stack – a long time challenge for many tools out there on the market – and the architects and developers will need to make sure that failures in third party services are managed gracefully. One major vendor had a significant outage of a new Cloud product within the first few days of launch due to a dependency on a third party service and they had not accounted for failure.

Using CouchDB with Uniface

I won’t repeat any definitions of what NoSQL databases are, nor a review of any specific products. I’ve read plenty about NoSQL databases and I think that the general view of developers is that it is one more tool in the arsenal of application development. I generally believe that you should choose the right tool for the job at hand.

So, you may get that task one day where the advantages of using a NoSQL database outweigh the disadvantages. Can, or how can you use this database with Uniface? The answer definitely depends on the specific NoSQL database product. Between them all, they have a large variation in their APIs and data structures. For that reason I will just describe my experiences doing some prototyping with CouchDB from Apache. Be aware that this is slightly different to Couchbase, which appears to be a commercialised offshoot from what Apache took on board as an open source project. For brevity, I refer you to the website for information about CouchDB’s characteristics:   https://couchdb.apache.org/

The major characteristic of CouchDB is that the documents stored in the database are in JSON format. While investigating another project, I stumbled upon a convenient source of JSON formatted documents that I could use to store in my CouchDB database. I hope that you aren’t offended by simple Chuck Norris jokes. It is a unique genre that not all will enjoy, but it served my purposes adequately. Thus in studying my prototype, you could imagine how you would handle more business related data.

I have provided a sample form in the community samples part of Uniface.info. All you need to do, besides compiling that one form, is to download and install CouchDB from the earlier link provided. I downloaded the Windows version. I manually created the “cnjokes” database using the CouchDB provided Futon utility, also installed with the Couch DB. I also manually defined the design document “vcnjokes”; more about that later.

The top part of the COUCHTEST01 form is really a “utility” area, where you can manually enter URIs and run requests against the “cnjokes” database.   These requests use the UHTTP internal Uniface component. The way the CouchDB API is structured gives you a very RESTful web service interface, though there are some comments on how RESTful CouchDB really is, within their online tutorials. The results of the calls are available in the message frame.   You can press the GET button without adding anything to the URI and you will see some global information about the “cnjokes” database. Overall, this “utility” is not as flexible as the CouchDB provided Futon utility, but it might be helpful during further Uniface development.

The 4 buttons, and accompanying entity and fields provide the real prototype; effectively demonstrating a CRUD lifecycle of managing CouchDB documents. The UHTTP component is used to obtain a CN joke in JSON format from an internet website, and then the UHTTP component is used to interact with the localhost CouchDB server. The document format is deliberately unchanged between the external joke website and CouchDB. However, you could manipulate the JSON before storing it in CouchDB if required, using Structs. Note that I have used $uuid as the basis for assigning a document ID.

The other 3 buttons query the CouchDB database using views. Ad-hoc queries are not possible in CouchDB. The 3 views are defined in a single “design document” called “vcnjokes”. The source for that design document are provided with the sample download, as comments for the COUCHTEST01 form.

  • Button “Get all current jokes from CouchDB” uses view “joke_by_jokeid”. All jokes are retrieved, and sorted by joke_ID, but only a few columns are selected. It cannot be edited as the revision ID is not available. Note that escaped quotation symbols in the data are displayed as quotations.
  • Button “Get all nerdy jokes from CouchDB” uses view “nerdy_joke”. The jokes list is filtered to those that have a category of “nerdy”. This list also cannot be edited.
  • Button “Get all current data from CouchDB for edit” uses view “all”. This view references all of the document and so all fields, including revision ID, are available. Thus editing can be done, and when stored, the new revision number is updated. Note that escaped quotation symbols appear as stored, for ease of updating.

When preparing the JSON for display in a Uniface form, it is certainly necessary to use Structs to manipulate it into the Component data structure. In fact the choice of the external data structure of the form entities is quite arbitrary. CouchDB has no fixed schema. Thus you can never be sure that an external application won’t add data that renders your entities and fields obsolete. All I could do is generate a useful number of jokes, and observe that some of them have one category with a value of “nerdy”. However, I can see that the category is defined as a JSON array, and so I make sure to set   $tags->jsonClass = “array” before converting the struct to a JSON string. This is what led to the one to many relationship between CNJOKE and JCATEGORY. With my CouchDB data set, I verified my schema by manually adding several extra categories to some jokes, using structure editor commands to add and remove occurrences (tool tip text will assist you).

Hopefully this prototype demonstrates how modern features in Uniface allow integration with other modern software systems.