Take A Load Off: Use RESTful Web Services in uniPaaS

Take A Load Off: Use RESTful Web Services in uniPaaS

We’re pretty good at keeping "well-guarded" secrets at Magic Software. Sometimes we even release useful new features that few people know about. We made a lot of fanfare when we started supporting Web Services based on the SOAP protocol. In fact, I think I wrote the press release back in January 2002.

Here we are nearly 10 years later and uniPaaS now supports REST (Representational State Transfer) approaches to Web Services and few of us paid close attention when this feature emerged in the product with the release of uniPaaS 1.9e. But it is worth paying very close attention because RESTful Web Services can be accomplished without the complexity and overhead of SOAP Web Services.

REST isn’t something new at all. In fact, it is the way the Web has worked all along but with some rules added to help everyone get along.

What are RESTful web services?

Baiscally, a RESTful web service is a simple approach to web services implemented using HTTP and based on the architectural principles of REST. A RESTful Web Service has three resources defined:

• the URL address for the web service (you may call it a URI if you want, it is basically the same thing). The URL is the equivalent of a noun.
• the supported Internet media data type of the web service.
• the set of HTTP operations supported by the web service. Think of this as the verb.

The following table shows how the HTTP methods are typically used to implement a web service.

Unlike Web Services based on SOAP, there is no industry protocol for RESTful web services. In this sense, it is akin to a concept like Service Oriented Architecture (SOA) where a number of different approaches and protocols can be used to accomplish the objectives of the architecture. RESTful Web Services are based upon established W3C and OASIS protocols such as HTTP, URL, XML, etc. The REST architectural style is based on the idea that a client and server are interacting in a stateless manner with cached data via a uniform interface.HTTP 1.1 was designed to conform to REST. Unlike SOAP and XML-RPC, REST does not really require a new message format. Nevertheless, XML is the most popular type of REST message format. When you use XML, it becomes easier to represent the information resource in a variety of ways using XSLT and Cascading Style Sheets (CSS).

In uniPaaS 1.9e, we improved upon the ability of uniPaaS developers to employ RESTful Web Services by adding a new function: HTTPCall. This function may be used with a proxy server and supports SSL\TLS with the client certificate password protected and both basic and digest authentication schemas.

HTTPCall runs an HTTP request and returns the results. You can consume REST services by using HTTPCall with any and all verbs. This function can be used instead of the HTTPGet and HTTPPost functions, thereby simplifying implementation of RESTful Web Services in uniPaaS. The syntax within uniPaaS for the use of HTTPCall is as follows:
	HTTPCall (verb, service URL, message, [header1], [header2], …)
	The “verb” is a string indicating the method. The options include GET, POST, PUT, DELETE, and HEAD. You can GET a list or a specific member of a collection. POST is like an append operation in that it adds a member to a collection. PUT replaces an entire collection or a specified member of the collection. DELETE erases the entire collection or a specific member of the collection. HEAD is a header that provides additional header information. The “service URL” is the string that represents the HTTP address where you will retrieve the HTTP request. The HTTPCall function can easily pass a user name and password to the service URL for a secure, rights-based approach to Web Services. For example, when a uniPaaS client is accessing a web server that requires a user name and password, the URL should be HTTP://User:Password@[URL]. uniPaaS will also support secret names by following this approach: HTTP://%user_secretname%:%pass_secretname%@[URL] Obviously, the “message” is a string with the text of the message. There is no limitation on the message content. Messages are self-descriptive and stateless. The use of “headers” is strictly optional and you may include as many as needed. Each header may contain a string that provides additional header information as requested.
	As one might expect, the HTTPCall returns a BLOB containing whatever information results from the HTTP request. If the function fails to make the connection, a blank value is returned. You can get the response headers using the HTTPLastHeader function. Magic Software provides both Online and Rich Client sample programs that detail the use of the HTTPCall function. Look for sample programs EL23 and REL23 to get an idea of how this function can be implemented. One of the traditional disadvantages of REST is that it doesn’t do well with complex data architectures such as those of relational databases. In this regard, using uniPaaS allows you to bridge the gap between REST and traditional databases. With uniPaaS, information is exchanged and represented using RESTful Web Services while at the same time you can store enterprise data in industry standard databases. REST advocates will simply say databases are too complex and should change to conform to the way the Web works. With uniPaaS, you avoid that argument altogether. It just works.

Mobile Enterprise Application Platform: Any Time

