SOA
And You
Will
You Be A Survivor Or Casualty?
By
Don Fowler, MCE 2006
SOA 101
Let’s be frank. Service
Oriented Architecture is being sold every day to executives as a way of
lowering costs, increasing company flexibility, and providing a corporate advantage
over competition. It is being shown to decision makers to be a viable solution
to improve a company’s capability of absorbing other entities as part of
mergers and acquisitions.
You
are either going to make the mainframe play in the SOA game or be replaced by
someone who can make it play. It is not a matter that the mainframe cannot play
in SOA; it is more of a matter of do you know how the mainframe can play. And
your IT management might know the mainframe can play exceedingly well in SOA. If
they don’t, maybe you should tell them before the company executives demand SOA
be embraced!
Can
you be articulate on what SOA is and how your company adopting SOA increases
the mainframe’s value and, in turn, your value?
Yes,
you can actually increase your value to the organization. SOA, in theory,
should insulate and isolate users from aspects of the underlying
infrastructure. But someone still has to build and maintain that
infrastructure.
In
a recent
Computerworld article on I/T jobs and the serious shortage of people
entering the I/T world, the author indicated that kids today view
managing computer environments as boring and tactical. Schools haven't done a
good job keeping the gig fresh, so since times have changed but the curriculums
really haven't, kids are on to the next great thing. Others believe companies
have brought on themselves the rejection of I/T curriculum by moving jobs
offshore, or having a policy of staff turnover to avoid higher labor
costs.
On the other hand companies with short sighted management, who
only think in a tactical mode, using cheap, in-experienced I/T staff will
eventually have that short-sighted decision making catch up with them. As stated by a responder to the referenced
article, "If there is anyone alive that thinks you can hire a $15-per-hour
person to design the next service-oriented architecture that will not only work
but will actually create business value, I have a bridge I'd like to show you.”
By
being a SOA knowledgeable, experienced I/T professional on any computing
platform, you can provide a valuable resource to building the underlying
infrastructure required in the SOA world. SOA is not the sole property and
realm of the desktop/server architect. It encompasses processes, procedures,
disciplines, protocols, and expertise that any longtime mainframe professional
has mountains of experience.
Can
you be articulate on how the mainframe plays in SOA?
If
you can’t do these things then begin your retirement paperwork or start looking
for a job in some third world country that has never heard of SOA.
SOA Defined
How
can you become an articulate “SOAer”?
There
are several ways.
One
approach would be to go to the Internet and research every important and
meaningful paper on the topics of SOA, required skills, and mainframe SOA
capabilities. This would probably take you several weeks to just research what
papers and documents would provide you the best overall view of SOA and the
best descriptions of how the mainframe participates.
Another
approach would be to take all of the pre-certification classes (14 or more if
you do not have the interdisciplinary skills described next) and then certify
in SOA development. SOA does incorporate aspects of and requires knowledge of
object-oriented architecture, business process engineering, and systems
management disciplines, as well as other methods and models.
A
more reasonable approach would be for us to provide you with completed
research, give you the readers’ digest version of SOA, and then answer any
questions you might have.
The term service-oriented architecture (SOA
[pronounced "es-ō-ā"]) expresses a perspective of software architecture
that defines the use of loosely
coupled software services to support the
requirements of the business processes and software users. In an SOA
environment, resources on a network are made available as independent services
that can be accessed without knowledge of their underlying platform
implementation.
A service is a unit of
work done by a service provider to achieve desired end results for a service
consumer. Both provider and consumer are roles played by software agents on
behalf of their owners.
SOA Examples
SOA is everywhere. Here’s an example of SOA likely to be found in your living room – a CD. If you want to play it, you put your CD into a CD player and it plays for you. The CD player offers a CD playing service. This allows you to replace one CD player with another. You can play the same CD on a portable player or on your high-priced surround-sound system. They both offer the same CD playing service, but the quality of the service is different.
The
idea of SOA departs significantly from that of object oriented programming,
which strongly suggests that you should bind data and programmatic processing
together. So, in object oriented programming style, every CD would come with
its own player and they are not supposed to be separated. This is the way we
have built many software systems.
Another
example of “service” can be found in something as simple as a set of snow skis.
You
wish to acquire a new set of snow skis. You could do the following:
1)
Read everything you can on making skis. This will involve time to do the
reading and expense to obtain the books.
2)
Buy the wood working equipment needed to construct the skis and house the
equipment in some kind of workshop. This involves expense and set up time.
3)
Buy raw wood stock. Time and expense again.
4) Build multiple prototype skis to get experience and test the skis for characteristics. More time and expense.
5) Build your dream set of skis and discover which wax is best. More time consumed!
Figure 1 – Real Life SOA
Or
more realistically, (see Figure 1) you will look up a good sporting goods store
in the yellow pages, drive there and purchase a set of skis from the store’s winter
sports department. The department’s salesman recommends the correct wax, which
you also purchase at this time.
You
have just consumed a service. In fact, you consumed two services in this
example - the acquisition of your new skis and the obtaining of the appropriate
wax.
The reason that we want someone else to do the work for us (like the ski manufacturer) is that they are experts. Consuming a service is usually cheaper and more effective than doing the work on our own. Most of us realize that we are not smart enough to be expert in everything. The same rule applies to building software systems. We call it "separation of concerns", and it is regarded as a principle of software engineering.
If interfaces do not work, systems do not work. Interfacing is also expensive and error-prone for distributed applications. An interface needs to prescribe system behavior, and this is very difficult to implement correctly across different platforms and languages. Remote interfaces are also the slowest part of most distributed applications. Instead of building new interfaces for each application, it makes sense to reuse a few generic ones for all applications.
Since
we have only a few generic interfaces available, we must express
application-specific semantics in messages. We can send any kind of message
over our interfaces, but there are a few rules to follow before we can say that
any architecture is service oriented.
Rule 1 - an SOA must have a mechanism that enables a consumer to discover a service provider under the context of a service sought by the consumer. The mechanism can be really flexible, and it does not have to be a centralized registry.
Rule
2 - the messages must be descriptive, rather than instructive, because the
service provider is responsible for solving the problem. This is like going to
a restaurant: you tell your waiter what you would like to order and your
preferences but you don't tell their cook how to cook your dish step by step.
Rule 3 - service providers will be unable to understand your request if your messages are not written in a format, structure, and vocabulary that is understood by all parties. Limiting the vocabulary and structure of messages is a necessity for any efficient communication. The more restricted a message is, the easier it is to understand the message, although it comes at the expense of reduced extensibility.
Rule
4 - extensibility is vitally
important. The world is an ever-changing place and so is any environment in
which a software system lives. Those changes demand corresponding changes in
the software system, service consumers, providers, and the messages they
exchange. If messages are not extensible, consumers and providers will be
locked into one particular version of a service.
SOA Is Many Things To Many People
SOA has many different faces and definitions based on your skills, experiences, and perspectives.
It
shows a service consumer at the right sending a service request message to a
service provider at the left. The service provider returns a response message
to the service consumer. The request and subsequent response connections are
defined in some way that is understandable to both the service consumer and
service provider. Figure 2 – SOA to
the Business Mind To the Business Mind, SOA does this: 1.
Ø
A Service Consumer
locates a Service Provider 2.
Ø
A Service
Provider tells the Consumer what the contract terms are. 3.
Ø
The Consumer
agrees and issues the request for service. 4.
Ø The Provider responds with
contracted deliverable. To the IT Manager’s mind (see Figure 3), SOA is usually a picture
of ‘services’ instead of providers and consumers. This is because providers can
also be consumers.
Figure 3 – SOA To
The I/T Management Mind To the Technical Mind, the steps involved in providing and
consuming services are (see Figure 4):
The directory shown in the slide could be a UDDI registry and more
than likely is today. The UDDI registry is intended to eventually serve as a
means of "discovering" Web Services described using WSDL. The idea is
that the UDDI registry can be searched in various ways to obtain contact
information and the Web Services available for various organizations or
departments.
SOAP generally uses HTTP, but other means of connection may be
used. HTTP is the familiar connection we all use for the Internet. In fact, it
is the pervasiveness of HTTP connections that will help drive the adoption of
Web Services.
SOA contains two pieces. The first is a formalized method for breaking down business
applications into services. The method should achieve the arrival at specific
pieces of functionality that can be combined with any other function, and be
re-used. A further characteristic is that the service should not care about the
state* of any other service. Think of
services as building blocks that you can place in any order or location. Since we are currently using Web Services as part of the
infrastructure. The WEB layers are required to deliver a flexible robust WEB
Services environment. The layers of this environment should interoperate to address
issues such as manageability, availability and scalability.
* State is defined as the current or last-known status, or condition, of a
process, transaction, setting, or service.
SOA requirements are measurable against six SOA domain areas: 1) Business Process & Strategy: Measure the
possible impact of SOA on a company’s long-term strategy and near-term
initiatives, and documents the problems that SOA is uniquely capable of
solving. 2) Architecture: Assess the company’s
overall map of services layers and how these layers could interoperate to
address issues such as manageability, availability, and scalability. 3) Building Blocks: Examine shared applications
and data services as well as the company’s overall relationship diagram of
services. 4) Organization & Governance: Any initiative that aims to
transform the delivery of IT to the business can succeed only by adopting a
genuinely strategic, enterprise-wide, approach to the problem by establishing a
best practice organization and governance structure from the outset. SOA is no
exception. 5) Projects & Applications:
Identify opportunities for service-enabling legacy applications and determines
how a company’s current IT initiatives can serve as starting points for
building out integration, application and data service layers. 6) Cost & Benefits: Justifying an SOA program is
not the same as justifying traditional software projects because SOA delivers
its benefits in a range of different ways on an enterprise-wide scale. Through
innovations made possible by optimizing business process with shared services,
SOA offers value opportunities that are disproportionately high when compared
to those expected from traditional software projects. To address discovery, examination and measuring the above items,
both IBM and other Consulting companies have brought fee services and tools to
the market. IBM announced Service Oriented Modeling and Architecture, or SOMA,
a service offering from IBM Global Services (IGS) to help enterprise customers
"bridge the gap between business and technology." Essentially, through SOMA IBM will help customers implement
service-oriented architectures that can transform enterprises to on-demand
businesses. An SOA is basically a collection of services that communicate with
and collaborate with each other. The SOMA service involves BPM (business process modeling) and CBM
(component business modeling). IBM also provides you a SOA
maturity/readiness self-assessment. Taking the IBM SOA assessment will help
you better understand: You can use the self-assessment to aid in determining the SOA
entry point (described below) that might be the correct starring point for your
SOA effort. BEA Systems, Inc. has a Web-based tool that is designed
to quantitatively measure and benchmark a company’s baseline for pursuing SOA
as its IT strategy. Called the “The BEA Service-Oriented Architecture
(SOA) Readiness Self-Assessment,” the instrument reflects the BEA SOA Practice
methodology and is designed to provide IT maturity comparisons against similar
companies within key domains. Now, where do you get started? It
has found that to improve the successful implementation of SOA, there is a
requirement to define and create SOA Governance early in the process. SOA
services require improved governance to maintain the level of control needed to
support the new Business/IT joint environment. The values provided by SOA
Governance are: Realization
of the business benefits of SOA Once Governance is in place, a suggested approach starts with the
entry points to fundamental assets of your enterprise—people, information and
processes. Governance projects expertise can be sourced from IBM and IBM
Business Partners’ SOA practices. These entry points are: IBM and Business Partner SOA practices also helps to lay the
technical groundwork for integration of people, processes and information by
offering entry points for connectivity and reuse. These SOA entry points can
help your business pursue SOA at a pace that suits your needs. These entry points are: SOA is here to stay. Start getting familiar with it now! You can use our WEB
Exploitation Board to ask any SOA related questions of both our specialists
and your counterparts actually exploiting SOA today. Loosely
Coupled: Loose coupling describes an approach where integration interfaces
are developed with minimal assumptions between the sending/receiving parties,
thus reducing the risk that a change in one application/module will force a
change in another application/module. Service: A “Service” has a definition.
This definition consists of: 1)An explicit and detailed narrative
definition supported by a low (but not detailed [not implementation specific])
level process model. The narrative definition is in some cases augmented by
machine-readable semantic information about the service which facilitates
service mediation and consistency checking of an Enterprise Architecture. 2) A set of performance indicators
that address measures/performance parameters such as availability (when should
members of the organization be able to perform the function), duration (how
long should it take to perform the function), rate (how often will the function
be performed over a period of time), etc. 3) A linkage to the organization’s
information model showing what information the “Service” owns (creates,
updates, and deletes) and which information it references and is owned by other
“Services”. 4) A listing of known downstream
consumers (other “Services” that depend upon its function or information) and
the documentation of their requirements. Software Architecture: The software architecture
discipline is centered on the idea of reducing complexity through abstraction
and separation of concerns. Software Services: In the context of Enterprise
Architecture (A.K.A. Systems or Organizational Architecture or Modeling) the
term “Service”
refers to a discretely defined set of contiguous and autonomous business or
technical functionality. (This is not to be confused with Web Services which
is just one way of implementing the automated aspects of a given business or
technical service.) 
Figure 4 – SOA To The Technical Professional
SOA In General
Getting Started With SOA
Mitigation of business risk
Effectiveness of Business/IT teams
SOA Entry Points
Summary
Definitions: