Top Banner
The Next Paradigm Multi-Enterprise SOA THE WORLD’S LEADING MAGAZINE DEDICATED TO WEB SERVICES TECHNOLOGIES www.SOA.SYS-CON.com 18 SOA Innovation Applied GRACIELA TISCAREÑO-SATO 22 Getting an SOA Initiative or Continuing the Journey KADEER BEG The Next Paradigm Multi-Enterprise SOA OCTOBER 2008 / VOLUME: 8 ISSUE 10 CHRIS JOHNSON 14
19
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: SOA World Magazine-Enterprise SOA

The Next Paradigm – Multi-Enterprise

SOA

THE WORLD’S LEADING MAGAZINE DEDICATED TO WEB SERVICES TECHNOLOGIES

www.SOA.SYS-CON.com

18 SOA Innovation Applied GRACIELA TISCAREÑO-SATO

22 Getting an SOA Initiative or Continuing the Journey KADEER BEG

The The Next Next ParadigmParadigmParadigm – – – –Multi-Enterprise Multi-Enterprise Multi-Enterprise ParadigmMulti-Enterprise ParadigmParadigmMulti-Enterprise ParadigmParadigmMulti-Enterprise ParadigmMulti-Enterprise

SOAMulti-Enterprise

SOAMulti-Enterprise Multi-Enterprise

SOAMulti-Enterprise Multi-Enterprise

SOAMulti-Enterprise Multi-Enterprise

SOAMulti-Enterprise Multi-Enterprise

SOAMulti-Enterprise Multi-Enterprise

SOAMulti-Enterprise Multi-Enterprise

SOAMulti-Enterprise Multi-Enterprise

SOAMulti-Enterprise Multi-Enterprise

SOAMulti-Enterprise

SOA

The Next Paradigm – Multi-Enterprise

SOA

OCTOBER 2008 / VOLUME: 8 ISSUE 10

CHRIS JOHNSON 14

Page 2: SOA World Magazine-Enterprise SOA

2 OCTOBER 2008 www.SOA.sys-con.com OCTOBER 2008 3 www.SOA.sys-con.comwww.SYS-CON.com

www.SOA.SYS-CON.com

INTERNATIONAL ADVISORY BOARD Andrew Astor, David Chappell, Graham Glass, Tyson Hartman, Paul Lipton, Anne Thomas Manes, Norbert Mikula, George Paolini, James Phillips, Simon Phipps, Mark Potts, Martin Wolf

TECHNICAL ADVISORY BOARDJP Morgenthal, Andy Roberts, Michael A. Sick, Simeon Simeonov

EDITORIAL Editor-in-ChiefSean Rhody [email protected] XML EditorHitesh Seth Industry EditorNorbert Mikula [email protected] Product Review EditorBrian Barbash [email protected] .NET EditorDave Rader [email protected] Security EditorMichael Mosher [email protected] Research EditorBahadir Karuv, Ph.D [email protected] Technical EditorsAndrew Astor [email protected] Chappell [email protected] Thomas Manes [email protected] Sick [email protected] Wacey [email protected] International Technical EditorAjit Sagar [email protected] Executive EditorNancy Valentine [email protected]

Associate Online EditorLindsay Hock [email protected]

PRODUCTION ART DIRECTORAbraham Addo [email protected]

ASSOCIATE ART DIRECTORTami Beatty tami @sys-con.com

