From the Editor

Issue LXXII • May 2013

Contents 3 5 20

From the Editor

PUBLISHER Arcitura Education Inc. EDITOR Thomas Erl

An Approach for Assessing SOA Maturity in the Enterprise by Andrzej Parkitny

A Methodological Approach to Entity Service Modeling

COMMUNICATIONS EDITOR Briana Lee Pamela Janice Yau SUPERVISING PRODUCTION MANAGER Ivana Lee

by Marco Fränkel

COVER DESIGN Jasper Paladino

31

Canonizing a Language for Architecture: An SOA Service Category Matrix

41

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

49

COPY EDITOR Maria Lee

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

by Enrique Castro-Leon & Robert R. Harmon

Contributors

WEB DESIGN Jasper Paladino CONTRIBUTORS Enrique Castro-Leon Marco Fränkel Robert Harmon John M. Kennedy Jürgen Kress Berthold Maier Hajo Normann Andrzej Parkitny Mrigank Shekhar Danilo Schmiedel Guido Schmutz Bernd Trops Clemens Utschig-Utschig Torsten Winterberg REVIEWERS Maurits Rijk Gerbrand van der Vooren Gero Vermaas

Copyright © Arcitura Education Inc.

2

www.servicetechmag.com


From the Editor

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


3


Cloud Computing

Concepts, Technology & Architecture

“This is a great book on the topic of cloud computing.” Kapil Bakshi, Architecture and Strategy, Cisco Systems Inc.

“We will recommend this book to Oracle customers, partners, and users for their journey toward cloud computing.” Jürgen Kress, Fusion Middleware Partner Adoption, Oracle EMEA

“A cloud computing book that will stand out and survive the test of time…. I highly recommend this book…” Christoph Schittko, Principal Technology Strategist, Microsoft Corp.

“… a must-read for any IT professional interested in cloud computing.” Andre Tost, Senior Technical Staff Member, IBM Software Group

The Cloud Computing: Concepts,

TABLE OF CONTENTS

Technology & Architecture text book

Chapter 1: Introduction Chapter 2: Case Study Background

will be released on May 16, 2013. This is the ninth title in the Prentice Hall Service Technology Series from Thomas Erl. The book is authored by Thomas Erl, Zaigham Mahmood and Ricardo Puttini.

To learn more about this book, visit: www.servicetechbooks.com/cloud

PART I: FUNDAMENTAL CLOUD COMPUTING Chapter 3: Understanding Cloud Computing Chapter 4: Fundamental Concepts and Models Chapter 5: Cloud-Enabling Technology Chapter 6: Fundamental Cloud Security PART II: CLOUD COMPUTING MECHANISMS Chapter 7: Cloud Infrastructure Mechanisms Chapter 8: Specialized Cloud Mechanisms Chapter 9: Cloud Management Mechanisms Chapter 10: Cloud Security Mechanisms PART III: CLOUD COMPUTING ARCHITECTURE Chapter 11: Fundamental Cloud Architectures Chapter 12: Advanced Cloud Architectures Chapter 13: Specialized Cloud Architectures

PART IV: WORKING WITH CLOUDS Chapter 14: Cloud Delivery Model Considerations Chapter 15: Cost Metrics and Pricing Models Chapter 16: Service Quality Metrics and SLAs PART V: APPENDICES Appendix A: Case Study Conclusions Appendix B: Industry Standards Organizations Appendix C: Mapping Mechanisms to Characteristics Appendix D: Data Center Facilities (TIA-942) Appendix E: Emerging Technologies Appendix F: Cloud Provisioning Contracts Appendix G: Cloud Business Case Template


An Approach for Assessing SOA Maturity in the Enterprise by Andrzej Parkitny, Enterprise Architect, Telus Abstract: 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 [REF-3], and OSIMM by The Open Group [REF-5], can assist IT integrators in establishing a formal process by which integration gaps can be captured and subsequent plans made to remedy such gaps. Where is your SOA Practice Headed? 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 serviceoriented 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 engagement with respect to the various stakeholders in the organization, and how do they or would they perceive an SOA philosophy? As SOA integrators, we are responsible for moving the organization’s IT systems to an architecture in which organizational agility is increased through a reduced IT burden [REF-1] to ultimately lead to a tangible return on investment [REF-1]. The main challenge that we face is that IT departments are for the most part sponsored by project-focused business teams, meaning grand visions of upheaving the IT landscape are rarely entertained. We can determine the current integration maturity of our IT enterprise through an assessment of SOA maturity, either against an industry-accepted model or its derivative. Depending on the maturity of our integration landscape, we can use this knowledge to identify where gaps exist and propose a roadmap to fill those gaps. Let us start by discussing SOA governance. SOA Governance, Service Ownership and Taxonomy At a minimum, we can be sure that each IT department has a separation of responsibilities that is aligned to specific business needs but not necessarily to specific functional components. That is, many stakeholders focus on their specific line of business and adopt a siloed approach. They measure IT success based on how the systems in a particular silo perform to fulfill very specific business needs.


5



It is the responsibility of us, as integrators, to keep their measurements honest. This responsibility should be shared between the system-owning teams and governance team to ensure that the strategic goals of increasing intrinsic interoperability, federation, vendor diversification options, and business and technology domain alignment [REF-1] are well understood by all parties involved, so that the benefits can be successfully achieved. At the inception of an SOA adoption, there may be a number of IT teams that start exposing the system capabilities of the domains they support as services. These may simply be components such as EJBs, or better yet, as Web services that are described by a Web Service Definition Language (WSDL) file. It is important to note that SOA adoption is not instantaneous. It may be that your particular organization will need to implement service-oriented architecture at the domain level rather than at the enterprise level, before working towards a target architecture. You can consider formalizing SOA governance by taking into account both design-time and runtime governance. This can be achieved by using a service repository that manages service governance through a service lifecycle workflow process. The individuals participating in the SOA governance activities should have clearly defined roles and responsibilities. Please refer to Table 1 for a high-level set of suggested roles and responsibilities, which can be tailored to your organization’s specific needs.

ROLE Service Provider Prime (Designer and Technical Owner of a Service)

RESPONSIBILITIES design data domain schemas design service contract interface work with development team to ensure that the requirements specified in the Service Contract are met work with the SOA Governance Prime to ensure adherence to SOA design guidelines

Service Consumer Prime SOA Governance Prime

approve service acquisition requests from service consumers formally acquire a service through a service repository system articulate changes, SLAs to service producers. maintain and publish SOA design guidelines for the IT staff to ensure consistent service design-time quality maintain and publish SOA policies to be applied to the service assets in your organization approve service submissions

approve service acquisitions SOA Quality Assurance maintain and execute test cases that validate the services submitted into the Prime SOA service repository SOA Infrastructure and maintain and support the operational integrity of the SOA infrastructure, Support Management Prime including service managers, load balancers, internal and external gateways, and physical endpoints residing on Weblogic, Websphere, JBoss, and so forth Table 1 – Some suggested roles and responsibilities for service governance and management.


6



Once your organization has a framework by which proper SOA governance can be executed, I suggest that the SOA Governance team, with participation from service domain owners as led by technical leads such as the service provider prime, assess the current state of services in the organization. For this, we can look at industry standards in order to classify service capabilities into categories of business processes. The TeleManagementForum (TMForum) in the telecommunications industry publishes The Application Framework (TAM) [REF-6] and the Shared Information Data Model (SID) [REF-7], which can be used as a reference service model taxonomy for helping to assign a category to an existing service or component and/or a newly designed service. In addition to specific industry standards, you may choose to use a maturity model to assess the current state of where your organization is, in terms of service-oriented architecture. Consider how an industry-accepted taxonomy based upon TAM and SID can be tailored to categorize schema and service contract assets in a service inventory, as illustrated in Figure 1. Notice that the namespace has a root qualification that represents the organization, which in the example is “examplecomp.” The data domain assets are categorized under the data taxonomy tree, as shown on the left in Figure 1. The data domain taxonomy tree can hold multiple levels of classification. For usability, I recommend limiting it to two levels in order to keep the asset qualifier character length relatively manageable. The service taxonomy tree has a similar structure to that shown for the data taxonomy tree. However, the service taxonomy is focused on the classification of capabilities, whereas the data taxonomy is focused on the data in the messages passed in a service.


7



Figure 1 – A graphical representation of how an application and data taxonomy that are based on an industry standard, such as TAM/SID, can be used to categorize services in a company’s service inventory. In Figure 1, two data schemas named Customer_v1_0.xsd and Address_v1_0.xsd have been identified. There is also a service called CustomerMgmtSrc under /service/CustomerManagement/CustomerInfoMgmt that has a WSDL that imports the Customer and Address schemas to be used in defining the service contract for this service.


8



