> Archive > Issue XXVI: February 2009

Issue XXVI February 2009

Service Development Lifecycle Controls for Creating a Service Factory

Clive Gee, Robert Laird

Clive Gee
Robert Laird

The concept of a software factory describes a practical work-product approach to governing an efficient service factory - a software engineering-based approach to defining, developing, testing, deploying, and operating functional services and automated business processes. All services follow a similar lifecycle of analysis, followed by design, development, deployment, and ongoing management. Because the service creation process is repetitive, a production engineering approach to automating software development can be used. The Production Engineering method required a significant effort up front, creating a specialized production or assembly line that can then mass-produce the product efficiently and in quantity In effect, we are building a Services Factory: much of the purpose of SOA governance is to define how that factory can operate most effectively. In the following excerpt from the book "SOA Governance: Achieving and Sustaining Business and IT Agility" [REF-1] we will take a look specifically at service development lifecycle control points. While most organizations have some form of a system development lifecycle (SDLC), the nature of creating shared services is best guided by an SDLC with sufficient governance control points to ensure quality of service. This article discusses and explains the key concepts of a governance control point, as applied specifically to the service development lifecycle...

The Rise of Virtual Service Grids

Enrique Castro-leon, Jackson He, Mark Chang, Parviz Peiravi

Enrique Castro-leon
Jackson He Mark Chang
Parviz Peiravi

The concept of virtualization and sharing of resources is not a new one. In fact, the idea of standardization has been around since the industrial revolution made it possible to mass produce identical parts. Because of this, manufacturing and production costs declined steeply, as businesses no longer needed to specialize in every aspect of production. And now, the same idea is being applied in the information age. Virtualization and service orientation are allowing businesses to share or sell common components to allow for faster and cheaper development times. This article discusses the way service-orientation came about, and provides a brief overview of what it can offer. The industrial revolution of the nineteenth century led to the pervasive replacement of manual labor with steel-based machinery powered by coal technology. The visible icons of this revolution are Thomas Newcomen and James Watt with their improvements to the steam engine design. One aspect that has received little attention is the role of the underlying industrial processes. Railway robber barons did not start from ground zero; they were able to build their empires without having to own coal or iron mines, or having deep knowledge about the extraction technologies. Different grades of steel with known properties became available to build locomotives and steam engines. Manufacturing became more efficient due to a number of standards. Standardized screw sizes in nuts and bolts made these parts interchangeable not only lowered the cost of building the railroad infrastructure, but also made possible the large scale production of firearms that the tycoons needed to defend their lairs. A similar transformation is happening with the information technology industry. This transformation is being driven by the synergistic interaction of three technologies: virtualization, service orientation and grid computing. As in the industrial revolution, this trio of technologies allows an efficient division of labor. The payoff of this efficiency comes in reduced cost of the delivery of IT services and in their reach across market segments and across geographies. IT services will no longer be the exclusive privilege of large organizations that can afford a sizable in house IT organization; these services will be affordable to small businesses and even individual consumers, and not only in advanced economies but also in developing countries across the world...

Service Transaction Handling Without WS-AtomicTransaction

Kanu Tripathi

Kanu Tripathi

This article explores options available to service-oriented architecture implementations to address distributed service transaction requirements when support for specifications like WS-Coordination [REF-1] and WS-AtomicTransaction [REF-2] are not available. An example is discussed to explain this problem state and four separate alternative solutions. As more and more organizations are realizing the benefits of creating an ever growing inventory of services, many of these services may have to be used in situations where the functionality they provide can be included in single, short-lived atomic transactions. Although there are ratified industry standards that address this requirement (e.g. WS-Coordination and WS-AtomicTransaction), your platform may not support them. As a result, you may need to explore alternative mechanisms capable of simulating transaction control. In this article defines we explore such mechanisms along with their pros and cons. Each solution discusses impacts on service design principles like Service Reusability, Service Autonomy, Service Abstraction, and Service Composability [REF-3]. Even though the examples focus on services implemented as Web services, the solutions covered here can be applied to other types of service implementation technologies...

Understanding WS-Policy Part I:
Policy Structure and Composite Policies

Umit Yalcinalp, Thomas Erl

Umit Yalcinalp
Thomas Erl

Web service contracts can be extended with policies that express additional constraints, requirements, and qualities that typically relate to the behaviors of services. You can create human-readable policies that become part of a supplemental service-level agreement, or you can define machine-readable polices that are processed at runtime. The latter type of policy is the focus of this article and the technology we'll explore to create machine-readable policies is the WS-Policy language and related WS-Policy specifications. The following article is an excerpt from the new book "Web Service Contract Design and Versioning for SOA" [REF-1] Copyright Prentice Hall/Pearson PTR and SOA Systems Inc. Note that some chapter references were intentionally left in the article, as per requirements from Prentice Hall. There are many kinds of policies, some of which are pre-defined by industry specifications and others that can be customized by the Web service contract designer. For example, you can use policies to express interoperability and protocol constraints, as well as privacy, manageability, and quality of service (QoS) requirements. Furthermore, policies may be created for a single party, or they may apply to multiparty interactions. From an architectural and contract design perspective, policies affect all levels of a service design. They can be applied to most parts of the abstract and concrete descriptions of a WSDL document, and they can be applied at different scopes. For example, one policy may pertain to a message definition while another is applied to the entire WSDL port type (or interface)...

Introducing 20 New SOA Podcasts


SOA Pattern

The InformIT OnSOA Podcast Channel is publishing 20 podcast interviews from the authors of the recently released books "SOA Design Patterns" and "Web Service Contract Design & Versioning for SOA". In these sessions, SOA journalists Joe McKendrick and Kevin Davis interview the authors who provide a variety of additional insights and commentary about various topics related to SOA design patterns, SOA governance, and service contract design and versioning issues and techniques...
[Podcasts] SOA Design Patterns
[Podcasts] Web Service Contract Design & Versioning for SOA

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