July 24, 2007
During this semester I learned quite a bit about Service Oriented Architecture
(SOA). I learned that SOA came about as an evolutionary process. The ideas of which
stemmed from lessons learned with programming languages, distributed computing, and
business computing. Specifically, the concepts of breaking down a business process into
individual manageable pieces, configuring those pieces at a coarse level of granularity,
and utilizing a distributed network to offload work onto multiple machines were
attributed. The motivation behind creating an SOA was that businesses wanted a solution
to utilizing as much assets as they could from there enterprise’s existing application
landscape. Most of which were riddled with heterogeneous middleware and technology.
Prior attempts to alleviate this “headache” failed. These attempts included
standardization efforts via technology (e.g. Enterprise Data Model & Enterprise Service
SOA was and has proven to be an acceptable solution. The success can be
contributed to the fact that it is neither a technology nor a standard. It can be considered
more of a set of guidelines. These guidelines are technology-independent, high-level
concepts that provide architectural blueprints. The blueprints help to define the creation
of an architectural landscape that allows the components of that architecture to be created
independently yet integrated globally. More importantly the architecture is founded
around the idea of breaking the entire business process down into smaller components of
business functionality. Each component of functionality is a derivation of the overall
business process and manifests itself in autonomous units called services. Hence the title
“service” oriented architecture.
All service oriented architectures are based on four key components: application
frontends, service, service repository, and service bus. The application frontends are
considered the initiators and controllers of the application landscape. These components
are responsible for forcing input through the system and gathering its output. Services
represent the fundamental building blocks of an SOA. Their purpose is to execute
various aspects of business functionality. Service repositories provide a means for the
storage and discovery of services. Lastly, service buses are the components that connect
the application frontends with the services.
There are essentially three stages of an SOA. The stages include the fundamental
SOA, the networked SOA, and the process enabled SOA. The most basic being the
fundamental SOA and the most advanced being the process enabled SOA. As you
progress from stage to stage, you essentially provide additional services with an increased
amount of functionality. The initial stage creates basic services that encapsulate
functionality to store, update, and delete data as well as functionality to execute
computational algorithms. The following stage introduces intermediary services which
help to bridge technical gaps within the network. Finally, the last stage introduces
process centric services which help to encapsulate the functionality of a business process.
Enterprises that make it to this stage are said to have a fully leveraged SOA. At this stage
one’s application landscape can consist of thin application frontends which are primarily
responsible for calling services (which do most of the work) and displaying results. The
progression from the Fundamental SOA to the Process Enabled SOA follows a logical
path. For this reason, the systematic progression along this path is recommended for
companies wishing to start their own SOA.
Companies such as Duetsche Post AG and Winterthur have been relatively
successful in implementing their SOAs. The key to their success was securing the
appropriate budget, choosing a suitable project to start with, setting up a strong SOA
team, and finding the appropriate budget. This strategy is referred to as the four pillars of
success. Because their SOAs were a success, they were able to reap the main benefit of
an SOA. That benefit is the creation of an agile enterprise in which processes and
services are completely flexible. Their SOAs allowed both business and IT sides of the
house to come together and develop the enterprise infrastructure with a common ground
of communication (i.e. services). In the end, their implementation of an SOA will allow
them to quickly reconfigure their infrastructure to meet the needs of their ever evolving
Web Services Summary
In edition to learning about the Service Oriented Architecture (SOA), I also
learned about web services. Web services are just one means to implement an SOA.
Specifically, a web service is “a software system designed to support interoperable
machine-to-machine interaction over a network.” To facilitate interaction, web services
utilize the following industry/web standards:
• XML – This is referred to as “the format” behind web services. Essentially XML
is an extensible markup language designed as a way to mark up a document and
expose its structure for machine processing.
• SOAP – This can be considered “the language” behind web services. SOAP is a
mechanism that utilizes XML to define the unit of communication in order to
facilitate cross platform distributed computing. It contains a flexible mechanism
for data representation, a convention for RPC’s and responses, and a protocol
• WSDL – This can be thought of as “the describer” behind web services. A
WSDL is essentially an XML based document that describes who, what, were,
and how about a service. Particularly, it serves as a definition of a service and can
be stored in service repository. This definition is read by service requesters to
determine if they need that service and how they can invoke it if they do.
• HTTP – This is the typical means of transporting web services. More
specifically, it is the mechanism for transporting XML across the distributed
network. Once transported, XML is marshaled and unmarshaled at both the client
and server sides to enact the functionality of the service.
In class we learned how to used HTTP, WSDL, and SOAP to create, publish, and
consume a web service. Though we did not have the chance to implement one, we also
learned about the UDDI registry. UDDI is not considered a service repository. However,
it provides similar functionality. Specifically, it provides a mechanism to describe
services and a means to both statically and dynamically discover them.
Has this course change any of your ideas about Enterprise computing?
Yes. I originally thought about tackling enterprise computing from a technology specific
approach. Specifically, I thought that standardizing the enterprise through use of data
models or enterprise-wide middleware was the key. After reading the case studies and
arguments presented in this book, I was made aware of the fact that companies that have
gone this route have failed. In the end, they ended up creating an application landscape
riddled with heterogeneous technologies. Taking the SOA approach just seems like
common sense. You are now breaking down business processes into sub components
(i.e. services) that have a coarse level of granularity. This provides them the potential to
be reused across multiple parts of the enterprise. More importantly, the SOA process of
creating those services provides a common ground for communication between the
business and IT sides of the house. I discovered that taking the SOA approach
necessitated an organizational shift within the companies that implemented them.
Deutsche Post AG and Winterthur were forced to reorganize the structure of their
business processes (e.g. into domains) as well as insert SOA Teams into their business
hierarchy. These teams included Architecture Boards, which regulated the process of
creating services, and the evangelizing teams which were responsible for broadcasting
and teaching the benefits of SOA.
In all, I’d say that SOA has changed my entire perspective of enterprise
computing. As a developer, I now have to think in terms of coarse-granularity and
stateless communication (when possible). As a manager, I now see the future of our
infrastructure not only needs to change from a technological level but at a business level
as well. This directly equates into the creation of new positions and regulatory bodies
(e.g. Architectural Boards) not currently in place.
What material was completely new / familiar?
I was already familiar with the idea of web services. I knew that creating them allowed
for a specific level of abstraction. Specifically, by creating a web service, I could
consume it via a standalone application, a web application, or even various operating
systems. However, I was not familiar with the concept of a service oriented architecture
(SOA) or more importantly that a web service was a means of accomplishing one. I now
know that building web services go way beyond bridging technology, it is part of a
greater concept and that concept is the SOA. To be successful in implementing an SOA,
one must carefully consider what should and shouldn’t be distributed (e.g. private vs.
public services), the ramification of distributing services (e.g. utilizing security
mechanisms across heterogeneous networks), and bridging heterogeneous technology
(e.g. middleware such as MOM, distributed objects, etc.). In all, I would say I now have
a better idea about the many facets of distributed computing. More importantly, I now
see SOA as a solution to “bringing it all together.”
Does this material have application in your current work environment?
Yes. I am currently working on creating an enterprise web portal. My original design
involved creating teams of programmers and assigning each team to a specific business
unit. From there we were going to take a uniform approach of development.
Specifically, we were going to independently tackle each units needs by creating
applications using C# and integrating them via ASP.NET. Though this approach may
work, it will tie us into a specific vendor (i.e. Microsoft). More importantly, it is limiting
its ability to be re-used. If our company is ever purchased, some if not all of it may have
to be re-engineered during the merger. This is especially true if the new company brings
a J2EE environment. However, if I can take the SOA approach I should be able to future
proof our technology. Specifically, I can follow Winterthur’s approach of defining
domains. In my case, each business unit correlates to a specific domain. I could then
refine the functionality of those domains down into services. While defining them, I
would make sure to leave the services at a coarse enough level so as to maximize their
potential for reuse. For example, the Marketing department asked me to create a contact
management system. Their system had a need to track what contacts they made, when
they made them, and what came out of those meetings (i.e. specific contracts awarded). I
can see myself now creating various services from this requirement. The first would be a
basic service that allows individuals to create, update, and delete contacts. This would
not only come in handy for the marketing department but may also come in handy for our
HR department. If I abstract this enough I could allow them to use it to manage potential
new hires (i.e. contacts) for a job position. Overall, SOA has opened my eyes. It is a
new approach that needs to be looked into. Before I continue with my original plans, I
plan on talking to my engineers to discuss using our web portal as our entry into the
SOA. Specifically, I may use the contact management system as the pilot project. It has
wide spread visibility, limited risk, and the support (budget and multiple departmental
manages backing it) needed to make it a success.
What material should be included if the course is taught again? What chapters
were most helpful?
Just about everything taught in this class should be taught again. However, I found a lot
of redundancies between the two books. My recommendation would be to start at
chapter 4 in the ESOA text. The information contained in the first three chapters was
pretty much repeated in the rest of the text. In general, everything up to chapter 14 was
excellent. I really thought chapters 14 – 17 were good. However, the greatest benefit
from these chapters could be obtained by simply reading the section on lessons learned.
In regards to the BWSWJ text, I recommend all of the chapters taught in this class. I
really liked having the opportunity to create a web service and consume it. Given enough
time I imagine someone could use Axis to create a UDDI repository. It would have been
neat if we had one in place for everyone to publish their own service and have the means
to locate and consume them. I think this would have brought all parts of the SOA into
Which book was most helpful?
Both were beneficial. ESOA helped introduce the concepts. The BWSWJ text helped
me solidify the concepts with an actual example. From an applied approach the BWSWJ
provides more of a hands-on approach. As a programmer I like this approach. However,
one of the things reiterated in our ESOA text was that an SOA benefits both the technical
and business sides of the house. By choosing only the BWSWJ text, you would be
limiting the benefit to just IT students. I could foresee business majors getting a lot out of
this class as well. Perhaps this class would be the prelude to another class on Business
Process Management Systems.
Did producing an on-line lecture help you come to grips with the material in the
chapter you were assigned?
Most definitely. I was assigned Chapter 4 which looking back at it now doesn’t seem
that difficult. However, at the time SOA was a new concept and I had a hard time
conceptualizing what it was. While preparing my on-line lecture for the class I found
myself reviewing other sources. This helped to fill in the gaps that the book left out.
Moreover, it gave a much greater understanding of the material.