As an organization matures, one will see that the artifacts in each of the categories that have been defined for the data and service domains will grow in number. If this is done properly, with acceptance and buy-in from multiple participants in the organization, the organization will achieve SOA benefits through service discoverability, service reuse and service composability [REF-1]. A Practical Approach to SOA Maturity Models In their piece on maturity models, Rathfelder and Groenda describe a reference model for assessing SOA maturity called the Independent SOA Maturity Model (iSOAMM) [REF-3]. The iSOAMM suggests looking at five aspects or viewpoints of SOA maturity. These are Service Architecture, Infrastructure, Enterprise Structure, Service Development, and Governance. The Open Group has published The Open Group Service Integration Maturity Model (OSIMM) [REF-5], which specifies a model by which you can assess the maturity of service integration in an organization. OSIMM defines a set of dimensions representing the different views, such as business or architectural, of an organization. These dimensions are Business, Organization and Governance, Method, Application, Architecture, Information, and Infrastructure and Management. OSIMM also defines seven SOA maturity levels that can be applied against each dimension. These SOA maturity levels are Silo, Integrated, Componentized, Service, Composite Services, and Virtualized Service and Dynamically Re-Configurable Services. Let us consider a simplified approach to the assessment of SOA maturity. The proposed flowchart in the following figures can be considered against three major aspects, with the assumption that your organization has an appropriate governance model that is driven via an SOA lifecycle management suite, such as the ORACLE SOA Suite [REF-2] or SOA Software Governance Suite [REF-4]. The three aspects are the following: ■■ Business Analysis ■■ Design-Time ■■ Runtime At the outset of the assessment process, we can look at the three streams individually (Figure 2). We may have one set of individuals scrutinizing the business analysis aspect, a set of individuals scrutinizing the design-time analysis aspect and another set of individuals scrutinizing the runtime aspect. It is highly recommended that each set of analysts has a high degree of competency in the stream they are assessing, which may be through education, certification, experience or a combination of these criteria. The success of SOA practices is a reflection of the combined efforts of the participants, who need to have the appropriate skill set in order to ensure an effective execution of the SOA journey to achieve the relevant goals and reap the benefits. I encourage you to use the OSIMM as a reference for generating a checklist by which you can assess each aspect. Also include any additional checklist items that are relevant to your specific organizational needs. For the purpose of this article I am assuming that your organization has an SOA governance team already established. In order to assess the level of SOA governance that your organization practices, you may consider referencing the OSIMM’s Organization and Governance Dimension: Assessment Questions (p. 21) [REF-5]. For business analysis, consider referring to OSIMM’s Business Dimension: Assessment Questions. For design-time, I recommend that you consider a number of dimension assessment questions that are described in Method Dimension: Assessment Questions, Application Dimension: Assessment Questions, Architecture


9



Dimension: Assessment Questions, and Information Dimension: Assessment Questions [REF-5]. Lastly, for runtime, I recommend that you consider Infrastructure and Management Dimension: Assessment Questions [REF-5].

Figure 2 – A proposed process flow (entry) for an SOA Maturity Assessment. Let us walk through a proposed method for the business analysis aspect, as illustrated in Figure 3. Determine whether business processes are documented across the enterprise, depending on the formal documentation processes in your organization. Any form of documentation that is sourced from a business primeship that articulates how they expect their business processes to be executed is a good starting point. If business process documentation exists, determine whether the documentation is isolated to a business silo or whether it is integrated with the processes’ other business units in the organization use. If there is minimal to no business process documentation available, this fact should be captured and communicated to management that the organization will be challenged to move forward in achieving a higher level of SOA maturity, from a business process perspective. If the business organization works in a way where all or most of the business groups integrate their business processes with each other, then the organization is classified as having an Integrated SOA maturity level from a business perspective. For the basic integrated maturity level, each respective group has its own processes and process components, and integration occurs at the periphery of the processes as a group for a specific business unit. The next level of business SOA maturity, or the Componentized SOA maturity level, requires the business


10



groups/units to share business process components. For the last two maturity levels there is tight coupling of processes. In order to ensure that SOA strategic goals and benefits are achieved, we are encouraged to move the business into adopting a paradigm of producer and consumer business functional roles that mirrors what we want to expose from a services perspective within all of the IT system domains. The concept of producer/ consumer business functional roles corresponds to the Service SOA maturity level. Once the organization has reached a Service SOA maturity level with respect to the business aspect of the organization, the next level of SOA maturity is the Composite Services SOA maturity level. The beauty of composite services is that they are the ultimate representation of business processes, where the business is not burdened with understanding the specific technical details but rather focuses on the business processes exclusively. This can be achieved by having the business teams articulate business processes using a service orchestration notation such as Business Process Execution Language (BPEL). The BPEL artifacts can be translated into distinct business capabilities and mapped to business composite services that can orchestrate supporting domain services, which are managed by IT.


11



Figure 3 – A proposed process flow (business analysis aspect) for an SOA maturity assessment.


12



Let us now look at a method by which we can go through the design-time analysis aspect, as illustrated in Figure 4. Firstly, we should assess the inventory of IT components that exist in the organization to the best of our ability. If components are already being governed through an SOA governance platform, then some of the components can be discovered using the cataloging capability of the platform. For components that are not registered in a central repository, the exercise may be a bit more challenging. If possible, each IT subdomain-owning team should document its IT components and provide the list to the SOA governance team for assessment and registration. For the purpose of our discussion, we can group IT components into a number of categories. One category is the legacy components grouping that contains all of the legacy components that are not service-oriented, for example mainframe components, proprietary vendor system components, stand-alone programs written in C, stand-alone programs written in Java, EJBs, CORBA components, and so forth. A second category is the non-compliant components grouping, which contains all of the service components and has been designed in a bottom-up fashion for a specific business need without taking into account any SOA governance standards that exist in the organization. The third and ultimate category is the compliant components grouping, which contains all of the service components that have been designed using proper SOA design considerations and are compliant to the enterprise-defined SOA standards and guidelines. These service components will have standardized service contracts [REF-1] that are designed in a way that minimizes message transformation through service federation [REF-1] and has message structures that reference canonical schema assets, following the Schema Centralization Pattern [REF-1] and Domain Inventory Pattern [REF-1] that are applied to entity schemas.


13




14



The last aspect that we will consider in our assessment of SOA maturity is runtime analysis, as illustrated in Figure 5. The initial step is similar to the one in the design-time analysis, where we do an inventory of runtime IT components that are governed under a runtime governance platform such as the one found in the ORACLE SOA Suite [REF-2] or SOA Software Governance Suite [REF-4]. The inventory of IT components is categorized into a number of groupings categorized into stand-alone application components, integrated application components (non-SOA), common reusable infrastructure (such as an organization-wide API that can be packaged into a Java archive (JAR)), project-based components (SOA-compliant) and federated SOA components. The stand-alone components are assessed at a Silo SOA maturity level. The integrated application components are non-SOA components and are assessed at an Integrated SOA maturity level. The common reusable infrastructure, such as a shared API (a layer that may abstract low-level programmatic components) can be assessed at a Componentized SOA maturity level. As the organization moves into a more mature integration environment, we can observe that project-based components that follow SOA standards and guidelines begin to get registered into the IT infrastructure. These components are considered to be classified at a Services maturity level. Once the Services maturity level has been reached, the organization, which has been using activities and assets coming out of the business aspect such as formalized business process documentation, will be in a position to produce business services that are classified at the Composite Services SOA maturity level.


15



Figure 5 – A proposed process flow (runtime aspect) for an SOA maturity assessment.


16



What Next? After you have completed the SOA maturity assessment of your organization, review the outcome of the analysis of each aspect of SOA maturity that we have discussed, namely, business, design-time, and runtime. You will most likely have different levels of SOA maturity across the analyzed aspects. The next step is to articulate and document a formalized plan by which your organization can move to the next level of SOA maturity for each aspect, and through doing so have alignment across these aspects. For a heightened understanding of what you should be looking for when moving your organization to a higher SOA maturity level, review the SOA strategic goals and benefits as articulated by Thomas Erl [REF-1], a listing of which is provided for your convenience in Table 2. I encourage you to review the material further for your own understanding. STRATEGIC GOAL/ BENEFIT Increased Intrinsic Interoperability [Strategic Goal] Increased Federation [Strategic Goal] Increased Vendor Diversity Options [Strategic Goal] Increased Business and Technology Alignment [Strategic Goal] Increased ROI [Strategic Goal and Benefit] Increased Organizational Agility [Strategic Goal and Benefit]

DEFINITION Services within a given boundary are designed to be naturally compatible so that they can be effectively assembled and reconfigured in response to changing business requirements. Services establish a uniform contract layer that hides underlying disparity, allowing them to be individually governed and evolve. The ability an organization has to pick and choose “best-of-breed” vendor products and technology innovations, and use them together within one enterprise. Some services are designed with a business-centric functional context, allowing them to mirror and evolve with the business of the organization.

Most services are delivered and viewed as IT assets that are expected to provide repeated value that surpasses the cost of delivery and ownership. New and changing business requirements can be fulfilled more rapidly by establishing an environment in which solutions can be assembled or augmented with reduced effort, by leveraging the reusability and native interoperability of existing services. Reduced IT Burden The enterprise as a whole is streamlined as a result of the previously described [Strategic Goal and Benefit] goals and benefits, allowing IT itself to better support the organization by providing more value with less cost and less overall burden. Table 2 – A list of service-oriented architecture strategic goals and benefits, as sourced from Thomas Erl’s SOA Principles of Service Design [REF-1]. Conclusion There is a definite benefit to performing an SOA maturity assessment. In keeping with the spirit of SOA strategic goals and benefits [REF-1], we can determine where our organization stands with respect to the kind of business and system integration that exists therein. Establishing SOA governance, applying SOA patterns that follow from SOA principles [REF-1], using industry standards to establish an appropriate data and service asset taxonomy, and implementing a reference SOA maturity model such as OSIMM [REF-5] can help elevate SOA maturity with respect to integration across business and IT system capabilities. Through the formalized


