> Issue LXXXV, July/August 2014

Download Issue
Download Full Service Technology Magazine PDF

Enterprise IT Insights for the Internet of Things

Mark O'Neill

Mark O'Neill

The Internet of Things (IoT) has been generating significant hype, and the recent acquisition of Nest by Google further fanned the flames of anticipation as consumers began to imagine real-life applications. But there have also been timely reminders of the security and privacy issues associated with the growing number of connected devices (such as the Snapchat hack and the publicized Tesla vulnerabilities). In these early stages, the Internet of Things is far from secure. In this contributed article, Mark O'Neill, vice president of innovation at Axway, will provide a timely reminder of the risks presented by the emerging IoT, what enterprise IT has done in the past to overcome similar issues, and how security approaches need to change to accommodate today's level of connectivity. Since the advent of the smartphone-brief as its introduction was in 1992 with IBM's Simon; complete in its ubiquity with Apple's 2007 iPhone launch-computers have taken over as the operation centers of our most commonly used devices. Today, the most current cars, refrigerators, thermostats, washers, dryers, ovens, televisions and more don't rely on wiring, but rather depend on programming to operate. Internet of Things (IoT) devices have Application Programming Interfaces (APIs), which enable remote management and connectivity. Through these APIs, they can interoperate. The IoT holds the promise of a world where, for instance, a thermostat equipped with motion sensor technology can connect to a home or business network, receive constant updates on the outside temperature, adjust indoor room temperature automatically by controlling heating and cooling systems through APIs...and tell the coffee maker to turn on when someone walks into the kitchen. Connected cars already offer APIs for remote unlocking and location services. And the list goes...

API Management - Governance of Public
Business Services

Gijs in 't Veld

Gijs in 't Veld

If you are involved with cloud computing and mobile (and if you are in IT, hopefully you are), you have probably already bumped into the term API Management. If not, now is the time to start getting to know all about it. It will become a crucial part of your integration platform. It can help you expose your B2B or B2C business services in a more manageable way. First, it is important to familiarize you with the term API in this context. API, or Application Programming Interface, is an old term. An API is basically a contract for exchanging information between computer programs. In the meantime though, this term does not really cover the real meaning anymore. Because, what is an application these days? Is that still a valid concept? In modern IT environments, an API is basically nothing more than the interface of a web service. These web services are most of the times based on SOAP, but more and more exposed as REST services as well. These services provide a specific piece of functionality (black-box). And they can, if they are developed with the right principles in mind, be used in many ways and thus used in many different contexts. The trend is that vendors of standard "applications" have made or are making their solutions available as services by means of the software-as-a-service (SaaS) model. And of course there are lots of software solutions available on the internet that have been designed as SaaS solutions from the ground up, like Google, LinkedIn, Bing,, etc. Lots of times, the most important functionalities of these SaaS solutions are exposed as APIs. These are the so called public APIs and they are always based on web services technology. Marketplaces for services provided by many organizations, exposed as APIs can be found on every cloud platform. To get an idea about what is going on in the so called API Economy, have a look at for instance. Among other things, they provide an API directory in which thousands of public APIs have been registered. Most of the times services are RESTful these days, because that's...

Security and Identity Management Applied to SOA - Part I

Jose Luiz Berg

Jose Luiz Berg

In recent years, security threats against the corporate systems is increasing exponentially, both in quantity and in complexity; despite the efforts of security systems vendors to accompany this growth, the war is being lost day by day, not so much because of lack of quality of the network controls, but mainly by the lack of knowledge of the developers on the subject, which results in insecure systems, especially considering the internally developed for corporate use. Recently we have seen an explosion in the adoption of identity management systems, and the use of SSO (single sign-on) services to facilitate the management of credentials, whether in own infrastructure or in the cloud. The adoption of this technology already brings, by itself, improvements in the security of applications, because authentication is a critical service that happens to be centralized and controlled by expert systems, within well know security best practices. However, even with this improvement, there are numerous other security issues that still need to be addressed to ensure the security of the applications developed in house, especially when dealing with Web Services. This document aims to present concepts on security and identity management applied in systems development, and notably in the construction of Web Services, and help minimize the lack of knowledge of the programmers on procedures and standards that allow operations to be performed safely by applications, but with the lowest possible impact on the process of development and operation. For an application to be considered absolutely safe, it could not be connected in a network, and should run on a server without external drives or USB ports, being used by a single highly skilled operator, which had access to physical facilities through biometric controls. However, an application in that way would not have much practical utility (except for the scriptwriters of Hollywood). So, develop a safe application always involves a series of trade-offs between security and functionality of the application, i.e. reducing controlled...

Building Standardized Service Contracts with Java

Andre Tost, Thomas Erl, Philip Thomas, Satadru Roy

Andre Tost

Thomas Erl

Philip Thomas

Satadru Roy

A foundational criterion in service-orientation is that a service have a well-defined and standardized contract. When building Web services with SOAP and WS-*, portable machine-readable service contracts are mandatory between different platforms as WSDL documents and associated XML schema artifacts describing the service data model. The finite set of widely used HTTP verbs for REST services form an implicit service contract. However, describing the entity representations for capture in a portable and machine-independent format is the same as SOAP and WS-*. For REST services, capturing and communicating various aspects of resources can be necessary, such as the set of resources, relationships between resources, HTTP verbs allowed on resources, and supported resource representation formats. Standards, such as WADL, can be used to satisfy the mandatory requirements. Having a standards-based service contract exist separate from the service logic, with service data entities described in a platform-neutral and technology-neutral format, constitutes a service by common definition. Even the self-describing contract of HTTP verbs for a REST service establishes a standards-based service contract. Recall the standards used for service contracts, such as WSDL/WADL and XML Schema, from Chapter 5. Ensuring that services are business-aligned and not strictly IT-driven is necessary when identifying services for a service portfolio in an SOA. Services are derived from a decomposition of a company's core business processes and a collection of key business entities. For a top-down approach, services are identified and interfaces are designed by creating appropriate schema artifacts to model either the operating data and WSDL-based service contracts, or model REST resources and resource methods. The completed service interface is implemented in code. However, enterprises can have irreplaceable mission-critical applications in place. Therefore, another aspect of finding services is assessing existing applications and components to be refactored as services for a bottom-up approach. This includes creating standard service contracts, such as WSDL definitions or REST resource models, for the existing components...

2017 2016 2015 2014 2013 2012 2011 2010 2009 2008 2007 2006