EDITORIAL OFFICES SYS-CON MEDIA577 CHESTNUT RIDGE ROAD, WOODCLIFF LAKE, NJ 07677TELEPHONE: 201 802-3000 FAX: 201 782-9637SOA World Magazine Digital Edition (ISSN# 1535-6906)Is published monthly (12 times a year)By SYS-CON Publications, Inc.Periodicals postage pendingWoodcliff Lake, NJ 07677 and additional mailing offices

POSTMASTER: Send address changes to:

SOA World Magazine, SYS-CON Publications, Inc.

577 Chestnut Ridge Road, Woodcliff Lake, NJ 07677

©COPYRIGHT Copyright © 2008 by SYS-CON Publications, Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy or any information storage and retrieval system without written permission. For promotional reprints, contact reprint coordinator. SYS-CON Publications, Inc., reserves the right to revise, republish, and authorize its readers to use the articles submitted for publication. All brand and product names used on these pages are trade names, service marks, or trademarks of their respective companies. SYS-CON Publications, Inc., is not affiliated with the companies or products covered in Web Services Journal.

Give Me a Sign

FROM THE EDITOR

WRITTEN BY SEAN RHODY

About the Author

Sean Rhody is the editor-in-chief of SOA World Magazine. He is a respected industry expert and a consultant with a leading

consulting services company. [email protected]

One of my favorite sayings is, “if you don’t know where you’re going, any direction will do.” While in many

cases people take that as license to do what-ever they feel like, what it really means is that before you embark on a journey, you should plan your destination. You know, get out the map, plot your direction, find out where you want to go, and what you want to accom-plish along the way. SOA is a journey, and also a destination. For most organizations, SOA is the end goal of the IT organization. They’ve begun to realize that SOA is the way that they will ultimately run their organization’s software (and to a certain extent, hardware too). Their vendors have all begun shipping their software as services, and they may even be using web-based software as a service such as Salesforce.com. So it’s now time to under-stand the destination. In order to do that, a wise organization creates a Roadmap. Just as you might consult an atlas (or MapQuest these days) to see where you are going, understanding what the stops are on the journey toward full SOA implementation and planning on how to reach them is also critical. Just as you might decide to take a scenic detour for your own enrichment (who doesn’t like seeing the changing leaves on some windswept country road over the weekend rather than driving down a soulless interstate), your company may very well choose to take a road less travelled for strategic, tactical, functional, or even financial reasons. It’s one thing to take the road less traveled upon careful planning. It’s another entirely to miss the street sign and go off road – it causes detours and rework, not to mention annoyances and loss of credibility with col-leagues and the executive committee. For many reasons, a roadmap for SOA is important, perhaps even critical to the success of the journey, or at least of the team making it. A roadmap for SOA has many aspects. It has foundational elements that include network and hardware, as well as

operating solutions. In the modern age, this includes capacity on demand, virtualized containers, and occasionally connected computing. In addition to being the platform that the SOA will run on, these foundations often expose services of their own that en-able the creation of more complex business logic or exception handling. Other elements are also important on the roadmap. The Enterprise Service Bus is a key architectural element – without it you have a point-to-point wiring issue that ultimately becomes even worse than the problems we were trying to solve in the first place. This is an area where companies seem to take detours frequently and one where, in most cases, they really should stick to the roadmap. It’s a lot easier to put in an ESB and adapt to it when you start then after you’ve done a number of implementations. One area that needs to be considered is the overall maturity of the organization with respect to SOA. There are multiple dimen-sions of maturity – you can look at technol-ogy, standards, security, governance, and management. All of these areas have differ-ent qualifications and levels associated with them that lead to an overall maturity level. A typical roadmap identifies these dimen-sions as well as the projects that will be undertaken to get to the end goal. In security it may be a first project toward single sign-on that will eventually lead to the basis for security as a service as part of the underlying infrastructure. There may be a discussion of core IT services that should be provided as part of the infrastructure. There may be a rationalization project to help align redun-dant business processes or applications. A good roadmap is multi-dimensional and includes a timeline. It may even (dare I say it) outline the dependencies each project has with respect to one another. Finally, a good roadmap is hard to create. It takes insight, it takes commitment, and it takes leadership. Before you take another step, ask yourself: “Do I know where I’m going?” If not, it’s probably time to get out the map.

Page 3: SOA World Magazine-Enterprise SOA

4 OCTOBER 2008 www.SOA.sys-con.com

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

Page 4: SOA World Magazine-Enterprise SOA

6 OCTOBER 2008 www.SOA.sys-con.com OCTOBER 2008 7 www.SOA.sys-con.com

CORPORATE President and CEOFuat Kircaali [email protected]

Senior VP, Editorial & EventsJeremy Geelan [email protected]

ADVERTISING Senior VP, Sales & MarketingCarmen Gonzalez [email protected] Advertising Sales DirectorMegan Mussa [email protected] Advertising & Events ManagerCorinna Melcon [email protected]

Events AssociatesKrisandra Russo [email protected] Susan Wechtler [email protected]

CUSTOMER RELATIONS Circulation Service CoordinatorsEdna Earle Russell [email protected]

SYS-CON.COM Consultant Information SystemsRobert Diamond [email protected] Web DesignersRichard Walter [email protected] Joon Kim [email protected]

ACCOUNTING Financial AnalystJoan LaRose [email protected] Accounts PayableBetty White [email protected]

[email protected] or 1-888-303-5282For subscriptions and requests for bulk orders, please send your letters to Subscription DepartmentCover Price: $6.99/issueDomestic: $99/yr (12 issues)(U.S. Banks or Money Orders)

For list rental information: Kevin Collopy: 845 731-2684, [email protected]; Frank Cipolla: 845 731-3832, [email protected]

SYS-CON Publications, Inc., reserves the right to revise, republish and authorize its readers to use the articles submitted for publication.

www.SYS-CON.com

www.SOA.SYS-CON.com

TAXONOMY

Creating an Effective SOA Service Taxonomy

BY MARK RICHARDS

It’s hard to think about Service Oriented Architecture without think-ing of services; after all, services are the main focus of SOA (it’s even in the name). If Service Oriented Architecture is an approach where the business and technical architecture is oriented around services,

then what exactly is a service? Unfortunately, the answer to this ques-tion varies greatly depending on whom you talk to and how you’re using SOA in your organization. This variation tends to create quite a bit of confusion when trying to design and implement a SOA-based solution. There are several excellent service-oriented methodologies available

today, most of which describe processes for identifying, defining, specifying, implement-ing, and governing services. While these methodologies provide the direction and tools necessary to help realize SOA in your organization, they don’t address the fundamental question about what a service actually is. A service is hard to define because there are in fact many different types of services in Service Oriented Architecture. Understanding what types of services exist, how those service types are defined and related, and how they are communicated to the stakehold-ers in your organization are key to any SOA-based initiative. In this article I will describe a method for building a SOA Service Taxonomy that will help you effectively classify services for the SOA-based initiatives in your organization.

Overview Taxonomy is a way of classifying things using a hierarchical classification structure. We use a hierarchical classification system to classify animals into phyla, classes, orders, fami-lies, genera, and finally species. Using this classification scheme we can group animals with similar characteristics and features, from the very general (phylum) to the very specific (species). We can apply these same concepts to the way we classify and define service types in a SOA. However, unlike the binomial nomenclature originally laid down by Carl Lin-naeus, there exists no foundational nomenclature for developing a hierarchical classifica-tion of services in a SOA. Fortunately, creating a classification scheme and categorizing SOA services is infinitely simpler than the task Mr. Linnaeus had several hundred years earlier. However, we still seem to get it wrong. Service Taxonomy is a way of classifying various types of services used in SOA. The purpose of a hierarchical service classification scheme is to provide clear, concise, and non-overlapping definitions for the various types of service you might use and encounter during a SOA initiative. An effective service classification will help facilitate communication between the various groups and individuals involved in a SOA initiative, from business us-ers to application developers. It does this by providing a common and accepted language, allowing more effective communication between the various stakeholders in your organi-zation. Since we don’t have a standard means of classifying the types of services in a SOA, we unfortunately have to create a new classification hierarchy every time we embark on a new SOA initiative. Service classifications differ greatly among various companies and SOA

What exactly is a service?

OK

Prepared by Goodby, Silverstein & Partners 2008. All rights reserved. 415.392.0669

Released on 07.14.08Print Output at 100% Reader 1

ClientJob Number

Ad Number

Ad-ID

Job Title

File Name

File Format

Start Date

Color / Media

1st Close

1st Insertion

Vendor

Pubs

B

T

L

G

S

PeopleCreative Director

Associate CD

Art Director

Copywriter

Proofreader

Account Manager

Asst. Account Manager

Print Producer

Project Manager

Client

Production Artist

Mechanical SpecsHP TSGHPTSG-281000084EQUP11610000SOA Software DG - Resize B PageHPTSG-281_SOA Software DG_B pg.inddAdobe InDesign CS37/11/08 2:40 PM4/c MagNoneNoneXYZ GraphicsNone

8.625 in x 11 in8.375 in x 10.75 in7.875 in x 10.25 inNone1 in = 1 in

Bill to HPTSG-201

Keith AndersonNoneBrian GundersonBrian ThompsonShannon / Sage / JenLiz HolperLeigh Mc DanielKatie BorzcikLisa NicolayNoneJessica Pettigrew @ 7/14/08 3:46 PM

Notes

©2008 Hewlett-Packard Development Company, L.P.

Technology for better business outcomes. hp.com/go/soa

A LT E R N A T I V E T H I N K I N G A B O U T S E R V I C E - O R I E N T E D A R C H I T E C T U R E :

Rethink The Architecture, Rethink The Business. (Rethink Your Bottom Line.)

Alternative thinking is shifting your SOA strategy to focus on business initiatives rather than technology initiatives. (Head in the game, not on bits and bytes.)

It’s using governance to speed the adoption and reuse of services—keeping everything from getting out of hand.

It’s building quality and management into every step, from idea through execution, to help ensure you’re always up and running smoothly.

It’s capitalizing on software that works across platforms, so your business operates effi ciently through mergers and acquisitions and alliances and massive growth.

It’s choosing the right SOA partner so you can get on with the business of the business. (Hello, tomorrow.)

1722907.14.08

GSPcl

150FortuneM17229_HPTSG-281_SOA_Sftwr_DG_Bpg

Cyan Magenta Yellow Black

S:7.875 inS:10.25 in

T:8.375 inT:10.75 in

B:8.625 inB

:11 in

Page 5: SOA World Magazine-Enterprise SOA

8 OCTOBER 2008 www.SOA.sys-con.com OCTOBER 2008 9 www.SOA.sys-con.com

TAXONOMY

initiatives; some get it right, but most seem to get it wrong. How to recognize a good classification and poor classification is part of what this article is about; the other part is how to build off of a standard set of service classifications to create a more effective clas-sification scheme for your SOA initiative. An effective service taxonomy is one in which the service type definitions are clear, concise, and most importantly non-overlap-ping. When creating a service taxonomy you should try to simplify

essential complexity (complexity that is inherent in the problem domain itself) while at the same time trying to avoid accidental complexity (unnecessary complexity we introduce ourselves). One way to accomplish this is to start with four basic SOA service types, and only extend these service types if necessary.

The Basic SOA Service Types When developing any SOA service taxonomy, a good place to start is with the four basic service types: Business Service, Enter-prise Service, Application Service, and Infrastructure Service. This is the simplest possible hierarchy, and in most cases will probably satisfy the needs of your particular domain or initiative. The follow-ing diagram illustrates the basic service classification structure: The following sections describe the attributes and characteris-tics of each of these four basic SOA service types. While you will most likely find these types sufficient for your particular needs, you can certainly extend these further if needed. I present some guidelines at the end of this article on when this makes sense and how to avoid the common pitfalls associated with extending this basic hierarchy.

Business Services Services contained in this service type are considered core services in SOA. They can be derived from use cases, user stories, user scenarios, or through the service identification and specifi-cation steps found in many SOA-based methodologies. They are course-grained, usually identified and defined by business users, and represent a business process or function. When choreographed they represent the manifestation of a high-level use case or user scenario. Business Services are abstract definitions containing a service name, input specification, and output specification inde-pendent of the underlying technology. In other words, the input and output specifications to the service represent data and infor-mation collected and consumed by the service. For example, to produce an auto quote an insurance com-pany collects specific information from the customer, stores that information, and then presents the auto quote to the customer. The information the insurance company collects for creating the auto quote would be represented in the service input specifica-tion, and the information it provides back to the customer would be represented in the service output specification. The name of this business service might be CreateQuote. It’s important to real-ize that the input and output data specification for this business service is completely independent of the underlying technology, language, or platform used to implement the business service. Technically speaking, while Business Services are typically imple-mented through standards such as WSDL (Web Services Definition Language), they can be implemented in any sort of CDL (Contract Definition Language), be it WSDL, XML, or some other interface language. The name of a Business Service is typically constructed in a verb-noun format, with the verb being one of the typical CRUD verbs (Create, Read (or get), Update, and Delete) and the noun representing one of the major business entities found in a typical Business Entity Model. Examples of typical Business Services include CreateQuote, ExecuteTrade, GetCustomer, GetPolicy, and PlaceOrder. A service classification template containing the primary char-acteristics for the service type of Business Service might look as follows:

Enterprise Services Services contained in this service type are also considered core SOA services. Enterprise Services are concrete services that imple-ment Business Services. The relationship between an Enterprise Service and a Business Service is either a one-to-one or many-to-one relationship (many Enterprise Services implement a single Business Service). Since Enterprise Services have scope across application domains, they are typically identified and defined by an Enterprise IT Architect or a shared services team. They are concrete services, meaning they are implemented through some sort of underlying technology or vendor product. Like Business Services, these services are typically course-grained and represent actions against major data entities. Since the relationship between an Enterprise Service and a Busi-ness Service is commonly a many-to-one relationship, Enterprise Services usually require some sort of service orchestration, which can be implemented through an aggregate service or through middleware technology (e.g., Enterprise Service Bus or workflow engine). For example, several Enterprise Services would need to be orchestrated to implement a CreateQuote Business Service, includ-ing createCustomer, checkMotorVehicleReport, calulateQuote, saveQuote, and so on. A common misconception is that Enterprise Services must be shared across the enterprise. Although Enterprise Services are gen-erally shared, it is certainly not a requirement. However, Enterprise Services should be course-grained and have the ability to be shared across the enterprise if needed. Enterprise Services have scope within the context of a Business Service, and therefore implement some sort of business logic. For example, an auditing service, although required for regulatory com-pliance, would not be considered an Enterprise Service. Rather, that type of service would be classified under Infrastructure Services (described below) because it does not directly serve a specific busi-ness function. The potential impedance mismatch between the data (and format) specified in the Business Service and the data (and format) expected by the Enterprise Service implementation is usually ad-dressed through message transformation and message enhance-ment, which are usually implemented through XSLT transforma-tions located in a middleware component or Enterprise Service Bus. A service classification template containing the primary char-acteristics for the service type of Enterprise Service might look as follows:

Application Services While an Application Service is considered a basic service type, services contained in this service type are not considered core ser-vices within the context of SOA; rather, they are referred to as sup-porting services. These concrete services are usually fine-grained and are associated with a specific application. In other words, they have application (or silo) scope and therefore are generally not shared in the enterprise. Application Services are typically identi-fied and defined by application developers and are specific to the application scope they are defined under. Application Services are generally used to perform fine-grained application-specific functions such as validation, data collection, and data transfer. For example, when creating an auto quote the ap-plication developer may create services such as addDriver, addAd-dress, addVehicle, and so on. These services are used to accumulate

the data needed by the Business Service as defined by the Business Service input and output specification. A service classification template containing the primary char-acteristics for the service type of Application Service might look as follows:

Infrastructure Services This service type classification defines those services that are used to support the enterprise. Examples of Infrastructure Services include such aspects as logging, auditing, data access, security, and so on. These concrete services are generally shared by the enter-prise and used by Enterprise Services (and sometimes Application Services). What distinguishes Infrastructure Services from Enterprise Services is that Infrastructure Services implement non-business functionality. The gray area between Infrastructure Services and Enterprise Services appears when considering such regulatory requirements as auditing and compliance. Although some forms of auditing and compliance are designated as business requirements, these services do not specifically address a particular user or busi-ness function; rather, they support the business requirements. Infrastructure Services are typically identified and implemented by application developers or an infrastructure support team. They generally have enterprise-level scope, which is one reason they are typically confused with Enterprise Services. A service classification template containing the primary charac-teristics for the service type of Infrastructure Service might look as follows:

Service Taxonomy Guidelines You can certainly extend the basic four service types either horizontally or vertically to suit your particular needs. However, before considering extending the basic hierarchy, you may want to consider the following service taxonomy guidelines:

• Start your service taxonomy with the four basic service types described above first. If you think you need an additional service type at the same level, make sure it is non-overlapping with respect to other service types. If you think you need an additional breakdown of service types below the basic level, then read on.

• Avoid the common pitfall of creating domain specific service types (i.e., types that are specific to divisions or functional groups within your domain). For example, if in the insurance domain, avoid creating service types such as Claims Services, Policy Services, and so on. These are not service types, but rather actual domain service names that are represented through the various types of services. To put it another way, there are many differ-ent service types that constitute a Claims Service (e.g., Business Services and Enterprise Services). Don’t confuse an actual service name (e.g., Policy Service) with the service type (e.g., Business Service).

• Keep your classification hierarchy taxonomy as simple as possible and avoid accidental complexity; remember one of the goals of the service taxonomy is to facilitate communication between the various stakeholders and groups involved in the SOA initiative. A complex hierarchy of service types will create confusion and hinder the basic understanding of the service types you are using. A complex hierarchy invariably leads to increased debates and

Figure1

Figure2

Figure3

Figure 4

Figure5

Page 6: SOA World Magazine-Enterprise SOA

10 OCTOBER 2008 www.SOA.sys-con.com OCTOBER 2008 11 www.SOA.sys-con.com

TAXONOMY

�������������������������

ISB

N 0

-977

7622

-0-3

from the World s̓ Leading i-Technology Publisher�����������������

© COPYRIGHT 2007 SYS-CON MEDIA�������������

ISB

N 0

-977

7622

-2-X

ISB

N 0

-977

7622

-2-X

��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

�������������������������������������

from the World s̓ Leading i-Technology Publisher�����������������

© COPYRIGHT 2007 SYS-CON MEDIA�������������

���������������������������������������������������������������������������������������������������������������������������������������������

������

���������

�������

����������

���������

��������

���������

�������

������������������������������������������������������������������������������

���������������������������������������������

�������������������������������

��������������������������������������

�������������������������������

����������������������������������������������������������������������������������������

� �����������������������������������������������������������������������������������

������

���������

�������

����������

��������

�������

��������

�������

lengthy meetings about how deep and wide the hierarchy should extend, and also increases the chance for overlapping service types in your classification hierarchy.

• Consider creating a simple context diagram showing the relation-ship between the different service types in the service taxonomy, particularly if your classification hierarchy extends beyond the basic four service types. This can greatly help in understanding where the service types fit into the big picture.

• Create an agreed-upon template for recording the definition and attributes of the service taxonomy. In general a tree-graph coupled with a context diagram and a simple document template is all that’s needed to effectively document and communicate the service taxonomy. Try not to go overboard with complex tools or UML to describe the hierarchy. If you need such tools, chances are your service taxonomy is too complex and should be simpli-fied.

• Don’t wait until the SOA initiative is well underway before beginning to put together a service taxonomy; start creating a

taxonomy as soon as the SOA initiative starts by using the basic SOA service types and refining it as necessary during the project initiation phase of the initiative.

• If you end up with something like a “duck-billed platypus” when creating the service taxonomy, stop and revisit how you are defining your service types. After all, you are just classifying service types, not something as complex as the animal kingdom. Chances are you are introducing accidental complexity and mak-ing the service hierarchy more complex than it actually needs to be. Keep it simple.

Summary An effective service taxonomy developed early in your SOA initiative can significantly improve your chances for success. Com-munication, clarity, and collaboration between the stakeholders in a SOA initiative are all key to the success of the overall effort. Start simple, use the four basic service types (Business Service, Enter-prise Service, Application Service, and Infrastructure Service), and only extend the classification hierarchy only when necessary. Make Mr. Linnaeus proud.

About the AuthorMark Richards is a director and senior solutions architect at Collaborative Consulting, LLC,

where he is involved in the architecture and design of large-scale Service Oriented Architec-

tures in J2EE and other technologies, primarily in the financial services industry. He served

as the president of the Boston Java User Group in 1997 and 1998, and the president of the

New England Java Users Group from 1999 to 2004. He is the author of several technical

books, and speaks at conferences around the country. Prior to joining Collaborative Consulting

Mark served as an executive IT architect at IBM with a focus on SOA in the financial services

industry.

“An effective service taxonomy developed early in your SOA initiative can significantly improve your chances for success”

������������������������������������������������������������������

������������������������������������������

������������������������������������

�����������������������������

�������������������������������������������

��������������������������������������������������������������������������������������������������������������������������

��������������������������������������������������������������������������������������������������������������������������������

����������������������������������������������������������������������������������������������������������������������

������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

���������������������������������

Page 7: SOA World Magazine-Enterprise SOA

12 OCTOBER 2008 www.SOA.sys-con.com OCTOBER 2008 13 www.SOA.sys-con.com

GOVERNANCE

You need SOA governance, design time, and runtime. However, SOA gover-nance does not come out of a box. Simply put, it’s really a matter of people

and processes put in place to insure that the services are designed, deployed, and operated as effectively as possible. However, people and SOA vendors seem to be dropping the ball around

design time, in terms of both people and tools. It’s more about missing approaches and missing features, and once again there needs to be some education out there as to how organizations need to approach SOA. First of all, those who define SOA governance as a set of tech-nologies are missing the boat on this concept. The humans need to be factored into the equation. Second, when you do focus on the tools, many things that are required for good SOA governance design are missing, and there are no signs that things will get better.First, let’s deal with the humans. The fact of the matter is that SOA governance, and governance in general, is really a people and process thing, with technology only coming into play to automate the processes and support the people. If you don’t establish that, you’re going to fail at SOA gov-ernance and thus fail at SOA, no matter how much technology you “invest” in. Thus, people rely more on tools and technology than education 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 should be spent on learning how to create and operate an effective SOA governance strategy, in terms of people and processes. Then you can spend the remaining 20 percent learning about the tools. Most drive toward the tools first, then to the approach as defined by the tools. In doing that, you assume your tools are correct in their approach and function, which is typically not the case, and my next point. Now, let’s deal with the technology. The issue with design-time SOA governance technology (not runtime) is how deeply the technology goes to serving the true notion of “design” as outlined above. The fact is that most don’t go that deep, and many who design a SOA are left wanting more robust features and functions, including true modeling and simulation capabilities based on SOA design and development best practices.

They don’t consider SOA holistically, but instead focus on the design and management of new and existing services. That’s a very small part of SOA, when you get right down to it. Another issue with design-time SOA governance technology, and as with most SOA technology, is the lack of a standard approach to design-time SOA governance. While there are a few standards emerging, most SOA governance technology providers have gone off in their own proprietary directions, using their own approaches, and no two are alike. Thus, not only are you picking a tool, but you’re picking a design approach which may or may not be right for you. The tools should never dictate the approach; they should sup-port best and proven practices, as well as drive design that holisti-cally supports more strategic modeling and simulation features, and supports what SOA is...an architecture. The whole notion of design-time SOA governance could be getting us off track when it comes to the proper approach to SOA. This is really the fault of the humans who focus way too much on the technology and not the processes or approaches, and the fault of the SOA design-time vendors who need to do a great deal more work on their offering, else the SOA architects will just jump directly into SOA runtime governance, which, as it seems, many are already doing today if you look at the penetra-tion of the technology into the market. I suspect the design-time SOA governance vendors will be fixing a lot of things this year and next.

About the Author

David S. Linthicum is an internationally known thought leader in the EAI, SOA, enterprise

architecture, and Web 2.0 spaces. He is a sought-after consultant, speaker, and writer, and

formed David S. Linthicum, LLC (www.davidlinthicum.com), a leading consulting organization

focusing on enterprise architecture, SOA, and use of the next-generation Web within the en-

terprise. He is the former CEO of BRIDGEWERX, CTO of Grand Central Networks, as well as CTO

of Mercator Software (now a part of IBM) and SAGA software (now a part of Software AG).In

addition, Dave was an associate professor of computer science for eight years, and continues

to lecture at major technical colleges and universities, including University of Virginia and

Arizona State University. He keynotes at many leading technology conferences, and has sev-

eral well-read columns and blogs, as well as a weekly Podcast. Dave has authored 10 books,

including the ground-breaking “Enterprise Application Integration” and “B2B Application

Integration.” You can reach Dave at [email protected].

[email protected]

Design Time SOA Governance Needs Some Work...Humans and Tools

BY DAVID S. LINTHICUM

����������������������

���������������������������������������������������������������������������������

���������������������������������������������������������������������������������������

�����������������������������������������������������������������������������������

��������������������������������������������������������������������������������������

����������������������������������������������������������������������������������������

�������������������������������������������������������������������������������������������������

������������������������������������������������������������������������������������������

�����������������������

�����������������������������������������������������������������

������������������������������������

������������������������������������

����������������������������

������������������������������������������

�����������������������������

Page 8: SOA World Magazine-Enterprise SOA

14 OCTOBER 2008 www.SOA.sys-con.com OCTOBER 2008 15 www.SOA.sys-con.com

LATEST TRENDS IN SOA

toolset. As a result, the most common use of SOA technology is to integrate existing inside-the-enterprise applications. SOA technology is a fine choice for internal integration projects; I don’t mean to dissuade IT from using SOA. The problem is oppor-tunity cost – if an organization focuses its SOA efforts (time, budget, management attention, etc.) inside the enterprise, its opportunities for meaningful innovation will be small compared with what could be accomplished outside the enterprise. Doing business in the global arena creates a great number of problems and opportunities that can only be solved outside a company’s four walls. Trends of industry consolidation (mergers and acquisitions) force companies to be ready to respond quickly to major structural changes in their supply chain, demand chain, or ownership. The complex demands of a global environment – extended supply chains that must be managed, multiple tax and regulatory regimes that must be accommodated, multiple subsid-iaries or partners that must be coordinated – all point to the unique requirements of and need to address the multi-enterprise environ-ment. There are many different multi-enterprise opportunities that can provide substantial return on investment (ROI) if properly addressed. For example, in an AMR Research study that analyzed companies implementing demand-sensing solutions, several com-panies achieved amazing results:

• 15% reduction in inventory• 17% improvement in perfect order performance• 10% higher revenue and 5%-7% higher margin than competitors

It’s hard to imagine an internal systems integration project that could deliver business results of this magnitude. According to a recent Gartner report, “By 2011, midsize-to-large companies will at least double the number of multi-enterprise and interoperability projects they’re managing and will spend at least 50% more on business-to-business (B2B) projects compared with 2006.” Gartner also says, “Global 2000 companies will double the number of automated multi-enterprise transactions, docu-ments and process-execution events between 2006 and 2011.” SOA concepts and technologies can play a crucial role in making these multi-enterprise projects successful and can deliver a much higher ROI than internal systems integration projects.

Heresy #2 – SOA isn’t (only) about Web Services Another area in which the practice of SOA is somewhat in conflict with the broader concept of SOA in the multi-enterprise domain is the choice of enabling technologies. While SOA thought leaders are careful to point out the separation between SOA concepts and technology for many practitioners the phrase and concept of SOA has become interchangeable with Web Services:

“Even though service-orientation as a paradigm and SOA as a technology architecture are each implementation-neutral, their as-sociation with Web Services has become commonplace – so much so that the primary SOA vendors have shaped their respective platforms around the utilization of Web Services technology.”

Selecting a single implementation technology such as Web Services can be a sensible thing to do when your focus is inside the enter-prise. Many companies aspire to have consistent enterprise archi-

tecture – and although after 23 years in the world of software I have not yet encountered any company that has achieved this goal, it is still a laudable one for many practical reasons. In contrast to this, when your focus is outside the enterprise, not only is a single-service access method an undesirable goal, it is a completely unachievable goal and should not be attempted. The reason for this is simple math. While a large company may have 300-1,000 internal systems that require integration and might possibly all designed to use a Web Services interoperability ap-proach, that same company could have 20,000 suppliers or 20,000 B2B customers, each with multiple process/data integration touch points. Attempting to have this population of trading partners con-form to a single technology implementation is grossly impractical. Your customers won’t accept your demands. In fact, if they are big enough, your customers may demand what technology you must use – and each customer could demand a different technology. Your suppliers may agree to your technology demand, but to do so increases their costs and increases the price you pay them in some direct or indirect way. Even if by some miracle your community of trading partners could agree on a single technology, it is logistically impossible for all parties to adopt or upgrade to the same version of the same standard simultaneously. 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, AS4, ebXML, SOAP over JMS, FTP, RosettaNet, SWIFT, etc. In the end, you may not choose Web Services as your preferred chan-nel for multi-enterprise interactions since more tightly defined standards such as AS2 can be easier to govern and manage in a multi-enterprise environment. Whatever your preferred channel might be, being able to support a multi-channel approach is a key requirement for multi-enterprise SOA.

Heresy #3 – SOA will be a legacy technology For inside-the-enterprise purposes, SOA technology is modern and current. However, in the multi-enterprise environment, SOA technologies will need to be managed in much the same way as other legacy technologies. The reason for this is the different dynamic of technology adop-tion inside and outside of the enterprise. Inside the enterprise, prudent IT management creates the motivation to limit the number of technologies and versions in use and the rate of change from one technology era to the next. Outside the enterprise, you can’t achieve that degree of control. New technologies – or new versions or combinations of technologies – will arise in such a way that you can’t avoid adopting them. There are many multi-enterprise wire protocols, process protocols, and data standards, each of which changes on its own schedule as determined by third parties. For instance, a typical global manufacturer might need to support ANSI X12, EDIFACT, TRADACOMS, CII, RosettaNet, HIPAA, SWIFT, ACH, OFTP ... typically 20 or more separate standards. Across the same manufacturer’s population of suppliers and customers, one might expect to find current and older versions of technologies and stan-dards in various combinations – the latest OAGi document format sent via WS-I Basic Profile 1.0-compliant Web Services, an older TRADACOMS document sent via a non-standard FTP protocol, the latest version of a SWIFT MX message sent via a service bureau us-ing AS2, and any other conceivable combination. In the multi-enterprise environment, companies are accustomed

The concept of a paradigm shift was first popularized by Dr. Thomas Kuhn in his book The Structure of Scientific Revolu-tions. Kuhn described a phenomenon

in which one worldview, or paradigm, is adopted so widely that its concepts, beliefs, terminology, values, and techniques eventually become unex-amined assumptions, leading to a condition of

“paradigm paralysis” that prevents people from seeing beyond their current mode of thinking. The shift to a new paradigm is triggered only when the prior worldview is stretched beyond its limits and a radical new worldview originally seen as heresy disproves central assumptions of the prior paradigm and is widely adopted (to begin the cycle again). The concept of Service Oriented Architecture (SOA) has caused a profound shift in the worlds of business and technology, causing important changes that will stand the test of time in how millions of people think and work. However, I believe the practice of SOA is overdue for a paradigm shift – a shift of focus away from enterprise architectures and applications toward larger, fundamentally differ-ent problems that need to be solved in the space between enter-prises – a problem/solution domain I call multi-enterprise SOA. Multi-enterprise SOA manages the flow of business processes and data across departmental, organizational, and geo-political boundaries, enabling organizations to rapidly adapt to changing business, technology, and legislative environments and facilitating IT-driven growth in a way that enterprise-internal projects gener-ally cannot. This concept of multi-enterprise SOA includes several principles that SOA practitioners may view as heresy.

Heresy #1 – IT doesn’t matter (as much) For many organizations, the current practice of SOA is firmly based on the principles and habits of inside-the-enterprise infor-mation technology (IT). As practiced in many companies, SOA is, in essence, just another application development and integration

The Next Paradigm – Multi-Enterprise SOA

BY CHRIS JOHNSON

The practice of SOA is overdue for a paradigm shift

Page 9: SOA World Magazine-Enterprise SOA

16 OCTOBER 2008 www.SOA.sys-con.com OCTOBER 2008 17 www.SOA.sys-con.com

to supporting a variety of old and new technologies and standards. Technologies you consider to be the latest and greatest could be viewed as legacy by some of your trading partners. And technolo-gies you think of as outdated will be required by some of your trading partners for years to come. While this situation would be viewed as undesirable inside the enterprise, it is expected and, to some degree, desirable in the multi-enterprise environment. Objec-tives of multi-enterprise SOA include acknowledging and dealing with the unavoidable complexity of the outside world (rather than just reducing complexity) and becoming easy to do business with (rather than just reducing IT costs). The cost of not being easy to do business with is simply too great. If a trading partner can’t or won’t integrate with you electronically, they will instead submit their purchase orders, invoices and other transactions by fax, mail or phone call – in which case each transaction can have manual handling costs five times greater than a fully electronic exchange. Multi-ply that expense by the number of transactions your company and trading partners exchange over the course of a year and your motivation to accommodate a wide range of potentially legacy technologies (both inbound and out-bound) becomes very clear. SOA technology in general won’t become “legacy” until the next major revolution in architecture thinking, but due to the need to support a large number of past, present, and future technologies at once in the multi-enter-prise domain, the way you have to think about and manage SOA technologies will be more like how you manage other (including legacy) technologies than the way you think about and manage your inside-the-enterprise SOA technologies.

Heresy #4 – You need multi-enter-prise SOA inside your enterprise The same tools and technologies you use to solve your multi-enterprise SOA requirements are, in many cases, the best choice for solving your inside-the-enterprise SOA requirements as well. Most large companies function like a col-lection of smaller distinct companies rather than one large uniform company. Whether the divisions are business units, departments, or

subsidiaries, it’s usually the case that technology choices – infra-structure, applications, standards, adoption patterns, and so on – are independently determined by each division and have the same range and complexity of technologies that a similar number of external trading partners would present. This is especially true for companies that have grown through a series of acquisitions. Enterprise SOA solutions are not well suited to interoperating with this wide range of protocols and standards, but multi-enterprise SOA solutions are. The same is true for companies that use business process out-

sourcing (BPO) providers that may function like a company department or division but bring in a different set of technologies. Decisions to add or change BPO providers, or bring a BPO func-tion in-house, causes technology churn similar to changing external trading partners. As enterprises become more virtual and make greater use of the sourcing options available, the line defining the “enterprise” boundary can move very quickly, and the multi-enterprise SOA approach becomes the only viable way to manage this change and com-plexity. Lastly, most companies that have SOA infra-structures actually have multiple SOA technologies and vendors, and these disparate SOA infrastruc-tures also need to be integrated. In many cases, the disparate enterprise SOA technologies will still be able to interoperate. However, with a large enough technology gap or design philosophy difference, a multi-enterprise-style SOA solution may be a better choice to address the range of technology differ-ences, even between the multiple enterprise-ori-ented SOA solutions.

Conclusion All kidding and hyperbole about “heresies” aside, the multi-enterprise view of SOA is distinctly different from the inside-the-enterprise view and has largely been overlooked by many SOA practitio-ners. SOA will always play a strong role inside the enterprise, but companies shouldn’t focus on it to the exclusion of the potentially greater rewards of multi-enterprise SOA.

About the Author

Chris Johnson is the vice-president of global product management

for the Integration Suite product line at Sterling Commerce, an AT&T

company.

LATEST TRENDS IN SOA

“Multi-enterprise SOA manages the flow of business processes and data across

departmental, organizational, and geo-political boundaries”

Page 10: SOA World Magazine-Enterprise SOA

18 OCTOBER 2008 www.SOA.sys-con.com OCTOBER 2008 19 www.SOA.sys-con.com

Are you a victim of outdated call center design syndrome? Symptoms include chaotic agent desktops, frustrated agents, miserable first-contact resolution rates, and angry customers calling back again and again.

If you recognize these symptoms, then you’re most likely a victim. This article will offer a Service Oriented Architecture (SOA)-based cure for outdated call center syndrome. A customer perspective of unique new integration capabilities enabled by SOA will illustrate the value of embracing this approach to power new services in the contact center, the enterprise, and between the two.

The Problem Many contact centers today have outdated design elements creating artificial boundaries between user interfaces and system administration. Customer service representatives are frequently forced to juggle a wide array of tools while attempting to serve a customer: using the requisite CRM system, e-mail, collaboration tools, instant messaging (IM), outbound calling scripts, and maybe more. The agent desktop can become a jumbled mess of disconnected systems. This causes terrible operational inefficiencies for the busi-ness plus high frustration levels for both the agent and the custom-er. Somewhere in the middle of navigating multiple systems while an impatient customer explains this is the third time he’s calling, the agent’s focus shifts away from the customer’s request to, “Where did I put that mobile number for that technical guy?” Contact center managers will almost universally agree that they are measured on customer satisfaction levels with the services the center provides. They will also admit that existing sys-tem fragmentation often hinders the abil-ity of agents (and subject matter experts) to get a customer’s inquiry or problem resolved in one call – a metric known as first call resolution (FCR). The result? Substandard customer service and miserable FCR rates, which can barely be measured because of the fractured nature of legacy contact center systems.

The Business Goal The business goal, therefore, is to have a high FCR rate. High FCR indicates the

center’s staff is enabled to satisfy customers the first time they call. This in turn creates loyal customers who are likely to spend again. One hundred percent FCR is the elusive goal, but it’s nearly impos-sible to achieve or measure today. Most systems deployed today were designed using proprietary standards intended for a single use only, and only within the walls of the physical center. Those systems were never intended to integrate with other software or processes that could provide a major boost in FCR. Enter the era of unified communications (UC) architected on SOA and built on open standards. This is communications software designed for maximum integration into other applications and business processes with shorter development cycles and potentially lower deployment costs. These new solutions provide contact center agents and managers a single view of all available customer databases, corporate directories and communications capabilities. If the center’s manager is logged in from an airport, then she sees the same view she’d see within the walls of the center. If an agent is permanently home based, then the UC-based solution provides all the capabilities and information that the agent would have without the real estate expense for the business or the commute for the agent.

The Integrated SOA Cockpit How is an integrated SOA cockpit possible? Simply answered, it’s possible through the componentized nature of the SOA on which these solutions are built. Code is designed to be reusable. An IT staff can design new ways to link services that deliver innovative approaches to business process problems. Solutions built from

the ground up using the SOA architecture (and the open standards associated with it) assume that integration into other applica-tions is desirable. This is the opposite of the proprietary code of the 20th century. For example, the familiar graphical user interface (GUI) of the agent desktop ap-plication can serve as a single, highly intui-tive user interface into which corporate di-rectory access is fully blended and available at the agents’ fingertips. Similarly, an audio conferencing service and real-time availabil-ity information can also easily be integrated turning the SOA-based agent desktop into a more powerful customer interaction cockpit.

SOA APPROACH

With such an integrated solution, agents can easily collaborate with subject matter experts when a customer escalates an issue even if the agent is sitting in a remote office and the expert is working from home. When a contact center is virtualized in this fashion and knowl-edge can truly flow from anywhere quickly and more accurately to address the customer’s questions, FCR rates can suddenly go from mysterious and unquantifiable to being the competitive advantage that meets strategic corporate goals of world class service, revenue protection and growth.

Seeing the Future Today Rick Tillotson, assistant information technology director –telecommunications, for the Texas Association of School Boards (TASB), has seen this future and has thought about how this new level of integration would benefit his organization. Four years ago, the TASB installed a Siemens contact center solution (HiPath ProCenter) to better serve its 7,000 school board members and administrative staff in all 1,036 school districts in the state. TASB (www.tasb.org), one of the strongest school board associa-tions in the country, manages a healthy investment pool, runs an online purchasing cooperative that sells everything from pencils to big yellow school buses and publishes school policy manuals online for its membership. Its biggest undertaking, however, is risk management. TASB offers members property-casualty, unemployment, and workers’ compensation coverage. This line of business also gets the most calls at TASB — fielding around 165,000 of the 190,000 calls into the organization’s contact centers each year. TASB’s existing solution provides excellent real-time availability status of agents to supervisors and managers in the various centers at their headquarters. They also have home-based agents around the Austin area and spread throughout Texas. At one site many small call centers act as autonomous groups. TASB’s highly special-ized agents have knowledge of legal rulings and regulations and are very one-to-one member focused. Yet even with this excellent operation in the contact center, Til-lotson said, “We continue to be challenged by the fact that agents need access to managers and experts who sit outside the center. Unless those experts are logged into the call center system, agents have no way to know who’s available to help, or how to reach them when a call comes in that requires their expertise.” He continues, “A lot of our callers are educators, like my wife and sister-in-law, and they are hoping to make a quick call and get back to the classroom before havoc breaks out. And, you can’t just call a teacher back in the middle of a class. First-call resolution is very important to us and that means getting all the resources fast, including subject matter experts when needed. With training, hear-ings, meetings, and travel, we can’t keep our experts tied to a desk anymore.” When the expert is outside the contact center, the agent is forced to play a guessing game – similar to what enterprise employees experience daily when trying to locate team members without any real-time display of who is available and through which media or device. This is not a productive use of a highly skilled TASB agent’s time nor does it help serve the TASB member. Since more employ-ees are mobile and increasingly located outside the confines of traditional call center settings, this is a challenge that Tillotson is actively addressing. Tillotson also wants to support agents and claims processors who are demanding flexible work arrangements as gas prices surpass $4 a gallon in Texas. Because their contact center is located in a highly competitive market, TASB utilizes work-at-home options as a ben-efit to retain their best talent. So what exactly did Tillotson see? What value could it provide to his organization? In an unprecedented move that uniquely bridges the contact center and the enterprise, Siemens Enterprise Communications professional services staff used the SOA components of its Open-

SOA Innovation AppliedBY GRACIELA TISCAREÑO-SATO

Leveraging Web Services To Boost First-Contact Resolution

Figure 1 Integrated, intuitive view of enterprise OpenScape UC Application users visible as SMEs to contact center agents, side-by-side with agents, supervisors, managers inside the call center.

Page 11: SOA World Magazine-Enterprise SOA

20 OCTOBER 2008 www.SOA.sys-con.com OCTOBER 2008 21 www.SOA.sys-con.com

SOA APPROACH

Scape UC Application (open, enterprise-class unified communi-cations software for enterprises) to make subject matter experts, wherever they may be (remote offices, home offices, hotels, etc.), available through the OpenScape Contact Center agents’ desktops. Simply stated, an agent using an integrated desktop, with embed-ded UC capabilities, will now be able to focus on delivering an excellent customer interaction. The agent will not be burdened with navigating a complicated desktop of customer data, while also juggling disparate communications systems to attempt to reach an expert immediately. Available through the agent desktop applica-tion, are instant messaging, audio and Web conferencing, and the ability to track the availability status of subject matter experts who are currently unavailable. Kevin Voth is the Siemens engineer who was directly involved in integrating the two SOA applications from the OpenScape UC Suite. He explained, “I simply took the open APIs from the OpenScape Contact Center SDK and the OpenSOA SDK for the UC Application, and combined them to solve a common business process problem in the contact center. I used DHTML and JavasScript to create a thin client that connects back to aggregated presence and availability Web Services that can run on any workstation in your network.”

Customer Perspective: The Value of Reusable SOA Components When Tillotson saw this integration demonstration, he recog-nized that the value of this virtualized contact center will come at three different levels. First, measurably higher FCR rates, shorter call handling times, and higher customer satisfaction ratings become immediately pos-sible. Tillotson said, “Now, you’ve made it simple. With this level of integration, it will be just as easy to contact managers and experts (who might be brought into a conversation but aren’t logged into the call center software) as it is to reach agents within the call cen-ter. Our agents would be able to connect with experts using these new capabilities embedded in our call center software like instant messaging and conferencing and know they’re available.” In an organization like TASB, where it’s the FCR that counts the most, this SOA-enabled capability is very valuable.

For example, in most cases insurance is confusing enough with-out the added worry of what is happening back in the classroom while you are on the telephone. With a tense customer online, the agent with an integrated SOA cockpit can start an ad hoc con-ference and resolve the issue in real-time with the right people involved. The agent can reach the subject matter experts whether they’re a call center software user or not. The era of an agent saying apologetically “I’m sorry. I’ll need to call around for that answer and call you back” will finally come to an end. And if the expert isn’t currently available, the agent can set a “tell-me-when” alert, which tracks the voice or IM availability status of that expert using a highly sophisticated presence engine. The moment the expert becomes available the solution initiates a chat session or voice call to the expert’s preferred device, depending on the desire of the agent. Tillotson observed, “From the call center arena the view is that, finally, there’s a SOA functionality that can truly make it easier for agents to quickly find and reach the right subject matter expert each time”. Secondly and perhaps more importantly, the virtualized contact center delivers valuable personnel benefits in recruiting and reten-tion, as Tillotson explained: “We have folks that we want to have as home-based agents. It’s a retention advantage and a quality-of-life issue. People who have never considered working from home before are demanding this capability for greater balance in their lives between work and fam-ily. A subject matter expert or agent that’s hard to recruit and retain can be made happier with the flexibility offered by this type of solu-tion.” But how to satisfy the agents’ need to see who is available to help them during a call? Tillotson continues: “When I walk around a call center today, I notice the ‘gopher effect’ – people popping up from their cubicles, up on their tip toes peering over the cube walls to see who’s nearby and available to help them during a call. We also recognize the power of tele-commuting and having remote offices in other parts of the city to reduce the length of employees’ commutes. What’s always held us back from embracing telecommuting is

the ‘gopher effect.’ If people aren’t physically in the center, then you can’t pop up to see if they’re available. That lack of visibility makes some people uncomfortable. Many of our expert staff have also embraced the new PDAs and smart phones as they recognize the need to stay connected. And now with this type of SOA application, agents can connect with those available experts who will help them help their customers. People at home, in hearings, in training, traveling, or just away from their cube are still accessible by the agent. It’s very, very exciting.” Finally, there are the very real benefits to the IT staff made pos-sible by SOA’s architectural advantages. First, an IT strategy committed to the open standards of SOA will greatly simplify the process needed to embed communications into today’s applications. A SOA approach simply slashes development time needed to create new applications. It also enables quick deliv-ery of new capabilities, through reusable code, from one applica-tion into another, as demonstrated by Siemens Enterprise Commu-nications to Tillotson. This is significant in that developers can now quickly and effectively align IT strategy to the strategic goals and vision of executive management. Secondly, to have the availability status appear in the agent desk-top, no additional licenses from the contact center application are required for those experts already using OpenScape UC Application outside the enterprise. The agent simply requests permission from

the expert to display their availability on their screen. Lastly, displaying OpenScape UC Application users in the agent desktop does not put any additional traffic on the contact center server. It is not necessary to identify the OpenScape UC Applica-tion user on the contact center server for monitoring because the UC application is doing the monitoring. Therefore, this approach has no impact on the overall call-by-call traffic burdening the call center application server. This also means there are no additional reports generated by having users outside the contact center visible within the contact center software. The link between a SOA approach and achieving a business goal of measurably improved FCR is now quite clear – agents can be equipped with new UC tools to resolve customer inquiries on the first attempt within the familiar environment of their contact center solution.

Equipped To Deliver Future High-Value Integrations One more reason to consider a SOA approach: think about the value of SOA in a mobility scenario. Should the TASB organization decide to adopt a mobility component in the future, these reus-able service components can be integrated into a mobile agent or supervisor desktop client, making these powerful customer service capabilities portable. See how FCR rates can immediately sky-rocket? For TASB, any new link between the contact center and the necessary experts outside it means improved service levels that will satisfy their school board members like never before. Says Tillotson:

“Here’s a way that we in IT can be heroes again. We can stay one step ahead of our business area users and our customers. At TASB, our IT staff never wants to confuse users by giving them the full view of our toy box. We want to understand the business need and then set just the right toy out in front of them one day before they realize they need it. A powerful new integration like this, made possible through SOA, would help us accomplish that and so much more. And...it’s kind of cool!”

Resources• For more information on the Siemens open approach to SOA-

based software, please visit: www.siemens.com/us/open/white-paper/opensoa.

• For the FCR white paper, visit: www.siemens.com/us/open/whitepaper/fcr.

• For case studies on organizations using Siemens SOA-based software, visit: http://www.enterprise-communications.siemens.com/northamerica/Info%20Center%20Clone/Success%20Stories%20Clone.aspx.

• For the white paper detailing the nearly $13 million wasted each year by 1,000-person enterprises: “Measuring the Pain: What is Fragmented Communication Costing Your Enterprise”, visit: http://enterprise.siemens.com/open/us/openinformation/whitepapers/ucsurvey/default.aspx.

About the Author

Graciela Tiscareño-Sato is senior global marketing manager for unified communications with

Siemens Enterprise Communications, insightful speaker, and published business technology

writer. She has a unique global perspective on how and where UC solutions, architected on SOA,

are being successfully implemented by organizations around the globe.

[email protected].

THREE STEPS TO START RIGHT NOW If you’re thinking to yourself that this type of reusable SOA compo-nents approach could benefit your organization, you’re probably right. But where to start? Here are three steps: First, identify the people and processes that differentiate your com-pany from your competitors. What is it that keeps your customers coming back? Now, having pinpointed those people and processes responsible for making your company competitive, identify the communications obstacles those employees endure that keep them from providing the best possible service. Are they using a workflow application that would benefit from a real-time view of experts and how to reach them? Choosing SOA-based software with reusable components will enable integration exactly as needed into customer service tools to make them more effective. Second, evaluate vendors and unified communications solutions. Make vendors prove they understand and deliver open communications. This means you can deploy their software on your existing IT and tele-phony infrastructure and use whichever phones and desktop clients are in place today. This also means their applications are built from the ground up using SOA. Be sure they’re not offering you bolted-on SOA components on top of their proprietary products that may require expensive integra-tion services to make them play nice and work together. Lastly, select the right user communities from step one and start with a pilot right away. Choosing either an on-premise pilot or a hosted solution, jump in and let users appreciate first hand the real-time benefits of reusable SOA components. Whether deploying new unified communica-tions capabilities such as a one-number service, Web conferencing, audio conferencing, instant messaging (together with one Web interface), or embedding these directly into existing software, users will see the value of this new approach right away. They’ll see the value because they’ll be better equipped to answer the next call from the customer by accessing available experts anywhere that will keep satisfaction levels high.

Figure 2 view of call center application with team presence and collaboration bar, displays contact information of those logged into the call center application

“One hundred percent FCR is the elusive goal, but it’s nearly impossible to achieve or measure today”

Page 12: SOA World Magazine-Enterprise SOA

22 OCTOBER 2008 www.SOA.sys-con.com OCTOBER 2008 23 www.SOA.sys-con.com

STRATEGY

It seems as if every few years we’re inspired to learn about the next big thing in IT. Of course, it usually begins with some three letter acronym (“TLA”), is punctuated by

the promise of significant ROI and ends with an eyebrow raising price tag. So why should SOA be anything different? Over the years SOA went from being an industry buzzword to becoming a must-have strategy

with proven and perceived benefits. However, like many technol-ogy paradigms, it has met with its fair share of failed attempts. While successful companies recognize that SOA is a journey, others should realize that there is no sense in abandoning a service-ori-ented initiative based on a failed attempt because SOA’s returns to the organization can be significant.What is worth evaluating is the initial approach to SOA that either resulted in success or perhaps didn’t deliver on what IT may have promised.

Reasons Why SOA Fails As we all know, SOA isn’t new, yet many businesses are still hesi-tant to adopt a service-oriented strategy or are abandoning their efforts for a myriad of reasons. It is important to understand and

learn from the reasons why an SOA strategy can fail.First and foremost, you have to define “success” and define “fail-ure.” Although this sounds obvious, many organizations do not establish these quantitative and qualitative metrics and, therefore, the end result of success versus failure becomes a very gray area. Al-ways ask and document your overall business and technical goals, and your critical success factors. Next it is important to treat an SOA project as one that is stra-tegic, rather than tactical. Don’t just focus your efforts on solving one short-term problem. It is important to create a long-term plan and vision, but with an approach that is phased and manageable. Whether you are looking to re-engineer your existing business processes or integrate your assets, only by having established a plan will you be able to reap true value from your SOA initiative. Now with a long-term, strategic plan automatically comes a need for establishing executive support, aligning business and IT, and defining a governance strategy to maintain quality and efficiency. These should help keep the project in check. Finally establish your overall approach. You need to balance an understanding of your current architecture – its redundancies, its bad code, its history, its function – with a set of future objectives to determine the right strategy for your company. Should it be one that integrates assets into a hub to share its services, or should it be one

that re-engineers all or aspects of old applications to extract more value out of them, or should it be a combination of both over a long-term plan? With a commitment to SOA comes an understanding of the importance of refining and realigning the infrastructure.

Creating Company-wide Consensus Given the many SOA success stories, along with some very public lessons learned, let’s take a closer look at the “how” when it comes to SOA deployment. At the onset of the project, it’s non-negotiable that your cross-com-pany team build consensus on the strategy and goals to ensure its success. Before you begin the actual IT construction of the project, here are 10 questions to present to the team to structure the con-versation: 1. What are our three primary goals for the SOA initiative?2. Who will be using the SOA environment?3. Are there plans to extend the processes, services, or applications

beyond the company walls to include customers and partners? If so, are we building a flexible and extensible infrastructure?

4. Which team and/or department will be the launching pad for the SOA initiative?

5. Who are the executive sponsors?6. How will we benchmark and showcase our success?7. Inventory: what do we currently have and what do we need in

terms of technology and skills?8. How will the SOA project innovate new business processes?9. How will the strategic initiative contribute to the bottom line

from a business and IT perspective?10. Are we taking advantage of the latest technologies to foster

collaboration and innovation while protecting our existing IT investments?

Once you’ve established an understanding of the strategy and direction, you can move forward on the actual approach to rolling it out to the organization. But just where do you start?

Three Proven Approaches to SOA: People, Processes and Information The three most popular and proven approaches to starting an SOA project are people, processes, and information. Of course, respective of the nuances and business requirements within every company, organizations will need to determine their own appropri-ate starting point to SOA. However, based on data collected from thousands of successful deployments around the globe, the three approaches cited above are consistently viewed as the fastest, most effective routes to SOA. A people-centric approach begins with fostering collaboration among employees, customers, and partners. Many people view this entry point from the glass and take into account the various ways that each person’s role in the organization impacts another’s. Based on this approach, the SOA project’s starting point prioritizes the end-user’s view and role. Essentially, the people-centric approach is focused on boosting employee productivity, overall business efficiency and enabling various constituents in the organization to easily and quickly make critical business decisions for competitive advantage. After all, people, not technology, drive business decisions and the ability to make the right decision should be based on the collective thoughts of informed individuals with access to real-time data that is un-leashed from its silos through an SOA infrastructure.

The process-centric approach to SOA focuses on the ways that your company runs its business. Each organization has established processes for executing tasks, from simple supply orders and ex-pense report approvals to more complex activities such as manag-ing and monitoring the entire supply chain or connecting a global team to create and design a new automobile. All of these processes have steps that intersect nearly every part of the organization and require access to various applications and databases that may be strewn throughout the company. By outlin-ing these business processes, companies can uncover redundancies and identify best practices that can be rolled out as services within the new architecture. The process-centric approach to SOA enables users to streamline their business processes and seamlessly perform their roles. All of this is achieved without being hindered by application silos or other roadblocks on the way to improving productivity, accelerating speed-to-market and quickly responding to new business chal-lenges. The information-centric approach to SOA looks at information as a service that may be made available to your entire organization as well as customers and partners. Using information as an entry point to SOA provides a power-ful advantage in terms of consolidating erroneous or redundant data, ensuring consistency of information, and gaining a better understanding of the various types of information that are currently running your business, such as operational, unstructured, and transactional. In addition, you will be able to see how the informa-tion flows throughout the company and the way that it intersects with employee roles. When a company employs the information-centric approach to SOA, it is assured of more consistent definitions and governance of critical business data. Further, as with all approaches to SOA, reuse of services saves both time and money while limiting exposure to human data errors. The business drivers for your SOA will most likely determine your starting point. As companies progress on their SOA path, they even-tually realize that they will need to mix and match their approaches as part of a larger strategy. For example, a consumer e-retailer may begin with a people-cen-tric approach and realize great success with its initial SOA project. As the architecture expands to include warehouse inventory, they may initiate their next project using an information-centric approach. Regardless of the selected entry point, the most successful SOA deployments are those that began with one of the three recom-mended approaches: people, process or information.While executive support is important, the success of your SOA will hinge, in large part, on the way that you execute your strategy. Se-lecting the entry point that is most closely aligned with the business goals is a critical first step because it will allow you to more quickly deliver tangible results that will not only inspire the team, it will also help illustrate to the entire organization that SOA is not just another “TLA” trend.

About the Author

Kadeer Beg is the CTO of Prolifics, an end-to-end systems integrator based in New York, NY.

With over 15 years of experience in delivering and architecting large-scale systems across

multiple platforms, Kadeer has provided consulting to Fortune 500 clients and worked in

senior management for Societe Generale, New Era of Networks, Sapient, Bell Canada, Cendant,

and IBM.

[email protected]

Starting an SOA Initiative or Continuing the Journey?It’s all in the approach

BY KADEER BEG

Page 13: SOA World Magazine-Enterprise SOA

24 OCTOBER 2008 www.SOA.sys-con.com OCTOBER 2008 25 www.SOA.sys-con.com

CICS

Web services have opened opportunities to integrate the applications at an enterprise level irrespective of the technology they have been implemented in. IBM’s CICS transaction server for z/OS v3.1 can sup-

port web services. It can help expose existing applications as web services or develop new functionality to invoke web services. One of the commonly used protocols for CICS web services is SOAP for CICS. It enables the communication of applications through XML. It supports as a service provider and service con-sumer independent of platform and language. SOAP for CICS enables CICS applications to be integrated with the enterprise via web services as part of lowering the cost of integration and retain-ing the value of the legacy application. SOAP for CICS also comes along with the implementation encoder and decoder. This article describes two cases where CICS acts as a service provider and also as a consumer for complex datatype objects. CICS SOAP 1.2 is the SOAP implementation and encoding and decoding is done by the PIPELINE programs. Two exclusive PIPELINEs need to be defined, one for the provider and the other for the consumer. IBM provides CICS Web Services Assistants, namely, DFHLS2WS and DFHWS2LS. The DFHLS2WS utility takes a language data structure used by the service provider and generates the WSDL and WSBIND files. The WSBIND file is used at runtime to convert a SOAP body to a language data structure and vice-a-versa. The DFHWS2LS takes the WSDL provided by a service and generates the language data structure and a WSBIND file. Complex data types are handled by these utilities. The languages supported by these utilities include COBOL, Java, C++, and PL1. The web services are registered in the CICS region using the PIPELINE SCAN command (see Figure 1).

CICS as a Service Consumer – Handling Multiple Result Sets The application is a Flight Inquiry. The input screen has the Departure and Arrival cities along with the departure date. This in-vokes a Java web service, which does a query on an Oracle database to retrieve all the flights between the cities on that date. The result is a varying list of flights between different city pairs. The high-level steps followed in the coding are:

1. Received the WSDL file for the service to be consumed. Appendix A has the WSDL.

2. Used the Web services assistant, DFHWS2LS, to create the request and response copybooks using the WSDL. Set the PGMINT parameter to CHANNEL as we do not know the size of the data being returned. This will help overcome the COMMAREA size limitations in case we receive a huge amount of data. Appendix B has these copybooks.

3. Did a PIPELINE SCAN on the pipeline, which has been defined to be used when the CICS is a web service consumer.

4. Coded a program to capture inputs and pass them to a wrapper that invokes the web service and creates a TSQ containing the response received. Display program reads the TSQ and displays data.

Figure 2 is the input screen shot of the sample application. Extracting values from the result sets received is a little tricky. The first GET CONTAINER gives us the number of result sets received; two in the example below and the name of a container, which further contains container names of the result sets. The next GET CONTAINER gets us all the container names, which store the actual values. Then we loop through these container name and value pairs to get finally to the data to be displayed. The first GET CONTAINER gets the name of the container which has container names containing the data:

EXEC CICS GET CONTAINER CONTAINER (‘DFHWS-DATA ‘) CHANNEL (‘FLTDTLS-CHANEL ‘) INTO (‘....DFHPI00000000000’) FLENGTH (20) NOHANDLE

The above result in HEX: EXEC CICS GET CONTAINER CONTAINER (X’C4C6C8E6E260C4C1E3C1404040404040’) CHANNEL (X’C6D3E3C4E3D3E260C3C8C1D5C5D34040’) INTO (X’00000002C4C6C8D7C9F0F0F0F0F0F0F0F0F0F0F0’)�2 total result sets received

Developing a CICS-based Web Service on an Array of “Complex Datatype” ObjectsCICS as a service provider and consumer

FLENGTH (X’00000014’) NOHANDLE The second GET CONTAINER gets all the container names con-taining actual data. There is no demarcation between result sets. The container names are just a bunch of sequenced names.

EXEC CICS GET CONTAINER CONTAINER (‘DFHPI00000000000’) CHANNEL (‘FLTDTLS-CHANEL ‘) INTO (‘....DFHPI00000000001....DFHPI00000000002....DFHPI00000000003....’...) FLENGTH (360) NOHANDLE

The above maps to the complete XML output as shown below. Each of the DFHPI* is the container name of the actual data ele-ment, e.g., <airways>, <arrivalDate>, <capacity>, etc., in the file We then loop through the GET CONTAINERS to get actual data. In our case, each result set contains nine elements (airways, arrivalDate, capacity, departureDate, flightFrom, flightNo, flightTo, flightTravelCode and price, refer to the XML output, between <re-turn> </return>). Hence one loop goes through nine GET CON-TAINERS.

EXEC CICS GET CONTAINER CONTAINER (‘DFHPI00000000001’) CHANNEL (‘FLTDTLS-CHANEL ‘) INTO (‘SPICE’...) FLENGTH (255) NOHANDLE The above maps to the XML output of � <airways>SPICE</air-

ways>

EXEC CICS GET CONTAINER CONTAINER (‘DFHPI00000000002’) CHANNEL (‘FLTDTLS-CHANEL ‘) INTO (‘2008-06-28T19:45:00+05:30’) FLENGTH (32) NOHANDLE

The above maps to the XML output � <arrivalDate>2008-06-28T19:45:00+05:30</arrivalDate> and so on and so forth till end of data. This way of using complex datatype objects of an advanced Java application can be used by a legacy system as a consumer of service will have a greater advantage of leveraging the concept of web ser-vices for legacy systems. Listing 1 is the XML output from the SOAPSonar web-services testing tool with the inputs mentioned in Figure 2. Please note that this is just to understand the output structure. When the commu-nication happens directly between the provider and the consumer, we do not see this output. Figure 3 is the output screenshot of the sample application. CICS as a Service Provider – Creation of an Order ID The application stores order details in a DB2 database on the mainframe and creates an order ID for the orders received through the external application(s). This service on the z/OS mainframe is tested through a Java application in the Windows environment. The result is an Order ID (unique number) of the order been placed.The high-level steps followed in the coding are:1. Created the language structure (COBOL request copybook) for

the service to be developed.

Figure 1: CICS services flow

Figure 2: Input screen on the mainframe

Figure 3: Output mainframe screen

Figure 4: Invoke the web service ‘createOrddet1’ through SOAPSonar

Figure 5: Response

BY SREE KUSUMANCHI, GIRISH MOKHASI , AND GVB SUBRAHMANYAM

Page 14: SOA World Magazine-Enterprise SOA

26 OCTOBER 2008 www.SOA.sys-con.com OCTOBER 2008 27 www.SOA.sys-con.com

CICS

2. Used the web services assistant, DFHLS2WS, to create the WSDL. Used the PGMINT =COMMAREA. Appendix C has the copybook.

3. Scanned the inbound pipeline, which has been defined to be used when the CICS is a web service provider.

4. Coded a program to receive input from the service consumer, inserts the order details and a unique order ID in the database, and returns the order UD to the service consumer.

The following are the steps involved in the web service testing. Rows from the DB2 table ORDER_DETAIL:

---------+---------+---------+--SELECT * FROM UCHB002.ORDER_DETAIL; ---------+---------+---------+--ORDER_ID PRODUCT_CODE PRODUCT_DESC PRODUCT_PRICE PRODUCT_QTY---------+---------+---------+--DSNE610I NUMBER OF ROWS DISPLAYED IS 0DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100 ---------+---------+---------+--

The XML output from the SOAPSonar web services testing tool with the above inputs (see Figure 4). Please note that this is just to understand the output structure when the communication happens directly between the provider and the consumer (see Figure 5). Rows in the DB2 table ORDER_DETAIL:

---------+---------+---------+---------SELECT * FROM UCHB002.ORDER_DETAIL; ---------+---------+---------+---------ORDER_ID PRODUCT_CODE PRODUCT_DESC PRODUCT_PRICE PRODUCT_QTY ---------+---------+---------+---------1 Soap Dove 55.00 10 1 Oil SunFlower 99.00 2 DSNE610I NUMBER OF ROWS DISPLAYED IS 2 DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100---------+---------+---------+---------

Conclusion With the increasing demand for integration of enterprise applica-tions with complex data type structures that have an advantage for manipulating large and complex data, developers have looked at various options one of which is web services. In this article, we have developed a CICS-based program to act as web service provider and consumer using complex data types.

References• http://www.redbooks.ibm.com/abstracts/sg247126.html• http://www-306.ibm.com/software/htp/cics/soap/• http://webservices.sys-con.com/read/39850.htm• http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.

jsp?topic=/com.ibm.ddi.doc/ddi168.htm• http://www.onjava.com/pub/a/onjava/excerpt/jsoap_5/index1.

html

About the Authors

GVB Subrahmanyam is principal solution architect for the Technology Advisory Group in

Satyam Computer Services (www.satyam.com). He holds a master of technology and doctor-

ate from IIT Kharagpur. His focus areas are SOA, Web Services, and Enterprise Applications

Architecture.

Sree Kusumanchi is lead architect with the Legacy Transformation Group in Satyam Computer

Services and has a masters in technology from BITS Pilani.

Girish Mokhasi is technical architect for Legacy Transformation Group in Satyam Computer

Services.

[email protected]

[email protected]

[email protected]

200401-wss-wssecurity-utility-1.0.xsd” xmlns:wsp=”http://schemas.

xmlsoap.org/ws/2004/09/policy” xmlns:soap=”http://schemas.xmlsoap.

org/wsdl/soap/” xmlns:tns=”http://service.air.tag.satyam.com/” xmlns:

xsd=”http://www.w3.org/2001/XMLSchema” xmlns=”http://schemas.xmlsoap.

org/wsdl/” targetNamespace=”http://service.air.tag.satyam.com/”

name=”AirTicketService”>

<types>

<xsd:schema>

<xsd:import namespace=”http://service.air.tag.sa-

tyam.com/” schemaLocation=”http://hcc-oneview:8080/ticket/

AirTicketService?xsd=1”>

</xsd:import>

</xsd:schema>

</types>

<message name=”fetchFlights”>

<part name=”parameters” element=”tns:fetchFlights”>

</part>

</message>

<message name=”fetchFlightsResponse”>

<part name=”parameters” element=”tns:fetchFlightsResponse”>

</part>

</message>

<message name=”AirException”>

<part name=”fault” element=”tns:AirException”>

</part>

</message>

<portType name=”AirTicket”>

<operation name=”fetchFlights”>

<input message=”tns:fetchFlights”>

</input>

<output message=”tns:fetchFlightsResponse”>

</output>

<fault message=”tns:AirException” name=”AirException”>

</fault>

</operation>

</portType>

<binding name=”AirTicketPortBinding” type=”tns:AirTicket”>

<soap:binding transport=”http://schemas.xmlsoap.org/soap/http”

style=”document”>

</soap:binding>

<operation name=”fetchFlights”>

<soap:operation soapAction=””>

</soap:operation>

<input>

<soap:body use=”literal”>

</soap:body>

</input>

<output>

<soap:body use=”literal”>

</soap:body>

</output>

<fault name=”AirException”>

<soap:fault name=”AirException” use=”literal”>

</soap:fault>

</fault>

</operation>

</binding>

<service name=”AirTicketService”>

<port name=”AirTicketPort” binding=”tns:AirTicketPortBinding”>

<soap:address location=”http://172.27.5.51:8080/ticket/AirTick-

etService”>

</soap:address>

</port>

</service>

</definitions>

Appendix B: Request and Response Copybooks

Request Copybook: ARTKTI01 * +++++++++++++++++++++++++++++++++++++++

* This file contains the generated request language structure(s)

* for WSDL operation ‘fetchFlights’.

* This structure was generated using ‘DFHWS2LS’ at mapping level

* ‘1’.

* +++++++++++++++++++++++++++++++++++++++

05 fetchFlights.

10 Xfrom-num PIC S9(9) COMP-5 SYNC.

10 Xfrom-cont PIC X(16).

10 Xto-num PIC S9(9) COMP-5 SYNC.

10 Xto-cont PIC X(16).

10 departureDate-num PIC S9(9) COMP-5 SYNC.

10 departureDate-cont PIC X(16).

01 ARTKTI01-Xfrom.

05 Xfrom PIC X(255).

01 ARTKTI01-Xto.

05 Xto PIC X(255).

01 ARTKTI01-departureDate.

05 departureDate PIC X(32).

Response Copybook: ARTKTO01

* +++++++++++++++++++++++++++++++++++++++ * This file con-

tains the generated response language

* structure(s) for WSDL operation ‘fetchFlights’.

* This structure was generated using ‘DFHWS2LS’ at mapping level

* ‘1’.

* +++++++++++++++++++++++++++++++++++++++

05 fetchFlightsResponse.

10 Xreturn-num PIC S9(9) COMP-5 SYNC.

10 Xreturn-cont PIC X(16).

01 ARTKTO01-Xreturn.

05 airways-num PIC S9(9) COMP-5 SYNC.

05 airways-cont PIC X(16).

05 arrivalDate-num PIC S9(9) COMP-5 SYNC.

05 arrivalDate-cont PIC X(16).

05 capacity-num PIC S9(9) COMP-5 SYNC.

05 capacity-cont PIC X(16).

05 departureDate-num PIC S9(9) COMP-5 SYNC.

05 departureDate-cont PIC X(16).

05 flightFrom-num PIC S9(9) COMP-5 SYNC.

05 flightFrom-cont PIC X(16).

05 flightNo-num PIC S9(9) COMP-5 SYNC.

Listing 1<?xml version=”1.0”?>

<S:Envelope xmlns:S=”http://schemas.xmlsoap.org/soap/envelope/”>

<S:Body>

<ns2:fetchFlightsResponse xmlns:ns2=”http://service.air.tag.

satyam.com/”>

<return>

<airways>SPICE</airways>

<arrivalDate>2008-06-28T19:45:00+05:30</arrivalDate>

<capacity>100</capacity>

<departureDate>2008-06-28T18:40:00+05:30</departureDate>

<flightFrom>Hyderabad</flightFrom>

<flightNo>SG-221</flightNo>

<flightTo>Chennai</flightTo>

<flightTravelCode>0628200820121</flightTravelCode>

<price>2287.0</price>

</return>

<return>

<airways>KING </airways>

<arrivalDate>2008-06-28T20:10:00+05:30</arrivalDate>

<capacity>100</capacity>

<departureDate>2008-06-28T18:40:00+05:30</departureDate>

<flightFrom>Hyderabad</flightFrom>

<flightNo>IT-2473</flightNo>

<flightTo>Chennai</flightTo>

<flightTravelCode>0628200820182</flightTravelCode>

<price>2584.0</price>

</return>

</ns2:fetchFlightsResponse>

</S:Body>

</S:Envelope>

Appendix A: WSDL pertaining to Web Service

Consumer<?xml version=”1.0”?>

<!-- Published by JAX-WS RI at http://jax-ws.dev.java.net. RI’s ver-

sion is JAX-WS RI 2.1.2-hudson-182-RC1. -->

<!-- Generated by JAX-WS RI at http://jax-ws.dev.java.net. RI’s ver-

sion is JAX-WS RI 2.1.2-hudson-182-RC1. -->

<definitions xmlns:wsu=”http://docs.oasis-open.org/wss/2004/01/oasis-

Page 15: SOA World Magazine-Enterprise SOA

28 OCTOBER 2008 www.SOA.sys-con.com OCTOBER 2008 29 www.SOA.sys-con.com

05 flightNo-cont PIC X(16).

05 flightTo-num PIC S9(9) COMP-5 SYNC.

05 flightTo-cont PIC X(16).

05 flightTravelCode-num PIC S9(9) COMP-5 SYNC.

05 flightTravelCode-cont PIC X(16).

05 price-num PIC S9(9) COMP-5 SYNC.

05 price-cont PIC X(16).

01 ARTKTO01-airways.

05 airways PIC X(255).

01 ARTKTO01-arrivalDate.

05 arrivalDate PIC X(32).

01 ARTKTO01-capacity.

05 capacity PIC S9(9) COMP-5 SYNC.

01 ARTKTO01-departureDate.

05 departureDate PIC X(32).

01 ARTKTO01-flightFrom.

05 flightFrom PIC X(255).

01 ARTKTO01-flightNo.

05 flightNo PIC X(255).

01 ARTKTO01-flightTo.

05 flightTo PIC X(255).

01 ARTKTO01-flightTravelCode.

05 flightTravelCode PIC X(255).

01 ARTKTO01-price.

05 price PIC X(32)

Appendix C: Request and Response Copybook

Copy book/Language Structure: CPORDDET

01 WS-ORDER-DETAIL.

10 WS-ORDER-ID PIC S9(4) USAGE COMP.

10 WS-ORDER-ITEMS-NUM PIC S9(4) USAGE COMP.

10 WS-ORDER-TABLE OCCURS 10 TIMES.

15 WS-ORDER-PRODUCT-CODE PIC X(8).

15 WS-ORDER-PRODUCT-DESC PIC X(50).

15 WS-ORDER-PRODUCT-PRICE PIC S9(6)V9(2) USAGE COMP-3.

15 WS-ORDER-PRODUCT-QTY PIC S9(4) USAGE COMP.

10 WS-ORDER-DETAIL-RESPONSE PIC X(40).

Appendix D: WSDL pertaining to

Web Service provider

<?xml version=”1.0” ?>

<!--This document was generated using ‘DFHLS2WS’ at mapping level ‘1’.

-->

<definitions targetNamespace=”http://www.OTSRT001.CPORDDET.com”

xmlns=”http://schemas.xmlsoap.org/wsdl/” xmlns:reqns=”http://www.

OTSRT001.CPORDDET.Request.com” xmlns:resns=”http://www.OTSRT001.CPORD-

DET.Response.com” xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/”

xmlns:tns=”http://www.OTSRT001.CPORDDET.com”>

<types>

<xsd:schema attributeFormDefault=”qualified” elementFormDefaul

t=”qualified” targetNamespace=”http://www.OTSRT001.CPORDDET.Request.

com” xmlns:tns=”http://www.OTSRT001.CPORDDET.Request.com” xmlns:

xsd=”http://www.w3.org/2001/XMLSchema”>

<xsd:complexType abstract=”false” block=”#all” final=”#all”

mixed=”false” name=”ProgramInterface”>

<xsd:annotation>

<xsd:documentation source=”http://www.ibm.com/soft-

ware/htp/cics/annotations”>This schema was generated by the CICS Web

services assistant.</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element name=”ws_order_detail” nillable=”false”>

<xsd:complexType mixed=”false”>

<xsd:sequence>

<xsd:element name=”ws_order_id”

nillable=”false”>

<xsd:simpleType>

<xsd:annotation>

CICS

Advertiser Index ADVERTISER URL PHONE PG

General Conditions: The Publisher reserves the right to refuse any advertising not meeting the standards that are set to protect the high edito-rial quality of .Net Developer’s Journal. All advertising is subject to approval by the Publisher. The Publisher assumes no liability for any costs or damages incurred if for any reason the Publisher fails to publish an advertisement. In no event shall the Publisher be liable for any costs or damages in excess of the cost of the advertisement as a result of a mistake in the advertisement or for any other reason. The Advertiser is fully responsible for all financial liability and terms of the contract executed by the agents or agencies who are acting on behalf of the Advertiser. Conditions set in this document (except the rates) are subject to change by the Publisher without notice. No conditions other than those set forth in this “General Conditions Document” shall be binding upon the Publisher. Advertisers (and their agencies) are fully responsible for the content of their advertisements printed in .Net Developer’s Journal. Advertisements are to be printed at the discretion of the Publisher. This discretion includes the positioning of the advertisement, except for “preferred positions” described in the rate table. Cancellations and changes to adver-tisements must be made in writing before the closing date. “Publisher” in this “General Conditions Document” refers to SYS-CON Publications, Inc. This index is provided as an additional service to our readers. The publisher does not assume any liability for errors or omissions.

HP http://www.hp.com/go/soa 7

Managed Methods http://www.managedmethods.com 36

Rogue Wave http://www.roguewave.com 5

SYS-CON Books http://www.theriabook.com 202-802-3020 11

SYS-CON Events http://www.events.sys-con.com 202-802-3020 10

Fiorano http://www.firoano.com/downloads 3

SYS-CON Events http://www.events.sys-con.com 202-802-3020 13

DataDirect Technologies http://www.datadirect.com 17

SYS-CON Media http://www.sys-con.com 202-802-3020 29

SYS-CON Books http://www.theriabook.com 202-802-3020 33

Web Age Solutions http://www.webagesolutions.com 877-517-6540 35

������������������������������������������������������������

24/7

Visit the ��� ���������������

Website Today!

������������������������������������������

������������������������������������������������������������

������������������������������������

���

��������������������

������������������������

�������������������

�������������������

���������������������������

����������������������

������������������������������

�����������

������������������������������

���������������������������

�����������������

����

��������������������������������

�������������������������������������������������������������������������������������������������������������

�����������������������������������������������������������������������������������������������

�����������������������������������������������������������������������������������������������������

��������������������������������������������������������������������������

������������������������������������������������������������

��������������������������������������������������������������������������������������������������������������������������������������������������������������

�������������������������������������������������������������������������������������������

������������������������������������������������������������

24/7

Page 16: SOA World Magazine-Enterprise SOA

30 OCTOBER 2008 www.SOA.sys-con.com OCTOBER 2008 31 www.SOA.sys-con.com

the namespace of a service to more clearly identify it during build-out and maintenance:

• The business domain the service belongs to • The service name that explains the business function • The major version of the service

Incidentally, you should change a major version of a service only when the service definition is no longer backward-compatible with the previous iteration. By the same token, change a minor version of a service if the service definition remains backward-compatible with the previous one. In terms of registries, remember that their purpose is two-fold: discovery and collaboration. When our clients ask us, “When do I use a registry?”, and they inevitably do, the simple answer is that it depends on the business criticality of a given service. If even one service is business-critical, you might as well use a registry to be assured of its reliability, dependability, and QoS. From a standards perspective, registries come in two flavors. A quick overview:

Universal Discovery Description and Integration (UDDI)• Geared primarily towards discovery of Web Services• Supports XML envelopes, XML headers, and XML payloads • Supported by several notable vendors

Electronic Business Using Extensible Markup Language (ebXML) • Geared towards discovery of Web Services and collaboration • More complete and complex than UDDI; among other things, it

covers in detail business abstractions and specifications, includ-ing partner agreement

• Supports MIME envelopes, XML headers, and arbitrary payloads

4. Ambiguity in project planning A poorly conceived project plan can break an SOA project, while a well-thought-out one can ensure its success. Remember that the devil is in the details of communicating with stakeholders, translat-ing their needs for your development staff, testing the project as you go, getting the right hardware and software in place, and meet-ing deadlines. Even minor changes in any of these areas could rock the boat and result in costly setbacks. Let’s consider certain areas pertinent to SOA — and to integration in general — that need to be clearly delineated well before you begin development:

• Communication with business stakeholders counts. It’s es-sential that you tease out subject matter experts’ wishes and demands for the finished SOA solution, and that you get buy-in across all departments. What problems do these experts need the project to solve? What are the business services they deem most essential? Across myriad departments, these stakeholders know better than anyone how business is run at the organiza-tion. In many cases, this information will need to be translated into requirements that your developers can understand, and the attendant results vetted by the experts again.

• but information can be lost in translation. In one of our SOA implementations, our contact — an IT person — told us that the business stakeholders wanted us to incorporate data from travel service providers (such as Sabre) with a VXML- based system to offer callers the best deals on airfares. After building the feature, we gave a demo to the business stakeholder, who

quietly said, “Sorry, but this is not what I was looking for.” The call took too long, he said; for every input the caller provided, the system waited for either a yes or a no before it proceeded. He then asked us for an approach whereby unless the caller explicitly said “no,” to keep advancing them through the appli-cation. Rectifying this took about three weeks, due to the size of the application. The key difference in the overhauled app? The Web Service gets invoked much earlier than before, thus better aligning technological features with business goals. Overall, be iterative and avoid the “waterfall” approach in which all stake-holder input is collected at one time, then “translated” into a project that’s likely to be wildly off the mark.

• End-to-end application testing. Don’t overlook this essential piece of any deployment, SOA or otherwise. Test early and often to make sure that subject matter experts’ wish lists are being properly translated into workable code.

• Hardware and software procurement. Consider working with a consulting partner or other trusted party to assess and procure the products your SOA implementation will require. Having a partner that has done SOA implementations before and has a good grasp of the product parameters pertinent to your organization can save you much time, effort, and dollars later. Try to avoid vendor lock-in as best you can; you don’t want to get stuck with a proprietary platform that won’t expand with your SOA infrastructure.

• Deadlines related to integrating partner organizations. Set realistic deadlines pertaining to integration with partners’ applications. Insist that all members of your team adhere to them. While the level of partner participation or commitment is largely out of your control, the inclusion of a generous time cushion may well mean that even a partner that’s dragging its feet should not have the power to disrupt the entire project schedule.

There’s no way to sugarcoat it: in the absence of these and other clear requirements, your SOA project is likely to fail.

5. Poor data quality Many of the failures we’ve observed in SOA enablement proj-ects originate from sub-par data quality. Remember the old adage, “Garbage in, garbage out”? This holds for an SOA project as well. Careful identification of data sources in terms of consistency would alleviate many of these issues, as would data cleansing that ensures information is accurate and standardizes the way common terms are used (e.g., “New York,” not “NYC,” “ny,” “New York City,” etc.) In addition, consider using metadata to enhance search capability.

6. A rush to SOA deployment The best SOA projects go live after a period of months — not when the proverbial switch is flipped. Trust us; this isn’t like deploy-ing a new server or putting IP phones on everyone’s desktop on Saturday afternoon, then starting them up Monday morning. It’s best to start small, perhaps in a certain department, and grow slowly across the rest of the enterprise in a methodical, incremental way. That way you can address problems as they arise, keep tabs on service granularity (which we guarantee will change over time), and flush out risk as you go. Enterprise-wide SOA enablement doesn’t happen overnight, but the benefits it engenders will generate many positive effects for your organization as a whole, your IT depart-ment, your end users, your partners, and your customers.

PITFALLS

Common Pitfalls Around an SOA Implementation – And How to Avoid Them

BY MUKUND BALASUBRAMANIAN

If you’re implementing a Service Oriented Ar-chitecture (SOA) in your organization, you’re probably seeking, among other things, a bet-ter way to align IT services with the day-to-

day business processes in which your colleagues, customers, and partners engage. To do this well, organizational changes as well as technological ones will be required, yet both areas are fraught with snares if you’re not careful.

While SOA can bring you and your organization closer to the place where business operations mirror technological systems and vice versa, the pitfalls that can attend even the most diligent implementation are not to be underestimated. Our company has completed dozens of SOA engagements on behalf of our clients; here, we lay out the most common bugaboos — some technical, some related to business processes.

1. Lack of standards and/or protocol complianceStandards compliance is at the very core of SOA, but not all of the vendors who have a stake in its success have recognized that fact — or, more likely, they perceive that their strength lies in their ability to differentiate their products’ features from those of others, thereby confounding the whole concept of standardization in the first place. But that’s another story. To begin with, realize that not all open source products available today comply with Web Services Interoperability, commonly known as WS-1, even though it’s the broadly accepted industry standard. In one of our SOA projects, we used Iona’s Artix Advanced SOA In-frastructure Suite as the SOA backbone to expose a layer of business services to be consumed by other applications, including the open source SugarCRM, Jira for bug-tracking, SAP, and Sage for assorted ERP functions, and some homegrown applications. Artix also let us expose certain fine-grained services to the organization’s open source, custom, and proprietary applications. Yet as we integrated SugarCRM and Jira, we realized that both exposed their Web Services using Remote Procedure Call encod-ing. However, WS-1-compliant Artix neither supports nor enforces RPC-encoded services. We did not identify the problem until imple-mentation; thus, we had to develop a method of handling RPC-encoded services, creating a six-week delay to address myriad service dependencies. By the same token, there’s a widely held belief that SOAP enables Web Services, but in

truth, most open source products make use of REST-based services. What’s more, some of the existing Web-based products make use of XML-based service in cases where the request is sent using a query string and the response is pure XML. If you’re creating an SOA framework, it’s critical to understand all of the applicable integra-tion points for the applications to which you’re exposing services, and to make provisions for the correct Web Services protocols. As you work, watch out for these small problem areas, which left unchecked have the potential to derail projects — or at least cause substantial and costly delays. And be vigilant about watching the evolution of SOA specifications in the industry and among your peers at other similar organizations.

2. Making assumptions about security Learn from an issue we encountered concerning Web Services Se-curity (WS-Security), broadly accepted in the open source develop-ment community, and Apache’s WSS4J, one popular WS-Security implementation. When in the course of a project integrating WSS4J with Infravio’s SOA governance stack for a large telecommunica-tions firm, we were asked to enable WS-Security for services rang-ing from encryption to signature verification. We sought to enforce security at the intermediary level; all went fine in this effort until we routed to a secured .NET service. That .NET service expected an encrypted message, and while we had the required certificate, every time we hit the service, it returned a fault. What went wrong? Investigating the problem, we discovered that WSS4J, in compliance with WS-Security, uses “xmldsig” in the name space — but the .NET service expected “xmlds.” This is just one example to remind you that while you must adhere to known security specifications in your SOA build-out, you must also carefully review security implementations that integrate different protocols and different vendors’ instantiations of com-mon security specs. Regardless of which protocols you are trying to integrate, using an XMKS-based framework to support security is an excellent starting place.

3. Ill-conceived use of naming conventions and/or registries Remember that in an SOA architecture, mul-tiple versions of the same services can be adver-tised and consumed simultaneously by differ-ent users in myriad departments around the organization. Because of this, arbitrary naming conventions must be avoided. We recommend you include at least the following parameters in

Page 17: SOA World Magazine-Enterprise SOA

32 OCTOBER 2008 www.SOA.sys-con.com OCTOBER 2008 33 www.SOA.sys-con.com

ment tools. Few enterprises can track the changing relationships among workgroup servers, databases, Web servers and enterprise service buses and metadata repositories. They can see part of the overall picture, according to EMA, but the visibility gap means they can’t necessarily track end-to-end performance or handle change management, and they do no Application Service Modeling. EMA found that mapping the impact of change management alone can slam an enterprise hard. “For enterprises with a highly structured IT management environment, 25% of their changes result in some kind of production problem,” the report said. “For those who aren’t as structured, that figure can run as high as 80%.” While a standalone APM approach will suffice for relatively sim-ple J2EE applications, APM alone has become obsolete in monitor-ing and managing SOA and other complex composite applications. What these tools fail to capture are the service entry and exit points associated with a particular application or transaction. You might have application component services running on three different servers, but which handles shipping logistics versus quote func-tions? This gets harder to discern as applications leverage shared components on middleware platforms. These legacy tools provide visibility into the performance of code components, but they fail to correlate component performance to the performance of the ap-plication services delivered. Why is this important? Service correlation is critical because it provides the ability to set performance metrics on particular services or business functions, and then diagnose and optimize the performance of applications on a service-by-service basis. The very purpose of an enterprise application is to provide business services, and if a problem with the performance or availability of a particular application service supported by shared application

components can’t be triaged quickly, the value of the application is soon overcome by the cost of outages, poor performance, and the general maintenance chaos associated with constant support. Ser-vice-oriented application complexity makes it doubly challenging to benchmark and tune performance, trace root cause of problems, and adequately plan capacity.

Common SOA Requirements Lead to a Service Modeling Approach As many readers know, the most widely used application profil-ing technique is bytecode instrumentation. How it works is that the profiler inserts bytecode into each class. For CPU performance profiling, these bytecodes are typically methodEntry() and metho-dExit() calls. For memory profiling, the bytecodes are inserted after each new or after each constructor. All of this bytecode insertion is done either by a post-compiler or a custom class loader. The key limitation in this technique is that once a class has been modified, it doesn’t change. This lack of flexibility often causes problems down the road. If you choose to profile the entire applica-tion, the overhead of all that instrumentation can cause serious performance problems. But if you use a package or class-based fil-ter to limit the instrumentation, you might end up not profiling an important part of the application. Further, if changing the instru-mentation requires restarting the application, the profiling process slows down considerably. In our case, the incumbent application management system in place relied purely on bytecode instrumentation. So we began our search for a better way to monitor the health of our service-orient-ed applications by eliminating what we know we didn’t want and by defining what we did: context. Bytecode instrumentation in and of

�������������������������

ISB

N 0

-977

7622

-0-3

from the World s̓ Leading i-Technology Publisher�����������������

© COPYRIGHT 2007 SYS-CON MEDIA�������������

ISB

N 0

-977

7622

-2-X

ISB

N 0

-977

7622

-2-X

��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

�������������������������������������

from the World s̓ Leading i-Technology Publisher�����������������

© COPYRIGHT 2007 SYS-CON MEDIA�������������

���������������������������������������������������������������������������������������������������������������������������������������������

������

���������

�������

����������

���������

��������

���������

�������

������������������������������������������������������������������������������

���������������������������������������������

�������������������������������

��������������������������������������

�������������������������������

����������������������������������������������������������������������������������������

� �����������������������������������������������������������������������������������

������

���������

�������

����������

��������

�������

��������

�������

MODELING

Making the Case for Application Service Modeling in SOA Environments

BY BARNEY SENE

For most companies, employing the latest technology is vital to staying competi-tive. For some companies in fact, service orientation is a key pillar of business suc-

cess. As CTO of a Fortune 500 company, my SOA challenges aren’t small. A little more than a year into our SOA deploy-ment project, we already have pure SOA ap-plications running in our environment. As the

world’s largest technology distributor and a leading technology sales, marketing and logistics company, we rely on automation to power our international supply chain fulfillment site. Through it, we offer solutions and services to approximately 170,000 resellers in 150 countries by distributing and marketing hundreds of thousands of IT products worldwide from nearly 400 suppliers. Many small to medium-size businesses prefer to source technology products from resellers instead of direct from the manufacturer to realize more favorable licensing and support terms. Our mission is to be a vital link in the technology value chain, creating sales and profitability opportunities for hardware and software vendors, technology solution providers, and resellers through unique marketing programs, outsourced logistics services, technical support, financial services, and product aggregation and distribution. We have to be as smart about acquiring technology for our own use as we are sourcing it for our VAR and reseller customers. Any so-lution we deploy on our domestic and global commerce sites must not detract from our central purpose: to help our business partners grow their profit and expand their market reach. For example, an offering central to our business is producing branded catalogs of available technology products tailored for resellers – anywhere in the world. So our service-oriented applications are only becoming more and more sophisticated to meet these custom requirements. The complex chain of services provided already includes order management and fulfillment, contract manufacturing, contract warehousing, product procurement, product pack out and cartoni-zation, reverse logistics, transportation management, customer care, credit and collection management services, among others.

The Challenge: Ensure the Delivery of Services Despite Application Volatility As more and more IT departments deploy multi-tier middleware

platforms and frameworks for the delivery of business-critical ap-plication services, they are expecting to garner the well-publicized benefits of a Service Oriented Architecture (SOA) approach: agility, flexibility, productivity, and extensibility. But going SOA demands special vigilance to avoid the pitfalls of Application Performance Management exposed by service orientation. Even as a $35 billion global company, our vision of SOA is no less challenging, if not unique, than that of other companies. It is vitally important to deploy an application infrastructure that allows IT to add additional services on top of an existing application without having to change the underlying foundation each and every time. Agile and extensible, today’s composite applications are expected not only to align with business processes at deployment, but then to adjust to change quickly and dynamically as market pressures dictate. The more unique Web Services that can be sourced and provided to customers from “the cloud” then integrated within our fulfillment application site without recoding, the better. Yet this “last mile” of alignment – which sometimes dictates that deployed applications get reconfigured weekly or even daily – is trying to guarantee the continued delivery of business-critical services on the backs of some pretty volatile applications. Controlling the inherent volatility of SOA is the only way we can remain able to roll out new services quicker and respond to customer needs better. For example, over the past year we’ve added an enhanced shopping cart, enhanced product search and order status, to name a few. Yet in the course of implementing SOA, we identified a major “visibility gap” inherent in traditional systems management tools and application performance management solutions. Sure, these tools are great at tracking IT assets, what they’re running, whether they’re operating efficiently, and who’s using them. But SOA’s com-posite approach to building and delivering applications renders discovery mechanisms such as SNMP monitoring, transaction trac-ing, and infrastructure mapping tools pretty ineffective. The major middleware technologies that organizations invested so heavily in actually hide the key relationships between business functions – like connections between inventory, fulfillment, and accounts receivable, for example. A recent survey of 150 IT executives by industry analyst firm Enterprise Management Associates (EMA) found that the top concerns in managing heterogeneous distributed applications were the high cost of support and the lack of available manage-

A Fortune 500 discovers visibility it didn’t know was possible

Page 18: SOA World Magazine-Enterprise SOA

34 OCTOBER 2008 www.SOA.sys-con.com OCTOBER 2008 35 www.SOA.sys-con.com

Sound Architecture Requires Proper Planning

Add Web Age Solutions to your plan & stay ahead of the competition

Custom training plans for virtually every job roleBUSINESS ANALYST ADMINISTRATOR DEVELOPER ARCHITECT QA/TESTER MANAGER EXECUTIVE SECURITY

Custom training for complementary SOA technologiesXML WEB SERVICES WSDL SOAP WEBSPHERE WEBLOGIC JBOSS J2EE SPRING/HIBERNATE/STRUTS WID/WBI/WMB

WEB AGE SOLUTIONS - YOUR TRAINING PARTNER FOR SOA

www.webagesolutions.com [email protected] 877.517.6540- -

Consulting services for all phases of SOA migration

In all phases of SOA migration, Web Age Solutions provides training and customized services from awareness to implementation. We support vendor specific or generic SOA training tailored

to your organization's needs.

MODELING

itself isn’t bad, but when employed without knowing the context of the application services as delivered it’s a bit like getting dressed in the dark. You can do it, but you really have no idea how you look. The search for a solution to our visibility problem was not short on requirements. We knew what we wanted. Among other require-ments, we wanted an intuitive management console, deep transac-tion mapping and modeling, persistent performance metrics on all components, advanced diagnosis and resolution capabilities, and historical/trend reporting. We’re an IBM shop, so the solution selected had to run well on WebSphere and related middleware. Finally, any solution had to pass muster with our outsourcing vendor and deploy rapidly without needing to loop in developers or additional expert resources. Based on these unique requirements and the solutions consid-ered, we decided that Application Service Modeling was the best approach to meet our needs. Application Service Modeling provides the necessary contextual visibility. It dynamically correlates the services provided by applications to the underlying code compo-nents supporting those services providing the necessary contextual visibility to manage their performance effectively. A recent Forrester Research report said that “the model-based approach is a ‘must-have’ for more complex composite applications, such as SOA apps and portals.”

Application Service Modeling Enables Superior Service Delivery Model-based monitoring of service-oriented applications is all about increasing contextual visibility. Application Service Model-ing delivers visibility into our service-oriented applications in the context of which business services are being enabled by which ap-plication components across our SOA infrastructure. Once IT had the necessary contextual visibility, we were able to manage one or more components to tune service delivery. Modeling at the application level returns a visual topology model of the infrastructure under each application service, so the dependencies integral to providing each service are laid bare. How this works is that the metadata in jar files, configuration files, and databases are parsed to detect all entry points. After this procedure is completed, the services are modeled, the metrics are determined, and then both are overlaid on the model. Any models that the tool generates automatically update them-selves as underlying components and relationships change, and do not require manual intervention or attention to these updates. Automation gives you a much better chance of keeping your busi-ness-critical services up and running. Additionally, IT organizations need a dependable means for doing an impact analysis. For ex-ample, before a pre-planned change is made, IT operations must be able to identify all application processes, application components, systems, etc. that will be impacted by the change. This adds signifi-cant value in a way that’s not possible without having the necessary context to bridge the IT visibility gap. Application Service Modeling provides a degree of visibility and troubleshooting capabilities we simply did not know was possible. For example, the system revealed in five minutes the root cause of a problem on which we had spent eight weeks trying to diagnose. So what was the problem? A search function on our Web site that allows customers to find and purchase products wasn’t working – a big issue to say the least. My staff spent six weeks trying to nail down the root cause. The job was complicated by all the third-party software that we had either

acquired or integrated into our data center. We launched a new version of a client’s commerce site, but didn’t see the issue arise until the transaction volume rose, and then it impacted us across our whole Web tier. At first we assumed it was a database issue with connection pulling, specific to our application. Within 24 hours of deploying Application Service Modeling, we were able to trace full transactions not just in the systems we had developed but into third-party tiers and applications as well. That in turn allowed us to isolate the problem. This was significant, since we used to spend so much time debating with vendors who needs to fix a problem. Service modeling is what allowed us to tune and test, over-tune and test while monitoring for the optimal perfor-mance fix. Doing SOA right demands an accurate diagnosis of trouble sources, especially across virtualized and shared resources. Impressed by the capabilities of an Application Service Modeling approach to diagnostics and repair, we have adopted the technol-ogy across our business-critical commerce sites domestically and worldwide. The benefits realized have included shorter mean time to repair, improved application service levels, and greater return on investment for our service-oriented applications. We identified ad-ditional areas for improving the central Web commerce application code leading to greater stability and improved performance. One of our SOA developers came to believe that employing Application Service Modeling earlier could literally have saved years of develop-ment time (I’m not kidding). But perhaps most important, it helps us fulfill our central mission of earning the respect and loyalty of our business partners through superior value and service.

Conclusion Application Service Modeling bridges the IT visibility gap inher-ent in today’s dynamic composite applications. Without having this contextual visibility, it has become impossible to effectively diag-nose application service problems in enterprise applications that leverage multiple layers of middleware under a barrage of constant change. An unmanageable application, no matter how sophisti-cated or rich the services, provides little value to an organization. Further, an IT operations team must understand an application’s logic to be able to effectively conduct the impact analysis required to stay ahead of potential application problems. By managing complex composite applications at the application services level, IT organizations can maximize application performance levels, reduce the mean time to resolution, and maximize productivity. A more sophisticated approach is needed to achieve the “last mile” of aligning IT with the business and enabling the organization to yield expected ROI from its composite application investments.

Resources• www.IngramMicro.com • www.ClearApp.com• www.EnterpriseManagement.com

About the Author

Barney Sene is Corporate Vice President and Chief Technology Officer, of Ingram Micro Inc, the

world’s largest technology distributor. His responsibilities include leading the IT enterprise

architecture team, and driving system designs and IT strategies that support the company’s

business goals. He leads a global organization that supports operations in 39 countries and

sales presence in 140 countries. Barney joined Ingram Micro in July 2005 and brought with

him more than 20 years of experience in IT architecture design, systems operations, and

application development. Barney was previously Vice President and Chief Technology Officer

at WellPoint Health Networks Inc. in Thousand Oaks, California, where he oversaw enterprise