17



plan that comes out of such an assessment, we can work with IT and business team stakeholders to work towards a better integration environment. Good luck in your SOA assessment efforts! References [REF-1] Erl, Thomas. SOA Principles of Service Design. Toronto: Prentice Hall, 2008. [REF-2] ORACLE. Right from the Start: SOA Lifecycle Governance. (2010) http://www.oracle.com/us/dm/ h2fy11/right-from-the-start-soa-194191.pdf [REF-3] Rathfelder, C. and Groenda, H. 2008. iSOAMM: An Independent SOA Maturity Model. Distributed Applications and Interoperable Systems Lecture Notes in Computer Science Volume 5053: 1-15. [REF-4] SOA Software. Integrated SOA Governance. (2013) http://www.soa.com/solutions/integrated_soa_ governance [REF-5] The Open Group. The Open Group Service Integration Maturity Model (OSIMM), Version 2. Berkshire, UK: The Open Group, 2011. [REF-6] TM Forum. Application Framework (TAM) Concepts and Principles, GB929-CP. (2012) http://www. tmforum.org/DownloadRelease125/14239/home.html [REF-7] TM Forum. Information Framework (SID), GB922 0-P, TM Forum Approved Version 1.6. (2011) http:// www.tmforum.org/DownloadRelease125/14240/home.html


18


Cloud Architect Certification Self-Study Kit Bundles Now Available and Shipping Worldwide

www.cloudschool.com/certifications/architect

CloudSchool.com CLOUD CERTIFIED

Architect

Arcitura the IT education company


A Methodological Approach to Entity Service Modeling by Marco Fränkel, SOA Architect, Xebia B.V. Abstract: 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 [REF-1]. 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 [REF-2]. This article describes a practical method to prevent its occurrence, using a real-life case study. Introduction 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 [REF-3]. 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 [REF1]. 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 serviceorientation. It may also take up a lot of time, especially when the supporting business process documentation is not up to par and the analysts need to gather additional information first. In such cases the project members may decide to drop this method altogether in lieu of following their instinct, all in the name of “getting things done fast.” During my assignment at the Dutch Chamber of Commerce, I came up with a method for modeling entity service candidates based on a list of functional requirements. It can be used as an alternative to the aforementioned “business process definition decomposition” method when there is insufficient time for the topdown approach, and/or when it’s clear that the resulting service has a very distinct functionality so there is no or little risk of denormalized services. Additionally, the fact that it can provide quick results makes it a good fit to the SCRUM-driven approach used by a lot of IT companies these days. Finally, it can be performed by analysts and architects that are less experienced when it comes to modeling services. I’ll start the article first by describing the method. After that, I’ll dive into the case and the way the method was applied to solve the problem it represents. I’ll end by looking a little bit beyond the base method.


20



Description of the Method The method I am proposing consists of five straightforward steps:

Figure 1 - The five steps of the method are shown. 1. Gather Concrete Requirements The functional requirements are collected and, if possible and/or necessary, completed. It is best for the requirements to be as specific as possible. 2. Define Abstract Requirements In this step the gathered concrete requirements should be rewritten into more abstract requirements. It might very well be possible that two or more concrete requirements will result in the same abstract requirement. 3. Extrapolate Abstract Requirements Based on the abstract requirements, a number of binary choices can be deduced. All possible combinations are listed in a matrix and checked for validity. Invalid combinations are removed from the list. 4. Define Capabilities By first normalizing and then denormalizing the leftover combinations, the capabilities of the service candidate can be defined. 5. Validate Results As a final step, the service candidate can be validated against the original requirements. Also, if more requirements came up during the process, they can be used to validate if the service candidate is indeed future proof. Case Background The method has been tried and tested in an actual project that had the goal of helping customers find a company name unique to the branch they’re in, using so-called ISIC records. The International Standard Industrial Classification of All Economic Activities (ISIC) is a United Nations system for classifying economic data [REF-4] that can be applied to assign a specific class to a company. Each class furthermore belongs to a specific group, each group to a specific division and each division to a specific section. The records themselves are stored in a local database table, containing only the fields named ISIC Code, Description, Registration Date, Start Date and End Date. Before I joined the project, it was decided that this data should be retrieved by applications through a Web service with a single operation. This operation would make it possible to select one or more elements using the input message described in the following XSD (List 1):


21



List 1 – The original input message definition. This is a typical example of contract-to-logic coupling, as the XSD was derived from existing solution logic. The situation threatened to worsen when there was talk about a possible database schema alteration and the fact that the XSD would also be required to change. Fortunately by then, the project functional analyst had come to the conclusion that there might be a better way and asked me to step in. I studied the problem and came up with a suitable method after some back-and-forth discussions with the team. The next paragraphs describe how that method was applied when working on the case in question. 1. Gather Concrete Requirements The following requirements were known at the time the project commenced: 1. It should be possible to request a specific element based on an ISIC code. -- i.e.: select a section, filter on only sections in response 2. It should be possible to request a list of all sections/divisions/groups/classes. -- i.e.: select everything, filter on only sections in response


22



1. It should be possible to request a list with a combination of all sections/divisions/groups or classes. -- i.e.: select everything, filter on only sections and classes in response 2. It should be possible to request a list of classes based on a supplied section-, division- or group code. -- i.e.: select a section, filter on only classes in response It should be possible to take historical data (expired codes) into account for all requests. 2. Define Abstract Requirements The concrete requirements can be rewritten as follows: 1. It should be possible to request a homogeneous element using a code. 2. It should be possible to request a list of homogeneous elements without using a code. 3. It should be possible to request a list of heterogeneous elements without using a code. 4. It should be possible to request a list of homogeneous elements using a code. It should be possible to take history in account. Several comments on these requirements are as follows: ■■ A code can be a class, group, division or section code. ■■ A result can consist of either a single element or a list of elements. ■■ An element/list of elements can be homogeneous, where information about only one type of element is returned. -- This doesn’t have to be the type of the requested element per se. Based on the division code, the descriptions of all underlying classes can be requested at once. ■■ An element/list of elements can be heterogeneous, meaning information about multiple types of elements is returned. -- i.e.: based on a certain division code, the descriptions of all underlying groups and classes can be requested at once ■■ Sending a request without using a code is equal to selecting all elements. -- a list of elements is effectively selected, and it is not possible to select a single element without using a code ■■ Sending a request using a code is equal to selecting a single element. -- it is not possible to select a list of elements using a code, although it is possible to select a list of subelements Selecting versus Requesting During the development of this method, it became clear that the presence of the indicators made defining the possible capabilities a tad harder. This because they can influence the result in such a way that the original request is hard to determine. That’s why the focus is on which elements can be selected, and not which elements can be requested.


23



The relationship between these can be described as follows: the correct information can be requested by selecting one or more elements, and then filtered using the indicators. For example, it is possible to request type A (i.e. a list of classes) by selecting type B (i.e. a group) and applying the correct filtering. 3. Extrapolate Abstract Requirements ■■ The following binary choices can be deduced from the previous list: ■■ supplying a code (yes or no) ■■ selecting an element (single or a list) ■■ composition of the elements (homogeneous or heterogeneous) ■■ history (yes or no) This leads to 24 = 16 possible combinations, as shown in Table 1 (red is an invalid combination, green is valid).

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Code no no no no no no no no yes yes yes yes yes yes Yes yes

Singular / List singular singular singular singular list list list list singular singular singular singular list list list list

Homogeneous / Heterogeneous homogeneous homogeneous heterogeneous heterogeneous homogeneous homogeneous heterogeneous heterogeneous homogeneous homogeneous heterogeneous heterogeneous homogeneous homogeneous heterogeneous heterogeneous

History yes no yes no yes no yes no yes no yes no yes no yes no

Table 1 – The 16 derived combinations are shown. The combinations are validated against the previously stated comments. It is not possible to select a singular element without using a code, making 1-4 invalid. It is also not possible to select a list using a code, making 13-16 invalid. This leaves eight possible valid combinations, which can be translated into the following requirements:


24



■■ It should be possible to select a list of homogeneous elements without using a code, including historical data (5). ■■ It should be possible to select a list of homogeneous elements without using a code, excluding historical data (6). ■■ It should be possible to select a list of heterogeneous elements without using a code, including historical data (7). ■■ It should be possible to select a list of heterogeneous elements without using a code, excluding historical data (8). ■■ It should be possible to select a single homogeneous element using a code, including historical data (9). ■■ It should be possible to select a single homogeneous element using a code, excluding historical data (10). ■■ It should be possible to select a single heterogeneous element using a code, including historical data (11). ■■ It should be possible to select a single heterogeneous element using a code, excluding historical data (12). 4. Define Capabilities In principle, all of the possible requests can be based directly on these eight valid requirements. Note that the practice of normalizing before denormalizing achieves several additional benefits. Table 2 lists the valid combinations: 5 6 7 8 9 10 11 12

Code no no no no yes yes yes yes

Singular / List list list list list singular singular singular singular

