> Archive > Issue LXXII, May 2013

Download Issue
Download Full Service Technology Magazine PDF

An Approach for Assessing SOA Maturity in the Enterprise

Andrzej Parkitny

Andrzej Parkitny

As a large organization grows, system integration becomes an important aspect of the operational nature of its growth and IT maturity. Organizations may claim that they have implemented a service-oriented architecture, but that claim may require further questioning. SOA is, in essence, a journey. This article explores how adopting SOA maturity models such as the independent SOA Maturity Model (iSOAMM) as described by Rathfelder and Groenda, and OSIMM by The Open Group, can assist IT integrators in establishing a formal process by which integration gaps can be captured and subsequent plans made to remedy such gaps. As Information Technology integrators, we may at times feel that the effort to integrate between the systems of an organization becomes too great as the organization grows. Although the practice of developing a service-oriented architecture is an approach that has its roots in dogmatic computer science, we still need to consider what is practical and achievable within the enterprise. The implementation of an SOA practice is a journey at heart. Depending on where your organization is on its SOA journey, it is important to ask a number of key questions: What is the current systems state of the organization from an IT-enterprise perspective? Which and how many legacy systems exist in the organization? Does the organization already have a configuration management system whereby the IT staff can work together with the business stakeholders to mature a service-oriented architecture? Of the existing components, on which technologies are the legacy components deployed – for example, mainframe, standard C, C++, J2EE EJBs (Weblogic, Websphere, JBoss), or .NET? What is the level of...

A Methodological Approach to Entity Service Modeling

Marco Fränkel

Marco Fränkel

When it comes to the service delivery lifecycle, service modeling is the part of the analysis phase during which service candidates are produced before the physical definition and development. Unfortunately, this phase is skipped completely in a lot of SOA projects so that the definition of a service is based either directly on the demands of the service consumer (contract-to-functional coupling) or the API of the underlying code (contract-to-logic coupling). Both coupling types are considered "negative" and should be avoided in order to maximize the governance independence of the service contract. This article describes a practical method to prevent its occurrence, using a real-life case study. Ideally, the modeling of an entity-centric business service is based on its known and predictable usage. That's why SOA follows the example of commercial product design, which applies expert judgment to determine the most suitable type and quantity of logic to be provided by a service. In his book Service-Oriented Architecture: Concepts, Technology and Design, Thomas Erl provides a step-by-step process that can be used to conceptualize the services and their capabilities, based on decomposing business process definitions. Although this method definitely has its perks and can produce (if done properly) a nicely balanced service inventory blueprint, it can be a bit too complex for people that are not that well-versed in the area of service-orientation. It may also take up a lot of time, especially when the supporting business process documentation is not up to par and...

Canonizing a Language for Architecture:
An SOA Service Category Matrix

Jürgen Kress, Berthold Maier, Hajo Normann, Danilo Schmiedel, Guido Schmutz, Bernd Trops, Clemens Utschig-Utschig, Torsten Winterberg

Jürgen Kress Berthold Maier Hajo Normann
Danilo Schmiedel Guido Schmutz Bernd Trops Clemens Utschig-Utschig Torsten Winterberg

Services have to meet different architecture and governance requirements whose relevance is determined by how the services are reused. The arrangement and structure significantly affect the analysis and design of the services, which in turn determine the level of granularity. Categorizing services makes it easier to arrange them according to service usage in the procedural landscape, which helps prevent unwanted entanglements. SOA architectures that have not undergone categorization quickly become "adapter" SOAs that lack a clear division of responsibilities. The orchestration of business processes in these architectures is interspersed with technical service calls that can lead to unaccountable call sequences. To tackle these challenges, a vocabulary that SOA professionals can use to describe different types of services has been developed. We explore the various possibilities for categorizing SOA services in this article, before introducing the range of service categories that we have successfully implemented in projects. The SOA service categorization matrix in Figure 1 contextualizes the concepts that are presented. The service categories that are most applicable to functionally motivated services will first be described. These functionally motivated or "public business services" are usually published in a registry such as UDDI. Different ways in which these public services can be implemented with the help of "private services" are discussed, along with an exploration of several other useful categories. A business process service (BPS) consists of the purely functional aspects of business processes. This type of service is based on...

On the Concept of Metadata Exchange in Cloud
Services - Part II

Enrique Castro-Leon, John M. Kennedy

Enrique Castro-Leon

John M. Kennedy

In the first article of this two part series we explored the concept of cloud service metadata and metadata exchange. Service metadata is information about a service itself, allowing service introspection. Metadata is essential for service consumer building a composite application to evaluate whether a given service offering from a provider matches the application's requirements. In this article we'll see how metadata features for artifacts inside a service can be exposed across service boundaries. Intel Corporation and Telefónica Digital initiated a joint project to build a proof point of the concepts described in the previous article. The goal for this project was to demonstrate the feasibility of cloud bursting across two companies. The PoC implements a service setup scenario where an application running on servers in Folsom, California requests external resources, namely servers hosted by Telefónica running in Madrid. A carefully choreographed pas de deux ensues, facilitated by a cloud fabric implemented under Citrix Netscaler* VPX. When the dance completes, the remote Telefónica servers ("nodes") end up in the same subnet as the initiating servers in Folsom, California. In the remainder of this section we provide a detailed description of the cloud bursting setup orchestration. In the initial state, as shown in Figure 1, we see two resources (servers) functioning independently. The Intel data center hosts an application capable of cloud bursting (that is, Intel is the service consumer or initiator), whereas the Telefónica data center offers hardware for rent as a traditional cloud IaaS service. Now assume that customer A1, currently running two virtual machines in the Intel host...

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