> Issue XXV: January 2009

Issue XXV January 2009

What Every Developer Should Know About SOA Governance

Robert Schneider

Robert Schneider

Governance is often the Achilles Heel of a service-oriented initiative, especially when it comes to how software developers treat their responsibilities in this important matter. Unfortunately, far too many enterprises witness an adversarial relationship between the developer and SOA's vital governance requirements. This article explores how easily things can go awry when software developers resist participating in governance. Happily, by investing in processes, people, and technology, the organization can mitigate the risk of this undesirable outcome. With these foundations in place, software developers can focus on applying proper governance techniques to the key deliverables created in any service-oriented project. Creating software for use in a service-oriented world requires a new perspective on design techniques and development technologies. Unfortunately, in the race to understand and implement these new methodologies and tools, important considerations such as governance frequently get overlooked. These types of oversights can end up as a significant reason for the oft-experienced gap between the promise of SOA (increased ROI on software investments, augmented organizational agility, and diminished IT maintenance burdens) and the reality of most SOA initiatives: a proliferation of duplicate services, unclear policies, and frustration...

Principles and Patterns at the U.S. Department of Defense

Dennis Wisnosky

Dennis Wisnosky

"The Department of Defense (DoD) is perhaps the largest and most complex organization in the world. It manages more than twice the budget of the world's largest corporation, employs more people than the population of a third of the world's countries, provides medical care for as many patients as the largest health management organization, and carries five hundred times the number of inventory items as the world's largest commercial retail operation." - DoD Enterprise Transition Plan, September 2005. Through SOA, the DoD's business IT solutions are being united via an infrastructure and standards-based pattern termed the Business Operating Environment (BOE). As a result, many of the projects and interrelated sub-projects that drive these mission areas are fundamentally based on the development of services through SOA and service-orientation with the support of proven principles and patterns. This article explores how the BOE relates to common SOA principles and patterns. The following article is comprised of an excerpt from SOA Design Patterns [REF-1] and references patterns published at [REF-2]. In 2005, the U.S. Congress passed the National Defense Authorization Act for FY2005 to modernize and streamline automated business systems within the DoD with the purpose of improving organizational agility and increasing the value of IT in general, while also reducing...

Scaling Services with Software Pipelines:
A Look at Service Design with the SPOC Methodology

Cory Isaacson

Cory Isaacson

As many architects are well aware, SOA offers incredible flexibility for business applications. However, this flexibility often comes at the cost of performance, especially when compared to more monolithic architectures. Software pipelines offers a new look at parallel computing, specifically designed for service-oriented processing requirements with an emphasis on increasing scalability and cleanly separating the design and development of business service components from deployment performance. This article includes excerpts from the new book "Software Pipelines and SOA: Releasing the Power of Multicore Processing" [REF-1} and covers some of the design aspects of pipeline technology, including how the architecture can be applied to an example banking application. It also provides a brief tour of the companion pipelines methodology, showing how to "do the math" to estimate, predict and optimize pipelines during the design phase. Software pipelines is a new concept for enabling scalable processing for service-oriented applications. The fundamentals of this technology platform have been covered in previous articles [REF-2]. This time around we'll be providing a brief tour of pipeline design elements that are part of the companion methodology known as the Software Pipelines Optimization Cycle (SPOC). Specifically, we will focus on the pipeline design stage of the SPOC cycle...

Web Service Contract Versioning Fundamentals Part II:
Version Identifiers and Versioning Strategies

Thomas Erl, David Orchard, James Pasley

Thomas Erl David Orchard
James Pasley

There are different ways of versioning service contracts based on policies, priorities, and requirements. This, the second article in a two-part series from the book "Web Service Contract Design & Versioning for SOA", introduces three common versioning strategies: strict, flexible, and loose. The pros and cons of each approach are discussed and further ranked in relation to strictness, governance impact, and complexity. The role of version identifiers is also explored through a series of examples. The following article is an excerpt from the new book "Web Service Contract Design and Versioning for SOA" [REF-1] Copyright 2008 Prentice Hall/Pearson PTR and SOA Systems Inc. Note that chapter references were intentionally left in the article, as per requirements from Prentice Hall. One of the most fundamental design patterns related to Web service contract design is the Version Identification pattern. It essentially advocates that version numbers should be clearly expressed, not just at the contract level, but right down to the versions of the schemas that underlie the message definitions. The first step to establishing an effective versioning strategy is to decide on a common means by which versions themselves are identified and represented within Web service contracts. Versions are almost always communicated with version numbers. The most common format is a decimal, followed by a period and then another decimal, as shown here: version="2.0" Sometimes, you will see additional period + decimal pairs that lead to more detailed version numbers like this: version="" The typical meaning associated with these numbers is the measure or significance of the change. Incrementing the first decimal generally indicates a major version change (or upgrade) in the software, whereas decimals after the first period usually represent various levels of minor version changes. From a compatibility perspective, we can associate additional meaning to these numbers. Specifically, the following convention has emerged in the industry:...

SOA Design Patterns Introducing the SOA Pattern of the Week Series


SOA Pattern

The SOA Pattern of the Week series is comprised of original content and insights provided to you courtesy of the authors and contributors of the community site and the book "SOA Design Patterns". The first article in this series (published at InformIT on January 18th) is dedicated to the Service Fa├žade design pattern and highlights how it can be leveraged to establish key abstraction layers within service architectures. Subsequent articles will follow on a weekly basis for the next 85 weeks, carrying over into 2010...

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