Heterogeneous / Homogeneous homogeneous homogeneous heterogeneous heterogeneous homogeneous homogeneous heterogeneous heterogeneous

History yes no yes no yes no yes no

Table 2 - The 8 valid combinations. Two things can be concluded: 1. History doesn’t play a role (both options are always valid). -- Combinations 6 (same as 5), 8 (same as 7), 10 (same as 9) and 12 (same as 11) can be removed. 2. The composition of the elements does not play a role (both options are always valid). -- Combinations 7 (same as 5) and 11 (same as 9) can be removed.


25



The following combinations are leftover: 5 9

Code no 9

Singular / List list yes

Heterogeneous / Homogeneous homogeneous singular

History yes homogeneous

Table 3 – The resulting combinations after normalization are listed. The two combinations can be translated into the next capabilities: ■■ selectElements – select a list of elements without using a code ■■ selectElement – select a singular element using a code There are several ways of declaring the type of element that should be selected when composing the selectElement capability. One solution is to have all four code parameters as part of the input message (List 1), but always having only one used. Another possibility is to have just one code parameter and then derive the correct type from its value, or to add an extra “type” parameter. A more elegant solution, however, is to have separate capabilities per code type to produce the candidate service (Figure 2):

Figure 2 – The resulting service candidate.


26



5. Validate Results There are a number of examples on how to use this service at the end of this article. The following table shows how to map the original requirements to those examples (Table 4):

Requirement It should be possible to request a specific element based on an SBI code. It should be possible to request a list of all sections/divisions/ groups/classes. It should be possible to request a list with a combination of all sections/divisions/groups or classes. It should be possible to request a list of classes based on a supplied section-, division- or group code. It should be possible to take historical data (expired codes) into account for all requests.

Examples selectSection (1), selectDivision (1), selectGroup (1), selectClass (1) selectElements (2) selectElements (1), selectElements (3) selectSection (3), selectDivision (3), selectGroup (3) Not included in examples.

Table 4 – The mapping of the original requirements to the solution. A number of supplementary requirements came up during the project. Instead of adding these to the list of original requirements, it was decided to use them as a validation mechanism.

Requirement It should be possible to request a list of divisions/ groups or classes based on a supplied section-, division- or group code. It should be possible to request a list with a combination of divisions/groups and/or classes based on a supplied section-, division- or group code.

Examples selectSection (3), selectDivision (3), selectGroup (3) selectSection (2), selectDivision (2), selectGroup (2)

Table 5 – The mapping of additional requirements to the solution. This leads to the conclusion that the aformentioned service candidate is future proof.

Dealing with Restrictions During the project a number of restrictions that should not have been possible surfaced. Taking these into account can lead to a situation in which the scope of the service interface would be too limited when such restrictions loosened up later on. As long as it doesn’t concern specific business logic, it is best to implement this kind of restrictions client-side. Another solution is to regulate by filtering the output-messages.


27



Room for Future Adjustments It may later become apparent that the five capabilities do not provide enough direction, meaning that it will not always be clear how to retrieve a list of classes per section. In those cases, the set of capabilities can be extended based on the next possibilities: ■■ request all elements of a certain type from the complete table ■■ request all elements of a certain type from the parent collection ■■ request a specific element of a certain type This results in two specific capabilities to request a section, three to request a division, four to request a group and even five capabilities to request a class, resulting in a total of 14 capabilities. The service can be split into four services (one for each type) using the Service Decomposition pattern, to prevent it from becoming “topheavy” [REF-3].

Figure 3 – The additional service candidates are defined. Here the new services are responsible for “pre-filling” certain request parameters if necessary, and of course for composing the correct operations. Note that a number of variants are imaginable here. The 14 “new” capabilities can become part of the same service or even be added to the original ISIC service. The choice should be based on matters such as maintainability, versioning, and so forth.


28



Conclusion The method proposed in this article is still relatively immature, but it has already delivered results that are much more in-line with the Service Reusability and Service Loose Coupling principles than the standard method, or rather lack thereof, that so many SOA projects seem to use. The method may not be as extensive as the “business process definition decomposition” method described by Erl, but on the plus side it does have a lower difficulty threshold and will especially shine in the cases in which the bottom-up service delivery strategy is applied. It can also act as an extension to Erl’s method during the “apply service-orientation” step by providing a good way to improve the reusability of entity service candidates. The method will probably be less suitable when it comes to modeling utility services, given that their functional context is difficult to determine. It also won’t work for task services, as their non-agnostic nature conflicts with the general idea behind this method. References [REF-1] Erl, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design. Toronto: Prentice Hall, 2005. [REF-2] Erl, Thomas. SOA Principles of Service Design. Toronto: Prentice Hall, 2008. [REF-3] Erl, Thomas. SOA Design Patterns. Toronto: Prentice Hall, 2008. [REF-4] United Nations Statistics Division – Classification Registry: http://unstats.un.org/unsd/cr/registry/regcst. asp?Cl=27 Acknowledgements I wish to thank my colleagues Maurits Rijk and Gero Vermaas for reviewing my article, and Gerbrand van der Vooren for being my soundboard when I was developing the method.


29


N EW

Cloud Certified Virtualization Specialist CloudSchool.com CLOUD CERTIFIED Virtualization Specialist

Arcitura Education Inc. has announced a new certification for the Cloud Certified Professional (CCP) program from CloudSchool.com, dedicated to cloud computing-based virtualization technology and practices. The new Certified Cloud Virtualization Specialist designation requires the completion of Prometric

CCP Module 16: Fundamental Cloud Virtualization Core topic areas pertaining to the fundamental virtualization mechanisms and types used within contemporary cloud computing platforms.

CCP Module 17: Advanced Cloud Virtualization A range of specialized and advanced topics that build upon module 16 to explore virtualization-related reliability, performance and integration, as well as combinations of mechanisms.

exams C90.01, C90.02, C90.16, C90.17 and C90.18. This certification track correspondingly introduces three new CCP courses and self-study kits.

CCP Module 18: Cloud Virtualization Lab A hands-on lab during which participants apply the models, concepts, and techniques covered in previous courses, in order to complete a series of complex exercises.

Workshops & Self-Study Attend an instructor-led workshop or purchase the official Cloud Virtualization Specialist Certification Self-Study Kit Bundle.



Canonizing a Language for Architecture: An SOA Service Category Matrixe by Jürgen Kress, Oracle, Speaker, Author, Hajo Normann, Oracle ACE Director, Danilo Schmiedel, Senior Consultant, Optiz Consulting, Guido Schmutz, Technology Manager, Trivadis, Bernd Trops, Senior Principal Consultant, Talend Inc., Clemens Utschig-Utschig, Chief Architect, Shared Service Centre, Global Business Services, Boehringer Ingelheim, Torsten Winterberg, Business Developement and Innovation, Optiz Consulting, and Berthold Maier, Enterprise Architect, T-Systems International department of Telekom Germany 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.


31



Public Service

■■ Business Service ■■ Purely businessrelated interface ■■ Facade of implementation (Private Services) ■■ Public Business Services are an Enterprise-SOA governance dimension that manages crossapplication lifecycle rules and interface design

Category Business Process Service (BPS)

External View ■■ business models ■■ process models

Business Activity Service (BAS)

Business Rule Service (BRS)

■■ validation or decision rules

Calls ■■ BPS ■■ BAS ■■ BRS

■■ responsible for governance ■■ responsible ■■ context-specific to important ■■ composite business or controller events over additional business services process step use case

■■ single-view ■■ Exchange data only Business of data and Entity Service in canonical format, functionality of (BES) etc. one entity

Private Service

Internal View executable business process

■■ not contextspecific

■■ BPS ■■ BAS ■■ BES ■■ BRS ■■ Private Service ■■ Private Service

■■ reusable ■■ atomic ■■ implementation in a rules engine

■■ Private Service

Utility Service ■■ the technical functionality used across several services Public services are implemented using private services. Private ■■ no assignment to business and utility Services are a subset of Public Services and often as exposed logic by existing applications. For public services, the language or application they are realized in does not matter. It is key to ■■ local/applicationsrelated governance standardize their interface description. Private services have little to no local life-cycle governance. Examples: Right-click-Java_Service, Controller-EJB, Siebel_ Customer_Service Figure 1 – The SOA Service Categorization Matrix.

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. Business Process Service (BPS)


32



