|
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...
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...
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...
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...
|
Looking forward to the upcoming book launch event at CloudExpo for “Cloud Computing: Concepts, Technology & Architecture”. I will be in New York for most of the day on June 11th to participate in the book signing with Ricardo Puttini, Pamela Wise-Martinez and several of the contributors. The best part of this type of event is getting a chance to meet followers of the book series first-hand. With this being the ninth title we’ve produced in nine years, it is always interesting to experience the diversity of culture and opinion of readers and to hear how content from different series titles influenced projects, specifications and mindsets. I positioned this new book as the anchor for a line of cloud computing titles that are already in various planning and development stages. Stop by with your ideas and thoughts if you’re in the neighborhood.
Thomas Erl, Series Editor and Site Editor
The book launch is over. To view photos from the event, visit the photo album at: www.facebook.com/techbks
Introductory Offer for New Text Book:
Cloud Computing: Concepts, Technology & Architecture
50% Discount + Free Shipping when also ordering CCP Kits.
For AITCP Members Only | Offer Ends June 30, 2013
Click here for more information.
|
The entire May 2013 issue of the Service Technology Magazine is now available for download as a high-resolution PDF.
|
To view the most current calendar of public SOA and Cloud Certified Professional workshops, visit www.arcitura.com/workshops
-
SOA .NET Developer Certification
June 3-5, 11, 14, 19-20, 2013 • Mexico City
-
Cloud Computing Architect Training
June 26-28, 2013 • Singapore
-
Cloud Architect Certification
July 15-19, 2013 • Las Vegas
-
Cloud Technology Professional Certification
July 22-24, 2013 • Toronto
-
Cloud Architect Certification
July 22-26, 2013 • Dubai
-
SOA Consultant Certification
July 29 - August 2, 2013 • Vancouver
-
SOA Architect Certification
July 29 - August 2, 2013 • Utrecht
-
Cloud Architect Certification
August 5-9, 2013 • Las Vegas
 |
Monthly Updates via E-mail |
|
|
|
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP)
Arcitura YouTube Channel
Service Technology Magazine
The Prentice Hall Service Technology Series from Thomas Erl