Ten Key Questions to Help Compare MEAP Vendors

Comparing mobile enterprise application platforms (MEAPs) can be challenging. Quite often those that are seeking a MEAP solution do so precisely because they do not want to invest in developing in-house expertise in all of the programming languages and environments required to provide native client solutions for major mobile device environments such as BlackBerry, iPhone, Android and Windows. The IT departments ability to anticipate the challenges of each target device environment is often limited due to lack of familiarity with the differences in all these environments.

To complicate matters more, MEAP vendors are rarely what they appear to be. It is first of all necessary to try to separate out current capabilities from future plans in the vendor roadmap. One must then ask, what is the vendor history in living up to the promises in their roadmap?

Even once you have all this sorted out and have separated out marketing hype from actual platform capabilities, the task of making comparisons gets tricky. Is device management a necessary part of the evaluation, or should we consider that a separate category just as we consider development tools and IT operations software as separate systems in the data center? Evaluators need to carefully consider their own rollout plans versus the vendors plan for device support.

More important than any of these tangled issues, however, is the question of productivity. The reason for adopting a MEAP is to reduce effort. In order to live up to the need to develop and deploy mobile apps at anytime and anywhere, you need a MEAP that is truly metadata based, employs fully native clients, and has seamless capability to develop and maintain enterprise data center, enterprise cloud and enterprise mobile apps without duplicate programming efforts.

Here are a few key questions to ask a MEAP vendor?

1. Are native coding skills required to complete projects or make changes? Some MEAP vendors surprisingly do not complete the process of creating the mobile app for the target device. Manual programming and tweaking is required.

2. Will we need to use the native debugger to test our applications? If the MEAP forces you to debug their deployment capabilities on a target device, then you that means you are likely to be required to write code to fix any problems you find.

3. Can my MEAP platform also create desktop, client server and web applications? Some MEAPs are mobile only and have little or no capabilities for supporting other types of applications. This lack of support means duplicate coding for those environments.

4. Does the MEAP platform allow me to control the look and feel of the application so that I can develop with a native look and feel for each device? Will BlackBerry apps look like other BlackBerry apps? Will an iPhone app look and feel like an iPhone app? etc.

5. Does the MEAP platform vendor have a solid track record of back-end integration? Do they have a complete set of integration tools to allow you to integrate enterprise IT systems, data and processes with your MEAP platform? Integration to backend systems is a crucial component of providing B2E, B2B, and B2C applications. Without a straightforward solution for integration, you may end up spending months of unnecessary development time trying to integrate your mobile apps to existing enterprise systems.

6. Is the solution multilingual and can the vendor provide multilingual support? If you need a global solution, some vendors have limited reach in North America but not beyond.

7. How long have you been in business? Too many vendors are in startup mode with no guarantee that they will stick around.

8. Will you provide financial statements showing your revenues, profitability, cash on hand and debt position? If a vendor is unwilling to provide financial statements, then you are at significant risk that you may be dealing with a vendor that is on the brink of imminent financial failure.

9. Does the MEAP vendor have a parent company whose objectives are different from those of the independent software vendor that it acquired? If the parent company acquired the MEAP platform to serve the needs of its larger client base, will that be at cross-purposes to your needs?

10. Does the MEAP vendor have a coherent strategy for enterprise systems, mobile apps and the cloud? Can the vendor ensure that all of these solutions can be based on the same service-oriented architecture (SOA)? Is the platform capable of compositing existing application logic from Java, .NET, COBOL, RPG and other environments? A good MEAP platform will be capable of leveraging all that you have today and have a coherent strategy for deploying solutions in all of the environments that you need to be in tomorrow. A vendor that can future-proof your efforts will ultimately be the smart choice for development of mobile apps.

Once you have a satisfactory sense of what your vendor can offer, the question of how it is licensed and priced is appropriate. Some vendors adhere strictly to a per user pricing strategy. Others offer a per server pricing model. Some offer both or a hybrid. If you are developing a B2C enterprise mobile app, then per user charges are unappealing. But if you have a fairly small target B2E or B2B audience, then hefty per server pricing may be disadvantageous. In the final analysis, you will need a vendor that is willing to work with you to assure complete satisfaction and success. Evaluate vendor technical support, training and professional services. All these things combine to make the selection of a MEAP platform a difficult decision. But if you know the questions to ask, you are on the right track. To see a video announcing the Magic Software Mobile Enterprise Application Platform (MEAP), click here.