A business process service (BPS) consists of the purely functional aspects of business processes. This type of service is based on process models that are written in languages like BPMN or with event-driven process chains (EPCs), before being translated into executable processes of different forms such as BPEL or BPMN 2.0 and used to orchestrate purely functional services. In other words, the functionality is determined on the functional side. Designers no longer need to tinker with the structure as they are now able to tweak the process skeleton, which can be automatically or manually generated. The designers can also enhance the structure with the technical details that are required for execution in the engine. For the sake of clarity, the business process steps and invoked services should outsource any deeper functional or technical details, such as transformations, into different data dialects. Organizations usually arrange business processes into a hierarchy in order to manage their complexity. A BPS is typically longrunning, as differentiated from use case controller, and often incorporates user interaction via workflow functionality. In order to achieve the loose coupling and flexibility that is promised by BPM, using functional terms to characterize only what a process does and not how it is performed is critical during the process design. The “how” is covered in the implementation of the process steps, which may have multiple alternatives. BPSs exclusively focus on the functional aspects. Technical aspects such as the data transformations into and out of the canonical model should be outsourced to the integration logic, so that BPSs can deal exclusively with data defined by the canonical service data model. Changes to the process should be made in the business model, and the link between the business model and the more technical implementation should be maintained as closely as possible. Business Activity Service (BAS) A business activity service (BAS) responds to functionally relevant business events and encapsulates contextspecific controller logic. The context of a BAS may be the process step of a business process or the use-case controller of an application. A BAS works on more generic and basic services, such as business entity services (BES) and business rules services (BRS). As part of a BPM project, however, a BAS may also invoke a business process service (BPS). This ensures that each process step is mapped to a BAS, the implementation of which may consist of anything from simple service calls to complex processes. The design of a business activity service often contains a composite service that calls more than one servicetypically a BES or another BAS. . BASs also include a wrapper or functionality extension that enhances services (usually generic BESs) with context-specific logic (usually a set of business rules). Business logic that is not context specific should be associated to the BES that manages the related data. This decision depends on whether or not it is context-specific, meaning it was designed for a specific use case (BAS) as opposed to general all-purpose (BES). BASs are usually created in an ESB, which is where XSLT-based mappings between the required data types are organized. BPEL is used to orchestrate more complex scenarios while ESBs are used to route or allocate BPEL processes.


33



Figiure 2 - Business activity services assemble functions and data. Recommended Naming Convention: Start with a verb that describes the activity, then the noun that the verb is acting upon, and end with the category abbreviation “BAS.” Example: ■■ checkIfGoodCustomerBAS (via a rule in a Rule Engine) ■■ determineProductsAndPricesBAS (via the Product and Price systems) ■■ writeInvoiceBAS (via the Invoice System) ■■ createMessageToCustomerBAS (via NotificationService) The implementation paths that are enclosed in parentheses in each example are categorized as “private services” in the following sections.


34



Business Entity Service (BES) The business entity service (BES) encapsulates the data and functionality that are related to a logical business entity, such as a customer or contract, in a specific context that is either across the organization or specific to a domain, subdomain, or department. BESs are core services on the entity level that are as loosely coupled as possible. Important definitions that are often discussed in projects include the fact that BESs always encapsulate an entity, meaning composite entities like “Contract” are BASs. Even though many SOA architects prefer using a BAS over a BES containing complex logic so that the complexity can be bypassed, we prefer using the latter option. A service should be defined based on its externally perceivable interface and not based on its implementation. This decision takes into account the fact that a service agreement not only constitutes exchanged data but runtime behavior as well. If BESs were defined in a taxonomy as “stateless and short-term,” that would lead to longer-term operations being moved from a BES to a BAS. Recommended Naming Convention: Start with a noun that functionally describes the entity, followed by the category abbreviation “BES.” Example: CustomerBES Discussion: Context in BES Leads to BAS Business entity services often have operations whose behavior is determined by the entity’s current status. Depending on the circumstances, it may be useful to outsource the context-specific functionalities to individual BASs that can work with static and even more basic entities. For example, consider a context-specific “CustomerUponSaleBAS” that carries out work for the generic “CustomerBES.” This is how the BAS’s nature as a facade for context takes shape. The data and functions of entity services are based on one or more sources that can come in the form of applications or individual components. Business logic that is tightly connected with the entity and therefore not strongly context-related can be merged with an entity service. Highly complex entities that have a variety of operations can themselves be subdivided into individual and coherent entity services. The criterion of coherence is essential since the context, data, and functionality within each entity belong together. Discussion: Master Data Management (MDM) and BES MDM needs to be associated with entities that are encapsulated by a BES. Transactional operations such as “write” can lead to longer runtimes for BESs, especially if the writing operation requires user interaction. The alternative would be to raise BES operations to the business process level.


35



Figure 3 - MDM that is encapsulated as a BES. Discussion: Designing Context-Specific Finder Operations Since one of the main functions of the BES is to perform searches, a possibility would be to outsource the filters above the call to the BES. The BES would return an entire business object that is re-filtered using the search criteria to deliver the exact data needed for a specific context. Another alternative would be for the BES to provide a wide range of precisely defined search/find operations for each search context. Both options, however, would overload the contract and increase the effort required for governance, which burdens the service lifecycle with the high rate of change. A recommended design as a solution for overloading is for the BES to define a generic finder method, which exposes the types in XML format. The fields to be returned when calling the method can be defined as a “find criteria” object, which can be removed at runtime.


36



Business Rule Service (BRS) Business rule services encapsulate decisions in a decision tree, such as “If ‘Good Customer,’ then...”, as well as validations that are often used as preconditions for a function. Validations ensure that the data is in the correct state and context-specific when required, such as “Customer data is correct.” Recommended Naming Convention: Use a meaningful name that expresses the result of the rule, followed by the abbreviation “BRS.” Example: “calculateWhetherGoodCustomerBPS” Public Services versus Private Services Defining the concepts of loose coupling and “separation of concerns” in terms of SOA necessitates differentiating between “public” and “private” services on a higher level of abstraction, to maintain a division between the service contract and implementation. This distinction clarifies how existing functionality can be incorporated into public, reusable, and loosely coupled services. Object-oriented programming distinguishes between the concepts of “private” and “public” to define the visibility and scope of objects and methods. A private method or property is a detail that is related to implementation and not externally visible, while the public method is an interface that can be accessed and usually used as well. Definition of a Public Service Public services are constructed over the functional interface as a facade over the implementation. The implementation can be any number of private services. Public services are therefore entirely motivated by the customer’s needs and functional perception. They are also strictly implementation-neutral, as their interface only deals with behavior that can be seen externally so that implementation details are not exposed. A BES that internally accesses the database on the private and utility service levels can provide functional data without externally propagating any of the technical details, such as DB keys. Public services are designed to allow for service reuse, which requires the service to be as minimally context or status-specific as possible. This enables reuse in a maximum range of contexts, although each service type corresponds to a different degree of context dependence. Business activity services are therefore significantly more context-specific than business entity services. Public services only exchange data in the canonical data format and are categorized as “public services” in (UDDI) service registries. These services also provide their entire functionality to operations as a contiguous set that is logically coherent with the respective concept. The public service is categorized according to the service taxonomy as either a business process service (BPS), business activity service (BAS), business entity service (BES), or business rule service (BRS). For example, a public service operation that checks for customer creditworthiness receives customer data that it uses to verify whether or not the customer is creditworthy. The module calling the service should not be able to view its method of implementation, regardless of whether a complex workflow that evaluates the applicant’s property is followed or a third-party credit rating service engaged. The advantage provided by this method is that the form of implementation can be replaced without affecting the customer, as long as the WSDL remains stable.


37



Treating Context-Specific Logic and Impacts on Service Lifecycle Management Large sections of context-specific logic, such as use-case controller logic and data format mappings, should not be stored within public services. If this rule is violated, the service layer will have a high level of dependency on all of the specific contexts, making public services much more difficult to reuse. Front-end controllers accurately encapsulate these aspects and call up generic BASs. Extensions and changes to service contracts resulting from new contexts, such as a new Web portal, should be conducted using public services through a strict governance regime that regulates the service lifecycle. The logic for roles and rights should be kept in a central entitlement component that is accessible to services, frontends, and back-ends. The Language Fluency of Public Services Public services are typically defined using a WSDL, which contains types for each operation that is defined using XML schemas. Some consumers, however, speak other languages like comma-separated values (CSV) and even Cobol. The translation into these languages may need to be outsourced to special adapters that translate on top of the public services, since the service contract cannot be overburdened. This option, however, would bloat the architecture again. Another solution is for the ESB to support the appropriate bindings into these languages, so that the service contract with the WSDL and associated XML schemas can remain as-is. The defined operation can be tied in with a CSV, Cobol, or another language’s binding that is configured in the ESB. Summary: Benefits of Service Categorization Once a common language has been created, services can be placed into each category in order to facilitate intercommunication. Differentiating between public and private services simplifies the creation of the services that are entirely functionally motivated and can come together to build a modular library of services. Focusing on behavior that is visible from the outside inherently leads to loose coupling, along with services whose implementation elements can be replaced without impacting consumers. Implementing these steps means that flexibility in executable business processes can finally be achieved, as categorization into BPS, BAS, BES, and BRS helps lend structure to services. Calls to services become part of a meta-concept that facilitates a better understanding of the service functions. A service call sequence can be easily read, such as when a “CarRentalBPS” calls a “calculateRentalFeeBAS.” This service then uses “returnCustomerConditionsBES” and “returnBillingAddressBES,” which respectively implement functionality from the “CarRentalSystem” and “InvoiceSystem.” Evaluations and reports that provide information on the numbers and reusability for each type of service can be generated for the public business services that have been properly registered. These reports also help simplify the billing process, as fees can be charged based on reported service usage. Conclusion: Takeaway Implementation teams can efficiently design reusable services by adhering to a system of clearly defined service categories. Service categorization is the first step towards integrated governance and should be embedded in the project design guidelines. Although not every SOA project requires BPS, BAS, or BES, differentiating between public services and private services remains essential.


38



Links and Literature D. Krafzig, K. Banke, and D. Slama. Enterprise SOA: Service-Oriented Architecture Best Practices. Toronto: Prentice Hall, 2004.


39


