Thứ Sáu, 5 tháng 7, 2013

Readings in Service Orientation

http://msdn.microsoft.com/en-us/library/aa479349.aspx

Readings in Service Orientation

4 out of 4 rated this helpful - Rate this topic

July 2006

Dave Welsh
John deVadoss

Applies to
Application Architecture
Services Orientation

Summary: This book presents an interesting set of classical papers on architecting services by a variety of well-known authors in the architectural space. (5 printed pages)

Preface
Articles in this Series

Click here to download "Readings in Service Orientation"

"All fine architectural values are human values, else not valuable."
—Frank Lloyd Wright

Preface

Many forces are involved with architecture, but the fundamental principles that govern all architectures are simple: it's easy, it works, it's familiar, and it can be trusted.

The purpose of this book is to let you form your own opinions about the impact of services orientation on your business and computing environments. This book is not trying to be an authoritative reference for service orientation. Rather, presented here is an interesting set of classical papers on architecting services by a variety of well-known authors in the architectural space. The topics, or architectural viewpoints covered, go from a perspective on business architecture, through model-based tools, to map from the business to technology to the choices in new IT infrastructure.

One way to look at any IT architecture is as a set of layers. At a technology layer, we are interested in how hardware and operational infrastructure connect together across the network. On top of technology is the application layer in which various applications and components are deployed. The problem with integration of both of these layers is that we typically think about specific instances (.NET to J2EE, or SAP to Siebel). If anything needs to change, then it is normal to change the integration, too; this is the tightly coupled effect.

Today's efforts towards service orientation build around a concept in which a "service" abstracts the inner complexity of distributed computing technology. It's not a new technical concept—a service makes network resources available in a repeatable and consistent manner or protocol, and people or systems can access services in a standardized way. What is new is the uniform agreement across technology vendors and industry groups around the world on everyone using the same fundamental building blocks: the Internet, XML, and open Web Services standard protocols.

Services have a number of characteristics: boundaries are explicit, services are autonomous, services share schema and contract but not class, and service compatibility is based on policy. They operate autonomously, but when together, the intent is that they work to accomplish a common goal and a contract has to exist between the services. Services themselves, in essence then, become the public expression of one or more capabilities of resources in each of our autonomous networks.

These autonomous, loosely-coupled services can be easily assembled to create composite services or easily decomposed into component services. The design intent is to create a whole greater than the sum of the parts, so a high degree of interoperability between your service and my service is sought.

Services are also meant to have real-world effects, so one area in which service orientation has been gaining ground is as an expression for business services, providing a scalable structure for IT to map real-world business requirements onto the technology.

Especially distinctive in service industries, such as telecommunications, service orientation abstracts away from the underlying applications. Instead of thinking about connecting SAP with Siebel, we think of integration in terms of connecting customers to orders, regardless of the underlying implementation.

Finally, looking at layers of technology, the business process layer is where solutions are constructed to support a business requirement through services to the underlying technology. The desired effect is for business process to be more resilient to underlying market changes, and IT can more easily accommodate new requirements in a more agile manner.

But what do we do about all of today's technology? The world still runs on legacy code, so how do we get to a services-based model from there?

Our existing software and many distributed technologies today are largely targeted at one of two distinct design points: ease of programming versus flexibility. Service orientation is about reducing shared assumptions and being more flexible. Object orientation is about ease of use, transparency, and lots of assumptions for easy programming. For the future of software architecture, neither objects nor services will probably be the dominant metaphor; rather, it will be contracts, activities, tasks, and other "higher up the stack" concepts as architects reach for higher-order expressions for their customer communities.

Today, a new meta-tenet, superseding the four commonly accepted service design tenets, is emerging and it can be simply expressed as "the separation of structure from interpretation." In effect, modeling takes on a more prominent role in architectures. Along with a new meta-tenet for services orientation, three truisms are emerging:

Embrace diversity; there is always something "other."
People matter (to write software, for example) to reach a higher ground of service orientation.
Say what you mean and mean what you say.

There has been a lot of material recently written around service architecture, much of it though may be called marketecture. This book takes five different viewpoints on service-oriented architecture and in each viewpoint presents a set of collected readings from various famous authors. The papers here are really a must-read for the architect.

The chapter on Design and Modeling is essentially an end-to-end, business-to-technology set of different perspectives related to architecting services.

A chapter on Data presents two interesting views on information management and information, the business fuel of services architecture.

Next, a chapter on Process talks about design aspects of the behavior of services and choosing the right technology to do the job. Process and Data taken together are really the architectural foundation of the new generation of electronic business transactions.

There is a chapter on Identity, which talks about something so fundamental, even beyond service orientation, that Identity will shift the very center of gravity in how we all need to perceive living on the Web.

Finally, there is a chapter on Protocols and Practice, which presents two papers on service orientation from an infrastructure perspective.

There just wasn't enough room in this book to put everything we would have wanted to include. A companion reference book to this is Microsoft's Dynamic Modeling: Aligning Business and IT.

In putting together this book, the intent was to provide a balanced selection of different viewpoints about this evolving space. No application is an island. Whether we like it or not, tying systems together has become the norm. Yet connecting software is about more than just exchanging bytes. As organizations move toward a services-oriented world, the real goal of creating effective business processes that unite separate systems into a coherent whole comes within reach.

There are too many people to thank for helping to put this book together, and we had too much material for more than just this book. Special thanks goes to Jon Tobey for his help in technical editing and bringing the content together.

We hope you enjoy this series of selected readings on services orientation and that you find practical use for your architecture. On behalf of the authors, we look forward to hearing from you and sharing your architectural vision.

Sincerely,
Dave Welsh
Architect
Microsoft Corporation

John deVadoss
Architect
Microsoft Corporation

Articles in this Series

ChangeTobeBetter's blog

Thứ Sáu, 5 tháng 7, 2013