Designing Powerful Web Applications Using AJAX and Other RIAs
SOA World Magazine-Enterprise SOA
1. THE WORLD’S LEADING MAGAZINE DEDICATED TO WEB SERVICES TECHNOLOGIES
www.SOA.SYS-CON.com
OCTOBER 2008 / VOLUME: 8 ISSUE 10
The Next
Paradigm –
Multi-Enterprise
18
SOA
SOA Innovation Applied
CHRIS JOHNSON 14
GRACIELA TISCAREÑO-SATO
22 Getting an SOA Initiative or
Continuing the Journey
KADEER BEG
3. INSIDE
2 Give Me a Sign
SEAN RHODY
6 Creating an Effective SOA
Service Taxonomy
MARK RICHARDS
12 Design Time SOA Governance
Needs Some Work… Humans and Tools
DAVID LINTHICUM
14 The Next Paradigm -
Multi-Enterprise SOA
CHRIS JOHNSON
18 SOA Innovation Applied
GRACIELA TISCAREÑO-SATO
22 Starting an SOA Initiative or
Continuing the Journey
KADEER BEG
24 Developing a CICS-based
Web Service on an Array of “Complex
Datatype” Objects
SREE KUSUMANCHI, GIRISH MOKHASI, AND GVB SUBRAHMANYAM
30 Common Pitfalls Around an SOA
Implementation – And How to
Avoid Them
MUKUND BALASUBRAMANIAN
32 Making the Case for Application
Service Modeling in SOA Environments
BARNEY SENE
4 OCTOBER 2008 www.SOA.sys-con.com
5. TAXONOMY
essential complexity (complexity that is inherent in the problem Enterprise Services the data needed by the Business Service as defined by the Business
domain itself ) while at the same time trying to avoid accidental Services contained in this service type are also considered core Service input and output specification.
complexity (unnecessary complexity we introduce ourselves). One SOA services. Enterprise Services are concrete services that imple- A service classification template containing the primary char-
way to accomplish this is to start with four basic SOA service types, ment Business Services. The relationship between an Enterprise acteristics for the service type of Application Service might look as
and only extend these service types if necessary. Service and a Business Service is either a one-to-one or many-to- follows:
one relationship (many Enterprise Services implement a single
The Basic SOA Service Types Business Service). Since Enterprise Services have scope across Infrastructure Services
When developing any SOA service taxonomy, a good place to application domains, they are typically identified and defined by an This service type classification defines those services that are
start is with the four basic service types: Business Service, Enter- Enterprise IT Architect or a shared services team. They are concrete used to support the enterprise. Examples of Infrastructure Services
prise Service, Application Service, and Infrastructure Service. This services, meaning they are implemented through some sort of include such aspects as logging, auditing, data access, security, and
Figure1 is the simplest possible hierarchy, and in most cases will probably underlying technology or vendor product. Like Business Services, so on. These concrete services are generally shared by the enter-
satisfy the needs of your particular domain or initiative. The follow- these services are typically course-grained and represent actions prise and used by Enterprise Services (and sometimes Application
ing diagram illustrates the basic service classification structure: against major data entities. Services).
The following sections describe the attributes and characteris- Since the relationship between an Enterprise Service and a Busi- What distinguishes Infrastructure Services from Enterprise
tics of each of these four basic SOA service types. While you will ness Service is commonly a many-to-one relationship, Enterprise Services is that Infrastructure Services implement non-business
most likely find these types sufficient for your particular needs, Services usually require some sort of service orchestration, which functionality. The gray area between Infrastructure Services and
you can certainly extend these further if needed. I present some can be implemented through an aggregate service or through Enterprise Services appears when considering such regulatory
guidelines at the end of this article on when this makes sense and middleware technology (e.g., Enterprise Service Bus or workflow requirements as auditing and compliance. Although some forms of
how to avoid the common pitfalls associated with extending this engine). For example, several Enterprise Services would need to be auditing and compliance are designated as business requirements,
basic hierarchy. orchestrated to implement a CreateQuote Business Service, includ- these services do not specifically address a particular user or busi-
Figure2 ing createCustomer, checkMotorVehicleReport, calulateQuote, ness function; rather, they support the business requirements.
Business Services saveQuote, and so on. Infrastructure Services are typically identified and implemented
Services contained in this service type are considered core A common misconception is that Enterprise Services must be by application developers or an infrastructure support team. They
services in SOA. They can be derived from use cases, user stories, shared across the enterprise. Although Enterprise Services are gen- generally have enterprise-level scope, which is one reason they are
user scenarios, or through the service identification and specifi- erally shared, it is certainly not a requirement. However, Enterprise typically confused with Enterprise Services.
cation steps found in many SOA-based methodologies. They are Services should be course-grained and have the ability to be shared A service classification template containing the primary charac-
course-grained, usually identified and defined by business users, across the enterprise if needed. teristics for the service type of Infrastructure Service might look as
and represent a business process or function. When choreographed Enterprise Services have scope within the context of a Business follows:
they represent the manifestation of a high-level use case or user Service, and therefore implement some sort of business logic. For
scenario. Business Services are abstract definitions containing a example, an auditing service, although required for regulatory com- Service Taxonomy Guidelines
Figure3 service name, input specification, and output specification inde- pliance, would not be considered an Enterprise Service. Rather, that You can certainly extend the basic four service types either
pendent of the underlying technology. In other words, the input type of service would be classified under Infrastructure Services horizontally or vertically to suit your particular needs. However,
and output specifications to the service represent data and infor- (described below) because it does not directly serve a specific busi- before considering extending the basic hierarchy, you may want to
mation collected and consumed by the service. ness function. consider the following service taxonomy guidelines:
For example, to produce an auto quote an insurance com- The potential impedance mismatch between the data (and
pany collects specific information from the customer, stores that format) specified in the Business Service and the data (and format) • Start your service taxonomy with the four basic service types
information, and then presents the auto quote to the customer. expected by the Enterprise Service implementation is usually ad- described above first. If you think you need an additional service
The information the insurance company collects for creating the dressed through message transformation and message enhance- type at the same level, make sure it is non-overlapping with
auto quote would be represented in the service input specifica- ment, which are usually implemented through XSLT transforma- respect to other service types. If you think you need an additional
tion, and the information it provides back to the customer would tions located in a middleware component or Enterprise Service breakdown of service types below the basic level, then read on.
Figure 4 be represented in the service output specification. The name of Bus.
this business service might be CreateQuote. It’s important to real- A service classification template containing the primary char- • Avoid the common pitfall of creating domain specific service
ize that the input and output data specification for this business acteristics for the service type of Enterprise Service might look as types (i.e., types that are specific to divisions or functional groups
service is completely independent of the underlying technology, follows: within your domain). For example, if in the insurance domain,
language, or platform used to implement the business service. avoid creating service types such as Claims Services, Policy
Technically speaking, while Business Services are typically imple- Application Services Services, and so on. These are not service types, but rather actual
mented through standards such as WSDL (Web Services Definition While an Application Service is considered a basic service type, domain service names that are represented through the various
Language), they can be implemented in any sort of CDL (Contract services contained in this service type are not considered core ser- types of services. To put it another way, there are many differ-
Definition Language), be it WSDL, XML, or some other interface vices within the context of SOA; rather, they are referred to as sup- ent service types that constitute a Claims Service (e.g., Business
language. porting services. These concrete services are usually fine-grained Services and Enterprise Services). Don’t confuse an actual service
Figure5 The name of a Business Service is typically constructed in a and are associated with a specific application. In other words, they name (e.g., Policy Service) with the service type (e.g., Business
verb-noun format, with the verb being one of the typical CRUD have application (or silo) scope and therefore are generally not Service).
initiatives; some get it right, but most seem to get it wrong. How verbs (Create, Read (or get), Update, and Delete) and the noun shared in the enterprise. Application Services are typically identi-
to recognize a good classification and poor classification is part representing one of the major business entities found in a typical fied and defined by application developers and are specific to the • Keep your classification hierarchy taxonomy as simple as possible
of what this article is about; the other part is how to build off of a Business Entity Model. Examples of typical Business Services application scope they are defined under. and avoid accidental complexity; remember one of the goals of
standard set of service classifications to create a more effective clas- include CreateQuote, ExecuteTrade, GetCustomer, GetPolicy, and Application Services are generally used to perform fine-grained the service taxonomy is to facilitate communication between the
sification scheme for your SOA initiative. PlaceOrder. application-specific functions such as validation, data collection, various stakeholders and groups involved in the SOA initiative.
An effective service taxonomy is one in which the service type A service classification template containing the primary char- and data transfer. For example, when creating an auto quote the ap- A complex hierarchy of service types will create confusion and
definitions are clear, concise, and most importantly non-overlap- acteristics for the service type of Business Service might look as plication developer may create services such as addDriver, addAd- hinder the basic understanding of the service types you are using.
ping. When creating a service taxonomy you should try to simplify follows: dress, addVehicle, and so on. These services are used to accumulate A complex hierarchy invariably leads to increased debates and
8 OCTOBER 2008 www.SOA.sys-con.com www.SOA.sys-con.com OCTOBER 2008 9
7. GOVERNANCE
Design Time SOA Governance Needs Some
Work...Humans and Tools
BY DAVID S. LINTHICUM
Y
ou need SOA governance, design time, They don’t consider SOA holistically, but instead focus on the
and runtime. However, SOA gover- design and management of new and existing services. That’s a very
nance does not come out of a box. small part of SOA, when you get right down to it.
Simply put, it’s really a matter of people Another issue with design-time SOA governance technology, and
and processes put in place to insure that the as with most SOA technology, is the lack of a standard approach
services are designed, deployed, and operated as to design-time SOA governance. While there are a few standards
effectively as possible. However, people and SOA emerging, most SOA governance technology providers have gone
vendors seem to be dropping the ball around off in their own proprietary directions, using their own approaches,
design time, in terms of both people and tools. It’s more about and no two are alike. Thus, not only are you picking a tool, but
missing approaches and missing features, and once again there you’re picking a design approach which may or may not be right for
needs to be some education out there as to how organizations need you. The tools should never dictate the approach; they should sup-
to approach SOA. port best and proven practices, as well as drive design that holisti-
First of all, those who define SOA governance as a set of tech- cally supports more strategic modeling and simulation features,
nologies are missing the boat on this concept. The humans need and supports what SOA is...an architecture.
to be factored into the equation. Second, when you do focus on The whole notion of design-time SOA governance could be
�����������������������������������������
the tools, many things that are required for good SOA governance getting us off track when it comes to the proper approach to
design are missing, and there are no signs that things will get better. SOA. This is really the fault of the humans who focus way too
������������������������
First, let’s deal with the humans. much on the technology and not the processes or approaches,
The fact of the matter is that SOA governance, and governance and the fault of the SOA design-time vendors who need to do a
in general, is really a people and process thing, with technology great deal more work on their offering, else the SOA architects
only coming into play to automate the processes and support the will just jump directly into SOA runtime governance, which, as it
people. If you don’t establish that, you’re going to fail at SOA gov- seems, many are already doing today if you look at the penetra-
ernance and thus fail at SOA, no matter how much technology you tion of the technology into the market. I suspect the design-time
“invest” in. SOA governance vendors will be fixing a lot of things this year
Thus, people rely more on tools and technology than education and next. � � ��� � � � � � � � � ����� � � �
when it comes to SOA governance, when it really needs to be the
other way around. Indeed, I promote the 80/20 rule when consid- ����������������� ������������������������ ������������������������ ����������������
ering SOA governance. 80 percent of the time, effort and money About the Author ������������ ������������ ������������ ������������
should be spent on learning how to create and operate an effective David S. Linthicum is an internationally known thought leader in the EAI, SOA, enterprise
SOA governance strategy, in terms of people and processes. Then architecture, and Web 2.0 spaces. He is a sought-after consultant, speaker, and writer, and
you can spend the remaining 20 percent learning about the tools. formed David S. Linthicum, LLC (www.davidlinthicum.com), a leading consulting organization
Most drive toward the tools first, then to the approach as defined by focusing on enterprise architecture, SOA, and use of the next-generation Web within the en- ���������������������������������������������������������������������������������
the tools. In doing that, you assume your tools are correct in their terprise. He is the former CEO of BRIDGEWERX, CTO of Grand Central Networks, as well as CTO ���������������������������������������������������������������������������������������
approach and function, which is typically not the case, and my next of Mercator Software (now a part of IBM) and SAGA software (now a part of Software AG).In �����������������������������������������������������������������������������������
point. addition, Dave was an associate professor of computer science for eight years, and continues
��������������������������������������������������������������������������������������
Now, let’s deal with the technology. to lecture at major technical colleges and universities, including University of Virginia and
The issue with design-time SOA governance technology (not Arizona State University. He keynotes at many leading technology conferences, and has sev-
����������������������������������������������������������������������������������������
runtime) is how deeply the technology goes to serving the true eral well-read columns and blogs, as well as a weekly Podcast. Dave has authored 10 books, �������������������������������������������������������������������������������������������������
notion of “design” as outlined above. The fact is that most don’t go including the ground-breaking “Enterprise Application Integration” and “B2B Application ������������������������������������������������������������������������������������������
that deep, and many who design a SOA are left wanting more robust Integration.” You can reach Dave at david@davidlinthicum.com.
features and functions, including true modeling and simulation
capabilities based on SOA design and development best practices. david@linthicumgroup.com
�����������������������
12 OCTOBER 2008 www.SOA.sys-con.com www.SOA.sys-con.com
���������������������� OCTOBER 2008 13
8. LATEST TRENDS IN SOA
toolset. As a result, the most common use of SOA technology is to tecture – and although after 23 years in the world of software I have
integrate existing inside-the-enterprise applications. not yet encountered any company that has achieved this goal, it is
SOA technology is a fine choice for internal integration projects; I still a laudable one for many practical reasons.
don’t mean to dissuade IT from using SOA. The problem is oppor- In contrast to this, when your focus is outside the enterprise,
tunity cost – if an organization focuses its SOA efforts (time, budget, not only is a single-service access method an undesirable goal, it
management attention, etc.) inside the enterprise, its opportunities is a completely unachievable goal and should not be attempted.
for meaningful innovation will be small compared with what could The reason for this is simple math. While a large company may
be accomplished outside the enterprise. have 300-1,000 internal systems that require integration and might
Doing business in the global arena creates a great number of possibly all designed to use a Web Services interoperability ap-
problems and opportunities that can only be solved outside a proach, that same company could have 20,000 suppliers or 20,000
company’s four walls. Trends of industry consolidation (mergers B2B customers, each with multiple process/data integration touch
The Next Paradigm –
and acquisitions) force companies to be ready to respond quickly points. Attempting to have this population of trading partners con-
to major structural changes in their supply chain, demand chain, form to a single technology implementation is grossly impractical.
or ownership. The complex demands of a global environment Your customers won’t accept your demands. In fact, if they are big
Multi-Enterprise SOA
– extended supply chains that must be managed, multiple tax and enough, your customers may demand what technology you must
regulatory regimes that must be accommodated, multiple subsid- use – and each customer could demand a different technology.
iaries or partners that must be coordinated – all point to the unique Your suppliers may agree to your technology demand, but to do so
requirements of and need to address the multi-enterprise environ- increases their costs and increases the price you pay them in some
ment. direct or indirect way. Even if by some miracle your community of
The practice of SOA is overdue for
There are many different multi-enterprise opportunities that trading partners could agree on a single technology, it is logistically
can provide substantial return on investment (ROI) if properly impossible for all parties to adopt or upgrade to the same version of
addressed. For example, in an AMR Research study that analyzed the same standard simultaneously.
a paradigm shift companies implementing demand-sensing solutions, several com-
panies achieved amazing results:
In a multi-enterprise SOA environment, Web Services are an
important option, and you can use them some of the time. But you
will also need to support a wide range of other options – AS2, AS3,
• 15% reduction in inventory AS4, ebXML, SOAP over JMS, FTP RosettaNet, SWIFT, etc. In the
,
BY CHRIS JOHNSON
• 17% improvement in perfect order performance end, you may not choose Web Services as your preferred chan-
• 10% higher revenue and 5%-7% higher margin than competitors nel for multi-enterprise interactions since more tightly defined
standards such as AS2 can be easier to govern and manage in a
T
It’s hard to imagine an internal systems integration project that multi-enterprise environment. Whatever your preferred channel
he concept of a paradigm shift was first could deliver business results of this magnitude. might be, being able to support a multi-channel approach is a key
popularized by Dr. Thomas Kuhn in his According to a recent Gartner report, “By 2011, midsize-to-large requirement for multi-enterprise SOA.
book The Structure of Scientific Revolu- companies will at least double the number of multi-enterprise
tions. Kuhn described a phenomenon and interoperability projects they’re managing and will spend at Heresy #3 – SOA will be a legacy technology
in which one worldview, or paradigm, is adopted least 50% more on business-to-business (B2B) projects compared For inside-the-enterprise purposes, SOA technology is modern
so widely that its concepts, beliefs, terminology, with 2006.” Gartner also says, “Global 2000 companies will double and current. However, in the multi-enterprise environment, SOA
values, and techniques eventually become unex- the number of automated multi-enterprise transactions, docu- technologies will need to be managed in much the same way as
amined assumptions, leading to a condition of ments and process-execution events between 2006 and 2011.” SOA other legacy technologies.
“paradigm paralysis” that prevents people from seeing beyond their concepts and technologies can play a crucial role in making these The reason for this is the different dynamic of technology adop-
current mode of thinking. The shift to a new paradigm is triggered multi-enterprise projects successful and can deliver a much higher tion inside and outside of the enterprise. Inside the enterprise,
only when the prior worldview is stretched beyond its limits and a ROI than internal systems integration projects. prudent IT management creates the motivation to limit the number
radical new worldview originally seen as heresy disproves central of technologies and versions in use and the rate of change from
assumptions of the prior paradigm and is widely adopted (to begin Heresy #2 – SOA isn’t (only) about Web Services one technology era to the next. Outside the enterprise, you can’t
the cycle again). Another area in which the practice of SOA is somewhat in conflict achieve that degree of control. New technologies – or new versions
The concept of Service Oriented Architecture (SOA) has caused with the broader concept of SOA in the multi-enterprise domain or combinations of technologies – will arise in such a way that you
a profound shift in the worlds of business and technology, causing is the choice of enabling technologies. While SOA thought leaders can’t avoid adopting them. There are many multi-enterprise wire
important changes that will stand the test of time in how millions are careful to point out the separation between SOA concepts and protocols, process protocols, and data standards, each of which
of people think and work. However, I believe the practice of SOA is technology for many practitioners the phrase and concept of SOA changes on its own schedule as determined by third parties. For
overdue for a paradigm shift – a shift of focus away from enterprise has become interchangeable with Web Services: instance, a typical global manufacturer might need to support ANSI
architectures and applications toward larger, fundamentally differ- X12, EDIFACT, TRADACOMS, CII, RosettaNet, HIPAA, SWIFT, ACH,
ent problems that need to be solved in the space between enter- “Even though service-orientation as a paradigm and SOA as a OFTP ... typically 20 or more separate standards. Across the same
prises – a problem/solution domain I call multi-enterprise SOA. technology architecture are each implementation-neutral, their as- manufacturer’s population of suppliers and customers, one might
Multi-enterprise SOA manages the flow of business processes sociation with Web Services has become commonplace – so much so expect to find current and older versions of technologies and stan-
and data across departmental, organizational, and geo-political that the primary SOA vendors have shaped their respective platforms dards in various combinations – the latest OAGi document format
boundaries, enabling organizations to rapidly adapt to changing Heresy #1 – IT doesn’t matter (as much) around the utilization of Web Services technology.” sent via WS-I Basic Profile 1.0-compliant Web Services, an older
business, technology, and legislative environments and facilitating For many organizations, the current practice of SOA is firmly TRADACOMS document sent via a non-standard FTP protocol, the
IT-driven growth in a way that enterprise-internal projects gener- based on the principles and habits of inside-the-enterprise infor- Selecting a single implementation technology such as Web Services latest version of a SWIFT MX message sent via a service bureau us-
ally cannot. This concept of multi-enterprise SOA includes several mation technology (IT). As practiced in many companies, SOA is, can be a sensible thing to do when your focus is inside the enter- ing AS2, and any other conceivable combination.
principles that SOA practitioners may view as heresy. in essence, just another application development and integration prise. Many companies aspire to have consistent enterprise archi- In the multi-enterprise environment, companies are accustomed
14 OCTOBER 2008 www.SOA.sys-con.com www.SOA.sys-con.com OCTOBER 2008 15
9. LATEST TRENDS IN SOA
to supporting a variety of old and new technologies and standards. subsidiaries, it’s usually the case that technology choices – infra-
Technologies you consider to be the latest and greatest could be structure, applications, standards, adoption patterns, and so on
viewed as legacy by some of your trading partners. And technolo- – are independently determined by each division and have the
gies you think of as outdated will be required by some of your same range and complexity of technologies that a similar number
trading partners for years to come. While this situation would be of external trading partners would present. This is especially true
viewed as undesirable inside the enterprise, it is expected and, to for companies that have grown through a series of acquisitions.
some degree, desirable in the multi-enterprise environment. Objec- Enterprise SOA solutions are not well suited to interoperating with
tives of multi-enterprise SOA include acknowledging and dealing this wide range of protocols and standards, but multi-enterprise
with the unavoidable complexity of the outside world (rather than SOA solutions are.
just reducing complexity) and becoming easy to do business with The same is true for companies that use business process out-
(rather than just reducing IT costs). sourcing (BPO) providers that may function like
The cost of not being easy to do business a company department or division but bring in
with is simply too great. If a trading partner a different set of technologies. Decisions to add
can’t or won’t integrate with you electronically, or change BPO providers, or bring a BPO func-
they will instead submit their purchase orders, tion in-house, causes technology churn similar to
invoices and other transactions by fax, mail changing external trading partners. As enterprises
or phone call – in which case each transaction become more virtual and make greater use of the
can have manual handling costs five times sourcing options available, the line defining the
greater than a fully electronic exchange. Multi- “enterprise” boundary can move very quickly, and
ply that expense by the number of transactions the multi-enterprise SOA approach becomes the
your company and trading partners exchange only viable way to manage this change and com-
over the course of a year and your motivation plexity.
to accommodate a wide range of potentially Lastly, most companies that have SOA infra-
legacy technologies (both inbound and out- structures actually have multiple SOA technologies
bound) becomes very clear. and vendors, and these disparate SOA infrastruc-
SOA technology in general won’t become tures also need to be integrated. In many cases, the
“legacy” until the next major revolution in disparate enterprise SOA technologies will still be
architecture thinking, but due to the need to able to interoperate. However, with a large enough
support a large number of past, present, and technology gap or design philosophy difference, a
future technologies at once in the multi-enter- multi-enterprise-style SOA solution may be a better
prise domain, the way you have to think about choice to address the range of technology differ-
and manage SOA technologies will be more ences, even between the multiple enterprise-ori-
like how you manage other (including legacy) ented SOA solutions.
technologies than the way you think about
and manage your inside-the-enterprise SOA Conclusion
technologies. All kidding and hyperbole about “heresies”
aside, the multi-enterprise view of SOA is distinctly
Heresy #4 – You need multi-enter- different from the inside-the-enterprise view and
prise SOA inside your enterprise has largely been overlooked by many SOA practitio-
The same tools and technologies you use to ners. SOA will always play a strong role inside the
solve your multi-enterprise SOA requirements enterprise, but companies shouldn’t focus on it to
are, in many cases, the best choice for solving the exclusion of the potentially greater rewards of
your inside-the-enterprise SOA requirements multi-enterprise SOA.
as well.
Most large companies function like a col- About the Author
lection of smaller distinct companies rather Chris Johnson is the vice-president of global product management
than one large uniform company. Whether the for the Integration Suite product line at Sterling Commerce, an AT&T
divisions are business units, departments, or company.
“Multi-enterprise SOA manages the flow of
business processes and data across
departmental, organizational, and
geo-political boundaries”
16 OCTOBER 2008 www.SOA.sys-con.com www.SOA.sys-con.com OCTOBER 2008 17