SOA with REST

Principles, Patterns & Constraints for Building Enterprise Solutions with REST “An inspirational book that provides deep insight into the design and development of next-generation service-oriented systems based on the use of REST. This book clarifies the convergence of SOA and REST with no-nonsense content that addresses common questions and issues head-on. An essential ‘instrument of modern service implementation’ and a powerful body of knowledge for software designers, architects and consultants.”

Pethuru Raj PhD,

Enterprise Architecture Consultant, Wipro Consulting Services

“This book illuminates the connection of the two domains - SOA and REST - in a manner that is concrete and practical, providing concise application to every day architectural challenges. Fantastic!”

Ryan Frazier,

Technology Strategist, Microsoft Corp.

The “SOA with REST: Principles, Patterns &

TABLE OF CONTENTS

Constraints for Building Enterprise Solutions

Chapter 1. Introduction Chapter 2. Case Study Background

with REST” book has just been released. This is the eighth published book, as part of the recently rebranded, Prentice Hall Service Technology Series. The book authored by Thomas Erl, Benjamin Carlyle, Cesare Pautasso and Raj Balasubramanian was officially launched at the 5th International SOA, Cloud + Service Technology Symposium.

To learn more about this book, visit: www.servicetechbooks.com/rest

PART I: FUNDAMENTALS Chapter 3. Introduction to Services Chapter 4. SOA Terminology and Concepts Chapter 5. REST Design Constraints and Goals PART II: RESTFUL SERVICE-ORIENTATION Chapter 6. Service Contracts with REST Chapter 7. Service-Orientation and REST PART III: SERVICE-ORIENTED ANALYSIS AND DESIGN WITH REST Chapter 8. Mainstream SOA Methodology Chapter 9. Analysis and Service Modeling with REST Chapter 10. Service-Oriented Design with REST PART IV: SERVICE COMPOSITION WITH REST Chapter 11. Fundamental Service Composition with REST

Chapter 12. Advanced Service Composition with REST Chapter 13. Service Composition with REST Case Study PART V: SUPPLEMENTAL Chapter 14: Design Patterns for SOA with REST Chapter 15: Service Versioning with REST Chapter 16: Uniform Contract Profiles APPENDICES A. Case Study Conclusion B. Industry Standards Supporting the Web C. REST Constraints Reference D. Service-Orientation Principles Reference E. SOA Design Patterns Reference F. State Concepts and Types G. The Annotated SOA Manifesto H. Additional Resources


On the Concept of Metadata Exchange in Cloud Services - Part II by Enrique Castro-Leon, Enterprise and Data Center Architect & Technology Strategist, Intel Corporation & Robert R. Harmon, Professor of Marketing and Technology Management, Portland State University 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.

Figure 1 - Initial state before cloud bursting (Source: Intel 2012)


41



Now assume that customer A1, currently running two virtual machines in the Intel host, requests that a third virtual machine be instantiated, as shown in Figure 2. Furthermore assume that under current policies there is no more room for virtual machines at the Intel host.

Figure 2 - The application receives a request to add a third virtual machine (Source: Intel 2012) The infrastructure manager orchestrating resources for the Intel application, which can be a service in its own right, makes a decision to outsource the hosting of the new virtual machine to an external IaaS provider and queries a resource broker, essentially a directory service. The broker returns a URL for the extended resource, a handle for the Telefónica data center provisioning API. The requester uses the handle to initiate a process to qualify and bind the Telefónica service to the application. At a higher level this orchestration can be accomplished through the OpenStack or the OCCI frameworks. Figure 3 shows some of the OpenStack Compute API (Nova API) calls. At a lower level these calls get mapped into Citrix Netscaler operations. Assume that as a matter of policy the application is compelled to compute the carbon footprint for all resources it touches, and through the Nova API it retrieves the Telefónica host metadata dictionary. After some parsing it extracts the power management object, listing the server’s power management features. In our proof-ofconcept this confirms the presence of Intel® Node Manager Technology and the access methods (API) to elicit these features. At this point the API can be bound to the power management policies already in effect, allowing operations such as calculating the energy expended by the operations performed on the Telefónica node.


42



Figure 3 - Current policy prevents new VM from being created at the Intel host. The Infrastructure Manager queries a broker for an external resource for a cloud bursting target. (Source: Intel 2012) The final configuration after the automated setup is shown in Figure 4.

Figure 4 - Physical host and virtual machine bound to originating service (Source: Intel 2012) When a number of services are connected in this manner to build a composite application, the result is a multicloud, and hence the moniker multi-cloud management.


43



Figure 5 - A Multi-Cloud Composite Application. (Source: Intel 2012) The multi-cloud handshaking process happens in this manner: An enterprise application monitoring the application’s performance senses in-house resources running short of an anticipated peak demand and goes through a third-party broker to identify a cloud provider to land the extra demand. The broker recommends the Telefónica service and goes through the provider/consumer setup described earlier. The choreography of this setup is fairly complex, facilitated by Citrix NetScaler VPX. In order to manage risk, Telefónica also balances in-house and subsidiary cloud providers. Some of these providers may be pure play providers, relying on IaaS providers for their infrastructure needs as shown in Figure 5. For each of the recursive provider/consumer relationships represented by the blue arrows in Figure 5, there is metadata flowing in the opposite direction, represented by the red arrows. Experimental Results Figure 6 depicts a management console running at an Intel lab in Folsom, California, represented by the Intel Data Center Manager (DCM) console, displaying a service metadata attribute, namely power management for a service running. The simulated service runs in a server installed at a lab in Madrid. After a cloud bursting handshake the remote server has been placed in the service consumer’s local subnet, and all the low level capabilities of that server are now available to the service consumer, including the IPMI-based API that DCM uses to access the firmware implemented Intel Node Manager capabilities for server power monitoring and for imposing power consumption limits.


44



Figure 6 - Folsom Management Console Displaying a Power Management Resource in Madrid. During the service negotiation the original enterprise cloud bursting requester has the option of requesting exclusive access to the hardware and can manage this hardware as if it were a local resource if the application demands it. Beyond that, the metadata exchange mechanism can in principle perform introspection on the service to identify all the intervening services to verify their reputation. Conversely, any service provider can advertise their presence and leverage their brand name. The “in principle” is an important qualifier. How much metadata is exposed is very much a business decision among the parties involved. Some providers will make their particular combination of services their secret sauce and choose not to disclose it, where others may decide that disclosing a complete portfolio is in their interest. Conversely, some service providers who want to make themselves known may require providers upstream to provide their identity as a condition for doing business. Conclusions The OpenStack effort has resulted in potential enhancements to OpenStack being identified, and in several research areas being identified for future collaboration. Further investigation is ongoing to identify a suitably scalable approach for secure metadata exchange that might be of interest to the OpenStack community. Economics is driving the adoption of the cloud, and within this context, the authors believe that economics will also drive the need for metadata. It is very likely that the metadata revolution that took place in consumer space social networks will take place in enterprise space in the next few years.


45



With the status quo and a one-size-fits-all strategy, a service product would be overprovisioned or too complex for customers with the lowest SLA requirements, resulting in higher OpEx, and there would be opportunity costs: customers not signing up because a service offering does not meet their requirements profile, being either under- or over-specified. The service metrics enabled by the availability of service metadata reduces uncertainty and adds predictability to service transactions, increasing the perceived value from the perspective of the service consumer, and enabling the service provider to offer more targeted, differentiated products. The geolocation example described in this article is only one example of new cloud service capabilities enabled by service metadata exchange. We will be reporting the outcomes of actual experiments in future publications. Another area that requires additional exploration is the security aspects of metadata exchange. Since the ability to advertise certain capabilities may determine whether or not a specific service gets hired, these decisions will have a revenue impact on service operators. Therefore the temptation exists for unscrupulous operators to alter metadata records. Hence it is necessary to implement methods to deter this potential tampering. An example could be service spoofing: a service operator may claim to be using a storage service from a highly regarded provider, when in reality the operator vectors storage functionality to a lower cost and presumably less reliable provider. Service metadata brings a needed degree of transparency in cloud transactions, a first step toward bringing predictable QoS that in turn will enable enforceable SLAs. This degree of unpredictability has been one of the main barriers toward cloud adoption in the industry. Metadata exchange depends on mutually agreed protocols between the contracting parties in order to work. To this end we are actively working with open source projects and open standards organizations to introduce and showcase such support into appropriate points in the cloud computing stack. The work reported here represents only the beginning of what we believe is a rich area for research, very relevant to cloud computing because of the revenue and cost implications to service providers and consumers alike. Platform power management features are being used in this project as a proof of feasibility for the metadata exchange. Support for metadata exchange is an optional component in a service offering. Service providers will support the capability if it’s in their interest, for instance if it helps in building a reputation with positive revenue impact. In any case, when a service provider chooses to expose certain metadata, the service consumer needs to have a reasonable assurance that the information is truthful. There are also technical motivations for metadata adoption: this framework can be extended into a general framework for a two-way auto-negotiation where a service consumer queries or imposes certain requirements on the service provider, for instance the type of hypervisor to be used in a service request. Areas to be further explored in the future are the concept of a metadata management infrastructure, whether brokered by third parties or as two-party exchanges such as the recursive aspects of metadata exchange and metadata filtering. We will report on these discoveries as data becomes available.


46



References [REF-1] Ganesan Shankaranarayanan, Adir Even, “The Metadata Enigma,” Comm. ACM, Vol. 49-2, February 2006. [REF-2] J. Wang, P. Varman, C. Xie, “Middleware Enabled Data Sharing on Cloud Storage Services,” Proc. ACM MW4SOC’10, Bangalore, November 29, 2010. [REF-3] Wikipedia, Metadata, Retrieved February 5, 2012 from http://en.wikipedia.org/wiki/Metadata. [REF-4] Dournaee, B., “Taking Control of the Cloud for your Enterprise,” Intel Corporation white paper, 2010. Retrieved from http://info.intel.com/rs/ intel/images/Taking_Control_of_the_Cloud.pdf. [REF-5] Harmon, R. R., Auseklis, N., “Sustainable IT Services: Assessing the Impact of Green Computing Practices,” PICMET 2009 Proceedings, IEEE, pp. 1707-1717, 2009. [REF-6] Kearney, K.T.; Torelli, F.; Kotsokalis, C.; “SLA: An abstract syntax for Service Level Agreements, Grid Computing (GRID),” 2010 11th IEEE/ ACM International Conference, pp. 217–224, 2010, http://www.sla4dgrid.de/sites/default/files/SLAWS_Grid-2010_SLAatSOI_Model.pdf [REF-7] Kennedy, J; Edmonds, A., Bayon, V., Cheevers, P. Lu, K., Stopar, M., Murn, D., “SLA-Enabled Infrastructure Management,” Chapter 7 in Service Level Agreements for Cloud Computing, Springer, 2011. [REF-8] E. Castro-Leon, E., He, J., Chang, M., Peiravi, P., The Business Value of Virtual Service Oriented Grids, Chapter 2, Intel Press, 2008. [REF-9] Open Cloud Computing Interface, Retrieved February 20, 2012 from http://occi-wg.org/. [REF-10] Linthicum, D.S., Cloud Computing and SOA Convergence in Your Enterprise, A Step-by-Step Guide, Addison-Wesley, 2010. [REF-11] Schmidt, R., “Perspectives for Moving Business Processes into the Cloud,” I. Bider et al. (Eds.), BPMDS 2010 and EMMSAD 2010, pp. 49–61, Springer-Verlag Berlin Heidelberg 2010. [REF-12] Schmidt, R., “A Service-System Based Identification of Meta-services for the Service-Oriented Enterprise Architecture,” Proc. 15th IEEE Int. Enterprise Distributed Object Computing Conference, pp. 293– 300, 2011. [REF-13] The W3C Incubator Activity. Retrieved February 20, 2012 from http://www.w3.org/2005/Incubator/ usdl/. [REF-14] Wolf, C., “Security and Compliance in the Cloud,” 2009. Retrieved February 5, 2012 from http://www. chriswolf.com/?p=230 [REF-15] Wolf, C., “The Cloud Mystery Machine: Metadata Standards,” 2010. Retrieved February 12, 2012 from http://www.chriswolf.com/?p=490 [REF-16] “The Future Internet Core Platform.” Retrieved February 20, 2012 from http://www.fi-ware.eu/. [REF-17] Verma, A., Venkataraman, S., Caesar, Campbell, R., “Efficient Metadata Management for Cloud Computing Applications,” Technical Report, University of Illinois, 2010. Retrieved from https://www.ideals. illinois. edu/handle/2142/14820 [REF-18] SLA@SOI Project Web Site in the European Union. Retrieved February 20, 2012 from http://www. sla-at-soi.eu.


47



[REF-19] Foundations for SLA Management – Evaluated Framework, SCLA@ SOI Deliverable D.A5a, Retrieved February 20, 2012 from http://sla-at-soi.eu/wp-content/uploads/2011/08/D.A5a-M38-SLAFoundations-and-Management.pdf. [REF-20] A Collection of Resources Relating to the SLA Model, SLA@SOI SourceForge Project Wiki. Retrieved February 20, 2012 from http://sourceforge.net/apps/trac/sla-at-soi/wiki/SlaModel. [REF-21] Coase, R. H., “The Nature of the Firm,” Economica, Vol. 4 No. 16. (Nov. 1937), pp. 386-405. [REF-22] Open Data Center Alliance Usage: Service Catalog, Open Data Center Alliance (2011)


48


Arcitura IT Certified Professionals (AITCP) Community

www.arcitura.com/community

Join the thousands of members of the growing international Arcitura community. Launched for the first time in mid-2011, Arcitura Education made official social media communities available via LinkedIn, Twitter, and Facebook. These new communities join the already existing memberships of LinkedIn, Twitter, and Facebook platforms for the Prentice Hall Service Technology Book Series from Thomas Erl and the International SOA, Cloud + Service Technology Symposium Series.


Contributors Enrique Castro-Leon Enrique Castro-Leon is an enterprise architect and technology strategist with Intel Corporation working on technology integration for highly efficient virtualized cloud data centers to emerging usage models for cloud computing. He is the lead author of two books, The Business Value of Virtual Service Grids: Strategic Insights for Enterprise Decision Makers and Creating the Infrastructure for Cloud Computing: An Essential Handbook for IT Professionals. He holds a BSEE degree from the University of Costa Rica, and M.S. degrees in Electrical Engineering and Computer Science, and a Ph.D. in Electrical Engineering from Purdue University. Contributions ■■ On the Concept of Metadata Exchange in Cloud Services - Part I ■■ Virtualized Cloud Power Management ■■ Client Virtualization in a Cloud Environment ■■ Cloud Computing Basics ■■ The Rise of Virtual Service Grids ■■ The Economics of Service-Orientation: Leveraging the Emerging Services Marketplace

Marco Fränkel Marco Fränkel is a SOASchool certified SOA Architect at Xebia B.V. in the Netherlands, and has almost 15 years professional experience as a software-developer and architect. For the past 3 years he has been assigned to the Dutch Chamber of Commerce, where he developed a SOA-based Integration Layer Framework and takes lead in the adoption of SOA as a methodology. Contributions ■■ A Methodological Approach to Entity Service Modeling


50



John M. Kennedy John Kennedy is a senior researcher in the Cloud and Services Lab of Intel Labs Europe. He is focusing on open standards and open source enablers to facilitate more dependable cloud computing. John is particularly active in Intel’s European research initiatives, engaging in collaborative research at local, national, and international levels. He has a B. Eng (hons) in Electronic Engineering and M. Sc. in Computing. John joined Intel in 1997 and has held roles of systems analyst, developer, solution architect, and applied researcher in Intel’s Manufacturing, IT, and Intel Labs organizations. Contributions ■■ On the Concept of Metadata Exchange in Cloud Services - Part I

Jürgen Kress An eleven year Oracle veteran, Jürgen works at EMEA Alliances and Channels. As the founder of the Oracle WebLogic and SOA Partner Community and the global Partner Advisory Councils. With more than 4,000 members from all over the world the SOA and WebLogic Partner Communities are the most successful and active communities at Oracle. Jürgen hosts the communities with monthly newsletters, webcasts and conferences. He hosts his Fusion Middleware Partner Community Forums, where more than 200 partners get the latest product updates, roadmap insights and hands-on trainings. Supplemented by many web 2.0 tools like twitter, discussion forums, online communities, blogs and wikis. For the SOA & Cloud Symposium by Thomas Erl Jürgen was a member of the steering board. He is also a frequent speaker at conferences like the SOA & BPM Integration Days, Oracle Open World or the JAX. Contributions ■■ Canonizing a Language for Architecture: An SOA Service Category Matrix ■■ Industrial SOA ■■ SOA Blueprint: A Toolbox for Architects


51



Berthold Maier Berthold Maier works in the T-Systems International department of Telekom Germany as Enterprise Architect. He has more than 19 years experience as developer, coach and architect in the area of building complex mission critical applications and integrations scenarios. Within eleven years as Oracle employee he has held several leading positions including chief architect in the consulting organization. Hi is the founder of many frameworks and take over the responsible for reference architectures around BPM/SOA and Enterprise Architecture Management. Berthold is also well-known as a conference speaker, book author and magazine writer. Contributions ■■ Canonizing a Language for Architecture: An SOA Service Category Matrix ■■ Industrial SOA ■■ SOA Blueprint: A Toolbox for Architects

Andrzej Parkitny Andrzej Parkitny is a SOA Enterprise Architect at TELUS. Andrzej has fourteen years of software development and software architecture experience. He has designed and developed solutions in the health insurance, finance, engineering and telecommunications industries. He holds an Honours Bachelor of Science in Software Engineering (Computer Science) from the University of Toronto. He has extensive experience in Service Oriented Architecture, Application Architecture, Solution Architecture, Software Development and Data Architecture. His expertise in SOA is supported by a SOACP certificate (Certified SOA Architect). Contributions ■■ An Approach for Assessing SOA Maturity in the Enterprise


52



Berthold Maier Berthold Maier works in the T-Systems International department of Telekom Germany as Enterprise Architect. He has more than 19 years experience as developer, coach and architect in the area of building complex mission critical applications and integrations scenarios. Within eleven years as Oracle employee he has held several leading positions including chief architect in the consulting organization. Hi is the founder of many frameworks and take over the responsible for reference architectures around BPM/SOA and Enterprise Architecture Management. Berthold is also well-known as a conference speaker, book author and magazine writer. Contributions ■■ Canonizing a Language for Architecture: An SOA Service Category Matrix ■■ Industrial SOA ■■ SOA Blueprint: A Toolbox for Architects

Hajo Normann Hajo Normann works for Accenture in the role of SOA & BPM Community of Practice Lead in ASG. Hajo is responsible for the architecture and solution design of SOA/BPM projects, mostly acting as the interface between business and the IT sides. He enjoys tackling organizational and technical challenges and motivates solutions in customer workshops, conferences, and publications. Hajo leads together with Torsten Winterberg the DOAG SIG Middleware and is an Oracle ACE Director and an active member of a global network within Accenture, as well as in regular contact with SOA/BPM architects from around the world. Contributions ■■ Canonizing a Language for Architecture: An SOA Service Category Matrix ■■ Industrial SOA ■■ SOA Blueprint: A Toolbox for Architects


53



Danilo Schmiedel Danilo Schmiedel is one of the leading BPM and SOA System Architects at OPITZ CONSULTING. He has been involved in large integration-, business processes automation and BPM / SOA development projects where he implemented solutions for various customers. His main field of interest is focused on the practical use of BPM and SOA on a large scale. Additionally he works as BPM and SOA project coach. Danilo is a frequent speaker in the German Java and Oracle communities and has written numerous articles about the above topics. Before joining OPITZ CONSULTING Danilo worked as Software Engineer in several international projects. The Leipzig University of Applied Science has awarded his outstanding reputation in 2009. Contributions ■■ Canonizing a Language for Architecture: An SOA Service Category Matrix ■■ Industrial SOA ■■ SOA Blueprint: A Toolbox for Architects

Guido Schmutz Guido Schmutz works as Technology Manager for the IT services company Trivadis. He has over 25 years as a software developer, consultant, architect, trainer, and coach. In Trivadis he is responsible for SOA, BPM and application integration, and is head of the Trivadis Architecture Board. His interests lie in the architecture, design, and implementation of advanced software solutions. He specializes in Java EE, Spring, Oracle SOA Suite and Oracle Service Bus. He is a regular speaker at international conferences and is the author of articles and several books. Guido is an Oracle ACE Director for Fusion Middleware & SOA. Contributions ■■ Canonizing a Language for Architecture: An SOA Service Category Matrix ■■ Industrial SOA ■■ SOA Blueprint: A Toolbox for Architects


54



Bernd Trops Bernd Trops is a Senior Principal Consultant at Talend Inc. In this role he is responsible for client project management and training. Bernd is responsible for all Talend projects within the Deutsche Post and the introductions of new versions and components. Before Talend, Bernd was a Systems Engineer working on various projects for GemStone, Brocade and WebGain and therefore has extensive experience in J2EE and SOA. From 2003 to 2007 Bernd Trops worked as a SOA Architect at Oracle. Contributions ■■ Canonizing a Language for Architecture: An SOA Service Category Matrix ■■ Industrial SOA ■■ SOA Blueprint: A Toolbox for Architects

Clemens Utschig-Utschig Clemens worked as Chief Architect for the Shared Service Centre, Global Business Services, Boehringer Ingelheim in architecture, master data, service management and innovation. At the moment he works with holistic enterprise architecture that provides the methodological platform for the new master data management. He previously worked as a Platform Architect at Oracle Inc. in the United States, where he helped to develop next product strategy as well as the SOA BPM Suite. Contributions ■■ Canonizing a Language for Architecture: An SOA Service Category Matrix ■■ Industrial SOA ■■ SOA Blueprint: A Toolbox for Architects


55



Torsten Winterberg Torsten Winterberg works for Oracle Platinum Partner OPITZ CONSULTING. As a director of the competence center for integration and business process solutions he follows his passion to build the best delivery unit for customer solutions in the area of SOA and BPM. He has long-time experience as developer, coach and architect in the area of building complex mission critical Java EE applications. He is a known speaker in the German Java and Oracle communities and has written numerous articles on SOA/BPM related topics. Torsten is part of the Oracle ACE director team (ACE=Acknowledged Community Expert) and leads the DOAG middleware community. Contributions ■■ Canonizing a Language for Architecture: An SOA Service Category Matrix ■■ Industrial SOA ■■ SOA Blueprint: A Toolbox for Architects


56


April 8-12, 2013 Fairfax, VA, USA

SOA Analyst Certification April 1, 3, 8, 10-11, 2013 • Lima

Certified SOA Architect

SOA Architect Certification April 1-5, 2013 • Lima

April 8-12, 2013 Melbourne, Australia Cloud Technology Professional

April 15-17, 2013 Brussels, Belgium

Cloud Architect Certification April 6, 13, 20, 2013 • Cairo

SOA Architect Certification May 27-31, 2013 • Toronto

SOA Architect Certification April 8-12, 2013 • Fairfax

Cloud Technology Professional Certification June 3-5, 2013 • Brussels

Cloud Architect Certification April 15-19, 2013 • Melbourne

Certified Cloud Architect

Cloud Technology Professional Certification April 22-24, 2013 • Dubai

May 6-10, 2013 Las Vegas, NV, USA

Cloud Architect Certification April 22-26, 2013 • Charleston

Certified SOA Analyst

May 13-17, 2013 Vancouver, BC, Canada SOA Governance Specialist

May 21-23, 2013 Stockholm, Sweeden

Cloud Architect Certification April 22-26, 2013 • Naarden SOA Architect Certification April 22-26, 2013 • Stockholm SOA Architect Certification April 29 - May 3, 2013 • Las Vegas SOA Architect Certification May 4-8, 2013 • Riyadh SOA Architect Certification May 6-10, 2013 • Quito

Certified SOA Consultant

Cloud Architect Certification May 6-10, 2013 • Las Vegas

June 3-11, 2013 Mexico City, Mexico

SOA Consultant Certification May 6-8, 13-14, 2013 • Quito SOA Analyst Certification May 6, 8, 13, 15-16, 2013 • Quito

SOA Security Specialist

Cloud Architect Certification May 13-17, 2013 • Singapore

June 10-12, 2013 Charleston, SC, USA Certified SOA Architect

June 10-14, 2013 Malmö, Sweeden


SOA Architect Certification May 20-24, 2013 • Utrecht SOA Governance Specialist Certification May 21-23, 2013 • Stockholm

Cloud Technology Professional Certification April 15-17, 2013 • Brussels

April 22-26, 2013 Charleston, SC, USA

SOA Architect Certification May 20-24, 2013 • Sydney

SOA Consultant Certification April 1-3, 8-9, 2013 • Lima

SOA Architect Certification April 8-12, 2013 • Melbourne

Certified Cloud Architect

Cloud Architect Certification May 20-24, 2013 • Sydney

Cloud Architect Certification June 3-7, 2013 • Fairfax SOA Architect Certification June 3-7, 2013 • Mexico City SOA Consultant Certification June 3-5, 10-11, 2013 • Mexico City SOA Analyst Certification June 3, 5, 10, 12-13, 2013 • Mexico City

SOA Java Developer Certification June 3-5, 11, 14, 17-18, 2013 • Mexico City

SOA .NET Developer Certification June 3-5, 11, 14, 19-20, 2013 • Mexico City SOA Governance Specialist Certification June 3, 5, 10, 21, 24-25, 2013 • Mexico City SOA Security Specialist Certification June 10-12, 2013 • Charleston Cloud Architect Certification June 10-14, 2013 • Bangalore SOA Architect Certification June 10-14, 2013 • Malmö SOA Architect Certification June 10-16, 2013 • Stockholm SOA Governance Specialist Certification June 17-19, 2013 • Frankfurt

SOA Architect Certification May 13-17, 2013 • Bangalore

Cloud Technology Professional Certification June 17-19, 2013 • Naarden

SOA Analyst Certification May 13-17, 2013 • Vancouver

SOA Architect Certification June 24-28, 2013 • Fairfax

Cloud Architect Certification May 20-24, 2013 • Melbourne

www.arcitura.com/workshops

Q2/2013 Workshop Calendar

Cloud Technology Professional Certification April 1-3, 2013 • Bangalore

Certified SOA Architect

Updated: Feb 1, 2013

The Service Technology Magazine is a monthly online publication provided by Arcitura Education Inc. and officially associated with the “Prentice Hall Service Technology Book Series from Thomas Erl.” The Service Technology Magazine is dedicated to publishing specialized articles, case studies, and papers by industry experts and professionals in the fields of serviceoriented architecture (SOA), cloud computing, semantic Web technologies, and other areas of services-based technology, innovation, and practice.

www.servicetechnologymagazine.com www.servicetechmag.com


From the Editor

From the Editor

Suggest Documents

from the editor del editor

Message from the Editor

Message from the Editor

Letter from the Editor

Letter from the Editor

From the Editor - SmithBucklin

Message from the Editor

From the Editor

from the editor - UAH

FROM THE CHIEF EDITOR

from the chief editor

From the Editor - BioTechniques

From the Editor - BioTechniques

From the Editor

From The Editor

Message from the Editor

From the Editor

From the Editor

from the editor

Message from the Editor

Message from the Editor

From the Editor - BioTechniques

Letter from the Editor

From the Editor