Documente Academic
Documente Profesional
Documente Cultură
Lee Ackerman
Paul Elder
Chris Busch
Ana Lopez-Mancisidor
Jin Kimura
Rishi S. Balaji
ibm.com/redbooks
SG24-7529-00
Note: Before using this information and the product it supports, read the information in Notices on
Notices on page xv.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
The team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Part 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 1. Introduction to Asset-Based Development . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Software delivery challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 The reuse challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Value of using assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Asset-Based Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.1 Asset management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.2 Artifacts within reusable assets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.3 Styles of reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.4 Packaging assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5 Asset life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6 Asset repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.7 Reuse success factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.8 Guide to the remaining chapters of this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Chapter 2. ZYX Electronics case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Overview of ZYX Electronics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 CEO interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 CIO interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4 Business composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 The business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Information technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Scope and approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2 Approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
18
18
18
20
22
23
25
26
26
28
28
29
30
31
33
33
35
35
36
iii
3.4
3.5
3.6
3.7
3.8
36
36
37
37
38
38
39
39
39
40
44
45
45
46
46
47
49
49
49
50
52
52
53
56
59
iv
103
103
104
105
111
114
115
117
117
117
117
117
118
120
120
Contents
7.17.2 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.18 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.19 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.20 Key concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.21 Asset-Based Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.22 Motivations for Asset-Based Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.23 Assets and artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.24 Asset standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.25 Reuse vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.26 Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.26.1 Realizing the vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.27 Identified risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.27.1 Asset misidentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.27.2 Asset Consumer mis-targeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.27.3 Volume-centric Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.27.4 Asset governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.27.5 Over-engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.27.6 Do It Yourself (DIY) equals innovation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.27.7 Budget and resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.28 Reuse environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.29 Reuse environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.30 Asset-Based Development process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.31 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.32 Asset production strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.33 Reuse infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.34 Reuse implementation strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.34.1 Reuse adoption strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.35 Maturity model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.36 Organizational templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.37 How it all fits together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.38 Reuse implementation plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.39 Phase one: Existing assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.39.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.39.2 Goals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.40 Phase two: Pattern-based engineering rollout . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.40.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.40.2 Goals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.41 Phase three: Services as assets rollout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.41.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.41.2 Goals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.42 Phase four: Post-pilot review and analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.42.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.42.2 Goals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
154
155
156
157
157
158
158
159
160
162
164
166
166
166
167
167
167
168
168
168
168
168
169
171
172
173
173
175
180
183
184
184
184
185
185
185
185
185
185
186
186
186
186
7.43
7.44
7.45
7.46
7.47
7.48
7.49
7.50
7.51
7.52
7.53
7.54
187
188
190
190
190
191
191
192
192
193
193
194
195
196
197
203
205
209
211
214
217
218
228
232
235
237
237
238
239
240
242
245
248
249
251
252
253
257
261
270
272
279
281
282
283
283
284
286
288
289
Contents
vii
290
290
295
297
303
304
305
306
307
307
309
310
311
313
314
314
315
316
317
318
318
324
324
324
326
331
335
336
336
336
336
338
339
339
340
340
341
341
341
343
343
345
346
349
349
349
350
350
351
352
353
354
355
355
355
356
359
360
360
362
366
371
373
374
375
380
380
382
383
383
386
387
392
392
393
394
399
400
400
402
403
403
406
410
411
414
415
Contents
ix
445
445
447
447
453
457
458
458
459
460
460
461
462
463
464
464
465
466
466
466
467
468
468
469
470
473
473
475
479
479
481
482
483
485
488
495
495
503
506
506
507
511
518
518
518
521
521
522
523
523
523
524
525
526
527
528
529
530
530
530
531
531
531
531
532
532
532
532
532
534
535
536
536
536
538
540
541
545
545
547
557
558
559
569
571
572
572
574
578
580
581
583
584
586
587
588
588
588
589
589
590
Contents
xi
xii
593
594
594
594
594
598
598
600
600
600
601
603
604
606
608
608
610
611
611
613
614
614
615
615
616
618
619
619
621
623
623
624
625
626
626
626
627
629
631
632
632
632
637
638
642
643
644
648
655
657
661
661
665
688
702
702
702
703
703
704
705
707
708
710
711
711
713
714
715
717
718
719
722
723
724
724
725
725
725
725
726
Contents
xiii
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to get IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
729
729
729
729
730
730
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
xiv
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs.
xv
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines
Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are
marked on their first occurrence in this information with a trademark symbol ( or ), these symbols indicate
U.S. registered or common law trademarks owned by IBM at the time this information was published. Such
trademarks may also be registered or common law trademarks in other countries. A current list of IBM
trademarks is available on the Web at Copyright and trademark information at:
http://www.ibm.com/legal/copytrade.shtml
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Redbooks (logo)
alphaWorks
developerWorks
i5/OS
z/OS
Ascendant
AIX
ClearCase
ClearQuest
Component Business Model
CICS
DB2
IBM
ProjectConsole
PureCoverage
PurifyPlus
Rational Rose
Rational Summit
Rational Unified Process
Rational
Redbooks
Requisite
RequisitePro
RUP
Summit Ascendant
Summit
System z
Team Unifying Platform
Tivoli
WebSphere
XDE
xvi
Preface
Reuse has often been touted as an approach to solving issues, such as time to market and
solution quality. Reuse over the years has taken on a number of forms, ranging from copy and
paste of code, reuse of objects, reuse of components, to more recently the reuse of services.
However, we still find ourselves running late on our projects (when we do deliver) and having
poor quality.
Unfortunately, we often underestimate the effort and forethought needed in creating a
successful reuse program within an organization. Successful reuse does not happen by
accident or by just wishing it to be true.
This IBM Redbooks publication is focused on a best practice-based approach to strategic
reuse within software delivery, known as Asset-Based Development, that will assist in
addressing these issues. We do not contend that this is the silver bullet that will fix all of the
issues that ail software delivery. However, Asset-Based Development is a key tool that needs
to be found within the tool chest of all software development organizations (or at least those
that want to succeed).
This book, as shown in Figure 1, is comprised of four major parts and a set of appendixes.
Part 1:
Introduction
Part 2:
Reusable Assets
Introduction to
Asset-Based
Development
Adopting
Asset-Based
Development
Process and
Tooling
Configuring
Asset
Management
Case Study
Overview
Produce,
Consume, and
Manage Assets
Part 3:
Services
Services as Assets
Produce, Consume,
and Manage Service
Assets
Appendixes
Rational Asset
Manager
Installation and
Administration
Process
Integration
Part 4:
Patterns
Patterns as Assets
Produce, Consume,
and Manage Pattern
Assets
Although we encourage you to read the entire book, we also recognize that different
audiences have more interest in certain areas than other areas. Therefore, we have a short
guide to the contents found within this book:
For an overview of Asset-Based Development, including process, roles, tooling, and types
of assets, read Part 1, Introduction on page 1.
For a detailed look at effective asset management, read Part 2, Reusable Assets on
page 123.
If you want to build reusable service-oriented architecture (SOA) service-based assets,
read Part 1, Introduction on page 1, Part 2, Reusable Assets on page 123, and Part 3,
Service Assets in an SOA on page 333.
xvii
If you want to build pattern-based engineering reusable assets, we have had excellent
results in groups adopting pattern-based engineering as a starting point into an asset
program. This starting point has proven to provide a quick time to market, significant ROI,
and high quality. Detailed guidance covering pattern-based engineering is provided in
Part 4, Patterns on page 455:
After you have succeeded with pattern-based engineering, it becomes easier to invest
in and launch a larger reuse initiative. As your skills in reuse mature and you build
further competency, we encourage you to follow up your patterns experience by
reading Part 1, Introduction on page 1 and Part 2, Reusable Assets on page 123.
If you are going to use patterns to build services, read Part 3, Service Assets in an
SOA on page 333 as well.
For those people, who want to deploy and administer Rational Asset Manager, then refer
to Part 1, Introduction on page 1, Part 2, Reusable Assets on page 123, and
Appendix A, Rational Asset Manager: Installation and administration on page 637.
Note that a number of sections in the book discuss topics that in real life happen
concurrently. Unfortunately, it is difficult to present topics in a book concurrently.
Figure 2 From left: Lee Ackerman, Paul Elder, Rishi S. Balaji, Ana Lopez-Mancisidor, and Jin Kimura
xviii
Lee Ackerman is a Senior Product Manager with the Rational Learning Services and
Solutions team in Canada. He has 12 years of experience in the software development field,
the last seven of which have been spent IBM. He holds a Bachelors degree in Business
Administration from the University of Regina. His areas of expertise include model-driven
development, pattern-based engineering, and service-oriented architecture. He has written
extensively about these topics and often presents at conferences, workshops, and training
events.
Paul Elder is a a Senior Software Developer in the IBM Ottawa Lab (Canada). He is the
Project Lead on the Eclipse Model-to-Text (M2T) project and the development lead for the
IBM Rational model-to-text development tools. He has 23 years experience in the software
development field and has worked with IBM Rational for the past seven years. He holds a
Bachelors degree in Mathematics from the University of Waterloo and a Masters of Business
Administration from the University of Ottawa. His areas of expertise include model-driven
development, pattern-based engineering, and Java and Eclipse development.
Chris Busch is a Business Flexibility (SOA) Practice Lead with the IBM Rational TechWorks
team in the United States. He has 19 years experience in the software development field and
13 years using Rational Software processes and tools. He has been part of the Rational
Software Technical Sales team since 1999 with a focus on software development best
practices, requirements and change management, modeling, SOA, and governance. He
writes extensive proof-of-technology material and develops implementation solutions to
provide internal training and client awareness of Business Driven Development, SOA, SOA
Governance, Service Life Cycle Management, and Asset-Based Development and
management. He often presents at conferences and user groups and delivers workshops and
training to IBM clients and IBM Business Partners.
Ana Lopez-Mancisidor is a Certified IT Specialist in Software Application Development for
IBM Rational Technical Sales in Spain. She has 14 years of experience in the software
development field and nine years of experience using IBM Rational tools. She holds a
Bachelors degree in Telecommunications Engineering from the Polytechnic University of
Madrid. Her areas of expertise include the software development process, Asset-Based
Development, requirements and change management, UML modeling, and testing. As part of
the Rational Technical Sales Team, she provides consultancy to clients helping them to
deploy and customize the Rational Unified Process and Rational tools to meet their needs.
Jin Kimura is an Advisory IT Specialist for IBM Global Technology Services in Japan. He has
six years of experience in the software development field. He holds a Masters of Science in
Chemistry from Tohoku University, Japan. His areas of expertise include the design and
development of J2EE applications with various assets and the management of their
complete end-to-end life cycle.
Preface
xix
Rishi S. Balaji is an Associate Architect at the Global Business Solutions Centre in IBM
India. He has six and a half years of experience in software development. He has been with
IBM for four and a half years, with three years in WebSphere development at India Software
Labs and the rest in asset development for the Global Business Solutions Center.His
expertise is in design and development of J2EE applications and reusable assets for
service-oriented architectures.
Special thanks to Grant Larsen, STSM, Chief Architect - Asset Management, IBM Denver, for
creating and providing access to many materials including articles, presentations, and white
papers. Also, we appreciate the time, guidance, and reviews that he provided.
Along the way, many people have contributed feedback and reference materials. We also
want to thank the following people for their contributions to this project:
Dan Popescu, IBM Vancouver
Scott Ambler, IBM Toronto
Grady Booch, IBM Boulder
Bruce Besch, IBM Atlanta
Kelli Houston, IBM Orlando
Gili Mendel, IBM Raleigh
Carlos Ferreira, IBM Lexington
Thierry Matusiak, IBM France
Ralph Schoon, IBM Germany
Bertrand Portier, IBM Toronto
Brian Paulsen, IBM Kansas
Dino Dagostino, IBM Toronto
Manprit Singh, IBM India
Darrell Schrag, IBM Chicago
Cindy VanEpps, IBM Houston
Derek Holt, IBM Raleigh
Chris Gerken, IBM Austin
Geoff Hambrick, IBM Austin
Jim Amsden, IBM Raleigh
Greg Rader, IBM Oklahoma
Franco Potepan, IBM Lexington
Germn Goldszmidt, IBM Watson
Carl Osipov, IBM Watson
xx
and
Joe DeCarlo, Manager - Special Projects, ITSO San Jose, California
And we also want to thank the authors of previous IBM Redbooks publications from which we
have reused content, including:
The IBM Rational Unified Process for System z, SG24-7362-00, by Enrico Mancin, Cecile
Peraire, Angelo Fernandes, Mike Edwards, and Kathy Carroll
Building SOA Solutions with the Rational SDP, SG24-7356-00, by Ueli Wahli, Lee Ackerman,
Alessandro Di Bari, Gregory Hodgkinson, Anthony Kesterton, Laura Olson, and Bertrand
Portier
Comments welcome
Your comments are important to us!
We want our books to be as helpful as possible. Send us your comments about this book or
other IBM Redbooks publications in one of the following ways:
Use the online Contact us review IBM Redbooks publications form found at:
ibm.com/redbooks
Send your comments in an e-mail to:
redbooks@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
Preface
xxi
xxii
Part 1
Part
Introduction
In this part, we introduce you to Asset-Based Development. As shown in Figure P-1, this will
also include a discussion of the business drivers, methodology, and associated tooling.
Part 1:
Introduction
Part 2:
Reusable Assets
Introduction to
Asset-Based
Development
Adopting
Asset-Based
Development
Process and
Tooling
Configuring
Asset
Management
Case Study
Overview
Produce,
Consume, and
Manage Assets
Part 3:
Services
Services as Assets
Produce, Consume,
and Manage Service
Assets
Appendixes
Rational Asset
Manager
Installation and
Administration
Process
Integration
Part 4:
Patterns
Patterns as Assets
Produce, Consume,
and Manage Pattern
Assets
Chapter 1.
Introduction to Asset-Based
Development
Software delivery has traditionally faced challenges regarding quality and time to market. As
software becomes increasingly intertwined with business success, expectations on the
software organization magnify these challenges. In this chapter, we introduce Asset-Based
Development as a key mechanism for addressing these challenges.
Business
Senior Executive
Define
Requirements
Model the
Business
Protect
IT Operations
Manager
Architect the
Solution
Analyst
Project Manager
Manage
Application
Support
Manage
Change
& Assets
Deploy
Implement
Architect
Test
Developer
Tester
Development
The software organization must be aware of the issues and concerns that face the business.
For example, Figure 1-2 on page 5 shows results from a CEO survey conducted by IBM. A
key outcome from the survey was that CEOs see innovation as a key to profitable growth.
Software plays a key role in supporting business innovation - ideally, allowing the business to
be agile and flexible. However, a number of external forces are bearing down on the business
and have implications across the organization. So in addition to figuring out how to improve
time to market and the quality of our deliverables, we also have to deal with skill shortages,
regulatory concerns, increasing expectations from clients, and so forth.
Clearly, we need to find better ways to deliver software.
The definition for systematic reuse comes from Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998.
Electronically reproduced by permission of Pearson Education, Inc., Saddle River, NJ., which references M.
Ogush, Terms in transition: a software reuse lexicon, Crosstalk: The Journal of Defense software Engineering,
pages 41-45, Dec. 1992.
In the meantime, rather than just provide an answer of It depends, let us take a moment to
review examples that we have come across that highlight the impact that reusable assets can
have within an organization. These results come from a collection of sources, including IBM
internal reuse, IBM client engagements, and experiences from the wider industry.
First, let us look at several results reported from the wider industry:
In Software Reuse: Architecture, Process, and Organization for Business Success2,
Jacobsen et al estimate the following benefits of systematic reuse:
Time to market: 2 to 5 times reduction
Defect density: 5 to 10 times reduction
Maintenance cost: 5 to 10 times reduction
Jeffrey Poulin, in Measuring Software Reuse3, proposes that the Relative Cost of Writing
for Reuse is 1.5. This means that there is an additional 50% cost when building reusable
software. He also proposes that the Relative Cost of Reuse is 0.2. This means that the
relative cost to use the asset is 20% of what it cost compared to having to rebuild the
solution.
In terms of IBM experiences, we can look at a few examples:
Leveraging pattern-based engineering, which is covered in Part 4, Patterns on page 455
of this book, a client was able to generate over 50% of the code necessary for a J2EE
solution.
In another case, a composite business service, which is covered in Part 3, Service Assets
in an SOA on page 333 of this book, was created for handling New Quotes for Home and
Auto Insurance. A client was able to reuse this Composite Business Service to achieve the
following results:
Increased top-line growth: Number of personal property quotes increased by a factor of
ten in one year, without adding staff
Increased asset reuse: 52 percent reuse across initiatives
Reduced operating costs: Experienced reduction in call center traffic with the reduction
in phone calls, faxes, and paper-based processes benefiting not just the client, but also
reducing costs, improving margins, and enhancing loyalty for partners
In terms of internal IBM experiences, we can look at an example of how an internal
development team leveraged pattern-based engineering. The development team needed to
re-architect a set of servlet-based commands into a set of Web services to support a
separation of application logic from presentation. There were over 100 services that needed
to be created in this manner. An initial attempt at detailing the steps needed to perform the
conversion ended up in a 100 page document. The steps needed to be followed in sequence
and required an individual developer four days to follow. A two day effort was put forth in
creating a pattern implementation that generated in minutes the service infrastructure and
associated test cases. The developers were then able to focus their efforts on adding in the
required business logic.
2
3
Software Reuse - Architecture, Process, and Organization for Business Success. Ivar Jacobson, Martin Griss, and
Patrik Jonsson, page 7.
Measuring Software Reuse. Jeffrey Poulin, pages 25-29.
Business domain
When in the process the asset is to be used
Where in the architecture the asset is to be used
Dependencies: relationships to other assets
Interfaces provided and consumed
Services provided and consumed
Policies compliant and ignored
Test plans
Test scripts
Deployment descriptors
Model templates
UML profiles
Domain specific languages
This is a quite a wide ranging, although not exhaustive, list of artifacts - which makes sense
when we think about all of the roles and elements that come together during the delivery of a
software project.
In addition to the artifacts that form the core of the reusable asset, you will find a selection of
additional, supporting artifacts within the asset, such as:
Documentation explanations:
How to use the asset
How to customize the asset
The goals, motivation, and purpose of the asset
Models that provide a visual representation of the elements involved in using the asset
Test artifacts
Build artifacts
These assets are needed to improve the consumability of the asset. If we do not take the step
to make the asset consumable, all of the effort that went into building the asset is for naught.
Remember that the value of an asset will vary depending on a number of factors. Later in
Chapter 6, Value, impact, and return on investment on page 103, we will look at metrics,
ROI, and scorecards to help assess the value of an asset. In many cases, the roles, activities,
and deliverables associated with Asset-Based Development can be applied generically
across reusable assets. However, we do find that Service-based assets and Pattern-based
assets stand higher than the other types of assets and require a more detailed examination.
10
In support of packaging assets, we are able to leverage the Reusable Asset Specification - a
standard supported by IBM within the Object Management Group (OMG).
11
Again, we come back to the idea that successful reuse does not happen by accident. We do
not just happen upon reuse and reap the rewards. To succeed, an investment is made in
enablement, tooling, process, and governance.
12
A Repository can be specialized to hold and manage the assets that define the enterprise
architecture for an organization.
Figure 1-6 highlights the benefits that are expected when we use an asset Repository, such
as Rational Asset Manager.
Manage compliance by
governing multi-platform
development assets
Accelerate delivery of
increased quality and
reliability applications
Unify disparate
development teams to
enable reuse and eliminate
unnecessary rework
13
Training for producers and consumers: For reuse to be successful, those people
producing assets must have skills in producing assets that are reusable. The Asset
Consumers need to understand how to find assets, use them in the environments, and if
appropriate, customize the assets for a particular situation.
Measuring productivity and quality: Understanding asset usage, asset quality, and the
cost and impact of assets is key to the program.
Sponsorship and maintenance of assets: Much like a software application, the cost to
maintain and support an asset does not end at the first release. There needs to be a plan
and support for the continued maintenance of the asset.
Communication of asset status to Asset Consumers: The Asset Producer needs to
understand where and how the asset is being used. This will assist the producer in
prioritizing the repair of defects and how to introduce and manage changes to the asset.
Commitment to high quality assets: Without a focus on high quality assets, a
Repository will become a junkyard, a dumping ground for any old thing that might be
reusable. This environment is unlikely to find success as the consumers of assets quickly
learn that it is quicker, easier, and less risky to proceed on their own.
Well-understood domains: Assets are meant to contain and represent best practice
solutions. To be able to build and support such assets, the Asset Producer needs to
understand the domain for the asset.
Customizable, coarse-grained reuse: Successful assets tend to have built-in support for
customization. In cases where there is unlimited access to changing and customizing the
asset, the consumer will find the assets flexibility overwhelming and lacking in guidance.
Architectures established to create and use assets: Related to understanding the
domain, we also need to understand the architectures that are targeted by the assets
being built.
Process and organizational structure to support reuse: In order for reuse to succeed
within the organization, there generally must be a team that focuses on manufacturing
assets. The challenge of this is that there are many technology domains for which
reusable assets can be created, and it is difficult if not impossible to have one team that
has all of the experts needed. Therefore, you generally have a core team that understands
the principles of asset manufacturing, and you have visiting experts that join for a time to
give guidance on the development of specific asset types. The enterprise needs to
support this activity of harvesting expert knowledge into reusable assets, when and where
it makes sense to the business.
You will see these factors discussed further as we make our way through this book. In
addition, these factors are built into the development process supported via tooling and
standards.
14
Part 1:
Introduction
Part 2:
Reusable Assets
Introduction to
Asset-Based
Development
Adopting AssetBased
Development
Process and
Tooling
Configuring
Asset
Management
Case Study
Overview
Produce,
Consume, and
Manage Assets
Part 3:
Services
Services as Assets
Produce, Consume,
and Manage Service
Assets
Appendixes
Rational Asset
Manager
Installation and
Administration
Process
Integration
Part 4:
Patterns
Patterns as Assets
Produce, Consume,
and Manage Pattern
Assets
Although we encourage you to read the entire book, we also recognize that different
audiences have more interest in certain areas than other areas. Therefore, we have a short
guide to the contents found within this book:
For an overview of Asset-Based Development, including process, roles, tooling, and types
of assets, read Part 1, Introduction on page 1.
For a detailed look at effective asset management, read Part 2, Reusable Assets on
page 123.
If you want to build reusable service-oriented architecture (SOA) service-based assets,
read Part 1, Introduction on page 1, Part 2, Reusable Assets on page 123, and Part 3,
Service Assets in an SOA on page 333.
If you want to build pattern-based engineering reusable assets, we have had excellent
results in groups adopting pattern-based engineering as a starting point into an asset
program. This starting point has proven to provide a quick time to market, significant ROI,
and high quality. Detailed guidance covering pattern-based engineering is provided in
Part 4, Patterns on page 455:
After you have succeeded with pattern-based engineering, it becomes easier to invest
in and launch a larger reuse initiative. As your skills in reuse mature and you build
further competency, we encourage you to follow up your patterns experience by
reading Part 1, Introduction on page 1 and Part 2, Reusable Assets on page 123.
If you are going to use patterns to build services, read Part 3, Service Assets in an
SOA on page 333 as well.
For those people, who want to deploy and administer Rational Asset Manager, then refer
to Part 1, Introduction on page 1, Part 2, Reusable Assets on page 123, and
Appendix A, Rational Asset Manager: Installation and administration on page 637.
Note that a number of sections in the book discuss topics that in real life happen
concurrently. Unfortunately, it is difficult to present topics in a book concurrently.
15
16
Chapter 2.
17
2.1 Introduction
This book uses a single example throughout the book to illustrate the use of IBM tooling and
processes to build and manage reusable software assets. ZYX Electronics (ZYX) will be
reviewed from an outsiders perspective, analyzed, and provided with a solution direction to
help it achieve higher returns on its software investments through software asset reuse.
ZYX Electronics is a fictitious supplier to retail, small business, and corporate customers. ZYX
has specific goals and constraints that provide a typical set of challenges for the team
implementing an asset reuse approach for software development.
2.2.1 Organization
Figure 2-1 illustrates the Chief Executive Officers (CEOs) organizational chart focusing on
Information Technology (IT). Chris, the CEO, has assembled a great executive staff over the
years to run the global operations and IT. Chris hopes this team will help ZYX Electronics
surpass its competition in value, service, and support for many years to come.
Cid Oreo, the Chief Information Officer (CIO) of ZYX Electronics, thinks that he has also
assembled a great team to evolve the technology department past the deep vertically focused
and autonomous development culture currently ingrained within ZYX Electronics into a
18
shared and reusable software development environment. Cid wants to reduce software
redundancy, to reduce the need for software rework, and to help make IT more agile to the
changes in the business environment. Figure 2-2 is Cids organizational structure, notably
focused on development.
Within Cids department, as outlined in Figure 2-2, a number of team members are involved
by the role in which they align. In our example reference application, the ZYX Electronics
team members who are most pertinent to the development are listed in Table 2-1. This is not
an all inclusive list, but it reflects those who might be referenced in our examples.
Table 2-1 ZYX Electronics development team roles
ZYX employee
Role
Description
Chris E. Oshman
Executive - CEO
Cid I. Oreo
Executive - CIO
Chuck T. Offilgy
Executive - CTO
Victoria Prezzio
VP of Development
Richard Compliton
Patricia Moon
Portfolio/Project Manager
Duncan Munchkin
Development Manager
19
ZYX employee
Role
Description
Greg Muldoon
GSI Manager
Bob Analyn
Al Aarkashan
(SOA) Architect
Deb Devak
(Service) Developer
Donna Archin
Data Architect
Pam Edison
Process Engineer
Irene Devin
Service Assembler/Integration
Developer
Tammy Archin
Test Architect/Manager
Terry Implemian
Rebecca Englo
Release/Build Engineer
Deon Adminio
Development Tools
Administrator and Source
Configuration Management
(SCM) Configuration Manager
20
Our success is based on a high-touch interaction with customers. Part of this high-touch
approach is that customers can use multiple channels to interact with the company. The
company wants to offer the best customer service at the lowest cost.
ZYX Electronics already has an e-business site with the lowest cost per order in the
industry. We recently acquired Jensen, Inc., and this has allowed us to strengthen our
corporate customer base. We treat our corporate customers as true business partners.
Our goal is to become the most profitable, high-touch company in the industry. Our plans
are to:
Pursue aggressive growth while minimizing risk
Optimize our corporate organization to maximize company responsiveness
Maximize our strategic investments in the best Web site in the industry
Establish the best sales force in the industry with global Customer Relationship
Management (CRM) and sales-focused call centers
Although Chris has a positive outlook about the direction of the company in general, ZYX
Electronics faces many of the same pressures exerted upon others in the industry (see
Figure 2-3). He expressed concern over the rising customer demands. Our customers are
very satisfied with our efforts as a supplier, but their expectations for better service and
delivery continue to rise. Our customers arent complacent, and nor can we be.
As noted in Chapter 1, Introduction to Asset-Based Development on page 3, CEOs are
experiencing pressures, such as rising customer expectations, commoditization of products
and services, and a shrinking world, which means that they have customers everywhere
around the globe, which brings in additional regulatory concerns internationally and which
has intensified the competition. ZYX Electronics is no exception to these pressures.
21
Internally, ZYX is also experiencing the pressures of industry technology advances. Chris is
concerned whether they can surpass, can keep up with, or will be passed by the competition.
As you can see in Figure 2-4, over the last three generations of basic technology
advancements in tools, components, and processes, software development organizations are
adopting the processes and tools that gain them efficiencies in project performance and
success. Projects are creating more reusable assets and involve writing less custom code
with more skilled labor.
Chris needs ZYX Electronics to mature out of the 90s by encouraging the organization to
adopt these sought after software practices and governance techniques. Keeping the
competitive edge through business and IT is foremost to Chris.
22
Figure 2-4 data is taken from the presentation IBM Software Group Executive Forum used with permission by Dr.
Daniel Sabbah, Rational Software.
We use both our employees and outsourced resources across multiple development
locations in several countries, with the US and Europe as core development centers
To be frank, we have very little reuse of components and skills across the company. This
is something I need to address:
Components are created to address specific application needs, but no one wants to
spend the time to harvest what we have or make the effort to understand how to reuse
what is available.
We have a tendency to rewrite common componentry over and over again.
We are not using common approaches to common software constructs.
As we transition to a service-oriented architecture (SOA), where service reuse is key, we
have a series of challenges ahead:
We set up a department to support shared services. HR was first, and SAP Enterprise
Resource Planning (ERP) was next, but it took a long time to complete (it came from
Jensen). CRM is the current project.
We have a single database, but we still keep information in different schemas
according to the area of business to which they relate. There is a resistance to sharing
customer information across the lines of business (LoBs).
We have no common terminology and cannot get the LoBs to agree. Before we can
implement SOA or make much use of reuse on a large scale, we have to get the LoBs
aligned, normalizing their requirements and designing services with the right level of
granularity.
Of our 2000 IT staff, over 1000 are developers using more than 40 various development
tools and environments.
We have no end-to-end development methodology. And, governance is a huge issue that
we have to address. You have heard about our business technology optimization
program. This will support a major development based on SOA, and without proper
governance, we will not know what services we have developed, who is responsible for
each one, or which applications are using them.
Thankfully, we have identified the key business processes that need optimization. We do
have a good idea of the current processes in this area and how they have to look. Fixing
these key business processes will help us achieve our business goals.
As you can see here, Cid understands the internal and external pressures on the ZYX
Electronics information technology department to stay current with the demands of the
business and to be flexible to respond quickly to its requests. Chris and Cid have discussed
the statistics related to corporate technology advances (see Figure 2-4 on page 22). Lagging
behind the technology adoption curve is a concern that must be addressed.
23
IBM, Global Business Systems specialists help organizations to decompose themselves into
an organized view of the business, segmented by business competencies, accountability,
and business components. The outcome is called a Component Business Model.
In reviewing Figure 2-5, the Component Business Model Heat Map (the highlighted items are
the hot areas to be addressed by the business) for ZYX Electronics, you can get a grasp for
the companys key Business Competencies, which are those items listed on the top edge of
the diagram as the column headers, that is, Business Administration, Product Management,
Customer Acquisition, and so forth. Business competencies are defined as large business
areas with characteristic skills and capabilities.
In further examination of ZYXs Component Business Model2, the row headings in the left
edge column of the diagram enumerate the scope and intent of activity and decision-making
using Directing, Controlling, and Executing. Directing is about strategy and overall direction
and policy. Controlling is about monitoring, managing exceptions, and tactical decision
making. And Executing is about doing the work.
The remaining area within the Component Business Model accounts for ZYX Electronics
business components related to business competencies and accountability. Business
components are the parts of ZYX Electronics that have the potential to operate independently
or as part of the company as a whole.
24
Component Business Model information was gathered through Franco Potepan of the IBM World wide SOA
Technical Sales team from a presentation developed by Mark Sower and Mary Etta Cope in 2006.
Looking back at Figure 2-5 on page 24, let us point out a few of the business components that
are highlighted as core to ZYX Electronicss business optimization effort. As a heat map, the
highlighted items are the hot areas to be addressed by the business:
Account Administration:
Automating the manual tasks for creating and administering accounts will:
Credit Administration:
Centralizing siloed departments and building optimized services to support the
converged organization and then negotiating better prices with our vendors while
taking advantage of our combined size will help us:
Decrease the negotiated cost (vendor volume discounts) of credit report retrieval by
20%
Sales:
Converging an optimized cross channel account application process will:
Reduce number of call center calls by the sales force and offices by 30% (account
inquiry)
Document Management:
Decreasing the number of paper documents processed by task automation will:
Understanding ZYX Electronics in this manner will help the CIO and the development
department structure themselves to support the CEOs goals. In addition, structuring
development in this fashion will provide ZYX Electronics a head start in defining reusable
business functions.
2.3 Challenges
ZYX Electronics, such as many companies, faces challenges with its current organizational
capabilities pertaining to software delivery and the reuse of its software and assets. In this
section, we will look at the challenges of ZYX Electronicss business processes as pointed
out by its Component Business Model. We will also review ITs challenges and have Cids
management team formulate a few thoughts about what will need to be addressed pertaining
to the companys Reuse Strategy.
Lastly, we will elaborate on reuse challenges in the software industry. ZYX is not alone in
their lack of a Reuse Strategy. Software reuse incurs greater costs than traditional software
development. Reuse is not free. It must be planned for and does not occur automatically
during normal software development practices. Reuse takes additional time and resources to
identify, document, and govern.
25
26
Let us recap several of the major issues Cid told us in the CIO interview related to software
reuse:
To be frank, we have very little reuse of components and skills across the company and
this is something that I want to address.
We have a tendency to rewrite common componentry over and over again.
As we transition to a service-oriented architecture (SOA), where service reuse is key, we
have a series of challenges ahead...(support for shared services)...(shared data)...(LoBs
aligned)
...(for) reuse on a large scale, we have to get the LoBs aligned.
We have no end-to-end development methodology. And governance is a huge issue that
we must address...
ZYX uses 40 plus development tools
Cid is deeply concerned about ITs ability to implement software reuse. Because ZYX has no
Asset-Based Development methodology, education on reuse is unavailable. This means
skills to identify, create, or reuse assets are lacking. And when reusable software assets are
identified, no governance mechanisms are available to determine and document who will be
responsible for maintenance, funding, quality of service, monitoring, and so forth.
Development staff are not motivated to identify and reuse software assets, either. Most
developers instead want to copy a chunk of code to customize as necessary for the
application situation. Copying code can cause maintenance nightmares if the code logic was
incorrect from the beginning.
Cid has serious work ahead of him in order to address these challenges. As we work with Cid
to identify the most pressing concerns, we can help Cid develop and focus on a number of
key IT objectives:
Speed up the delivery of software systems and yet:
Meet or beat the agreed upon delivery dates
Reduce development costs and stay within the agreed upon budget
Deliver high-quality products
Meet business goals and objectives
Provide IT assets that are more flexible to the constantly changing needs of business and
reusable across application boundaries
Restructure IT to achieve the component sharing that we need to add business flexibility,
value, and reuse of software assets
Integrate development efforts across application boundaries to help eliminate or to reduce
writing the same business functions multiple times
Determine what Asset-Based Development methodology, governance practices, skills,
and expertise that we can acquire, create, or educate to develop a software infrastructure
capable of aligning IT with the business and getting the most use and quality of each
software asset that we create
Cid is determined to upgrade the IT department practices and capabilities in order to
positively impact business value in turn helping to drive an increased revenue stream for
ZYX. Through these efforts, Cid wants to shorten application time-to-market and improve the
quality of all applications. And lastly, Cid wants these applications to incorporate the business
functionality necessitated by our customers. Cid wants true IT alignment with the business
and with our customers.
27
2.4.1 Scope
As described by the CEO earlier in this chapter, the goals are to pursue aggressive growth,
provide quick response to changing business needs, and to maximize our strategic
investments. The customers expect better service from ZYX. Better service means better
software systems delivered on time, in high quality, and functioning as needed.
The ZYX Electronics IT department now has to step up its capabilities to respond to the
business. Implementing an asset Reuse Strategy is a start, but the employees must be
committed in order to make it work. Producing software assets identified for reuse and then
reusing them requires dedication, resources, time, and money for it to succeed.
In the CIO interview, Cid articulates the need for an end-to-end methodology, software asset
reuse and governance, shared services, LoB alignment, and streamlined toolset. Cid is fully
aware the challenges ahead and is ready to scope the initiative. First of all, it is not just an IT
problem. This is a business problem, too. Introducing the ZYX Electronics organization and
Component Business Model was to provide an outline of the business functions or
components. Business components can be stand-alone or work together to accomplish a
greater need.
Components become candidates to be broken down into finer grained functionality that we
will call tasks, for simplicity. Tasks perform very specific duties within a software system. At
this level, we begin to see greater reuse opportunities where a task can be reused across
different components in order to provide identical duty without rewrite.
Seen in this way, components and tasks are the more obvious reusable software assets, but
they are identified by aligning IT architecture and design with business competencies. At IBM,
we call this a Business Driven Development approach. Again, first of all, the business is in the
scope of our asset reuse vision.
The other side of this scope is, of course, the IT department. IT develops the systems that the
business uses to manage its business and the systems that its customers, partners, system
integrators, and so forth use to interact with the business. These systems are at the center of
the microscope with respect to reuse.
And in the midst of both the business and IT, we insert an Asset-Based Development
methodology, which guides the organization through asset identification, specification,
production, consumption, and management. Asset-Based Development is a work product or
instantiation of the Asset Governance processes that are defined by ZYX Electronics.
Governance is the critical success factor in Asset-Based Development.
28
Reuse can be approached in a number of ways, which we will describe later. At this point, Cid
will ask the IT team to look at existing system implementations, as well as at new applications
for reuse opportunities.
ZYX Electronics is limiting the initial scope of their Reuse Strategy and efforts to:
Software requirements: functional and non-functional
Architectures and designs, including models, transformations, and patterns
Interface specifications and other documentation
Specific code constructs and patterns
SOA-based services
Test plans and test cases
The book might not address all of these reuse opportunities, but it is a good list for ZYX to
start with and to be aware of in their development efforts.
2.4.2 Approach
Cid has scoped the asset reuse effort; now, he must lay out how he intends to approach
resolving the asset reuse challenges. From all that we have learned thus far in this book,
implementing and enforcing an entire methodology and the tools to automate and measure
results in a single sweep across the organization are a guaranteed way not to succeed.
People instinctively do not accept change gracefully, especially a lot of change at one time.
Approaching this initiative with an incremental and iterative approach, slowly implementing
the methods and tools, will provide a much higher chance of success. The ROI will come at a
slower pace, but it will increase as the number of reusable assets are identified, developed,
and consumable.
Before we take on outlining an iterative approach, consider that to meet our objectives and
stay within scope, the following points must be kept in mind while developing the approach:
Software development methodology
End-to-end method for guiding software and systems development
Asset-Based Development methodology
Guidance in producing, consuming, and managing reusable assets
Asset governance to:
Create initial governance plans and document decisions, roles, and responsibilities
Determine how we will implement the plans and decision rights
Implement the plan through process education, mentoring, and automation
Measure reuse activity, assess cost, and ROI
Streamlined tools:
Store, search, and retrieve reusable assets
Enforce review processes and asset life cycle
Reports to measure statistics, such as usage, searches, and reviews
Reports for auditing assets
Make it easy to produce and consume reusable assets
Skill growth through education: both methodology and tools
Chapter 2. ZYX Electronics case study
29
Each item in the list aligns with the key challenges that Cid revealed during the original CIO
interview, which we described earlier in the chapter. And, each item impacts the staff. As Cid
is planning the approach, Cid must be sensitive to the changes that the department will be
experiencing. Process and tool adoption taken slowly and methodically from project to project
can have a significant positive impact on software results and quality. Conversely, both
process and tool adoption can be productivity inhibitors if no education and mentoring are
provided to advance individual skills.
Cid can now have the management team begin to lay out a Reuse Strategy implementation
plan. He reminds the team that the company has budget constraints within which to work and
that he is a little sceptical whether reuse will work well for ZYX given the currently ingrained
culture.
Chuck, ZYX CTO, and Victoria, VP of Development, direct a team from the project
management office to create an iterative and incremental (phased) asset reuse approach.
They will need to report back to Cid on the perceived benefits and ROI that ZYX will receive
from this effort.
The approach that they develop will be iterative in that it will build the teams skills and
capabilities slowly at a satisfactory maturation rate within increments (phases) over several
phases until the entire defined solution is deployed. The outline of the plan is:
Establish a methodology team to establish a ZYX software development (SD) approach
using the Rational Unified Process (RUP). This virtual team will be made up of existing
personnel, who are the most skilled in process. These employees will establish process
requirements for ZYX, customize a software development process to meet their
requirements, provide process education, and mentor project teams along the way to
reduce the risk of failure.
Establish an Asset-Based Development and governance (ABD/G) team to establish the
ZYX approach. This virtual team will be made up of existing personnel, who are skilled
software architects from around IT. The team will establish ABD and governance
requirements for ZYX using the Rational ABD and Asset Governance method, provide
education, and mentor project teams to reduce the risk of failure.
Implement streamlined tooling to support our methodology, governance, SOA, and asset
reuse efforts.
Continue building out our development capabilities to support the adoption of SOA with a
business fabric that can support our Component Business Model and the dynamic nature
of our business, while reusing our existing software assets to help reduce the cost of new
applications.
Pilot a project to focus on process usage and refinement, tool selection, automated
metrics gathering, and building the skills of our development team at producing,
consuming, and managing reusable assets.
Using this level of plan, the management team is able to build out a detailed phased plan over
several years. Before presenting the details, though, the team wants to ensure that Cid is
aware of the benefits that he will receive by implementing the teams plan.
2.4.3 Benefits
Cid and the management team will be moving forward on their plans. He has met with the
CEO and CTO to discuss the plans, and they agree that a reuse initiative will be a lot for the
business to consume, but it will have significant ROI in the long term.
30
As the development team becomes skilled in asset production and consumption, ZYX will:
Reduce the costs of new application development and existing application maintenance
significantly through reuse instead of rewrite
Develop repositories of searchable software assets reducing the time to locate and reuse
the asset, in turn helping to reduce the cost of implementing that piece of application
functionality
Increase the standardization of application look and feel, providing a more consistent
experience to our users
Increase application dependability and quality, because the software components,
services, models, and frameworks will have been proven and tested already in working
systems
Focus on leveraging individual expertise by bringing the employees together to build or
harvest the reusable assets in their realm of knowledge
Bring our applications to market earlier, therefore, capitalizing on early entry in the market
to bring more sales and revenue to the company
Reduce the time necessary to reuse a software asset as we refine how to reuse the asset
from project to project, therefore, estimating projects with greater accuracy
Our continued efforts to develop our SOA capabilities will play a larger and larger part in our
Reuse Strategy and deliver even more benefits than we have described. Our increased
capabilities will allow us to:
Change business systems, which dynamically decreases the time to application
availability
Decrease the time-to-market by deploying applications quicker
Choreograph multiple deployed business services and Composite Business Services
together to produce the right business solutions more efficiently
Preserve existing IT assets by encapsulating them into dynamic business services
Enforce consistency of business and IT behavior across the company
Control IT costs and help make IT more efficient
As Cid can see, enabling ZYX Electronics software reuse capabilities can yield multiple
benefits to the company. The remainder of this book will focus on many of the ways that you
can make use of processes and tools to enable your software reuse capabilities.
2.5 Assumptions
In the following chapters of Part 1, we will discuss tool selection, the Asset-Based
Development method, Asset Governance, and metrics and ROI.
In an effort to limit the scope of this book, we have made the following assumptions about our
work at ZYX Electronics:
ZYX Electronics is not undergoing a complete organizational business transformation. We
undertake what RUP calls business improvement - the techniques that a company uses
to design its business according to specific goals involving trimming costs and lead times
and monitoring service and quality.
We do not assess the organizational structure; although, we have discussed it in detail,
and we do not make changes to that structure.
31
We do not assess the business structure; although we have discussed it in detail, and we
do not make changes to that structure.
We limit ourselves to analyzing a subset of the ZYX Electronics business problems but
only in respect to the topic of the book, Asset-Based Development.
Lastly, we do not offer or provide a full process and tools implementation. The purpose is
to provide guidance in helping you understand and begin to plan your implementation.
32
Chapter 3.
33
Process
management
FOCUS
Tooling selection to support software innovation and IT and Business alignment is a critical
success factor. As shown in Figure 3-2, we can look at the tooling and process needs of the
organization from both a scope and focus perspective. If the selected tooling does not provide
alignment, control, and efficiency, we end up with barriers to innovation and an inability to
align with the business.
Manual, error-prone
processes with poor
coordination and
automation
Brittle, inflexible
architectures with
unreliable integrations
Project
management
Software
delivery
Resource
availability
Lack of alignment
between business
needs and
software results
Lack of traceability
between requirements Lack of visibility
and deployed solutions and accountability
Chronic project
management problems
Poor software
quality
Development
productivity/turnover
SCOPE
Individual
Team
34
Organization
Business
3.2 Eclipse
Eclipse is a platform engineered to build integrated Web and application tools for
development. The platform encourages rapid development of integrated features based on a
plug-in model. Eclipse is more than a foundation for development, it is:
A Java development environment:
The Java development environment in Eclipse makes you productive by automating
mundane and time-consuming operations. It integrates with advanced tools to help you
generate, edit, and navigate your Java code.
The platform handles the logistics of finding and running the right code. The platform
user interface (UI) provides a standard user navigation model. Each plug-in can then
focus on doing a small number of tasks well.
A tool integration platform
Eclipse is a foundation or technology platform for tool integration. Think of it as a home for
tools. It brings together designing, programming, testing, and drawing tools. As you work
your way through this chapter, note that a number of the tools leverage Eclipse as their
underlying platform. As a result, the user interface is consistent across the tools; the tools
support multiple platforms; and, it is possible to integrate other components into the
products.
An open source community
Eclipse.org is a group of technical professionals who use and produce not only the basis
for tool integration, but also a set of tools integrated on that base or platform. Eclipse is an
open source project that delivers a tool integration platform and tools in a package called
the Eclipse SDK.
More information regarding Eclipse can be found on the Web site:
http://www.eclipse.org
35
36
37
development. Security features, such as user authentication and audit support, help meet
internal and external compliance requirements.
ClearCase scales from small workgroups to geographically distributed enterprises. It is
accessible through local, remote, and Web interfaces, and leading integrated development
environments (IDEs), including IBM Rational Application Developer, IBM WebSphere Studio,
Microsoft Visual Studio 2005, and the Eclipse framework.
ClearCase integrates seamlessly with IBM Rational ClearQuest for a comprehensive
software change and configuration management solution and contains in-depth integration
with requirements, development, and build, test, and deployment tools to provide a complete
end-to-end solution to meet current and future needs.
39
services that implement Web Services Description Language (WSDL) interfaces with
SOAP/HTTP bindings as well as a broad range of SOA services that can be described using
WSDL, XML Schema Definition (XSD), and policy decorations, but might use a range of
protocols and be implemented according to a variety of programming models.
You can use WebSphere Service Registry and Repository (WSRR) to store information about
services in your systems, or in other organizations systems, that you already use, that you
plan to use, or that you want to be aware of. For example, an application can check with
WSRR just before it invokes a service to locate the most appropriate service that satisfies its
functional and performance needs.
This capability helps make an SOA deployment more dynamic and more adaptable to
changing business conditions.
WebSphere Service Registry and Repository includes:
A service registry that contains information about services, such as the service interfaces,
its operations, and parameters
A metadata Repository that has the robust framework and extensibility to suit the diverse
nature of service usage
WebSphere Service Registry and Repository does not manage all service metadata, and it
does not manage service metadata across the whole SOA life cycle. It focuses on a
minimalist set of metadata that describes capabilities, requirements, and the semantics of
deployed service endpoints. It interacts and federates with other metadata stores that play a
role in managing the overall life cycle of a service.
40
41
Figure 3-3 Comparing Rational Asset Manager to WebSphere Service Registry and Repository
Many assets managed by Rational Asset Manager have nothing to do with deployed
services. And not every deployed service automatically is an asset that an enterprise might
want to reuse and load into Rational Asset Manager.
However, there are a number of artifacts that can be of interest to both user communities:
basically any document (for example, WSDL, XSD, and WS-Policy) stored in WebSphere
Service Registry and Repository software can be of interest as part of a reusable asset;
WebSphere Service Registry and Repository users might be interested in understanding the
design specifications, implementation, or documentation about a specific service.
Having two repositories for development and run time is the right strategy for not penalizing
the performance of the runtime environment. The users of both repositories are different, and
service runtime information must not be penalized by searches or any other activity that is
performed by users accessing the development information of services.
Both tools are integrated so that assets managed by Rational Asset Manager that contain
Web service definitions can be published to the WebSphere Service Registry and Repository,
and WebSphere Service Registry and Repository information can be replicated into the
Rational Asset Manager Repository.
For a detailed discussion about the differences and relationship between both products, refer
to Chapter 12, Introduction to service assets on page 335.
Both Rational Asset Manager and Rational ClearCase have the concept of version, but it
represents different things for each tool:
Rational ClearCase controls and manage versions of individual artifacts or files (file
elements for Rational ClearCase).
Rational Asset Manager controls and manages versions of individual assets. Assets will
be composed of individual artifacts (that can be under the control of Rational ClearCase or
not) and additional metadata information to complete the asset information, such as
name, description, asset type, to which category the assets belong, and so forth. All of this
information will be packaged following the Reusable Asset Specification (RAS) standard.
So, there are generally two major levels for versioning with assets: the asset version and the
artifact version. The artifact version is typically managed and dictated by the source control
management system (Rational ClearCase), whereas the asset version is generally dictated
by the policies of the enterprise and managed by the Repository. Figure 3-4 illustrates the two
major levels for versioning.
Because the asset has information in addition to the individual artifact versions, although the
artifact versions remain the same, a structural change in the metadata information in the
asset can force the creation of a new version in the asset. For example, although the
spring.jar and license.txt files in Figure 3-4 do not change their versions in Rational
ClearCase, if the Spring asset has a new relationship with other assets, this will require a new
version of the asset although the artifact versions remain the same.
In addition to the two types of version concepts that managed by both types of tools
(individual artifacts compared to assets), SCM repositories compared to Rational Asset
Manager are not oriented to:
Facilitate searches to the user.
Extend artifact metadata with additional information. The artifact is just the file with
information that is just oriented to controlling changes.
Establish relationships to facilitate impact analysis.
43
And Rational Asset Manager compared to SCM repositories is not oriented to:
Create detailed reports comparing different versions of assets. Rational Asset Manager
logs the history of the changes made to the asset, but it is not oriented to compare
changes between different versions.
Manage individual files without a real value to the user.
But Rational Asset Manager and Rational ClearCase are integrated, and clients using both
tools can benefit from this integration. This integration recognizes when artifacts that are
submitted to Rational Asset Manager as part of the asset content are checked into Rational
ClearCase, and it maintains a reference. When a user wants to download a version of the
asset, Rational Asset Manager will use this information in providing the user the option of
reconnecting the artifacts to Rational ClearCase.
44
45
easily assess project progress and quality. This allows you to better predict which areas will
require special attention and where to focus scarce resources to stay on schedule. More
importantly, ProjectConsole enables you to make decisions based on quantitative analysis,
rather than subjective status reports.
As discussed in Chapter 6, Value, impact, and return on investment on page 103, it is
important to be able to capture and track metrics to support a reuse program. Going into the
program, you will need a baseline in regard to the time that it takes to deliver software, the
cost of building the solution, and the overall quality of the solution.
47
review process defined in Rational Asset Manager to adapt it to the specific organizations
needs. For more information about how to set up and customize this integration, review
A.4.2, Integrating Rational Asset Manager with Rational ClearQuest.
Assets that contain Web service definitions can be published to the WebSphere Service
Registry and Repository using the integration already provided in Rational Asset Manager.
The integration between both tools also allows you to synchronize information from
WebSphere Service Registry and Repository into Rational Asset Manager, helping
developers to search for already published service assets and their supporting
development assets. In Part 3, Service Assets in an SOA on page 333, you have a
detailed explanation of how this integration works. A.4.1, Integrating Rational Asset
Manager with WebSphere Service Registry and Repository gives more detailed
information about how to configure the integration.
Rational Asset Manager server can use Rational ClearCase to store assets as an
alternative to using the file system. Rational Asset Manager also recognizes when
artifacts that are going to be submitted to its control are under control of a version control
system, such as Rational ClearCase or Concurrent Versions Systems (CVS), and records
this information, which will be used later when the user wants to download or import the
asset. A.4.3, Integrating Rational Asset Manager with Rational ClearCase describes the
details of the integration with Rational Clearcase.
The Asset Management Eclipse perspective of Rational Asset Manager allows users of
Eclipse-based tools, such as Rational Software Architect, to use a flexible user interface to
quickly find and package assets without having to leave the development environment.
A specific integration exists between Rational Asset Manager and Rational Software
Architect through the Rational Asset Manager Configurator Plug-in. This plug-in allows
the user to export as XMI models the Rational Asset Manager configuration data, such as
communities, asset types, categories, attributes, and relationships, using Rational
Software Architect and import them into Rational Asset Manager.
Asset Production: If we look at Asset-Based Development from the perspective of an
Asset Producer, we notice that there is a collection of tools related to modeling,
development, and testing. Each of these tools, and many more, can be used to produce
assets that we want to use within the organization. In later chapters, we look at several of
these tools in-depth, as well as best practices associated with the tools in building certain
types of assets.
Asset Consumption: When looking at Figure 3-5 on page 47 from an Asset Consumer
point of view, again we see quite a few tools that can consume a reusable asset. For
instance, there can be a set of models that need to be reused, a set of test plans, or a
code component. Those people using consumer assets can interact with the Repository,
searching for assets, downloading assets, and providing feedback on the assets.
48
Chapter 4.
4.1 Introduction
Every company, project, or team has a method. It can get invented every morning when the
team walks through the door, but the team has a method, a way of working together. The
question is, Is this the appropriate method for the team? This chapter introduces the IBM
Rational Unified Process and the tooling that supports the use and consumption of the
process.
49
Figure 4-2 on page 51 shows a few key definitions that we have to understand before we can
effectively understand RUP.
50
The more recent versions of RUP and the Eclipse Process Framework project use an updated version of the
original SPEM specification. This new version is currently being proposed by IBM and others as SPEM V2.
51
Method Composer also provides mechanisms for rapid process assembly using process
patterns and reusable method elements. It supports the creation of method plug-ins that
provide powerful ways of extending and modifying existing content, simplifying method
content, process management, and maintenance.
A marketplace for process extensions
The Method Composer/RUP section of the developerWorks Rational Web site provides
a place for process engineers in the software development community to share their
method extensions as consumable plug-ins and provides a rich source of method
extensions for the project manager. You can access the Method Composer/RUP section
of the developerWorks Rational Web site at:
http://www.ibm.com/developerworks/rational/products/rup/
You can read more information about Rational Method Composer at:
http://www.ibm.com/software/awdtools/rmc/
53
Adapt the process ceremony to the life cycle phase (allow the formality to evolve from less
to more as uncertainties are resolved)
Improve the process continuously
Balance plans and estimates with the level of uncertainty
Anti-patterns:
Always see more process and more detailed up-front planning as better:
Force early estimates and stick to those estimates.
Develop precise plans, and manage the project by tracking against a static plan.
Anti-patterns:
Thoroughly document precise requirements at the outset of the project and force
stakeholder acceptance of requirements:
Negotiate any changes to the requirements where each change can increase the cost
or duration of the project.
Lock down requirements up front, thereby reducing the ability to leverage existing
assets.
Primarily perform custom development.
Architect a system only to meet the needs of the most vocal stakeholders.
54
Patterns:
Motivate people to perform at their best.
Create self-managed teams.
Encourage cross-functional collaboration (for example, analysts, developers, and testers).
Provide effective collaborative environments.
Manage evolving artifacts and tasks to enhance collaboration, progress, and quality
insight with integrated environments.
Integrate business, software, and operation teams.
Anti-patterns:
Nurturing heroic developers willing to work extremely long hours, including weekends
Having highly specialized people equipped with powerful tools for performing their jobs,
limited collaboration among team members, and limited integration between tools. The
assumption is if everyone just does their job, the end result will be good.
Anti-patterns:
Plan the whole life cycle in detail and track variances against plan (can actually contribute
to project failure).
Assess status in the first two-thirds of the project by relying on reviews of specifications,
rather than assessing the status of test results and demonstrations of working software.
Moving a development team and its stakeholders to an iterative process is hard. An iterative process introduces
perceived uncertainties, such as a lack of a stable set of requirements, difficulty in planning and costing work,
regular rework, and challenges scheduling staff requirements. RUP, the supporting material, and training address
all of these issues directly.
55
elevation of the level of abstraction: services being reused, modeling and transformations to
translate business requirements to code as quickly as possible, and the use of SOA as an
architectural style.
The benefits are:
Productivity
Reduced complexity
Patterns:
Anti-patterns:
To go directly from vague, high-level requirements to custom-crafted code:
Because few abstractions are used, a lot of the discussions are made at the code level
compared to a more conceptual level, which misses many opportunities for reuse,
among other things.
Informally captured requirements and other information require decisions and
specifications to be revisited repeatedly.
Limited emphasis on architecture causes major rework late in the project.
56
The RUP summary chart captures many of the concepts of RUP in one diagram. The chart
shows a project with time on the x-axis and the disciplines on the y-axis. Each RUP project is
divided into four phases (Inception, Elaboration, Construction, and Transition). Each phase is
broken down into zero or more iterations. An iteration is a vertical slice through the
disciplines as shown in Figure 4-3. This iteration is the first iteration in the Construction
phase.
The bumps on the chart indicate the level of effort required for each discipline. Notice, for
example, how the business modeling and requirements disciplines are biased toward the
beginning of the project but still continue into the Transition phase. One of our favorite
questions about this chart is based around testing, Why do the bumps on the testing
discipline line get bigger and bigger over time?3
We now look at several of these terms and ideas in more detail.
Iterative development
Iterative development is the concept of breaking a project into a set of iterations:
An iteration encompasses the development activities that lead to a product release a stable, executable version of the product, together with any other peripheral elements
necessary to use this release.
This is because as we build more and more code, we write more and more tests. Each iteration runs the tests of the
new code and the tests from the previous iteration. If we managed to identify the really high-risk areas of the project
correctly, we will have regression tested these areas to the full extent by the end of the project.
57
The project effectively becomes a set of smaller projects. The traditional software
development project life cycle of gathering requirements, designing, implementing, and
testing the solution is discarded. However, an iteration contains these traditional disciplines,
hence, the idea of an iteration as a mini-project. A project consists of a number of iterations.
This approach has many advantages, including:
The focus of each iteration is to produce a form of working, tested code. In earlier iterations,
this code might be a prototype of a certain aspect of the service or composite services. In
later iterations, the working code will be complete builds of the services or composite services
but with reduced functionality. This reduced functionality can be stubbed out code, no or
reduced handling, or simulation of an intended function (for example, a database access and
retrieval might be simulated).
Project managers are concentrating on using the iterations to mitigate or expose risk.
Contrary to natural inclinations, we encourage projects to attempt the highest risk aspects up
front. This in turn allows us to spend most of the time addressing the risks. Each iteration
must start with an assessment of what has changed since the start of the last iteration.
Changes in risks and priorities can steer us to change the plan for this iteration, bringing part
of the work forward and pushing part of the work back.
Phases
Each RUP project is broken into four phases. The phases in order of execution are:
Inception
Elaboration
Construction
Transition
Inception is the phase where we scope out the project. During the iterations in this phase, we
define business use cases (or revise them if several use cases already exist). We define our
business goals, key performance indicators, and metrics. We create initial as is and to-be
business process models.
Elaboration is the phase where we make sure that we can have a working end-to-end
automated business process or processes. Updates are made to all of the work products that
were created in the Inception phase. Part of the code that was previously stubbed out is filled
in. Tests from the previous phase are rerun and expanded to include the new functionality.
Construction is where we complete the coding and testing. Many of the work products, such
as the business process models, requirements, service model, and other work products, are
further refined as appropriate and locked down as completed. At the end of the phase, the
software is ready to be released to alpha and beta testing. Further changes to requirements
based on feedback will be scheduled for future releases, or we might remain in Construction.
Because the stakeholders have already seen running code during the preceding two phases,
and we have been tracking changes in business processes and business goals, it is less
likely that major changes will surprise us at this point.
Transition is the phase that can vary the most. It entirely depends on what kind of software
you are building. For a product release (such as a release of IBM Rational tools), transition is
focused on alpha and beta testing. We are finishing training materials, marketing materials,
58
deciding on the color of the box or CD, and checking that the copyright notices appear on the
accompanying literature4. We are fixing any critical defects found in the alpha and beta
releases. An internal project for the business will be working with operations to get system
and user acceptance testing completed and planning for deployment. When the Transition
phase is complete, further changes to the software require a new project (run iteratively, of
course). Maintenance has a slightly different type of project.
Each phase has strict entry and exit criteria or gates. By the end of each phase, we require
that:
Inception: We have agreed upon the scope of the project.
Elaboration: Architecturally significant aspects of the project are up and running as tested
code.
Construction: The coding is complete.
Transition: The project is live.
It is very important that a project does not proceed to the next phase if these high-level goals
have not been achieved. We can add iterations to the phase to enable us to achieve the goals
of the phase. This has an obvious impact on schedule, but we can catch up later by
accomplishing more in future iterations or we decrease the scope of the functionality that we
plan to deliver. Iterative development makes this easier, because at the end of each
successful iteration, we have a stable build of the code and the associated work products that
must be suitable for release.
Architecture-driven
RUP is an architecture-driven process. Defining and building an executable architecture is
the focus of the Elaboration phase of any RUP project. An executable architecture means
code that demonstrates and proves the effectiveness of our architectural decisions.
Use case-driven
Prior to the introduction of SOA concepts, RUP focused on aligning iterations to system use
cases. This is still true in that we expect to take system use cases through to implementation
during a iteration; there are higher level drivers of the goal of an iteration.
Automating a business process or task becomes the new goal of the iteration. We have to
implement system use cases as part of this goal, but now we focus on implementing a thread
of the business process from beginning to end. We might not handle all cases in the process,
and we might not cover all exceptions or branches in the process flow, but we have to
implement something useful end-to-end.
If we use business use case realizations as an alternative to business process flows, we are
implementing these business use case realizations. Either way, the focus of the iteration is to
deliver useful business functionality.
4.3 References
For more information:
Read the Rational Method Composer developerWorks article series at:
http://www-128.ibm.com/developerworks/rational/library/dec05/haumer/
59
60
Chapter 5.
Important: Throughout the course of this book, we leverage content from the Asset-Based
Development V3.0 and Asset-Based Development Governance V1.0 Rational Method
Composer plug-ins. You can download these plug-ins by using the following links:
For use with Rational Method Composer V7.1:
http://www.ibm.com/developerworks/rational/downloads/06/rmc_plugin7_1/#16
For use with Rational Method Composer V7.2:
http://www.ibm.com/developerworks/rational/downloads/07/rmc_v7.2/#15
61
62
Figure 5-1 Integrating Asset guidance into a process based on the Rational Unified Process
The Asset-Based Development workflows can be inserted into other software development
processes, such as the one shown in Figure 5-2. In this example, the Asset-Based
Development workflows are inserted into each of the process phases. In certain cases, the
business-related assets are only used on the software project and are not produced on the
project, whereas each of the software-related phases produce and consume assets on the
project. This example does not address a situation in which there are more central or
cross-project asset manufacturing teams.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
63
5.3 Governance
Let us take a quick look at a couple of foundational definitions before getting into the details of
Asset Governance:
Governance:
Establishing chains of responsibility, authority, and communication to empower people
(decision rights)
Establishing measurement, policy, and control mechanisms to enable people to carry
out their roles and responsibilities
IT Governance:
Decision making rights associated with IT
Mechanisms and policies used to measure and control the way IT decisions are made
and carried out
Figure 5-4 on page 65 relates this definition of IT Governance to the goals for IT Governance.
64
Risk Reduction
Understand and mitigate risks associated
with initiatives and operations
Building on this understanding of the levels of governance, there are two more definitions of
which you need to be aware:
Governance Solution (n) is a work product of Governance, a set of governance decisions
applicable to a specific context and scope of activities.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
65
Management (v) includes the activities of goal setting, decision making, oversight,
enablement, and guidance that implement a governance solution in pursuit of a set of
defined objectives.
As we discussed in 5.1, Introduction to the asset plug-ins on page 62, we want to build out a
strategic approach to leveraging reuse. This means that the resulting program must follow a
systematic approach and that the results of the effort are tied to and driven by the business.
Asset Governance is a key concept that helps us ensure that our reuse efforts are tied into
the goals of the larger organization.
66
The following sections take a more in-depth look at the focus areas and the roles, tasks, and
deliverables within each focus area.
5.4.1 Planning
Next, we discuss planning for governance.
Overview
In planning, we spend time determining what needs to be governed, the initial resource and
cost requirements, and who will fund this effort. This effort will also include a discussion and
decision about funding models.
The capability pattern for this focus area is shown in Figure 5-7 depicting two activities:
Preparation and Funding.
Preparation
Figure 5-8 on page 68 depicts the tasks found within the Preparation activity. Certain key
planning tasks need to be performed first so that the estimates and funding discussions are
meaningful. Within the tasks associated with this activity, we spend time in assessing the
reuse capability of the organization and determine the Reuse Strategy for moving forward. As
the strategy solidifies, we are able to start to plan staffing, training, asset classification, and
reuse program adoption.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
67
Funding
Figure 5-9 on page 69 depicts the tasks found within the Funding Activity. We are concerned
with determining the costs of the asset program, as well as the preferred funding model.
In regard to the funding model, we need to recognize that funding issues differ in a reuse
situation compared to a traditional development project. In typical funding situations, the
funds are allocated for the activities to deliver the artifacts for the project. This relationship
changes with the reuse model, where the funding for assets and their artifacts can provide
value for several projects. In addition, the project where the asset is built might need to incur
additional costs to build and package the reusable asset. However, other teams that then use
the asset get the benefits of using the asset and, therefore, appear to cost less to deliver.
There are several models for funding the reuse team and related reuse efforts:
Overhead funding: The costs for the reuse team are handled in the pool of overhead
expenses.
Tax funding: Each application development project pays a tax, which covers the cost of
the reuse team.
Payments for assets and services: The application development teams pay for the assets
and services that they use from the reuse team.
The organization needs to determine its funding model for conducting Asset-Based
Development. An initial recommendation is to start with overhead funding and then shift to
payments for assets and services. The purpose of this recommendation is to provide time for
startup costs and then move to another funding model, such as for services or assets, when
the initial value has been verified. For instance, you can use the overhead funding model
throughout the startup phases and then shift to an asset and services funding model
thereafter. Factors that will impact this decision include the decision to have an asset
manufacturing team and a governance board, to support tooling, and so forth.
As part of this work, we will find a sponsor for the program and ensure that the goals of the
program align of the needs of the sponsor and the organization.
68
Preparation
The deliverables and roles associated with this activity are depicted in Figure 5-10 and
Figure 5-11 on page 70.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
69
Funding
The deliverables and roles associated with the Funding activity are depicted in Figure 5-12.
Key deliverables
There are six key deliverables associated with this focus area, including:
Reuse Assessment: A Reuse Assessment describes the opportunities and abilities of an
entity to conduct asset reuse work.
The scope of the Reuse Assessment must be selected first. In general, it is not a good
practice to attempt to apply reuse principles to the entire enterprise at one time. As input
70
to the Reuse Assessment, the business problem and priority need to be understood. This
provides the necessary context and scope for focusing the Reuse Assessment. Even in
cases where there is a significant business driver, we want to start the rollout with a
narrow focus.
The Reuse Assessment evaluates two major elements for the selected scope:
a. Reuse Capability: Reuse capability describes the organizations ability to conduct
reuse activities. Reuse opportunity describes the extent to which recurring problems
and recurring solutions exist within the selected scope.
An organizations reuse capabilities are increased when the following factors are in
place:
Management support
b. Reuse Opportunity: There are generally more reuse opportunities when the following
factors are in place:
Well-understood domains
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
71
b. Standards: WIthin this perspective, we describe the standards to which the reuse
initiative will adhere, as well as the standards that will be ignored.
c. Tools: Within this perspective, we describe the tools that will be leveraged to support
the reuse initiative. This perspective must include a discussion of the asset Repository
and process configuration, as well as the tools that will be used to produce and
consume assets. The expectation is that the organization will use a standard set of
tools based on the decisions and explanations detailed in this section.
d. Assets: This perspective is used to outline the major types of assets that the
organization plans to leverage. Up to this point, we have discussed assets quite
generically, because many artifacts can be packaged together to create assets. For an
organization to succeed in reuse, the organization needs to have a more narrow scope
and identify the types of issues that the organization will pursue.
Resources and Training Plan: Simply put, the Resources and Training Plan is used to
detail the roles, users, and the plans for training them. We have a number of resources at
our disposal to assist in building this plan including, but not limited to: Reuse Assessment,
Reuse Strategy, and the Reuse Adoption and Incentive Plan.
Asset Financial Estimate: There are three steps associated with generating this
deliverable, including:
a. Conduct Estimates: Determine the general asset program cost estimates. In order to
estimate this cost, the Reuse Strategy needs to be understood, as well as the
Resource Adoption and Incentive Plan and the Resources and Training Plan. These
artifacts provide the scope and timing for resources to work on asset manufacturing,
management, and use.
b. Determine Initial Funding Approach: With the initial cost estimates, the funding
approach needs to be determined. Often the overhead funding approach is used to
launch the initial asset activities. This overhead funding can be done at the enterprise
level, within the scope of a business unit, or on a project.
c. Determine Long-term Funding Approach: More mature asset programs can use a tax
approach on each project to fund the asset efforts in the long run. This funding
approach generally occurs when the asset efforts have proven viable to the enterprise.
72
5.4.2 Definition
Next, we cover the Definition focus area.
Overview
There are multiple workflows that comprise the assets life cycle, for example, the activities of
submitting an asset to the Repository, the review and approval process, or the retirement and
archiving activities. The workflows need to be identified, and the key participants understood.
Often you must consider the type of asset or its categorization (for a specific business
domain), as well as which organizational unit owns the asset. All of these considerations are
factors in determining the workflows for assets.
Controlling the access to assets is a key element of governance. Determining who can do
what with an asset involves understanding the assets intended use and scope. Access
control can be determined for assets of a given type, of a given classification, or of a given
owner. These factors must be considered, and the access control must be captured in the
Repository. Figure 5-14 depicts the capability pattern for the Definition focus area.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
73
Figure 5-15 The tasks within the Types and Rules Definition Activity
74
Figure 5-18 Asset Governance Board role, associated tasks, and deliverables
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
75
Key deliverables
The five key deliverables associated with the Definition phase include:
Asset Rules and Policies: This deliverable is the rules and policies to which assets need to
comply to participate in the Repository.
This artifact is controlled by the Asset Governance Board and establishes the policies for
Administrators, asset manufacturing teams, and asset consumption teams.
The kinds of rules created include:
Naming conventions for Asset Types, Assets, Artifacts, and Relationship Types
Required support resources, length of support, and contact information for assets
Asset classification requirements, including policies for tagging assets with
user-provided values and policies for classifying assets using category schema values
When creating these policy documents, be sure to include a version number on the
document.
Asset Type Specification: This deliverable describes the structure of asset types. Declare
one or more asset types to configure the Repository. Look for name collisions, as well as
similar asset types and artifacts with different names.
76
Each asset that is placed in the Repository will map to one of the types that we define.
Based on the asset type that is selected, the user submitting the asset will have to abide
by the constraints put into place by the asset type. The type definition will include
information, such as:
Name: The type must have a unique and meaningful name.
Purpose: Specify the purpose for the asset.
Content: Define the artifacts that will comprise the asset.
Relationships: Specify other asset types that are related to this asset type.
Categories, schemas, and contexts, which are relevant, are included.
Custom attributes or metadata elements on the asset type are included.
Asset Version Policy: A description of how assets must be versioned. Recall from earlier
that an asset will contain one or more artifacts. Therefore, there are generally two major
levels for versioning with assets: the asset version and the artifact version. The artifact
version is typically managed and dictated by the Source Configuration Management
(SCM) system, whereas the asset version is generally dictated by the policies of the
enterprise and managed by the Repository. As we define this policy, we will have to
ensure that we accommodate any distributed development requirements for both the
assets and the underlying artifacts.
Asset Workflow Specification: A description of the steps in an asset submission, review, or
procurement workflow. This artifact can be represented in various forms, such as a model,
text, or other format. The workflow must identify the steps, the participants, and the asset
states. Figure 5-22 shows how the different workflows relate to asset production,
consumption, and management.
Community Map: A Community is an arbitrary collection of users, roles, and their assets.
A Community can be defined along several boundaries, including:
Organizational unit
Project
Users with a common role, such as Business Analyst
Therefore, the Community Map describes the organization of the Repository in terms of its
Communities, user roles, and their permissions. The enterprise needs to determine
whether there will be one asset Repository or many asset repositories. In addition, for
each asset Repository, the organization of the assets, the teams, and the review
processes needs to be determined.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
77
The Community becomes the primary element for organizing the Repository. An asset
lives in one Community. Roles and permissions are specified for a Community. Review
processes and other workflows are specified for a Community.
5.4.3 Enablement
Next, we discuss the Enablement focus area.
Overview
In the Enablement focus area, we define the teams needed to support the production,
consumption, and management of assets and identify the tools that they will use.
The tools for conducting Asset-Based Development must be selected and set up. Key to this
is understanding which roles will work with which tools throughout the Asset-Based
Development process.
Recall from earlier that the work in the focus areas often overlaps and occurs iteratively and
incrementally. Therefore, we start to see that there are dependencies between a number of
the activities, tasks, and deliverables. For example, work done in the Plan focus area will
have impact on the work done within the Enablement focus area, and the reverse is also true.
Figure 5-23 depicts the capability pattern for Enablement, which includes the following
activities:
Organization: This activity includes tasks, such as Create Asset Governance Board,
Create Asset Manufacturing Team, and Enable Asset Usage Teams.
Environment: This activity includes tasks, such as Determine Tools to Support
Asset-Based Development, Determine Topology, and Evaluate Cost of Ownership.
Organization Activity
The Organization Activity contains the tasks shown in Figure 5-24 on page 79. This set of
tasks is focused on defining the teams that will support the production, consumption, and
management of assets. When the teams are defined, we will then work to enable them on the
tools that have been identified as needed for supporting their work.
78
Environment Activity
The Environment Activity contains the tasks shown in Figure 5-25. As mentioned previously,
in this activity, we focus on the tooling needed for supporting the reuse team.
The tooling for asset production and consumption activities needs to be similar to and easily
accessible to the way in which people perform their work today. Setting up an environment,
which naturally extends the way that people work today, will reduce the adoption and learning
curves required for Asset-Based Development.
We will also need tooling to support the management of assets, which is most likely a
Repository.
Organization Activity
Figure 5-26 on page 80 depicts the Manager role along with the tasks and deliverables found
within the Organization Activity.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
79
Figure 5-26 Manager role and deliverables within the Organization Activity
Environment Activity
Figure 5-27 and Figure 5-28 on page 81 depicts the Administrator and Manager roles along
with the tasks and deliverables found within the Environment Activity.
Figure 5-27 Administrator role and deliverables in support of the Environment Activity
80
Figure 5-28 Manager role and deliverables in support of the Environment Activity
Key deliverables
The key deliverable associated with this phase is:
Asset Workflow Specification: As introduced earlier in the Planning focus area, this
deliverable provides a description of the steps in an asset submission, review, or
procurement workflow. In this focus area, we have defined the teams for asset production,
consumption, and management. In addition, we determined the tools that these groups
will use in order to fulfill their duties. This deliverable shows up as both an input and an
output within this focus area.
5.4.4 Measurement
Overview
Identifying the measurements important to your organization is key to the long-term and
sustainable use of assets. Measurement is often tracked at several levels, including:
Asset Owner and Producer measurements: Level of investment (hours, money, and time)
in an asset
Asset Consumer: Level of benefit and value delivered to the asset user
Repository: Level of activity on the Repository
Management: Value to the organization and return on investment (ROI)
Figure 5-29 on page 82 depicts the capability pattern for Measurement.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
81
Tip: Notice that in this case the capability pattern contains tasks rather than activities.
Tasks
Next, we discuss the tasks.
Report on asset
Reports can be generated graphically or textually. The metrics can be exported from the
Repository into reporting tools, or the Repository can render the reports.
Managers often requires reports on a periodic basis, which generally means Repositories
need a way to run reporting jobs and send them to the appropriate stakeholders.
Repositories must be integrated with portfolio and project management tools to aid the
generation of derived metrics.
82
Report on asset
Figure 5-31 depicts the Asset Consumer role along with the deliverables found within the
Report on Asset task.
Key deliverables
There are two deliverables associated with this phase:
Metrics Collection Plan: Describes what metrics will be captured, by whom, and how often.
When making these decisions, we need to remember the scope for the metrics: deciding
between project, community, or enterprise-wide metrics. Also, we need to recognize that
certain metrics are more easily captured than others.
Asset Report: A report of the asset activities in the Repository. Provide summaries of
asset and other Repository activities. The report must provide both qualitative and
quantitative information about the assets and related activities.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
83
The other cycle is the Usage or Consumer cycle. As shown in Figure 5-33 on page 85, in this
cycle, the consumer finds, reuses, and provides feedback about the asset. This cycle repeats
each time that assets are reused.
84
These cycles are connected and interact with each other. As shown in Figure 5-34, the usage
cycle receives assets from the manufacturing cycle and provides feedback (or requests) to
the manufacturing cycle. The manufacturing cycle receives feedback from the usage cycle
and updates and gives assets to the usage cycle.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
85
Figure 5-35 Asset Governance workproducts shaping the Asset-Based Development process
Earlier, we discussed the fact that there are three major aspects to the asset life cycle,
namely produce, consume, and manage. These aspects play a prominent role in the
associated process guidance provided within the Asset-Based Development Rational Method
Composer plug-in.
Figure 5-36 on page 87 presents the capability pattern for Asset life cycle associated with
Asset-Based Development. The diagram provides a high-level view, showing the activities
found within the life cycle. Within each activity, you will find a number of tasks and steps that
will guide you in Asset-Based Development.
86
Tip: In the remaining parts of the book, we leverage the asset life cycle as a framework for
the content. In Part 2, Reusable Assets on page 123, Part 3, Service Assets in an SOA
on page 333, and Part 4, Patterns on page 455, we use the life cycle as a basis for
chapters that discuss the creation, management, and use of assets. The discussion starts
with describing these topics in regard to assets in general and then delves into specific
types of assets, including patterns and services.
Overview
Let us take a more detailed look at the Produce Reusable Asset Activity.
This activity is described as:
The production of a Reusable Asset really involves two steps: producing the Asset Artifacts
that comprise the asset and then packaging those artifacts into a reusable asset. Producing
asset artifacts can involve creating those artifacts from scratch, or it can involve harvesting
those artifacts from existing project artifacts.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
87
88
Figure 5-39 depicts the Asset Consumer role along with the tasks and deliverables that the
Asset Consumer role participates in building.
Figure 5-40 depicts the Asset Owner role along with the tasks and deliverables that the Asset
Owner role participates in building.
Figure 5-41 on page 90 depicts the Asset Reviewer role along with the tasks and deliverables
that the Asset Reviewer role participates in building.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
89
Figure 5-42 depicts the Community Administrator role along with the tasks and deliverables
that the Community Administrator role participates in building.
Key artifacts
Next, we discuss key artifacts.
Asset specification
The asset specification describes the asset being proposed. The specification must provide
technical justification for the asset. Not all assets require an asset specification. In general,
assets that require or are expected to require a meaningful investment for the organization or
assets that are of sufficient complexity or reuse scope as to require multiple teams will benefit
from creating an asset specification. The asset specification can go through several iterations
as greater understanding of the problem and the solution are gathered from stakeholders.
The need for this asset has generally been established, and sometimes sponsorship and
support for the asset has been secured. This specification can be used by the support teams
to understand the asset. The specification is also used by the Asset Owner or Producer to
create and update the asset.
This specification is largely intended for technical teams to use, although it can be shared
with sponsors and technical management as part of making decisions to fund and staff the
effort to build, maintain, and support the asset.
90
Reusable asset
Recall that we earlier defined an asset as:
An asset is a collection of related artifacts that provides a solution to a problem. The asset is
customizable through its variability points, meaning those locations within the asset (or more
specifically, within the assets artifacts) that can be customized.
You can consider an asset to be a candidate for reuse when it fits a cross section of:
Providing a solution to your problem
Fitting your technical context
Meeting your business objectives
Fitting within your delivery process
Integrating within your organizational structure
Overview
The purpose of asset management is to provide control and organization to the review and
approval workflow and to deliver assets to consumers in a managed, scalable manner. Asset
management is subject to and operates under the policies and guidance from Asset
Governance.
Note that Manage Reusable Assets is a capability pattern. Figure 5-43 on page 92 provides
an overview of the activities found within the Manage Reusable Assets capability pattern.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
91
92
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
93
94
Key deliverables
Next, we discuss key deliverables.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
95
Overview
Let us take a more detailed look at the Consume Reusable Asset Activity.
This capability pattern is focused primarily on:
Locating reusable assets
Evaluating the located assets
Applying the located assets to the project
Provide Asset Feedback on the applied assets, including identifying the need for assets
that cannot be located
The work is best done when the Asset Consumer has a well-defined problem that needs to be
resolved. The Asset Consumers understanding of the problem directly affects the activities of
searching and evaluating an asset for its relevance. A key aspect to an asset is that it is
targeted to a specific context. To successfully reuse assets, we need to understand our
current context before we evaluate and reuse.
Note that the consuming assets play a key role in the production of assets. This suffices in a
number of situations, such as:
Asset feedback: After using an asset, the feedback provided on the asset helps the Asset
Producers understand how their asset is used, areas for improvement, and aspects of the
asset that worked well.
Identification of needed assets: An Asset Consumer is one of the best sources for
identifying where an asset is needed. An Asset Consumer often has the domain specific
knowledge and can guide an Asset Producer both to where an asset is needed as well as
what the asset must do or contain.
Asset specialization: There are times when an asset is a close fit for a problem, but it is
not quite an exact fit. The Asset Consumer can take the asset and determine that it is in
the best interests of the team to customize the asset. The customized version of the asset
might represent a variation that other Asset Consumers want to reuse as well. Working
with the asset production team, the variation might end up as a new asset in the
Repository.
Figure 5-51 on page 97 depicts the tasks that are found within the Consume Reusable Asset
Activity.
96
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
97
Key deliverables
There are three key artifacts associated with the Consume Reusable Asset Activity:
Reusable Asset: An Asset Consumer interacts with the asset Repository, searching to find
assets that are relevant to the current problem and context.
Reuse Feedback: As the Asset Consumer uses an asset, it is critical that the Asset
Consumer provides feedback on the asset, which is beneficial both to future Asset
Consumers, as well as those that produced the asset.
Asset Specification: In cases where an asset does not yet exist, the Asset Consumer can
create an Asset Specification that details the requested asset. The specification must
provide technical justification for the asset. Not all assets will require an asset
specification. In general, assets, which will require or are expected to require a meaningful
investment for the organization or are of sufficient complexity or reuse scope as to require
multiple teams, will benefit from creating an asset specification. The asset specification
can go through several iterations as greater understanding of the problem and the solution
are gathered from stakeholders.
98
When publishing a custom process configuration, you can choose which of these views to
leverage. In addition, you can add your own client views as determined by the needs and
preferences of your organization.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
99
Figure 5-53 Mapping SOA life cycle and SOA Governance to Asset life cycle and Asset Governance
100
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
101
102
Chapter 6.
103
To justify these costs, both initially and ongoing, the organization needs to be able to see that
there is a positive impact from the assets and that a positive ROI is achieved in a specified
time frame. Therefore, we need to find ways to measure and calculate the value of the asset,
which are accurate and can be defended when placed under scrutiny.
And regardless of how strongly we believe in Asset-Based Development, we still need to be
able to provide metrics that support the decision to adopt Asset-Based Development. As
discussed in our opening chapter, those of us working in software delivery are now more than
ever integrated with the business. Therefore, the decision to adopt Asset-Based
Development is a business decision and requires information that allows the business to
choose how to make investments.
Remember this advice as you work your way through the remainder of this chapter. For your
organization and situation, which metrics will provide the most value? How will this
information be used to assist in rolling out and then managing your asset reuse program?
How can this information be used to improve an existing reuse program? How can this
information be used to help align a reuse program with the needs of the business?
Possible values
Guidance
Points of variability
{Yes | No}
Packaging
{Yes | No}
Documenting
{Yes | No}
{Yes | No}
{Yes | No}
Asset testing
{Yes | No}
105
Category
Possible values
Guidance
Asset dependencies
{Yes | No}
Asset specification
{Yes | No}
Reference solution
{Yes | No}
Cost to produce
{Yes | No}
{None | Low |
Medium | High}
{None | Low |
Medium | High}
{Low | Medium |
High}
N/A
{Run-time |
Design-time}
{Yes | No}
Asset consumption: In this perspective, we look at the support in place for those users
consuming a certain type of asset. The Asset Consumption scorecard is found in
Table 6-2 on page 107. Questions to ask include:
Is there associated tooling that supports working with points of variability? Is the
documentation for the asset integrated with the working environment? Does the
environment support the composition of assets into a larger solution? Is there support
for customizing the output from the asset (in the case of a generative asset)?
Is there expertise available to support the use of the asset?
How much skill is needed to learn how to use the asset? How much skill is needed to
use the asset?
Is there supporting documentation available? What is its quality?
106
Possible values
Guidance
Reuse style
Asset usage
{Compositional | Generative}
Points of variability
Tooling support:
N/A
Import
{Yes | No}
{Yes | No}
107
Category
108
Possible values
Guidance
Integrated documentation
{Yes | No}
Leveraging compositional
features of asset
{Yes | No}
Leveraging generative
features of asset
{Yes | No}
{Yes | No}
Cost to consume
Complexity
Ease of use
Ease of learning
Location of support
{Internal | External}
Category
Possible values
Guidance
Is there documentation
supporting the asset? What is
the level of quality of the asset
documentation?
{Run-time | Design-time}
Is this a design-time or a
run-time asset?
Asset management: In this perspective, we look at how well the asset can be managed.
Part of this information might not be available until after the assets have already been put
into use. The Asset Management scorecard is found in Table 6-3. Questions to ask
include:
Does the asset align with the categorization and classification system in place?
What feedback has been received about the asset?
What is the change history for the asset? Is there a great deal of churn?
How many times has the asset shown up in searches? How many times is the asset
reused?
Table 6-3 Asset Management scorecard
Category
Possible values
Guidance
{Yes | No}
Change history
{Yes | No}
Asset defects
109
Alignment with business: In this perspective, we look at how well the asset aligns with and
supports the business. Part of this information might not be available until after the assets
have already been put into use. The Alignment with Business scorecard is found in
Table 6-4. Questions to ask include:
Is this asset targeted to a business or technology domain?
How often does the issue occur that the asset addresses?
From where will funding for the asset come?
Table 6-4 Alignment with Business scorecard
Category
Possible values
Guidance
Domain
{Business | Technology}
Domain specific
Frequency of underlying
recurring problem
Fund creation
{Yes | No}
{Yes | No}
The scorecard contains a collection of subjective and objective data points to consider as you
analyze an asset. Generally, we expect to limit building assets with the following
characteristics:
White Box: Providing the consumer of the asset with too much freedom is likely to greatly
diminish the impact of the asset.
Lack of an asset creation process: An asset creation process will often guide you to
successfully identify the necessary points of variability on an asset. Lack of a process
often leads to assets that overestimate the amount of required variability.
Lack of tooling support for reuse: Whether producing or consuming an asset, you want
tooling that supports the asset, points of variability, and asset import and export.
Limited automation in support of the asset: Although assets, such as best practice
documents, have value, they require each user of the asset to follow through with a
significant amount of manual work in leveraging the asset. Therefore, you will want to
move to leverage automation as much as possible.
110
111
A Repository has additional metrics that can be added to the mix. As Figure 6-2 on page 113
shows, these metrics can be categorized by role.
112
The general framework for categorizing these metrics is illustrated in Table 6-3 on page 109.
113
114
Adapted from Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by
permission of Pearson Education, Inc., Saddle River, NJ.
Pre-asset creation
In cases where an asset has not yet been built, we can consult the following sources:
Architecture and design documents: Do these documents specify elements in the solution
that have a great deal of commonality? Are there estimates in place as to how long each
instance will take to build?
Models: Are there subsystems, mechanisms, services, and so forth that have
commonality? Are there estimates in place regarding how long it will take to build these
elements?
Existing systems: Are there reference solutions in place that serve as a blueprint for how
future development will be done? How long did it take to build the existing systems? How
long will it take to recreate the reference solution in new systems?
Historical metrics: Based on past projects, are there areas that take significant effort? Are
there areas that have high defect rates?
Risk profiles: Are there aspects of the system that are more risky than other aspects?
Frameworks: Does the project team plan to use one or more frameworks in their
development? Are there recurring patterns of using the framework?
Business processes: Are there groups of services that often work together as part of a
business process? Are there groups of services that work together across a number of
business processes?
How many artifacts are needed within the asset? How many of these artifacts already
exist?
Repeating questions: Do the experts within your organization find that they continue to
see the same questions asked? What topics are covered by the question? How often do
they have to answer these questions?
Best practices documents. We often find that best practice documents exist, but are not
used. Are there important best practices that need to be codified? What areas do the best
practices cover? What is the anticipated impact?
Leverage past asset production data:
How long did it take to build an asset?
115
Post-asset creation
In cases where the asset has already been built, we can consult the following sources:
User community surveys: Contact the people that have downloaded the asset and query
them on their use of the asset.
Defect rates: Are defects being filed against the asset?
Help requests: Are requests coming in for help on using the asset?
In the case of code generation assets, are defects that are generated from the asset
showing up across a number of targets?
Monitor discussion forums: Are there forums, mailing lists, or news groups related to asset
use? And if so, is the asset under scrutiny discussed?
Project plans: Are project plans referencing the use of assets?
Architecture and design documents: Do these documents specify the assets to be used?
Do they specify what is to be generated via these assets?
Asset specification: The asset specification must detail when and where the asset must be
used. This information will help to guide you in your effort to gather metrics.
Tooling associated with the asset: Evaluate the environment that is used with the asset.
What metrics does it provide? For instance, if the asset is a service, does the service
provider provide details about how much use the service receives?
Actual time required to build the asset
Actual time spent in updating and maintaining an asset
Actual time spent in learning how to use an asset
Actual time spent in applying and using an asset
116
117
6.5 Calculations
Now that we have ideas about where we can capture input data, let us start to look at how we
can leverage that data in calculations.
As seen in Figure 6-5, our first calculation is simple and obvious. The cost of producing and
using an asset must be less than the cost of just business as usual.
productivity cost
using an asset
approach
cost to implement
asset
productivity cost
of business as
usual
Let us take a more detailed look at the elements that comprise this formula, starting with the
user productivity cost. In this case, we are interested in the consumer of the asset, and we
need to figure out what the cost is for that person to use the asset. Questions that we want to
consider:
The amount of time that is spent in learning about the asset:
What problems does the asset address?
What is the solution that is provided? How can it be customized?
What other assets can be used in conjunction with this asset?
What constraints are placed on your project after you have used the asset?
When you have learned how to use the asset:
How long does it take to actually apply and use the asset?
How many times will the asset be used?
How many people need to use the asset?
118
Figure 6-6 provides a view of how we calculate the user productivity cost, where:
L: Learn Asset, the average amount of time that it takes to learn to work with the asset
A: Apply Asset, the average amount of time that it takes to someone to use and apply the
asset
x: Number of asset users
y: Number of times that the asset will be applied
Now, let us take a more detailed look at the factors that go into calculating the cost of building
the asset:
Reference solution: Depending on the type of asset that we build, we might want to take a
bottom-up approach when building our reusable assets. Therefore, we must have a
reference solution in place that we can use as the starting point for building the reusable
asset.
Asset specification: Even when we have a reference solution, we will still need to spend
time documenting how this reference solution really is reusable. Therefore, we need to
spend time creating a specification for the asset that details the problem that it addresses,
the solution that it provides, variability points, related assets, and so forth.
Asset implementation: At this point, most of the hard work is done, we just need to build
the asset itself. The hard work surfaces in creating the reference solution and figuring out
how it must present itself as a reusable asset. Creating the asset becomes a mechanical
task.
Figure 6-7 provides a view of how we can calculate the cost of building the asset, where:
DA: Describe the asset, whereby we create a reference solution and then document that
solution as an asset specification
AI: Asset implementation: Whereby we create an asset based on the specification
Although not a part of the high-level equation with which we started, we also need to think
about project risk. Figure 6-8 provides a view of how we can calculate project risk:
z: Probability of an incorrectly created solution; the contention is that by using an asset the
probability will be much lower
CD: Cost to discover a defect
CR: Cost of rework
119
The project risk factor can then be used to adjust estimates based on whether assets are
used in the project.
2
3
120
Adapted from Poulin, Jeffrey C., MEASURING SOFTWARE REUSE, 1997. Electronically reproduced by
permission of Pearson Education, Inc., Saddle River, NJ.
Adapted from Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by
permission of Pearson Education, Inc., Saddle River, NJ.
121
122
Part 2
Part
Reusable Assets
In this part, we take a more in-depth look at how to implement a strategic reuse program. The
discussion will cover process, tooling, and governance. As shown in Figure P-2, we discuss
reusable assets in general. Part 3, Service Assets in an SOA on page 333 and Part 4,
Patterns on page 455 will build upon this content and will look at specific types of reusable
assets, including Services and Patterns.
Part 1:
Introduction
Part 2:
Reusable Assets
Introduction to
Asset-Based
Development
Adopting
Asset-Based
Development
Process and
Tooling
Configuring
Asset
Management
Case Study
Overview
Produce,
Consume, and
Manage Assets
Part 3:
Services
Services as Assets
Produce, Consume,
and Manage Service
Assets
Appendixes
Rational Asset
Manager
Installation and
Administration
Process
Integration
Part 4:
Patterns
Patterns as Assets
Produce, Consume,
and Manage Pattern
Assets
123
124
Chapter 7.
Adopting Asset-Based
Development
This chapter provides a more in-depth look at how we can adopt a strategic reuse process.
When looking at adopting a strategic reuse program, there are changes in culture, process,
tooling, and skills. Introducing these changes into an organization needs to be planned and
will occur iteratively and incrementally.
In situations, such as this one, there are a number of things that we can do to help the
organization in both making a case to adopt a strategic reuse program, as well as set up a
foundation for the programs implementation. Considerations include:
Pilot projects
Reuse maturity models
Organization templates
Reuse adoption strategy
Leverage Rational Method Composer plug-ins covering Asset Governance and
Asset-Based Development
ZYX: In the past, the CIO of ZYX Electronics has seen the concept of reuse promoted as a
cure-all for an organization. However, time and again, the approach did not live up to its
publicity and failed to deliver the promised benefits. Therefore, although the idea of reuse
and the promised benefits has appeal, the CIO is reluctant to move ahead quickly.
125
126
127
Reused assets
The Measure phase includes the following tasks:
Measure:
Prepare measurement report
Communicate report
Plan for rolling out to other projects
Deliverables for this phase include:
Asset measurement report
Planning
To complete these tasks and build these deliverables, we leverage content from the Asset
Governance and Asset-Based Development Rational Method Composer plug-ins. In
particular, there are a number of templates that we can use as a starting point when creating
a Reuse Assessment and a Reuse Strategy.
After you have identified the focus of the pilot and the major tasks (as shown in Figure 7-1 on
page 126), create the estimate for the pilot.
128
http://www.sei.cmu.edu/cmmi/general/index.html
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of
Pearson Education, Inc., Saddle River, NJ.
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
129
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
130
When looking at specific types of reusable assets, such as patterns or services, you are likely
to find specialized maturity models. For an example of a maturity model that is specific to
services, look at Part 3, Service Assets in an SOA on page 333.
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
131
Each of the organization templates has a number of categories that are used to describe its
characteristics, including:
Reuse scope: The intended reuse visibility. As can be expected, more formality and
structure appear as the scope of the reuse increases.
Governance board: The number and kind of governance boards
Asset management: Location of the resources that manage the assets
Asset manufacturing: Location and resources producing the assets
Asset Use: The techniques and formality for asset reuse
Figure 7-5 provides a comparison of the characteristics for each of the organization
templates.
We provide more detail regarding each template in the following sections. We present the
templates based on increasing order of formality.
132
These are significant challenges to overcome, and most likely, this approach will lead to a
failed reuse program.
The proper use of this template is to use it as a starting point on the path to a governed
Repository. If the enterprise uses this template for a period of time to gather lessons learned
and then move on, this template can fulfill that purpose quite well.
133
135
ZYX: ZYX Electronics has decided that they will adopt the Governed organization template
for the pilot. Depending on the success of the pilot and funding levels, they will consider
adopting one of the Enterprise Partial or Enterprise Full organization templates. Also,
based on the results of the pilot and their further analysis, they might customize the select
organization template.
the business drivers exists and that a clear understanding of how reuse aligns with and
supports the business.
Plan: In this phase, we create a plan that details how we are going to leverage reuse
within the organization.
Implement: In this phase, we follow through on our plan and work to become a
reuse-based organization.
Improve: As we follow through on our plan, it will likely become apparent that we will learn
about reuse, our organization, and the need to make adjustments. In this phase, we
recognize the need to improve our approach and then roll those improvements back into
our plan.
The model is meant to be customized as needed for your organization. In addition, you will
want to leverage the artifacts that we have discussed, such as organization template, maturity
models, and pilot projects, as well as the Asset Governance and Asset-Based Development
Rational Method Composer plug-ins.
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of
Pearson Education, Inc., Saddle River, NJ.
137
138
Note: Figure 7-14 shows the cover from the completed ZYX Electronics Reuse
Assessment document. The document leverages the Reuse Strategy template provided by
the Asset-Based Development Rational Method Composer plug-in. The contents of the
document appear in the following sections of this chapter. Appendix C, Additional
material on page 725 provides details about how to download a text document that
contains the content to use as a starting point for your own assessment.
139
Figure 7-14 Cover from the ZYX Electronics Reuse Assessment document
7.7 Purpose
The purpose of this document is to describe the opportunities and capabilities of ZYX
Electronics (ZYX) to conduct strategic asset reuse within its software development teams.
We have not yet adopted any formal reuse program; any reuse that has happened to date
has been ad hoc and driven by individuals. The expectation is that a strategic reuse program
will allow the IT organization to deliver results more quickly, deliverables will be of higher
quality, and we will be better aligned with the overall business.
Planning, diligence, and execution, at the corporate level, are necessary to ensure that reuse
happens successfully for ZYX Electronics. Software reuse will not simply be a by-product of
software development. To be useful, reusable assets must be:
Well designed, implemented, and tested
Documented regarding how to reuse
Cataloged and made easily retrievable
140
As a company, we need to assess our ability to create reusable software assets. Today, IT is
not organized for this reuse to happen. Our software development teams are autonomous
and not aligned with the way that our business operates. No reusable asset library is
available within the company today. And, we have no standard end-to-end software
development processes to exploit best practices to identify or guide the development and
management of reusable software assets. This document will detail these issues, as well as
highlight a few positive areas that will be leveraged as we roll out a strategic reuse program.
7.8 Background
ZYX Electronics is adopting a strategic reuse program within the IT organization. Reuse
capability describes the organizations ability to conduct reuse activities. Reuse opportunity
describes the extent to which recurring problems and recurring solutions exist within the
selected scope.
An organizations reuse capabilities are increased when the following factors are in place:
Management support:
Management specifies policies that support asset reuse.
Management provides top-down support for investing with bottom-up implementation.
Mature software process in the organization:
Project teams follow a repeatable software process.
Management artifacts are produced from the process, and management uses them.
There are generally more reuse opportunities when the following factors are in place:
Well understood domains
The business problem space is understood by the software organization.
Architecture to support reuse
The software architecture permits assets to be harvested and plugged in for reuse.
Mature versioning and configuration management:
The software team practices source code versioning and configuration management.
A release cycle is in place for delivering software in the organization.
To ensure that the entire team is on the same page, we provide the following definitions:
Systematic reuse is defined as, Systematic reuse is the reuse of assets within a structured
plan with well-defined processes and life cycles and commitments for funding, staffing, and
incentives for production and use of the reusable assets.7
Strategic reuse builds on the idea of systematic reuse and sees an organization tie their reuse
program to the strategy of the business. Therefore, the strategic reuse program must
implement a systematic approach to reuse that enables the organization to deal with
expertise shortages, globalization, regulatory concerns, rising customer expectations, and so
forth.
The definition for systematic reuse comes from Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998.
Electronically reproduced by permission of Pearson Education, Inc., Saddle River, NJ., which references M.
Ogush, Terms in transition: a software reuse lexicon, Crosstalk: The Journal of Defense software Engineering,
pages 41-45, December 1992
141
7.9 Scope
In general, it is not a good practice to apply reuse principles to the entire enterprise at one
time. As input to the reuse assessment, the business problem and priority need to be
understood, which provides the necessary context and scope for focusing the reuse
assessment. Therefore, we have decided that we will limit the scope of the reuse assessment
to the team lead by Duncan Munchkin, the Development Manager for the Credit Application
(see Figure 7-15).
142
Figure 7-16 Component business model heat map for ZYX Electronics
7.10 Maturity
In order to truly determine where our reuse capabilities are as a company, we will set the bar
against known criteria. In the software industry, several maturity models have been
documented and found to be very effective in measuring a companys current software
development and asset reuse maturity. In addition, the maturity model can provide a road
map in helping the organization plan how they will move forward and advance their approach
to reuse.
Perhaps the most well known of these is Capability Maturity Model Integration (CMMI). CMMI
is a process improvement approach that provides organizations with the essential elements
of effective processes. However, this is a more generic maturity model and therefore is not
tailored to reuse.
Taking reuse into account, other maturity models are available. In particular, ZYX Electronics
will leverage the Reuse Maturity Framework The Five Stages of Reuse Maturity by Kulton
and Hudson, because it was the best at outlining organizational reuse capabilities in a well
described approach. The Reuse Maturity Framework, as depicted in Figure 7-17 on
page 144, describes the dimensions of a companys reuse maturity. Although we have a
143
minor issue with the framework not directly targeting our business, it provides a great deal of
value as we plan a reuse adoption.
In addition to the Reuse Maturity Framework itself, we will also leverage the characteristics of
each level in the framework that are shown in Figure 7-18 on page 145. Thoroughly
understanding our current level of reuse maturity can only help us to better formulate a
successful Reuse Strategy.
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
144
Management support
Software process
Business domain understanding
Architecture to support reuse
Versioning and configuration management
Within each perspective, we will also align our responses with the Reuse Maturity
Framework. As a result of this alignment, we will provide more depth to the assessment and
position ourselves to move further up the maturity model. As seen in Figure 7-19 on
page 146, there are both Motivations and Travel Events that we will be using as a loose guide
indicating that we need to be looking at moving to a particular level in the framework. These
motivations and travel events usually occur before we can migrate from one level in the
9
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
145
framework to the next higher level. For example, to move from the Initial/Chaotic level to the
Monitored level, we must recognize that competitive pressures require increased reuse. In
addition, the management team must be requesting reports detailing the progress made
toward this reuse goal.
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
146
Strategic reuse
Common, proven development process
Leveraging of industry best practices
Leveraging an iterative and incremental approach
Leveraging abstraction and automation
147
Note that as an organization, we do not map to one specific column. Our interpretation of our
current as is situation is depicted in Figure 7-21 on page 149. In terms of reuse, based on the
definition of elements that can be considered a reusable asset (components, frameworks,
models, test scripts, design documents, and so forth), we have determined that a limited
amount of reuse has been occurring. However, this reuse has not been systematic or
strategic.
As noted in Figure 7-21 on page 149, our team configuration and work approach is based on
a distributed model. A major concern is that with having a distributed IT organization, along
with leveraging GSI partners, our lack of advancement in the other areas will limit the success
of leveraging a distributed model (and will likely lead to failure).
148
Figure 7-21 ZYX as is: Software governance - generations of basic technology advancements
149
Metrics:
Are reuse metrics collected? At the code level? Based on Repository assets?
Is an analysis performed to determine the payoff for developing an asset?
Are the tooling and accounting mechanisms set up to track reuse?
7.13.2 Are there management artifacts produced from the process and does
management use them
With the lack of a formal process in place, it is not surprising that few management artifacts
are produced from the process. A key success that has been achieved in this area is the
implementation of Unified Change Management. Metrics regarding defects, components, and
project progress are available.
Although reuse is occurring, no metrics are yet collected on the reuse, what is being reused,
or the benefits of the reuse. Information regarding reuse is collected via informal discussions
and anecdotes.
150
corporate strategies, overall direction and policy, the way that we monitor our business and
manage exceptions, tactical decision making, and business execution.
This model, referred to as a Component Business Model (CBM) and shown in Figure 7-22,
has led us to begin organizing our early service-oriented architecture (SOA) efforts to the
goals of our business. We still have a long way to go, but IT is headed in the right direction to
align with the ZYX Electronics business structure. Aligning IT with our business goals allows
us to focus on the needs of the business, create software products that mirror the business,
and will help us to identify business areas where we perform the same tasks.
As discussed in the scope section, our initial reuse efforts will focus on the Credit
Administration component. This is a core component for the business and therefore, an area
where we need to focus IT investment.
In regard to the business drivers within this component, we are aware of the following
requirements for the Credit Administration component:
Centralizing siloed departments and building optimized services to support the converged
organization and then negotiating better prices with our vendors and taking advantage of
our combined size help us:
Decrease the negotiated cost (vendor volume discounts) of credit report retrieval by
20%.
151
152
tooling, and a common process, we expect to identify many recurring solutions that can be
converted into assets.
7.16.1 Does the software team practice source code versioning and
configuration management
An area of strength for ZYX Electronics is their source code versioning and configuration
management approach. With the globally distributed development approach of the IT
Organization, a strong software configuration management approach was needed. The IT
Organization has adopted Unified Change Management supported by IBM Rational.
One of the key aspects of the Unified Change Management model is that it unifies the
activities used to plan and track project progress and the work products undergoing change.
The Unified Change Management model is realized by both process and tools. The IBM
Rational products Rational ClearCase and Rational ClearQuest are the foundation
technologies for Unified Change Management. ClearCase manages all of the work products
produced by a software project, including both system work products and project
management work products. ClearQuest manages the projects tasks, defects, and requests
for enhancements (referred to generically as activities) and provides the charting and
reporting tools necessary to track project progress.
Currently, however, there is no specialized focus on reuse. In addition, because little work
has been done to identify the assets that we currently use, we have not taken steps to create
a classification schema or an asset Repository, nor has work been done to determine how
our development tools support assets.
7.17 Conclusions
In this section, we look at our alignment with the maturity model, as well as a summary of the
assessment.
153
surprisingly, we find ourselves primarily in the Initial/Chaotic level of the framework. When the
ZYX Reuse Strategy is developed, the Reuse Maturity Framework will be used to guide many
of our key reuse competency improvement decisions.
7.17.2 Summary
Coming into this assessment, the team had a number of preconceptions regarding ZYXs
reuse abilities and opportunities. The assessment guidelines and maturity framework details
have assisted the team in looking past our preconceptions and have also led to interesting
discoveries regarding reuse abilities and opportunities. In particular, we had the impression
that we were less prepared than we actually are and that we had fewer opportunities for
reuse than actually exist.
Although we did find a number of areas that are problematic and will require attention, we
also found a number of positive aspects that will position us for reuse, including:
Alignment with our SOA initiative: In addition to SOA having reuse of services as a key
concept, the alignment with business, business agility, and business flexibility concepts
will serve ZYX well in a wider, more general reuse program.
11
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
154
7.18 References
For more information, refer to:
Incentive Compatibility and Systematic Software Reuse, Journal of Systems and
Software, Apr 27, 2001; Vol. 57, Iss. 1, Robert G. Fichman
Managing Software Reuse, Prentice Hall, 1998, Wayne Lim
Measuring Software Reuse, Addison Wesley, 1997, Jeffrey S. Poulin
Global Development and Delivery in Practice: Experiences of the IBM Rational India Lab,
SG24-7424-00
Note: Figure 7-24 shows the cover from the completed ZYX Electronics Reuse Strategy
document. The document leverages the Reuse Strategy template provided by the
Asset-Based Development Rational Method Composer plug-in. The contents of the
document appear in the following sections of this chapter. Appendix C, Additional
material on page 725 details how to download a text document that contains the content
to use as a starting point for your own strategy.
155
Figure 7-24 Cover from the ZYX Electronics Reuse Strategy document
7.19 Purpose
Systematic software reuse is the purposeful creation, management, support, and reuse of
assets. In Software Reuse: Architecture, Process, and Organization for Business Success,
Jacobson, Griss, and Jonsson estimate the following benefits of systematic reuse12:
Time to market: 2 to 5 times reduction
Defect density: 5 to 10 times reduction
Maintenance cost: 5 to 10 times reduction
Strategic reuse builds on the idea of systematic reuse and sees an organization tie their
reuse program to the strategy of the business. Therefore, the strategic reuse program must
implement a systematic approach to reuse that enables the organization to deal with
expertise shortages, globalization, regulatory concerns, rising customer expectations, and so
forth.
12
156
Software Reuse - Architecture, Process, and Organization for Business Success. Ivar Jacobson, Martin Griss,
Patrik Jonsson, pg 7.
Leveraging these definitions, the mission for the ZYX Electronics (ZYX) reuse program is to
improve the quality and time lines of deliverables from the IT organization to support and
enable the business goals and objectives of ZYX Electronics.
ZYX Electronics expects to realize this mission by developing tools, processes, and policies
that will establish, maintain, and encourage strategic reuse.
There are many challenges, however, to implementing software reuse at an organization,
because reuse has an impact and dependency on culture, process, and tooling. All three of
these elements must come together to realize a successful reuse program.
This document discusses the changes in policy and practice that will be required at ZYX
Electronics to adopt and apply Asset-Based Development.
As detailed in the Reuse Assessment, the initial scope for the reuse program will be the
Credit Application development team. Also, as detailed later in this document, the initial
rollout of this program will include a pilot phase. Therefore, this document must be seen as a
living artifact as decisions, best practices, and documents are built during the rollout.
Standards
Process
Tooling
The relationships among the elements are shown in Figure 7-25 on page 158.
157
158
products from the software development process, for example, requirements, models, source
code, and tests. The relationship between assets and artifacts is shown in Figure 7-27.
Problem
Solution
Artifact
Artifact
Artifact
Artifact
for a context
Variability point
Asset
Artifact
Of particular importance to our reuse program will be the idea of variability points. We expect
that the assets that we create are engineered for reuse. Therefore, they must either support
Black box reuse (that is, zero variability points) or Gray box reuse where a small number of
variability points are provided. It is unacceptable to produce and contribute reusable assets
for White box reuse (that is, unlimited points of variability). White box reuse drives
development to rewrite instead of reuse. Encapsulating and controlling the functionality within
a reusable asset is of the utmost importance.
Contains name and value pairs that describe, classify, and categorize
the asset
Solution
Contains the assets payload (that is, the artifacts, such as models,
code, and so forth, which comprise the solution that the asset
provides)
Usage
Related Assets
159
The tooling that we use for producing, consuming, and managing assets must support the
RAS standard. We do not want to end up with just a scrap heap that contains a collection of
stuff that no one can figure out how to use. To support strategic reuse, the assets that are
created, in addition to providing a correct and proven solution, must be packaged as a
reusable asset. The Reusable Asset Specification provides us with a mechanism to use in
increasing the reusability of our assets. In addition, we are able to leverage an industry
standard, which prevents vendor lock-in.
160
ZYX Electronics has initiated efforts in Asset-Based Development and strategic reuse to
support the Credit Administration business component. As discussed in the Reuse
Assessment, the initial efforts for reuse will focus on this business area and the associated
development organization.
We want to support business agility and flexibility within Credit Administration. The business
drivers within this component are based on the following requirements:
Centralizing siloed departments and building optimized services to support the converged
organization and then negotiating better prices with our vendors and taking advantage of
our combined size to help us:
Decrease the negotiated cost (vendor volume discounts) of credit report retrieval by
20%.
Automate 75% of all credit report retrievals.
Implementing consistent business rules to manage risk
Decrease the number of credit report retrievals by 10%.
The development team wants to reduce software development costs, increase software
quality, and reduce software maintenance costs.
In this section, we describe ZYX Electronics vision for Asset-Based Development.
Chapter 7. Adopting Asset-Based Development
161
7.26 Vision
The overall vision of the ZYX Electronics Asset-Based Development (ABD) strategy is to
produce systems through a strategic reuse program in support of the following themes:
Business alignment in support of a larger IT Governance requirement. We need to ensure
that the investments made in the reuse program support the business. The result will be
targeted investments that support business agility and flexibility.
Reduce software development costs.
Increase software quality.
Reduce software maintenance costs.
The ZYX Electronics business drivers that motivate this vision are:
Improve business agility and flexibility.
Improve efficiency of business operations.
Reduce skill shortages.
Meet rising customer expectations.
The ZYX Electronics IT drivers that motivate this vision are:
Leverage Reuse Strategy in all architectural layers, including in the code.
Improve maintainability, availability, and scalability.
Minimize total cost of ownership.
Reuse is a two-part decision process: first, the organizational level decision to institute
strategic reuse and second is the decision for practitioners to practice reuse at lower levels of
the organization. Both decision levels require management support and enforcement. For the
reuse vision to be successful, the application development teams must see from the start that
the reuse efforts provide value to their development challenges and assignments. Relying on
a Reuse Strategy that holds out benefits in the distant future will fail.
Therefore, assets must be identified early that have high value for a targeted Asset
Consumer audience, namely, the application development teams. There are two approaches
here: identify assets that are reusable across a broad sector of the development teams or
identify assets that are highly valuable to a narrow sector, perhaps for a specific project or
two. The latter strategy tends to be more approachable, because it helps to control scope,
cost, training, project coordination, and so on.
To successfully implement the reuse vision, there are fundamental principles that must be
observed. Without support for these principles, implementing the reuse vision is placed at
risk:
Management support for Asset-Based Development. In particular, the management team
will monitor the team deliverables and reuse metrics and will both recognize and
encourage reuse.
Seek ways to shift the extra costs and risks of reuse production and consumption out of
the individual application development projects and into the core asset development team.
Look for high quality, relevant assets that are critically needed by the target Asset
Consumers, namely the application development teams.
The functional and non-functional requirements must be well understood by both the
application development teams, as well as the core asset development team.
Application development teams have limited resources available for reinvention.
162
There is a strong architect, who acts as the reuse guardian for asset assessment and
usage.
Seek reuse opportunities where they have the highest probability of a net positive project
payoff. A key aspect of this principle is that we will have team members enabled on
pattern-based engineering to ensure that we find and build assets that provide an ROI
within the projects where they are used.
Recognize and encourage all forms of reuse that have net benefits at a project level,
which includes reusing document templates, procedures, and so on.
With these principles in mind, the reuse vision is to provide cost-effective assets that provide
value to Asset Consumers in particular, application development teams so that there is
business value to using these assets. The business value can be described in terms of
increased production time, lower development and maintenance costs, improved return on
investment, and so on. The reuse program can be altered to focus on the identified value that
the business seeks to obtain.
A critical element of this vision is that the reuse program is implemented so that the costs of
reusing assets are continually pushed down. The reuse cost is a major factor in the success
of the reuse program. Increasing the packaging costs to decrease reuse costs is generally a
reasonable strategy. However, having nicely documented non-reusable assets only
increases costs for the business. Refer to 7.27, Identified risks on page 166.
Of particular importance at ZYX Electronics is a desire to avoid unnecessary formality and
over-engineering. Therefore, we leverage iterative and incremental approaches to building
our assets. At the end of each iteration, there must be a reviewable deliverable.
A critical aspect to controlling asset production and reuse costs is through the nature of the
relationship of the asset development team and the Asset Consumer teams. As part of the
reuse vision, the asset development team provides resources for ensuring the success of
assets on the asset consumption teams. This not only helps the asset consumption teams in
terms of their costs, but it also provides valuable feedback on the assets that benefits future
asset development efforts.
The scope of the reusable assets can also affect the cost. As seen in Figure 7-30 on
page 164, there are multiple scope levels regarding how an asset can be reused within an
organization. Generally the higher the assets scope for reuse, the higher the testing,
packaging, communicating, and maintenance cost. The strategy for this reuse, as outlined in
this document, is to start with smaller scoped assets and then grow the scope across the
phases over time as experience and lessons learned are gathered.
163
With the guiding principles outlined in this vision, the real focus becomes what can help ZYX
Electronics develop systems to meet the overall vision and business drivers that have been
specified.
There are four major aspects to how we plan to leverage reuse, including:
Open source software: An abundance of open source software is available for use by
organizations. ZYX Electronics will leverage assets from the open source realm. An
important concern with this aspect is a need to ensure that all legal issues are addressed
and managed.
Tools and frameworks: Industry leading tools and frameworks will be leveraged. A
preference for open standards and specifications exists.
Services: ZYX Electronics is adopting the SOA architectural style. Therefore, there is the
expectation that siloed application development will be reduced or eliminated, services will
be reused, and there will be alignment with the business. As part of this effort, work will be
done regarding how to ensure that business services are reused, Composite Business
Services are created and used as necessary, and the WebSphere Business Services
Fabric is leveraged as appropriate.
Pattern-based engineering: A strong bottom-up, quick ROI approach to building pattern
implementations in support of frameworks, industry best practices, and ZYX Electronics
best practices is required.
164
This approach is a top-down, model-driven style of reuse. There are multiple styles for
addressing reuse. This template only illustrates one approach.
The exact steps and approach will differ depending on the aspect and the types of assets. For
example, this approach can be compressed via the use of pattern implementations that infuse
architectural best practices and decisions. Therefore, it might be possible that the seven
steps turn into a smaller number of steps, such as two or three steps. The number of steps
will depend on the patterns that are identified and the amount of variability that exists. Also,
the input models into the patterns can be graphical, as shown in Figure 7-31, or they can be
textual (for example, XML-based). For more information about a pattern-based engineering
approach, refer to Part 4, Patterns on page 455. For more details about a Service-based
approach that leverages Composite Business Services and the WebSphere Business
Services Fabric, refer to Part 3, Service Assets in an SOA on page 333.
Next, we briefing describe each of these steps. For more information about ZYX Electronics
Asset-Based Development (ABD) process, see Part 2, Reusable Assets on page 123:
Step 1: Business Process/Solution Architecture Mapping: Starting with the ZYX
Electronics Business Model (considered a mandatory input), the IBM Patterns for
e-business are applied, which describe the mapping of the business processes onto a
runtime topology. Then the product mapping is developed, which identifies the
technologies and products that are to be used within the high-level Solution Architecture.
165
In addition, an analysis is done to determine which industry and open source software
frameworks must be included in this solution. In cases where it is clear that certain
frameworks will fit, a further analysis for identifying supporting assets and best practices
that are associated with the framework will be conducted.
Step 2: Application Use-Case Modeling: The application use cases that implement the
business processes are defined. As can be expected, work is done to prioritize the use
cases, and consideration is given to the iterations in which the use cases will be attacked.
In addition, a pattern opportunity analysis will be done to find areas of recurring problems
that can be addressed via pattern-based assets. As part of the analysis, a search for
exemplars will be performed. In cases where exemplars do not exist, archetypes will be
built to serve as input into the pattern creation process.
Step 3: Application Behavioral Modeling: The key abstractions, use-case realizations
(for example, interaction diagrams), and other behavioral models are created. In cases
where we have identified a pattern opportunity, we perform these tasks in building the
archetype. In cases where we have a unique and non-repeating solution, we will leverage
this approach to build the solution.
Mitigation strategy
Identify asset identification criteria and conduct regular asset surveys and assessments with
these criteria. Establish governance policies and acceptance policies whereby management
has the option to accept or deny the development and long-term maintenance of the asset. In
addition, leverage the Asset Scorecard as published in Chapter 6 of the Strategic Reuse with
Asset-Based Development book.
Mitigation strategy
Establish an asset packaging policy that tests the organization of the assets documentation,
guidance, and even variability points that eases the effort to reuse the asset. Increasing
packaging costs to lower reuse costs are a critical part of the success of the asset reuse
166
activities. Another key element to the mitigation strategy for this risk is to establish training for
the Asset Consumers on the process, tooling, policies, and guidelines early in the asset reuse
program.
Mitigation strategy
Set objectives in place that seek to positively impact the value to the Asset Consumers
project, such as increased productivity or decreased development and maintenance cost.
The Repository must always be kept fresh through asset usage reviews, statistics, and
feedback. Assets must be retired that are not providing value to the Asset Consumers.
Mitigation strategy
The assets that are commissioned and developed by the reuse team will be owned and
maintained by the reuse sponsors funding. Those assets developed by the application
development teams will be owned and maintained on the budgets of the respective projects.
The application development teams can propose assets to the reuse team to own and
maintain. The business case for the cross-project relevance of the proposed asset must be
achieved. If the reuse team takes ownership of a project-developed asset, the funding model
must support the reuse teams ownership and maintenance costs associated with the asset,
because there will generally need to be refinements to the newly acquired asset to support a
broader reuse scope.
7.27.5 Over-engineering
There is often a tendency to build the perfect reusable asset that will solve the entirety of the
problems facing a project. Development time becomes lengthy, costs rise, and the asset
development becomes a project unto itself.
Mitigation strategy
An iterative and incremental approach to asset creation will be a key aspect to the mitigation
strategy. We will avoid the creation of custom and in-house frameworks and other large scale
assets. A compositional approach to building larger solutions must be followed, which means
that we plan to have a selection of smaller assets, which can then be composed into larger
and larger solutions.
167
Mitigation strategy
Innovation can be achieved by bringing together a number of smaller assets in a unique
composition. Therefore, we again stress the importance that we will favor smaller,
composable assets. We can create new and innovative compositions quickly and easily from
a selection of smaller and proven assets. Those assets can be built by ZYX Electronics or
sourced from other organizations (either commercial or open source).
Mitigation strategy
We will leverage estimation and cost calculators provided by industry sources to assist in
building reasonable estimates. In addition, we will focus on finding assets that quickly
produce desired levels of ROI.
168
7.31 Organization
In this section, we describe how the ZYX Electronics organization will be structured to support
Asset-Based Development. The ZYX Electronics entities involved in the Asset-Based
Development process are shown in Figure 7-33 on page 170.
169
We describe these organizational roles and their responsibilities with regard to reuse next:
ZYX Electronics management (CIO and CTO): ZYX Electronics management needs to
support the reuse efforts in order for those efforts to be successful.
Chief Technology Officer (CTO): The CTO oversees and leads the Solution Architects.
Enterprise Architecture (EA) Team: The EA Team is responsible for developing,
implementing, and maintaining the Enterprise Architecture within ZYX Electronics. Within
ZYX Electronics, the Enterprise Architecture is represented in multiple levels, each with its
own architectural framework, and each with its own architect:
Solution Architects are responsible for assembling and integrating core assets and
developing solutions to specific technical requirements (Solution Architectures).
Application Family Architects are responsible for application architectures that
leverage commonality across a family of applications (Application Family
Architectures).
Application Architects are responsible for the development of the software
architectures for specific application architectures.
Reuse Team: The Reuse Team shoulders much of the Asset-Based Development
responsibilities. The Reuse Team provides the reuse environment (both process and
tools), develops the core reusable assets, certifies all produced enterprise assets,
manages the enterprise asset repositories, and manages and coordinates the overall
reuse program.
Core Asset Development (CAD) Team: The Core Asset Development (CAD) Team is
responsible for performing the hardest tasks of qualifying, harvesting, and delivering the
core reusable assets. Assets can be commissioned to be built from respected Asset
Producers, who can be the Reuse Team or a specific domain expert. The Reuse Team
will build several of the assets and will gather funding to pay respected Asset Producers to
170
develop and maintain reusable assets. At times, a respected Asset Producer might need
to be pulled into an application development project to provide support. The CAD team
requires the funding to support this kind of activity.
Reuse Working Group (RWG): The Reuse Working Group (RWG) includes
representatives fulfilling each of the Asset-Based Development process roles (for
example, asset production, asset consumption, and so forth). The RWG serves as the
champion for the reuse program, communicating managements goals regarding the
reuse program and reporting on the progress of achieving those goals.
The RWG supports the development of the Asset-Based Development environment
(including the ABD guidelines), identifies candidate assets, approves the development of
enterprise assets, and encourages inter-organizational cooperation.
The RWG provides asset marketing services to the architecture and application
development teams (the primary Asset Consumers). Representatives from the RWG work
with the development teams to understand their requirements and then they communicate
to those teams the kinds of assets that are in the Repository that might fit those needs.
The RWG also provides asset support services to the architecture and application
development teams to help ensure the success of using the assets. They formally solicit
feedback from the development teams in order to understand the effectiveness of the
assets; this information is then communicated to the Asset Development team to improve
the assets.
Asset Certification Board (ACB): The Asset Certification Board (ACB) is responsible for
certifying assets before they are published in the asset Repository.
User Requirements (UR) Team: The User Requirements (UR) Team is the liaison
representing the users and their requirements. This role exists in application development
and is impacted by the set of assets that begin to flow within a description of the
requirements and the users needs.
Business Architect (BA): The BA drives the activities for describing the business
requirements, processes, and use cases. The BA role exists as part of the business unit
and application development teams. The BA is impacted through assets that describe the
business and also is responsible for ultimately driving the technical solution from the basis
of the business description.
The previous organizational role descriptions provided a high-level strategy for how the ZYX
Electronics organization will support Asset-Based Development.
171
There are also multiple options for determining where in the life cycle the assets are built:
Prior to application project development
During application project development
After application development projects have been completed (harvesting assets)
There are several places within the organization that assets can be produced: the reuse team
and the application development teams. The reuse team operates outside the context of any
given project, but it certainly must be tightly associated with the application development
teams to ensure the success of the teams use of reusable assets. Application development
teams can also develop reusable assets, although the scope of these assets is bound by the
current project on which they are created. Application development teams building assets
must be aware of the potential costs of creating and maintaining reusable assets. In certain
cases (that is, with small, closely located teams), informal reuse can occur, and this is
encouraged where possible and where the obvious benefits exist.
Initially, the reuse team will create assets based on conducting reuse assessments and
determining redundant problems and solutions across the teams. The artifacts from these
projects will be harvested and organized for reuse. It is possible to see a time when the reuse
team can create artifacts and assets from scratch, rather than from harvesting activities.
There are several reuse failures that can occur during asset consumption. These failures
must be addressed as part of the reuse program management and the asset production
activities. A reuse failure is ultimately when an asset is not discovered, found, or cannot be
used, as listed:
Assets are not searched for: In other words, the asset repositories are not being used.
This situation creates the need for incentives and influencing the behavior of potential
Asset Consumers.
Assets are not found: Tracking the nature of the queries on the Repository to help Asset
Producers understand the needs of Asset Consumers helps mitigate this situation.
Asset cannot be used: The asset does not accomplish what is needed. The earlier in the
asset consumption workflow that it can be determined that the asset is not going to meet
the needs, the less expensive the reuse failure is. Therefore, this situation creates the
need to have strong packaging and documentation that outline the asset very clearly so
the decision to not use the asset can be made as early as possible. This situation also
creates the need for a strong asset certification workflow.
The real goal is to lower the costs of reuse, and this goal falls squarely into asset production
(effective asset consumption depends on effective asset production). The goal here is to
reduce the number of reuse failures that are more costly, such as discovering the asset will
not work after the asset has already been brought into a project and development activities
are taking place, or discovering the asset will not work during testing and validation. This
experience is expensive reuse failure, and many times, it can be mitigated through strong
asset packaging and documentation strategies. The assets must be high quality and well
documented. There can be variants of the same asset supporting the same functionality but
supporting different performance requirements.
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of
Pearson Education, Inc., Saddle River, NJ.
173
Plan: In this phase, we create a plan that details how we are going to leverage reuse
within the organization.
Implement: In this phase, we follow through on our plan and work to become a
reuse-based organization.
Improve: As we follow through on our plan, it will likely become apparent that we will learn
about reuse, our organization, and the need to make adjustments. In this phase, we
recognize the need to improve our approach and then roll those improvements back into
our plan.
During initiation, the Reuse Team gained an understanding of Asset-Based Development
and presented it to several levels of management for support and commitment. The Reuse
Team then initiated a program (investigation) to explore Asset-Based Development concepts
and work with Rational to develop an initial set of guidelines and standards to prepare ZYX
Electronics for Asset-Based Development. As part of the initiation, the decision was made to
that we will make two passes through this adoption model as part of the reuse rollout. In this
first pass, we will go through all of the steps in a pilot project. Then, based on the results from
the pilot, we will take a second pass through the model as part of a larger rollout.
Figure 7-36 depicts the high-level steps that we will include in the pilot project. The results
from the pilot project will feed into this document, as well as into a second pass of the
adoption strategy.
ZYX Electronics is currently in the investigation phase. With the support of Rational, ZYX
Electronics has started to investigate how to implement a reuse program within ZYX
Electronics. The results are described in the ZYX Electronics Asset-Based Development and
Strategic Reuse Guidelines and Standards document set. The purpose of the guidelines and
standards is to provide a solid foundation for the ZYX Electronics Asset-Based Development
and strategic reuse initiative. The ZYX Electronics Asset-Based Development and Strategic
Reuse Guidelines and Standards are:
Part 1: Reuse Strategy (this document)
Part 2: Asset-Based Development Process Overview
Part 3: Asset Packaging Guidelines
Part 4: Asset Configuration Management and Version Control Guidelines
Part 5: IBM Patterns for e-Business Guidelines. You can refer to these guidelines and
associated guidelines at:
http://www.ibm.com/developerworks/patterns/
Part 6: Asset Modeling Guidelines
Part 7: Asset Certification
174
175
Figure 7-38 on page 177 provides further details regarding the framework by depicting the
characteristics of each level in the framework.
14
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
176
Figure 7-39 on page 178 uses a star shape to show the as is current state assessment
of ZYX Electronics position within each of the categories in the framework. The target symbol
is used to indicate the desired endpoint for the organization in the medium term. Longer term
advancement along the framework will depend on results during the pilot and then in the
initial rollout of the program.
15
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
177
Figure 7-40 on page 179 shows the motivation and travel events that are associated with
each level in the framework. The Motivations and Travel Events will be used loosely as a
guide to indicate when we need to move to a particular level in the framework. These
motivations and travel events usually occur before we can migrate from one level in the
framework to the next higher level. For example, to move from the Initial/Chaotic level to the
Monitored level, we must recognize that competitive pressures require increased reuse. In
addition, the management team must request reports detailing the progress made toward this
reuse goal.
A key challenge for the reuse program will be to prove itself to the organization to earn a
multi-year funding commitment and to reach the Planned level in the framework.
16
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
178
As a result of the funding commitment issue, we envision the organization migrated from the
Initial/Chaotic level to the Coordinated level in the initial rollout of the reuse program (see
Figure 7-41 on page 180). A longer term goal, when further funding commitments are in
place, will be to move to the Planned and Ingrained levels.
17
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
179
Figure 7-41 ZYX Electronics next stage in the Reuse Maturity Model18
18
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
180
Each of the organization templates has a number of categories that are used to describe its
characteristics, including:
Reuse scope: The intended reuse visibility. As can be expected, more formality and
structure appear as the scope of the reuse increases.
Governance board: The number and kind of governance boards
Asset management: Location of the resources that manage the assets
Asset manufacturing: Location and resources producing assets
Asset use: The techniques and formality for asset reuse
Figure 7-42 provides a comparison of the characteristics for each of the organization
templates.
Figure 7-43 on page 182 provides an overview of the Governed organization template. Key
characteristics of this template include:
Asset production is funded, supporting both the development and maintenance of key
assets.
Use of the assets is supported by the Asset Producers.
Asset use is both planned and opportunistic.
181
Figure 7-44 provides an overview of the Enterprise Full organization template. A key
characteristic of this template is that the functions around asset production and asset
management require overhead, and the organization can achieve efficiency by centralizing
them.
A challenge for this structure is that asset production can occur too distantly from the domain
experts working on the projects. Attention and effort need to be in place to ensure that this
undesirable circumstance does not occur.
We have decided to adopt the Governed organization template for the pilot. Depending on
the success of the pilot and funding levels, the preference is to then move to the Enterprise
Full template.
182
The organization chart shown in Figure 7-44 on page 182 provides a view of the to-be
organization structure after we have completed the pilot of our reuse program. Those
employees who work in the pilot will become a reuse team during the pilot and will then see
their responsibilities grow from just the Credit Administration development team to the wider
organization.
19
Adapted from Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of Pearson
Education, Inc., Saddle River, NJ.
183
7.39.1 Description
Although we have had little focus on reuse in the past, we do expect to find a number of
assets already in use within the organization. Therefore, we need to locate the assets,
evaluate the assets, ensure legal compliance as necessary, and make the assets available
for other people to use. This is a key step for the organization, because it provides a quick win
and provides momentum for the organization.
184
7.39.2 Goals
The goals for this phase include:
Get a quick start to reuse.
Get teams thinking about reuse.
Ensure license and legal compliance with open source software use.
Get team started using reuse adoption model (RAM) and consulting RAM for assets.
Start collecting feedback and discuss the assets.
Define communities and asset types within the asset Repository.
7.40.1 Description
In this phase, we get the team enabled on pattern-based engineering (PBE) and leveraging
this approach in how we deliver software. A key appeal of starting with this approach is the ability to
learn how to build patterns quickly, build patterns, and deliver a positive ROI. A key aspect of
this work is opportunity identification, where the team is able to analyze the work that needs
to be done for pattern opportunities. Perform evaluations of other preexisting pattern
implementations that are provided by third-party sources.
7.40.2 Goals
The goals for this phase include:
Enable the team to build pattern implementations.
Evaluate, select, and acquire pattern assets from third-party sources.
Include pattern activities in project plans.
A pattern opportunity identification mentality is created within our development
organization.
7.41.1 Description
In this phase, we focus on getting the team to look at SOA as a key mechanism for leveraging
and supporting reuse. Therefore, we will enable the team on the RUP-SOMA approach to
creating SOA solutions and in particular will focus on the Service Identification phase.
In addition, we need to find ways to reuse service assets that are made available from
third-party providers. In particular, we need to evaluate the IBM WebSphere Business
Services Fabric (WBSF).
185
7.41.2 Goals
The goals for this phase include:
Enable the team to identify, design, and build reusable service assets leveraging
RUP-SOMA.
Identify an initial set of services within the Credit Application component.
Identify opportunities for leveraging WBSF elements within the Credit Application
component.
Enable the team to leverage pattern opportunity identification for finding pattern
possibilities within the creation of service assets.
Complete an evaluation of the WBSF product as a source of reusable service assets.
7.42.1 Description
In preparation for a larger rollout of the reuse program, we need to evaluate the results of the
pilot project. As part of the evaluation, we capture lessons learned, both good and bad. The
investment in the pilot project is seen as providing payback in improving our odds of success
as we broaden the scope of the reuse program and roll it out to a larger portion of the
organization.
We expect that the ZYX Electronics Asset-Based Development and Strategic Reuse
Guidelines and Standards will be updated based on the experiences in the pilot projects.
The metrics and maturity models will be leveraged to interpret the results of the pilot. The
metrics will serve as a baseline for future iterations.
We will enhance and update the process workflows, roles, and deliverables to better suit ZYX
Electronics.
7.42.2 Goals
The goals for this phase include:
Gather and report on lessons learned from the pilot.
Gather metrics and results that have proven reuse and that prove that a further investment
is warranted.
Create a Repository instance with useful and proven assets.
Provide a foundation upon which the reuse program can grow.
Build a plan for the next phase of the reuse adoption program, looping back to the Initiate
step in the reuse adoption model.
Update the ZYX Electronics Asset-Based Development and Strategic Reuse Guidelines.
186
187
motivators that are initially selected; when selected, the proper metrics and measurement
techniques must be put in place:
Reduce development costs.
Reduce maintenance costs.
Increase productivity.
Improve product quality.
Provide a consistent look-and-feel.
Remove the barriers to entry for new products.
The general framework for categorizing these metrics is illustrated in Figure 7-47.
Each category in Figure 7-47 lists sample metrics to consider. Considering the potential
breadth and depth of the metrics outlined in Figure 7-47 and the costs of capturing those
metrics, a subset of these metrics will be gathered initially for the purposes of the ZYX
Electronics reuse program. The categories for these initial metrics must include economic
metrics, primary metrics, and Asset Consumer feedback. As the program matures, additional
metrics must be added to each category, as well as specific categories of metrics, such as
library metrics and so forth.
20
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, 1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
188
FY 06
FY07
FY08
$0
$0
$0
$0
$0
$0
$0
$0
$0
Total benefits
$0
$0
$0
Net result
$0
$0
$0
Producer costs
Startup
Reuse management
Work product creation
Library creation
Tools creation
Training/marketing
Other
Total startup
Ongoing
Reuse management
Workproduct creation
Library creation
Tools creation
Training/marketing
Other
Consumer benefits
Total asset ROI
Development resources saved
Quality Assurance resources saved
Development Manager resources saved
189
190
Asset change request rate/time period: Number of change requests for an asset in a
given time period
Asset maturity: Breakdown of the asset versions in the library
191
192
SA
AA
BA
AD
UR
Reuse
7.53 References
For more information, refer to:
Incentive Compatibility and Systematic Software Reuse, Journal of Systems and
Software, Apr 27, 2001; Vol. 57, Iss. 1, Robert G. Fichman
Chapter 7. Adopting Asset-Based Development
193
194
Chapter 8.
195
Community X
Assets
Community Map: Users, Roles, Permissions
Asset Workflow Specification: Review Process
Connections to:
Rational ClearQuest,
WebSphere Service Registry and Repository
Community Y
Assets
Category
Schemas
Asset
Attributes
Relationship
Types
In the next sections, we will explain in detail the terms represented in Figure 8-1, including:
196
Community Map
Asset Workflow Specification
Asset Type Specification
Administration Roles
As part of the explanation, we will also discuss best practices to configure your Rational Asset
Manager Repository to govern the assets that are relevant for your organization.
Cannot create
or modify
Testing community
Testers
User Group
Cannot create
or modify
197
Important: If you are interested, you can download a template of the Community Map
artifact that is provided as additional material to this book. For details, refer to Appendix C,
Additional material on page 725.
Organizing the Rational Asset Manager Repository into partitions of assets for specific users
and interests enhances scalability by easing reusable asset communication and
maintenance, as well as the approachability of the Repository user experience. Making all
assets visible to everyone quickly decreases the value proposition of the Repository, because
it becomes too large for people to navigate.
Administrators will use communities to:
Control the level of access that users will have to the communitys assets.
Define and configure the review processes for specific communitys assets.
Integrate with external tools to extend the default functionality provided by Rational Asset
Manager:
Use with Rational ClearQuest to customize asset review processes and forum
discussions.
Use with WebSphere Service Registry and Repository to publish and search for
services in the runtime environment.
To control the level of access of users to the various communities created, the Administrator
will define and configure roles, users, user groups, and permissions:
A role is a collection of permissions that Administrators can assign to individual users or
user groups. Roles are defined by community.
A user is an individual with assigned roles and permissions within a community. A user
can have multiple roles and permissions. Rational Asset Manager manages two types of
users: authenticated or anonymous:
Anonymous users do not have to log in to the Repository, but they are restricted to
searching and reading the general details of an asset. They have permission to search
for assets, but they do not have permission to modify, download, or view the artifacts
contents.
Authenticated users need a valid login and password to log in to the Repository, and
their permissions depend on the permissions assigned by the community
Administrator.
A user group is a collection of users with the same roles and permissions for a particular
community.
Users and user groups can come from an Lightweight Directory Access Protocol (LDAP)
registry or can be manually added to the Repository. For more information about how user
authentication works in Rational Asset Manager, see A.2.4, User authentication on
page 657.
Permissions define the actions that a user can perform in any given community. Roles
provide a way for community Administrators to group those permissions and assign them
to all users, particular users, or user groups as shown in Figure 8-3 on page 199.
198
LDAP
LDAP Group
Community
User Group 1
User Group 2
Query
User Group 1
A list of users that comes
from an LDAP group
Users
A list of users entered
into the repository, or
from LDAP.
Users
Roles
Review Process
User Group 2
A list of users
entered directly in
the repository
Roles
A list of roles and
their permissions,
scoped within one
Community
Review Process
References user and user groups to
participate in the review process.
A role consists of a role name, description, permissions, and scope. Administrators can
constrain the scope of a role by making permissions apply only to assets that meet a specific
criteria (specific types or categories).
Each new community is created with a set of default roles, as shown in Figure 8-4 on
page 200, including:
Administrator: The Administrator has administration capabilities to configure the
community.
Asset Owner: The Asset Owner role is a person or an organization that defines and
submits the asset version, as well as updates or removes the asset version. The Asset
Owner is the original creator of the asset version.
Asset Review Board: The Review Board is responsible for specifying review processes. It
works with the Community Administrator to get the assets into the Repository. The Review
Board identifies the potential reviewers and customizes the review process in the
Repository to add the reviewers. The Review Board also initiates the review in the
Repository, monitors who has submitted reviews, and then evaluates the submitted
reviews and casts the final vote on an asset. This role needs to be optional, allowing
varying degrees of formality in the asset review process.
Asset Reviewer: The Repository notifies the Asset Reviewer when an asset is submitted
for review. The Asset Reviewer selects the asset to review and evaluates the asset,
prepares review material, and then votes to accept or reject the asset.
Asset Consumer: The Asset Consumer searches and browses Reusable Assets in the
Asset Repository, and ultimately uses the assets. The Asset Consumer provides feedback
about the assets.
Asset Producer: The Asset Producer updates an asset version by developing artifacts
and harvesting artifacts, as well as making changes to the metadata. If the updates
require the creation of a new asset version, the Asset Producer becomes the Asset Owner
in the Repository.
199
Important: These are the same roles that are defined by default in the Asset-Based
Development plug-in of Rational Method Composer.
Administrators can create additional roles as a method of grouping permissions that can be
assigned to users or user groups. Individual users or groups can have more than one role.
Note: Roles are not used to group Repository users; user groups are used to group
Repository users. Roles are used to assign permissions to individual users or groups of
users.
These Repository roles must be assigned to the various users or user groups of the Rational
Asset Manager Repository. When assigning roles, Community Administrators must consider
a users tasks within the context of a particular community. For example, user groups, such
as Analysts, are not required to modify or change development code and only need browse,
download, and submit access in a development community. However, users with a role of
Analyst in the Analyst Community can adopt full permissions so that the Analyst can modify
existing assets or upload new assets in their field of expertise.
The same role can be assigned to different users or user groups, and more than one role can
be assigned to a single user or user group.
The following list describes the permissions available to choose from when defining a role
within a specific community:
Browse assets: Users can view the asset, including the artifacts, which includes
searching and reading details.
Create assets: Users can create new assets. Creating assets includes describing and
adding artifacts.
200
Delete assets: Users can permanently delete assets from the Repository.
Download assets: Users can download assets. This permission also includes describing
and adding artifacts.
Forums administration: Users can administer forums for an asset (if assigned to an
asset role) or administer all forums and forum connections in a community.
Publishing administration: Users can perform publishing actions for an asset (if
assigned to an asset role) or perform all publishing actions (including publishing
connections) in a community.
Read asset details: Users can view asset details beyond the standard search asset
page.
Search assets: Users can search for assets using keyword and filter searches.
Subscribe to assets: Users can subscribe to e-mails or Really Simple Syndication (RSS)
file feeds to receive notification when an asset is modified.
Update assets: Users can update the content or descriptive metadata of assets.
Table 8-1 shows the various roles that are defined by default when a new community is
created and the permissions that are associated by default to each role.
Table 8-1 Roles and permissions for a community
Permission
Administrator
Asset Owner
Asset
Producer
Asset
Consumer
Asset Review
Board
Asset
Reviewer
Browse assets
YES
YES
YES
YES
YES
YES
Create assets
YES
NO
YES
NO
NO
NO
Delete assets
YES
YES
NO
NO
YES
NO
Download assets
YES
YES
YES
YES
YES
YES
Forums
administration
NO
NO
NO
NO
NO
NO
Publishing
administration
NO
NO
NO
NO
NO
NO
Read asset
details
YES
YES
YES
YES
YES
YES
Search assets
YES
YES
YES
YES
YES
YES
Subscribe to
assets
YES
YES
YES
YES
YES
YES
Update assets
YES
YES
YES
YES
YES
YES
Asset Review
Board *
N/A
N/A
N/A
N/A
YES
N/A
Review asset *
N/A
N/A
N/A
N/A
N/A
YES
Note: Permissions marked with * are not available to the Community Administrator to
assign to new roles. These permissions are only assigned and used by the Asset Review
Board and Asset Reviewer default roles.
201
Business Analyst
Community
Business Analyst
Repository Permissions
Search asset Browse asset
Retrieve asset Create asset
Update asset Delete asset
Community
Admin
Architect
Service Designer
Service Developer
Repository Permissions
Create asset
Delete asset
Update asset
Testing Team
Community
Service Tester
Service Assembler
Repository Permissions
Search asset Browse asset
Retrieve asset
Repository Permissions
Search asset Browse asset
Retrieve asset Create asset
Update asset Delete asset
Community
Admin
Community
Admin
202
It will take several iterations to create the proper set of communities. In most cases, the
Repository will need to be configured and then exercised for a period of time in order to
properly refine it. It is best to start with fewer communities and then add more as necessary.
203
Rational ClearQuest driven review process: Although the default review process is
generic, and it can be used in a wide majority of cases, if the organization requires a
customized review process with different states and transitions, Rational Asset Manager
(RAM) can be connected to the Rational ClearQuest change management tool. With
Rational ClearQuest, you can create a customized review process integrated with the
Rational Asset Manager review process. For more information about how to install,
customize, and use Rational Asset Manager and Rational ClearQuest to implement a
custom review process, go to A.3.2, Integrating Rational Asset Manager with Rational
ClearQuest on page 665.
An asset can have more than one review process assigned to it, but Administrators can
assign priority to them, so the users can view the review processes in order of the lowest
priority to the highest priority. Each review process is characterized by a single asset type and
zero or more category selections. The review processes are then ordered in a top-down
review process list. RAM checks this list from the top down. When it locates a review process
that meets all of the characteristics of the asset being submitted, it then uses that review
process. If no review process is found, the asset review process is skipped, and the asset is
automatically approved.
Name
Version
Community where the asset belongs
Asset type
Short description
There are other optional information fields that can be filled by the user when submitting a
new asset, such as a long rich-text description of the asset and tags to help in asset
searches. Also, creation time and usage time can be specified and later used to produce
metrics and statistics about the usage and return on investment (ROI) of the assets.
Rational Asset Manager can be customized to include additional metadata information and
attach it to the asset. This additional information will be dependent on the asset type that the
user selects.
When creating an asset type specification, there are four types of information to capture,
including:
Asset types
Category schemas
Asset attributes
Relationship types
205
Asset types
An asset type is the primary level of organization for assets within the Asset Manager
Repository. As discussed previously, asset types contain information that helps a user store
and find assets. Another important aspect of asset types is that they also facilitate
governance. Therefore, when a user submits an asset, the asset type controls the information
and artifacts that users must include with the asset.
Repository Administrators can customize the asset type with the following constraints:
Artifacts: You can define rules to control the number and types of artifacts that must be
part of the asset of a specific type.
Categories: A category is a classification that helps to organize assets within the
Repository so that users can find and reuse them more easily. You can configure and
control which category or group of categories the user can complete when submitting a
new asset of a specific type.
Relationships: You can define restrictions to control the number of relationships that the
asset that you are creating needs to have, and you can specify the type of assets with
which it needs to be related.
Attributes: An attribute is an additional information field associated to the asset. You can
control the additional information fields (and make them optional or mandatory) that the
user must complete when submitting a new asset of a specific type.
For example, you can define an asset type called Software Design with the following rules or
restrictions:
Contains at least one .emx file, which represents a Uniform Modelling Language (UML)
model
Has at least one related asset of type Requirement with a relationship named design
for
Defines its associated Business Domain (category)
Defines the type of architecture that is used to implement the asset (Java 2 Platform,
Enterprise Edition (J2EE), batch application, and so forth) (category)
The Repository Administrator can also customize the constraints (category schemas,
relationship types, and asset attributes) that will later be referenced when creating a new
asset type as represented in Figure 8-7 on page 207.
206
Figure 8-7 Asset types reference categories, relationship types, and asset attributes
Tip: Remember that you can also use asset types and categories to constrain the scope of
roles when configuring communities. Therefore, the permissions associated with a role will
only apply to assets that meet a specific criteria.
Category schemas
Category schemas can be used as mechanisms for searching and discovering assets, and an
asset can be classified using values from many category schemas. The category schemas
can be exclusive and unrelated to each other. Using category schemas in this manner
permits many perspectives to be captured. For example, not only do practitioners (architects,
developers, testers, and so forth) work with assets, but certainly Administrators and technical
management will interact with the assets, as well as with report generators, metrics
collectors, and other tools.
Each classification schema must be created with a specific focus. For example, you can
create a classification schema to describe the business domain of interest to the enterprise.
You might create another classification schema to describe the technical contexts for the
enterprise, such as runtime platforms and development platforms.
Category schemas are often created from the perspective of a target consumer. For example,
architects might want to discover an assets relevancy from the perspective of non-functional
characteristics so a Technical environment category schema will be created as represented
in Figure 8-8 on page 208.
207
Category schemas do not have to apply to all types of assets. You can define and use
specific category schemas to facilitate searches and the organization of specific asset types.
Administrators must evaluate the way in which users will view and access their assets. In
general, the Administrator will create one classification schema per perspective. To keep
things simple, remember that not all users need to be burdened with all perspectives.
Tip: When creating the schemas, the use of models or pictures to communicate the
category schema simplifies the effort to achieve acceptance from the users.
Asset attributes
Custom asset attributes are metadata elements that help you to provide an asset with
additional information that fits a specific context.
Custom attributes contain either strings or predefined lists and are defined at the Repository
level by the Community Administrator. They are associated with asset types and might be
required or optional on the asset type.
The following are examples of custom attributes that Administrators can create:
Project: The project that has created the asset
Support contact: The person with the knowledge to answer questions about the asset
Relationship types
Relationships enable users to specify which assets are related to each other within the
Repository and to describe the nature of that relationship. Relationships facilitate search,
governance, and impact analysis.
Asset relationships are bidirectional, and each relationship end has a type. If a user creates a
relationship from asset A to asset B, the reverse relationship exists from asset B to asset A.
For example, if you create a relationship type Uses open source framework to describe that
a component asset type was built using an open source framework, you must also define the
reversed relationship Open source framework used by to describe that the framework is
being used by the component as shown in Figure 8-9 on page 209.
208
Dependent/Dependency
Parent/Aggregation
Tutorial/Tutorial for
Test/Test for
Specification/Implementation
209
Category
Schemas
Asset
Attributes
Community Y
Relationship
Types
Administrators will use specific Administrator menus that are available in the Rational Asset
Manager Web client to configure metadata information (this functionality is not available in the
Rational Asset Manager Eclipse client). For more information about the differences between
these client types, go to A.2.3, Installing Rational Asset Manager clients (Web and Eclipse)
on page 655. The next section in this chapter shows how ZYX Electronics configured their
Rational Asset Manager Repository and gives you detailed information about how to
configure your Repository.
Tip: If the Administrator wants to have a visual representation of a specific Rational Asset
Manager configuration, the Rational Asset Manager Configurator plug-in can be used in
Rational Software Architect to provide a UML visualization of the configuration and allow
you to import and export these configurations into an XML Metadata Interchange (XMI) file.
See A.5.1, Rational Asset Manager configurator tool on page 711 for more information.
210
Community Map
To create the community map:
Start with a basic configuration that is easy to understand. With the introduction of your
new Asset-Based Development process and asset management tooling, a basic
configuration needs to be easy to digest by the users in the short term. Later, the tool
configuration can be modified to include more process detail as your situation allows.
Communities must group architecturally related elements together and facilitate access
control.
Start with fewer communities and then add more communities as necessary.
Create a community for each unique set of assets over which you want specific control
and governance, which will facilitate administration.
When considering creating a role, evaluate the asset types that are defined in the
Repository against asset type specifications. This action can both discover potential asset
types, as well as help refine with which assets the role will be working.
211
The asset type specification plays an important role in helping Asset Consumers discover
assets. So when creating this specification, do so from the perspective of Asset
Consumers and other stakeholders.
Do not confuse categories and asset types. Both are used for describing the asset, and
both are used for searching and discovery. But the asset type has a stronger affinity with
describing the set of artifacts that must exist in the asset and also with the kinds of
relationships that the asset must have with other assets. An asset has one type, whereas
it can have many classifications, which enhance the description of the asset.
There is a balancing act that needs to be performed when defining the necessary asset
types. An asset must contain a number of artifacts that are necessary to make the asset
meaningful. However, you must include only the artifacts that are meaningful to the asset.
If you include too many artifacts, the asset type definition is diluted and becomes
meaningless.
Define attributes for important information needed to describe the asset or for additional
information needed to generate metrics and reports on the Repository contents. For
example, if you want to measure the return on investment from reusing a specific type of
asset, define an attribute called Time saved to represent the time saved by users when
reusing the asset and make this attribute mandatory.
Create a policy document describing the rules by which the assets must comply as they
are created. Table 8-2 provides a sample of this type of a document.
Table 8-2 Sample asset rules and policies
Version
1.0
Description
Asset rules
Target audience
Version
2.0
Description
Target audience
212
Artifact rules
Relationship type
rules
Asset classification
rules
Version
1.0
Description
Target audience
Version
1.0
Description
Target audience
Version
2.0
Description
Classification
schema rules
Target audience
Version
1.0
Description
Target audience
General
In general:
Define naming conventions and policies to give coherent and standard names to the
configuration that you create.
Create a community in the Repository called Repository Configuration to store the
assets describing the policies and decisions you have followed for your configuration
(create a specific Dev Time Policy asset type to store these information assets). The
Administrator must have a single picture or a spreadsheet of the asset types, their
213
definitions, and their structure along with the artifact definitions in order to reduce
confusion and provide the consistent use of terms.
When users come to the Repository they often do not understand many things about the
Repository (information metamodel, communities, access control, asset versioning policy,
and so forth). So, you must create a Repository Configuration Overview document and
distribute it to the Rational Asset Manager users.
Integrate the Repository with the LDAP registry for your organization to manage users and
groups. Doing so, you will avoid a great deal of administration overhead.
214
Also, as discussed in the ZYX Electronics Reuse Strategy document, a new Reuse Team has
been created within the organization, as depicted in Figure 8-12. The Reuse Team will work
with Duncan Munchkin and the team as they work through the pilot phases of the Reuse
Adoption project.
Important: The Reuse Team will report into the Enterprise Architect, because ZYX
Electronics is using Rational Asset Manager as the Repository to manage the details and
artifacts associated with the overall enterprise architecture. The Enterprise Architecture
represents a key set of assets, which ZYX Electronics needs the entire organization to
follow and leverage. Therefore, this will be a key aspect of the Rational Asset Manager and
Reuse program adoption.
ZYX Electronics management team decided that Duncan Munchkin, the Development
Manager for the Credit Application, is the best candidate to lead this project due to his great
experience and knowledge of software reuse. In addition, as part of his teams effort in the
Reuse Pilot, they will define the initial Repository configuration and be the first to work with
the Repository. Therefore, they will produce, consume, and manage the first set of assets to
be loaded into ZYX Electronics Rational Asset Manager Repository.
Using this initial configuration, the objective is to have an environment ready to start using
Rational Asset Manager at ZYX Electronics to validate the defined process and the tool
implementation.
This initial configuration will not be the final one. It will be reviewed and updated later based
on user feedback, collected metrics, and reports generated. In Part 3, Service Assets in an
SOA on page 333 of this book, you will see how this initial configuration can be expanded to
manage service assets to help ZYX Electronics to transition to a service-oriented architecture
(SOA) and in Part 4, Patterns on page 455 to manage pattern assets.
Chapter 8. Configure your Asset Repository
215
216
Asset Manager, see Appendix A, Rational Asset Manager: Installation and administration on
page 637.
Business Modeling
Requirements
Analysis Design
Implementation
Test
Deployment
Project Management
Environment
As per the best practices covered earlier, ZYX Electronics also created a community for
managing the assets related to the configuration of the Repository. So one additional
community was created, which was called Repository Configuration.
To facilitate administration, Deon Adminio, the Rational Asset Manager Repository
Administrator for ZYX Electronics, wanted to assign Administrators to each community.
Because this was a pilot project, and not many people were involved, he decided to assign
Duncan Munchkin (the Development Manager) as the Administrator for all of the communities
instead of having to define different Administrators for each community.
To create communities and to assign Duncan as the Community Administrator, Deon used
the Rational Asset Manager Web interface, which contains all administrative capabilities.
Deon performed the following steps as depicted by Figure 8-13 on page 218 for each
community that he needed to create:
1. Click the Administration tab.
2. Click New Community.
3. Specify the following information in the New Community window:
Name: name to identify the community, for example, Analysis Design.
Description: brief description of the community
Type the name of the specific user who will be assigned as the Community
Administrator and click Search.
Select the check boxes next to the users who will be added as Community
Administrators.
Click OK.
217
218
Table 8-3 Asset types and restrictions associated to each asset type
Asset type
Artifact constraints
Category constraints
Relationship
constraints
Attribute
constraints
Business
Process
Requirement
Include at least
one .doc file to
represent the
requirements
document
Optionally, include
one .emx file to
represent the use
case model
Architecture
Software
Design
Database
Design
Database Type:
SQL Server
DB2
Oracle
DB Schema
Name
Microsoft Access
SQL Anywhere
219
Asset type
Artifact constraints
Category constraints
Component
Include at least
one BIN label
artifact
Technology
software:
Include at least
one SourceCode
label artifact
Relationship
constraints
J2EE
Cobol
C++
Others
Technology
hardware:
Windows
Linux
UNIX
z/OS
Others
Development
Type:
Internal
development
External
development
Framework
Framework type:
Open source
Commercial UI
components
SQL scripts
Batch scripts
Technology
hardware:
Windows
Linux
z/OS
Test
Optionally include
one .ini file to specify
the connection to
ClearQuest
TestManager
Include at least
one relationship of
type tests for with
the Component
asset type
Include at least
one relationship of
type tests for with
the Requirement
asset type
220
Attribute
constraints
Asset type
Artifact constraints
User Support
Material
Include at least
one .doc file to
contain the user
manual
Category constraints
Relationship
constraints
Attribute
constraints
Optionally include
one .emx file to
define the
Deployment
model
Project
Management
Information
Process
URL link to
Rational
Portfolio
Manager
Include at least one
.doc file to explain the
process artifacts
Methodology
used
Asset Governance
Artifact type:
Dev Time
Policy (asset
describing the
policies and
decisions for
the ZYX
Electronics
configuration)
Asset type
specification
Workflow
specification
Asset versioning
policy
Category schema
Repository
configuration
overview
Community map
Presentation
221
Values
Business Domain
Business Administration
Business Planning
Business Unit Tracking
Staff Appraisals
Account Administration
Product Administration
Purchasing
Branch/Store Operations
New Business Development
Sector Planning
Sector Management
Product Management
Product Directory
Marketing Campaigns
Relationship Management
Account Planning
Relationship Management
Credit Assessment
Credit Administration
Servicing and Sales
Sales Planning
Sales Management
Sales
Customer Service
Collections
Product Fulfillment
Fulfillment Planning
Fulfillment Monitoring
Product Fulfillment
Document Management
Financial Control and Accounting
Portfolio Planning
Compliance
Reconciliation
Customer Accounts
General Ledger
Geographic Area
North America
South America
Europe
APAC
Inception
Elaboration
Construction
Transition
In advance of creating and configuring these asset types and their restrictions, the Repository
Administrator had to create the categories, asset relationship types, and attributes.
222
Create categories
To create a new category schema that represents the Database Type that is referenced by
the Database Design asset type, Deon performed the following steps:
1. Go to the Administration tab.
2. Select Category Schemas from the Repository Administration sidebar as Figure 8-14
shows and click New Category Schema.
3. Define the new category by entering a category Name and Description. Use Add Field to
create additional root nodes as necessary.
4. To begin creating the Category tree, click Add Field to add the root of the category tree.
Note that the Add Field link creates new root nodes of the Category Schema. Use Insert
Child to create leaf nodes.
5. Enter the Name and Description of the category node.
Note: When you select Children are exclusive, it means that an asset can be categorized
using only one of the subcategories. Each choice in the list of subcategories is mutually
exclusive; therefore, the user can only assign one value from the list to the asset.
6. To add child categories, click Insert Child as many times as necessary to add the
necessary child categories to complete the category definition as shown in Figure 8-15 on
page 224 (add SQL Server, DB2, Oracle, MS Access, and SQL Anywhere values).
223
224
3. As shown in Figure 8-17, in the New Relationship window, specify database design for
as the Relationship type. Then, specify database design as the value for Reversed
relationship.
Create attributes
Next, Deon moved on to create the necessary attributes. Attributes will be used at a later time
as a restriction in the asset type. For example, a new attribute called DB Schema Name can
be used to describe the type of database associated with an asset of type Database Design.
225
3. In the New Attribute window, as shown in Figure 8-19, type the name and description for
the new attribute. To specify a default value to be assigned to the attribute, select the
check box Use preset values, type the value to be displayed, and click Add.
226
3. Provide a name and description for the new Database Design asset type.
4. Define a new artifact constraint by clicking New Artifact Constraint. A new window will
appear as is shown in Figure 8-21. Select the number of artifacts that will be required, the
restriction type, and the type of the required asset. When finished with these selections,
click OK. For example, to create the restriction to check if the datamodel diagram created
with Rational DataArchitect is included, Deon created a restriction to verify that the asset
type has at least one datamodel diagram (one file with extension .ldm).
227
5. Define the category constraints that will be shown to the user when creating a new
instance of this asset type. As Figure 8-22 shows, Deon selected just the general
categories (Business Domain and Geography) and the specific category for this type of
asset called Database Type.
6. Define a new asset constraint by clicking New Relationship Constraint. A new window
will appear as is shown in Figure 8-23. To define the constraint to have a relationship with
the Software Design asset type, Deon selected the number of relationships that will be
required (1), chose the asset type to relate with (Software Design), selected the type of
relationship already defined in the Repository (Database Design for), and then clicked
OK.
7. Define the attribute constraints that will be shown to the user when creating a new asset of
this type. Figure 8-24 shows Deon was able to select with a check box the attributes that
were already defined in the Repository to use to add additional information to the
Database Design asset type. To make the attribute mandatory when the asset is
submitted, Deon checked the Required check box for the DB Schema Name attribute.
by Rational Asset Manager when a new community is created so for each community he just
had to assign the roles permissions to the LDAP user groups according to the permissions
agreed upon in Table 8-6.
Important: Roles not listed in the table have Asset Consumer permissions in all
communities.
Table 8-6 ZYX Electronics roles permissions
Community
User groups
Role permission
Business Modeling
Business Analyst
Asset Producer
Project Manager
Asset Reviewer
System Analyst
Asset Producer
Project Manager
Asset Reviewer
System Analyst,
Architect, and
Database Architect (but only
with permissions to produce
database design asset types)
Asset Producer
System Analyst
Asset Reviewer
Developer,
Integration Developer, and
Architect
Asset Producer
Project Manager
Asset Reviewer
Test Architect/Manager
Asset Producer
Project Manager
Asset Reviewer
Asset Producer
Asset Reviewer
Asset Producer
Asset Reviewer
Development Tools
Administrator
Asset Producer
Development Manager
Asset Reviewer
Development Tools
Administrator and
Development Manager
Asset Producer
Requirements
Analysis_Design
Implementation
Test
Deployment
Project Management
Environment
Repository Configuration
Community
229
designated as a Community Administrator, this task might also have been performed by
Duncan as well:
1. Open the Administrator tab.
2. Click the community name Analysis_Design to modify the user groups and their
permissions that are associated with the community.
3. Open the User Groups tab.
4. To add a new user group to the community, click New User Group.
5. Type a name and a description for the new user group that is going to be created (System
Analyst, Architect, and Database Architect).
6. Because authentication was configured to use an LDAP directory, he clicked Bind to
select the LDAP group that he wanted to bind to Rational Asset Manager.
Note: A scheduled job will pick up any user information modifications for the group listed
on the LDAP server. After you bind the LDAP group to this user group, you can no longer
modify any of the users information about the Rational Asset Manager server (for
example, a users name or telephone number). This information must be modified on the
LDAP server.
7. To add new users to the user group, Deon clicked Add User in the Group Members
section. Then, he typed a search string and clicked Search to retrieve a list of user
names. Note that this search might return multiple user names.
8. Select the check box next to each users name to add them to the user group as shown in
Figure 8-25.
9. Select the roles to assign to the user group as shown in Figure 8-26 on page 231 and click
OK.
230
Tip: If the roles that are listed do not satisfy the needs of the user groups that you are
adding, add the user group and then go to the Role tab to create the new role. Later, you
can edit a user group and modify its roles.
Asset Owner, Asset Reviewer, Asset Review Board, and Administrator roles are created
automatically by Rational Asset Manager. These roles cannot be assigned to users or user
groups. There will be specific menus to assign these roles to users:
Administrator: This role will be assigned by the Repository Administrator to users when
creating a new community.
Asset Reviewer and Asset Review Board: This role will be assigned by the Community
Administrator when creating and configuring the review process for an asset type
(Review Process tab).
Asset Owner: This role is the original creator of the asset version.
To implement a restriction for the Database Architect role in the Analysis_Design community
so that it only has permissions to produce Database Design asset types, Deon had to create
a new role called Database Asset Producer and restrict the scope to only database design
asset types. To modify default roles permissions to constrain database design asset types,
Deon followed these steps:
1. Open the Administrator tab.
2. Click the community name Analysis_Design to modify the roles and permissions that are
associated with the roles in the community.
3. Open the Roles tab.
4. Because Deon needed to create a new role for the community, Deon clicked New Role to
add a new role definition to the community.
Chapter 8. Configure your Asset Repository
231
232
Figure 8-29 No special conditions were selected for the review process
8. Deon did not select Add review board members to this review process.
9. Rather than select individual reviews, Deon wanted to assign the responsibility for reviews
to a user group. So, to add the System Analysts user group to this review process as a
Reviewer, Deon followed these steps:
a. Click Add User Group and select System Analyst group from the list as shown in
Figure 8-30 on page 234.
233
234
To create the other review processes of Table 8-6 on page 229, Duncan and Deon just
followed the same process that we just described for the rest of communities.
235
The remaining chapters of Part 2 will detail the asset management life cycle tasks and roles
that are needed to produce, consume, and manage assets using the Rational Asset Manager
configuration that we have just created and defined for ZYX Electronics.
Part 3, Service Assets in an SOA on page 333 of the book will extend the configuration
defined in this chapter to include new metadata that is needed to manage services following
an SOA approach.
Part 4, Patterns on page 455 of the book will extend the configuration defined in this chapter
to include new metadata needed to manage patterns that are developed using Rational
Software Architect.
236
Chapter 9.
9.1 Introduction
In this chapter, we look at the asset manufacturing life cycle, that is, the production of assets.
As shown in Figure 9-1, it is important to remember that this is a cycle. We are not looking at
a large waterfall type process with long lags between deliverables and infrequent
opportunities to adjust course.
237
Also, we need to remember that there is a connection between the manufacturing cycle and
the usage cycle. This interaction is a key aspect of the success of any asset reuse program.
The assets that are produced must find an audience, be usable by that audience, and
address issues that are important to that audience. The Asset Producers need to
communicate with the consumers listening to the needs of this community, as well as accept
the feedback that is provided on assets that have already been built as shown in Figure 9-2.
238
Asset Manufacturing Team: This team creates and uses Asset Specifications to create
and maintain assets. The intended scope of the team must be defined. Will the team be
responsible for creating assets for the declared reuse scope at the enterprise level or the
divisional level? Will the team create the assets, or is the purpose of the team to clean up
assets and prepare them for reuse?
Directly associated with the scope of the Asset Manufacturing Team is the manufacturing
process. There are several models to consider. These models use the basic producer and
239
consumer model for assets. The premise is that an organization is focused on the creation
of assets and another organization is focused on the usage of assets.
In more mature organizations, the assets having a wider scope and impact are developed
by special teams as part of an Asset Manufacturing Center or Excellence Center. This role
captures the responsibilities and the tasks performed by these development groups with
regard to the asset production.
This role mainly performs the following tasks:
Create Asset
Update Asset
In this task, the Asset Producer analyzes recurring problems, or problems that are expected
to be recurring, and evaluates whether it makes sense to build a reusable asset to address
the problem.
As part of the analysis, the Asset Producer needs to determine the cost to build the asset, as
well as the benefits derived from using the asset. We encourage you to leverage the material
from Chapter 6, Value, impact, and return on investment on page 103 to help you to perform
these calculations. A good starting point is to leverage the relative cost factors proposed by
240
Jeffrey Poulin, in Measuring Software Reuse. He proposes that the Relative Cost of Writing
for Reuse is 1.5, which means that there is an additional 50% cost when building reusable
software. He also proposes that the Relative Cost of Reuse is 0.2, which means that the
relative cost to use the asset is 20% of the cost to rebuild the solution1.
Recommendations:
Leverage the tooling and automation that support reuse. As discussed in Value, impact,
and return on investment on page 103, place value on those tools that help you to build
and consume assets. Consumability is a key aspect of reuse; the harder it is to build and
use an asset, the more likely it is that your reuse program will fail.
Pragmatism is a valuable trait. Take a common sense approach, ask many questions, and
avoid over-engineering. For example, ask these questions:
Why are we building this asset?
What is the value of building the asset?
What is the cost of not building the asset?
Does this solution really represent a best practice?
Is there an incremental approach to building the asset, where we can achieve results
more quickly?
Unfortunately, it is not unusual to come across situations where the time pressure for a
project leads the team to decide that reuse introduces risk into a project. From the outside,
this looks to be a strange decision, because reuse and assets are meant to address
time-to-market issues and reduce project risk. However, human nature is often at odds with
accepting change and views change as introducing risk. We have actually come across a
number of projects where this decision has been made, and it is only later in the projects time
line, when it is clear that deadlines will not be met that reuse is reconsidered and then
adopted. Tips to consider if you find yourself in this type of situation:
A strategic reuse program adopted throughout the organization leads to a culture that
views reuse as the way that we do business and looks to leverage reuse as a risk and
time line reducer.
Again, tooling and automation need to be in place for building the assets.
Iterative and incremental asset delivery need to be considered. The quicker that you can
show that there is a payoff for the reuse investment, the better. Assets that take a team
three years to build before allowing for reuse are not likely to help the situation.
This task includes the following three steps:
1. Identify recurring problem: To understand the problem, the Asset Producer needs to
understand the impact of the problem on the users. When defining the problem, define the
context within which the problem exists. Explain the context in business terms and in
technical terms. Also, verify that the problem and its context exist in multiple places and
determine if this is an issue that occurs in other teams, projects, or organizations. When
the scope of the issue has been determined, ensure that communication occurs with those
individuals within the scope.
2. Identify common solution to recurring problem: The temptation is to focus on
describing the solution before having a solid definition of the problem. Fight this tendency
and do not spend significant time on this step until step 1 is completed. The proposed
solution must be relevant to the problems context and assumptions.
3. Verify the existence of the problem: A general rule from the patterns community is that
the problem and solution combination must be verifiable in three places in order for it to be
1
241
a candidate for a pattern. While this rule is not strictly prescribed here, it is a reasonable
guideline to follow.
It is critical to evaluate the combination of the problem and the solution. In certain
contexts, the solution to the same problem can vary slightly. It is possible to have multiple
implementations, or solutions, to the same problem. The variance is caused by changing
contexts, target Asset Consumers, and delivery channels for the assets. Also, ensure that
over-engineering does not occur. We need to be aware of variations of the problem, but it
is likely that if we address several of the variants initially and prove the asset and results,
we can return to the asset later and generalize it further.
A major goal of this task is to properly describe the problems, their context, and the solution.
This task can be described as asset proposal and adoption, because specification can be
used as a key input into the decision regarding whether to build the asset.
After an asset is published, it is natural that the asset can be used by the people who do not
know its background or context. That is, the problem, their context, and the solution of the
asset must be specified precisely enough for the consumer to evaluate the fit of the asset for
their problem.
242
Ideally, the asset will be able to be used in slightly different contexts from the original source
of the asset. The asset will need to provide future Asset Consumers with ways to adjust the
asset to meet the needs of their situations. Therefore, a key aspect of the specification is that
it accurately captures the points of variability that will be provided by the asset.
To reduce reuse failure costs, the specification must provide the information needed by Asset
Consumers as they determine whether to use the asset in their project.
This task includes the following steps:
1. Analyze asset requirements: Understand the problem that you want to solve, its scope,
and specific context. In cases where an asset is created for unspecified consumers, the
requirement of the asset tends to be based on the experience and decisions of the Asset
Producer. Define asset requirements while considering these points:
Conducting recurring problem analysis in advance helps to find the true requirements.
Collect requirements from many candidate consumers, if possible, to raise the
precision of the requirements.
It is often a good idea to build an architectural prototype or an archetype of the asset,
as a means of mitigating risks and getting early feedback, even when the asset is not
executable software.
2. Describe the asset: Leverage the Five Ws and One H (Who, What, Why, Where,
When, and How) to help write the specification in a manner that will answer Asset
Consumers questions. For example:
Who do I ask for help?
What points of variability are available for this asset?
Why must I use this asset?
Where must this asset be used?
When must this asset be used?
How can I use this asset?
The assets specification must include the following information:
Asset name and version
The problem that the asset is expected to solve
Description of the solution
Expected contexts:
Development context
Testing context
Runtime context
Business
Technical
Organizational
243
Requirement
Requirement
Solution
Produce
create
Solution
Consumer
Produce
create
consume
Consumer
RAS is generally realized in an .xml file and describes the specification of artifacts, such as
classification, solution, usage, and related assets. Also, it indicates the locations of its
artifacts in the solution section. All artifacts, including RAS, can be packaged as a single zip
file with the extension name, ras. In general, the structure of RAS is extremely simple;
however, a .ras file can become large and complicated. Regardless of the size and
complexity, using tools, such as RAM, shields us from having to know the structures and
specification in detail.
The important point is that RAS provides a standard for packaging assets so that they can be
supported in production, consumption, and management by a variety of tools.
244
In this task, the asset artifacts are created and harvested. The asset is created according to
the Asset Specification. Packaging the asset includes preparing documentation and
supporting material to provide easy comprehension of the asset. The assets metadata, such
as name, description, and anticipated context, is prepared. Finally, the asset is submitted to
the Repository.
In asset creation, variability analysis weighs more heavily than in comparison to building a
traditional software artifact. Rather than building a solution to be used in just a specific
instance, you look at how you can leverage the solution in multiple situations. Part of the
analysis looks at:
What must be common to the solution and asset across all uses of the asset?
What aspects of its use are unique to certain situations?
What assumptions can be made within the asset?
What information must be provided by the user of the asset? Is there a subset of this
information that can be calculated based on a combination of other values in the set of
assumptions?
245
Even in the case of an asset that is meant for reuse in a White box manner, it is worthwhile to
spend time thinking of how and where the asset can or must be adjustable. Preferably, we
want to limit the points of variability and provide the Asset Consumer with a manageable set
of points of variability. If we allow the set of points of variability to be unconstrained, we make
it much more difficult for the user of the asset to succeed.
Also, initial versions of the asset are unlikely to have a perfect set of points of variability
defined. In the first iteration or two, focus on building the asset and a best effort approach on
the points of variability. In later iterations, you can increase your focus in this area and
incorporate feedback from Asset Consumers as you harden the asset for wider reuse.
This task includes the following five steps:
1. Understand the considerations in creating assets: Several of the main considerations
are described in the description for this task that is provided earlier in this section.
Understanding the answers to these considerations is critical to building the proper asset.
Again, the goal is to not over-populate the Repository with assets just because we can.
The goal is to populate the Repository with the right set of assets that provide a solution to
a problem that the organization faces and that are easy for Asset Consumers to use.
Remember, reuse failure has a cost as well.
2. Create or harvest artifacts: An asset can have many artifacts. Certain artifacts are
created for the asset, whereas other artifacts can be harvested. In either case, the
artifacts must be prepared to the accepted level of context and dependencies.
In many cases, dependencies need to be removed or modified in the artifacts to meet the
expected context Asset Consumers will have. The artifacts are prepared in the Asset
Owners or Asset Producers workspace. The artifacts must be checked in to a software
configuration management system before associating the artifacts with the asset in the
Repository.
A project that produces a reusable asset needs to address many of the same concerns
addressed by Software Architecture, even for assets that are not executable software.
Therefore, architectural concerns for an asset can include:
The logical structure of components that make up the asset and the relationships to
other assets (for software, this is covered by the Design Model)
The physical files that make up the asset, and how will they be packaged (for software,
this is the Implementation Model). The nature of the target user experience, as well as
the target audience, might require that the asset is reorganized. This reorganization
can involve adjusting the way that the artifacts contained in the asset are organized or
can involve splitting the original asset into several assets.
The major technical decisions driving development of this asset
At a high level, the architecture of a reusable asset must include a description of its parts
(the asset artifacts), how those parts fit together, and how those parts can be customized
or tailored to fit into a specific context. For the reusable asset as a whole, you must
describe:
Within what environment or context you intend to apply the asset. This environment
includes the development context, deployment context, business domain context, and
so forth.
How the Asset Consumer must use the asset or an initial usage model for the asset
(view this as the use case view of the asset)
What asset artifacts make up the asset, what their inter-dependencies and the
relationships among these artifacts are, and what is the overall organization of these
artifacts (think of this as the logical view of the asset)
246
How are the physical files that make up the asset organized (think of this as the
implementation view of the asset)
Any mechanisms for customization of the asset (for example, variability points,
framework parameters, and so forth). What can be customized and what are the
guidelines for customizing?
Any relationships to other reusable assets
Any constraints or limitations
The relative priority of the asset use cases (to assist in iteration planning)
What, if any, standard representation format is being used to represent the asset
For each asset artifact, you must describe:
The type of the artifact, for example, document, model, script, template, plan, and so
forth
What part of the overall solution does the artifact provide
What customization options must exist for the artifact (the initial definition of the
variability points of the asset)
Whether the artifact already exists or if it needs to be developed
What relationships and dependencies the artifact has with other artifacts
What physical files contain the artifact
Tip: The degrees to which the Asset Consumer can access the artifacts of the asset can
also affect packaging. For example, a White box asset can require more packaging and
documentation than a Black box asset because of the increased visibility of the assets
internal information.
3. Package asset: Addressing documentation quality and ease of asset comprehension are
the purpose of the packaging assets. The extra investment for packaging assets is
justified if the effort in this area reduces the costs of reuse. The type of documentation that
is developed for an asset, and its level of detail, depends on the target audience and the
target user experience.
There are two categories of documentation when documenting an asset:
External asset documentation: The documentation available to Asset Consumers
when browsing an asset Repository or catalog where the asset is published. This
documentation can be considered marketing material.
Internal asset documentation: The documentation that an Asset Consumer uses to
install and use the asset. This documentation can be considered the assets users
guide.
The external documentation can be created by abstracting from the detailed internal asset
documentation. People might question the value in taking the time to develop distinct,
more abstract external documentation that is separate from the internal asset
documentation. However, providing a less detailed description of the asset allows Asset
Consumers to get a feel for the purpose and intent of the asset without having to wade
through all of the details.
4. Categorize asset: There are several terms describing this step, such as classifying the
asset or using taxonomies.
The goal here is to assign values to the asset metadata that benefit the discovery of the
asset. More formal structures, such as category schemas or taxonomies, are typically
used. However, other techniques, such as tagging assets with terms that are meaningful
Chapter 9. Produce reusable assets
247
to the Asset Consumer, are less structured techniques but are often more useful means of
searching and finding assets.
Assets must be categorized as they are created and submitted, but they certainly must be
permitted to be categorized at other points in the lifetime of the asset.
5. Submit asset: Submitting the asset to the Repository, the Asset Owner/Producer typically
fills in the asset metadata, associates the selected artifacts, and categorizes the asset
using category schemas and taxonomies in the Repository.
For certain repositories, the asset version is declared by the person submitting the asset.
When selecting the artifacts to be in the asset, typically the Asset Producer/Owner will
select the root directory where the artifacts live. Certain repositories will permit only one
root directory in the asset, other repositories can permit multiple root directories. When
selecting the artifacts for the asset, the Asset Owner/Producer will often need to identify a
label or other identifiable tag that is stored in the asset metadata and SCM to ensure the
proper retrieval of the asset artifacts for the Asset Consumer.
In a governed Repository, the asset must be submitted to review and approval processes.
Governing the asset submission, review, and approval processes adds to the quality and
usability of the assets in the Repository.
248
Tested
Documented
Packaged
Submitted to the Repository
249
An asset is described with metadata and has artifacts, each of which can be modified. The
nature of the modification, or update, dictates if a new asset version is required.
It is up to the organization to establish the asset versioning policies, such as when a new
asset version is required. For example, certain people might think that modifying a grammar
issue in the metadata does not require a new asset version. Whereas if the grammar issue is
in one of the artifacts, people might state that a new asset version is required.
A general guideline to follow is to categorize asset modifications as structural and
non-structural. Structural changes include modifying the following items:
Metadata:
Asset version
Asset relationship
Artifact reference
Artifact
File name, path, or content
In general, these kinds of changes require that a new asset version is created. Non-structural
changes are modifications to asset metadata other than those described and do not require a
new asset version.
This task includes the following four steps:
1. Identify or discover a problem with an asset: The organization needs to determine the
tolerance level for changes before requiring a new asset version. When the new version is
created, then the asset review and approval activities take place.
250
251
252
Note: Because the sample asset to produce in this section is not a service and it cannot be
published to a service registry, such as WebSphere Service Registry and Repository, we
will not cover the Publish or Deploy Asset task in this chapter for the ZYX Electronics
case study. It will be covered in Part 3, Service Assets in an SOA on page 333 of this
book when we talk about producing services.
253
happening on the browser, but in reality, the server is executing the code and DWR is
moving the data backwards and forwards.
Open source build systems in Java:
Maven: Maven3 is a Java project management and project comprehension tool. Maven
is based on the concept of a project object model (POM) in that all of the artifacts
produced by Maven are a result of consulting a well defined model for your project.
Builds, documentation, source metrics, and source cross-references are all controlled
by your POM. To see the full list of Mavens features, go to:
http://maven.apache.org
Ant4: Ant is a Java-based build tool.
Open source caching solutions in Java:
OSCache: OSCache5 is a widely used, high performance J2EE caching framework. In
addition to its servlet-specific features, OSCache can be used as a generic caching
solution for any Java application.
Open source charting and reporting tools in Java:
JFreeChart: JFreeChart6 is a free Java class library for generating charts.
Open source integrated development environments (IDEs) in Java:
Eclipse: Eclipse7 is a type of universal tool platform. Eclipse is an open extensible IDE
for anything and nothing in particular.
NetBeans8: NetBeans is a full-featured integrated environment for Java developers.
JEdit: JEdit9 is a mature and well designed programmers text editor that has been in
development for over five years.
Open source persistent frameworks in Java:
Hibernate: Hibernate10 is a powerful, ultra-high performance object/relational
persistence and query service for Java. Hibernate lets you develop persistent objects
following common Java idioms, including association, inheritance, polymorphism,
composition, and the Java collections framework. Extremely fine-grained, richly typed
object models are possible. The Hibernate Query Language, designed as a minimal
object-oriented extension to SQL, provides an elegant bridge between the object and
relational worlds. Hibernate is now the most popular Object Relational Mapping (ORM)
solution for Java.
Open source testing tools in Java:
JUnit: JUnit11 is a regression testing framework written by Erich Gamma and Kent
Beck. It is used by the developer who implements unit tests in Java.
Open source J2EE/Web frameworks in Java:
Struts: The core of the Struts12 framework is a flexible control layer based on standard
technologies, such as Java Servlets, JavaBeans, ResourceBundles, and XML, as
well as various Jakarta Commons packages. Struts encourages application
3
254
13
14
15
16
17
18
19
255
In fact, during the meeting, there were several discussions between Java developers from
different projects talking about incompatibilities between framework versions. Due to the
framework incompatibility, the developers were uncertain whether the resulting applications
will be compatible.
The COBOL and C++ frameworks were only used by a few teams and all team members
were using the same versions. But the meeting helped Duncan to discover that these teams
were using a common directory in one of the ZYX Electronics servers to share these
frameworks. However, no policy was defined for reusing them, and they were not using any
Software Configuration Management System to manage different versions of the frameworks.
In addition, Chris E. Oshman, the Chief Executive Officer at ZYX Electronics, had recently
read an article published in the press about legal issues of using open source and he wanted
to know how this was managed in his company. Refer to Open Source, Open Legal Issues
from New York Law Journal, January 2007, at:
http://www.dlapiper.com/files/Publication/97b92444-d924-4820-a3c0-66f0073ffc21/Pre
sentation/PublicationAttachment/220248cd-da82-4c8b-89d2-6cf0783c8396/NYLJ_Radcliff
e_Nelson_Article_Jan07.pdf
Chris was very worried after discovering that there was not a policy in place to manage the
licensing terms of these open source frameworks. Moving forward, Duncan met with the
Risk, Security, Audit, and Compliance Department to implement a mechanism to manage
the use and restrictions of open source frameworks within ZYX Electronics.
Duncan analyzed the list of frameworks already used and thought that it might be a good idea
to start uploading these open source frameworks into the Rational Asset Manager
Repository. Publishing these frameworks as assets into Asset Manager provided a number of
benefits, including:
Developers had a central place to look for all open source assets that were allowed to be
used within their organization.
Versioning of frameworks was managed and versioning lowered the incompatibility risk.
Duncan was now able to track which teams were using which assets.
Support for the definition and implementation of an approval process for all of the open
source assets used within the ZYX Electronics organization (including the Risk, Security,
Audit, and Compliance Department in this review process).
Figure 9-11 on page 257 shows all roles that benefit from reusing open source frameworks
and the relationships to open source frameworks.
256
Figure 9-11 Roles that will use open source framework assets in ZYX Electronics
The next step for Duncan was to develop the asset specification for this asset type, which we
will see in the next section.
257
redistribution without having to pay the original author20. These licenses can have additional
restrictions, such as a requirement to preserve the name of the authors and the copyright
statement within the code.
Note: The Open Source Initiative (OSI) is a non-profit corporation formed to educate
individuals about and advocate for the benefits of open source and to build bridges among
various constituencies in the open source community. This corporation has approved a set
of open source licenses that comply with the Open Source Definition (see
http://www.opensource.org/licenses/alphabetical for a complete list of open source
licenses approved by the Open Source Initiative).
So although the initial configuration allowed ZYX Electronics to manage open source
frameworks, the Framework asset type did not include any information about the license
terms and conditions needed to use the asset. As a result, Deon and Duncan had to modify
the initial Framework asset type definition to:
Include additional constraints to verify automatically the content of the asset.
Create a specific asset review process to include the Risk, Security, Audit, and
Compliance Department in the review and approval process of open source frameworks.
They also included the following additional metadata information in the Framework asset
type:
New artifact constraint to include a LEGAL TERMS&CONDITIONS label to describe the
specific terms and conditions to use the open source framework. Because the Framework
asset type was also used to manage other frameworks that are not open source, this
constraint is optional.
New category constraint called Open source license name specific to this asset type to
classify the open source framework. This category must include the list of open source
licenses approved by the Open Source Initiative (OSI) that are listed at this Web site:
http://www.opensource.org/licenses/alphabetical
Because the Framework asset type was also used to manage other frameworks that are
not open source, this constraint is also optional.
A new category constraint called Technology_Software specific to this asset type and to
the Component asset type to define the technology where this framework must be used.
This category can have following values: J2EE, COBOL, C++, and Others.
A new attribute called License Expiration Date to define the expiration date, if it exists, of
the open source framework licenses. This attribute is optional.
A new attribute called Specific Restrictions to capture additional information about
restrictions that can apply to use the asset. This attribute is optional.
All component asset types that were using an open source component must include a
relationship named Uses open source framework with the Framework asset type that
represents the open source framework.
All open source framework assets were planned for Black box reuse: although the source
code is available, the assets are delivered and used as binaries (libraries and executables).
To include this additional metadata to the Framework asset type, Deon logged in as the
Repository Administrator and used the Administration tab to go to the asset type definition.
When in the Administration section, he modified the asset type definition to include these
20
258
updates. For detailed information about how to modify an asset type configuration, go to 8.2,
Repository configuration for ZYX Electronics on page 214.
To implement the review process for the open source frameworks, Deon and Duncan had to
create a new review process to include the Risk, Security, Audit, and Compliance
Department. This review process must only be applied to Framework asset types with
Framework Type equal to Open source. Chapter 11, Manage reusable assets on page 303
describes how ZYX Electronics created this special review process and assigned it only to
open source frameworks (not to other types of frameworks).
According to the information gathered from developers, one of the assets most often used by
ZYX Electronics projects was the Spring J2EE framework. Based on this fact, Deon decided
to develop the Asset Specification for the Spring open source framework as an example to
offer to users.
Table 9-1describes the ZYX Electronics asset specification content for the Spring J2EE open
source framework.
Table 9-1 Asset Specification for Spring open source framework
Asset Specification
Value
Name
Spring Framework
Version
Description of problem
Description of solution
259
Asset Specification
Value
Expected contexts:
Development context
Testing context
N/A
Runtime context
All component asset types that use the Spring open source
component must include a relationship named Uses open
source framework with it.
Category schemas
Custom attributes
260
Expected Asset
Consumer skills
Estimated asset
development effort
Estimated Asset
Consumer benefits
This Asset Specification was used as an input for the asset creation phase as we will see in
next section.
261
262
2. To include the required artifacts associated to the Spring framework asset, Al selected the
Attach tab and noticed that there was an information message warning about the
constraints associated to the open source frameworks, as shown in Figure 9-13.
263
3. As shown in Figure 9-14, based on the Asset Specification information of Table 9-1 on
page 259 and the asset type constraints, Al attached the following artifacts:
A word document describing how to use the Spring Framework
A license.txt with a Legal Terms&Conditions label to describe the specific terms and
conditions to use the open source framework
A zip file containing the framework content (both the source and executables)
4. To categorize and classify the Spring framework asset, Al selected the Categorize tab
and entered the following information as Figure 9-15 on page 265 shows, based on the
Asset Specification information of Table 9-1 on page 259. To specify each category
classification, Al had to select the values for each category in the left and then click Add to
add each value to the Repository):
Framework Type: Open source
Technology Hardware: Windows
Technology Hardware: Linux
Technology Hardware: UNIX
Open Source License Name: Apache License, 2.0
Technology_Software: J2EE
264
1. To associate the Spring framework asset with other assets that already exist in the
Rational Asset Manager, Al selected the Associate tab. However, the Spring framework
was the first asset to be loaded into the Repository so there were no component assets
using this framework, so he left this section empty, as Figure 9-16 shows.
2. To finish the asset submission and to verify that all Spring constraints were correctly
introduced as Figure 9-17 on page 266 shows, Al selected the Confirm tab and clicked
Submit for Review. If any of the restrictions for the Framework asset type had not been
entered correctly, this Confirm section displays in red the constraints that were not met for
this asset type.
Al also might have selected other options instead of submitting the asset for review:
Save as Draft: This option saves the modifications made to the asset, but the asset
remains in the draft state.
265
Submit As Is: This option submits the asset directly to the Approved state, but it still needs
to be reviewed by the Administrator if the review process was configured for an asset to
need administration approval.
As shown in Figure 9-18 on page 267, Rational Asset Manager displayed a confirmation to Al
displaying the different options available to continue working with the asset (Subscribe To
Asset, E-mail Asset, and Forums).
266
By default, when Al submitted the asset, the Repository listed him as the Asset Owner. Later
on, if necessary, he can change this Asset Owner to someone else. As Asset Owner, he
automatically is given e-mail subscriptions to the asset and will be notified when any user
downloads the asset, updates the assets metadata or content, or discusses the asset.
In Chapter 10, Consume reusable assets on page 281, we will talk in detail about these
additional available options and how ZYX Electronics used them for consuming and
managing assets.
The initial Repository configuration had associated a default review process for all of the
assets submitted to the Implementation community. Therefore, the Spring asset automatically
went to the Review state. The Project Managers user group was responsible for reviewing the
asset.
In 9.2.4, Create asset on page 245, you saw how ZYX Electronics used this Rational Asset
Manager default review process to implement a generic workflow to review all asset types
stored in the Implementation community.
Important: As discussed earlier, an issue with the default review process was that the
Risk, Security, Audit, and Compliance Department was not involved. In Chapter 11,
Manage reusable assets on page 303, you will see how ZYX Electronics customized this
default review process with Rational ClearQuest to create a special review process to
manage license issues and applied it only to Framework asset types with Framework Type
value equal to Open source.
Rational Asset Manager stores the artifacts and metadata associated to the Spring open
source framework using the Reusable Asset Specification (RAS) structure. Example 9-1 on
267
page 268 is a copy of the manifest file created by Rational Asset Manager for the Spring
asset.
Important: This manifest file is shown here to provide additional detail and insight into how
Rational Asset Manager manages information related to assets. In the typical usage of an
asset, you will not need to delve into this level of detail.
Example 9-1 Manifest file for Spring open source framework
268
<nodeDescriptor
href="http://localhost:9083/com.ibm.ram.repository.web/classif/frameworktype.xmi#o
pensource"/>
<classificationSchema
href="http://localhost:9083/com.ibm.ram.repository.web/classif/frameworktype.xmi#/
"/>
</descriptorGroup>
<descriptorGroup name="Open Source License Name">
<nodeDescriptor
href="http://localhost:9083/com.ibm.ram.repository.web/classif/opensourcelicensena
me.xmi#apachelicense20"/>
<classificationSchema
href="http://localhost:9083/com.ibm.ram.repository.web/classif/opensourcelicensena
me.xmi#/"/>
</descriptorGroup>
<descriptorGroup name="Technology Hardware">
<nodeDescriptor
href="http://localhost:9083/com.ibm.ram.repository.web/classif/technologyhardware.
xmi#windows"/>
<nodeDescriptor
href="http://localhost:9083/com.ibm.ram.repository.web/classif/technologyhardware.
xmi#unix"/>
<nodeDescriptor
href="http://localhost:9083/com.ibm.ram.repository.web/classif/technologyhardware.
xmi#linux"/>
<classificationSchema
href="http://localhost:9083/com.ibm.ram.repository.web/classif/technologyhardware.
xmi#/"/>
</descriptorGroup>
<descriptorGroup name="Technology Software">
<nodeDescriptor
href="http://localhost:9083/com.ibm.ram.repository.web/classif/technologysoftware.
xmi#j2ee"/>
<classificationSchema
href="http://localhost:9083/com.ibm.ram.repository.web/classif/technologysoftware.
xmi#/"/>
</descriptorGroup>
</classification>
<solution>
<artifact name="How to use Spring Framework.doc" type="application/msword">
<reference><value>How to use Spring Framework.doc</value></reference>
</artifact>
<artifact name="spring-framework-2.0.6.zip" type="multipart/x-zip">
<reference><value>spring-framework-2.0.6.zip</value></reference>
</artifact>
<artifact name="license.txt" type="text/plain">
<reference><value>license.txt</value></reference>
<artifactType type="Legal terms&Conditions"/>
</artifact>
</solution>
<description><value><p style="margin: 0px;">Spring Asset
Description .... <br></value></description>
</defaultprofile:Asset>
269
Deon had already configured that all of the assets belonging to the Implementation
community must go through a default review process and that users included in the Project
Managers user group must be the reviewers for these assets.
Patricia Moon, the Project Manager, logged in to the Rational Asset Manager Web Interface
and selected the My Asset Manager tab to check for assets pending for review. The section
Assets to Review showed the Spring asset, as shown in Figure 9-20 on page 271.
270
So, Patricia clicked the Spring Framework asset and selected the Review tab. As shown in
Figure 9-21, the Spring asset was still in the Review state.
To start the review process, Patricia clicked Claim Review, added comments to the review,
and clicked Accept to finish the review process as shown in Figure 9-22 on page 272.
271
After the Spring asset was approved by Patricia (who was the only reviewer assigned to
approve the asset), it went to the Approved state, and it was also available for the other
Rational Asset Manager users.
In Chapter 11, Manage reusable assets on page 303, you will see how ZYX Electronics
customized this default review process with Rational ClearQuest and applied it only to the
open source framework assets to involve the Risk, Security, Audit, and Compliance
Department in their review.
272
This is a summary of the Asset Version Policy document that Duncan wrote and sent to all
Rational Asset Manager and Rational ClearCase users to define and clarify the policy that
ZYX Electronics users must follow to manage versions of assets and the individual artifacts
of assets.
Rational ClearCase
Spring.jar v2
license.txt v1.9
license.txt v1.9
Additional metadata =
Figure 9-23 Rational Asset Manager and Rational ClearCase versions for ZYX Electronics
When you submit a new asset to the Rational Asset Manager Repository, you have to assign
a version to the asset, because the version is a mandatory field.
But when the asset content is modified, you must follow these rules to determine whether you
need to create a new asset version. Rational Asset Manager will not force you to create a
new version when you change asset content:
Create a new asset version when:
A few days after submitting the 2.0.6 Spring asset version to the Repository, Al received an
e-mail from the official Spring Web site indicating that a new version of the Spring framework
Chapter 9. Produce reusable assets
273
was available. Because he was the Asset Owner and responsible for its maintenance, he
decided to update this information into Rational Asset Manager. He reviewed the changelog
file describing what was new in the new Spring version. There was a change in the spring.jar
file, which consisted of the removal of the RemoteInvocationUtilsTests class. Based on this
information, he decided to update the asset in Rational Asset Manager and create a new
version of the asset.
To create a new asset version and update its content:
1. Al logged into Rational Asset Manager using the Web interface. Al selected the My Asset
Manager tab to find the asset version that he had previously submitted into the
Repository. When located, he clicked Spring Framework (Version 2.0.6) to check its
content as shown in Figure 9-24.
2. Because Al was the Asset Owner, he had permissions to create a new asset version. To
modify its content, he clicked Create new version of the Asset Detail Tools section as
shown in Figure 9-25 on page 275.
274
3. Because there was a change in one of the asset artifacts, Al had to change the asset
version, so he updated the Version field to 2.1 in the Describe tab as shown in
Figure 9-26. He also included a comment in the Description field to reflect the change
that he introduced.
Figure 9-26 Create a new version for the Spring Framework asset
275
4. To load the new version of the spring.jar file, Al clicked the Attach tab and removed the old
version of the spring.zip file and replaced it with the new version as shown in Figure 9-27.
There were not any changes in the word document describing how to use the framework
nor in the license.txt file describing the licensing terms and conditions to use this asset.
5. Because no additional changes were needed, Al just clicked Confirm to save the
modifications to the new asset version and submit it for review.
6. To verify that the new asset version was submitted correctly to the Repository, Al went to
the My Asset Manager tab to check that there was a new version for the Spring
Framework as shown in Figure 9-28.
As we can see in Figure 9-28, the new version 2.1 was submitted to the Repository but was
still in the Review state. The process to approve the new version was exactly the same
276
process that Patricia Moon, the Project Manager, followed to approve the first version of the
asset (See details in 9.2.5, Review and test asset on page 248).
The Unique ID, which is an internal field used by Rational Asset Manager to identify each
asset, remains that same across asset versions.
If the modification that Al wanted to make to the asset had not needed to create a new
version according the rules specified by Deon in the Asset Version Policy document, Al might
have used the Modify link instead of Create new version as shown in Figure 9-29.
7. After the modification was made, Al had to confirm the changes using Update, write
comments explaining the change made to the asset, and then submit the asset for review.
If Al had wanted to create another asset with similar information to the Spring asset, he might
have reused the content of this asset and clicked the Duplicate link as shown in Figure 9-30
on page 278.
277
Rational Asset Manager will create a new asset with same content of the Spring asset but will
use a new Unique ID. The asset must be renamed and then updated according to the new
asset specification.
Looking at the functionality provided by the Duplicate link, Al thought that it might be a good
idea to propose creating template assets that can be reused later by Asset Producers as
shown in Figure 9-31 on page 279.
278
Asset Template
Duplicate
New Asset
Draft Asset
Save as Draft
Modify
Artifact templates
Asset Artifacts
Attach
Create new content
based on the templates
Submit
Final Asset
These template assets contain detailed descriptions of what was expected of any new asset
of this type (templates for Microsoft Word documents, models, and so forth) for the Asset
Producer to use as a base, as well as providing default settings for many fields within the
asset. Asset Producers can reuse these asset templates and duplicate their content to make
a copy for their new assets. With this approach, Asset Producers can review the detailed
description with the instructions of how to create the asset, download the artifact (templates
of documents), give the asset a new name, and save it as a draft until they finished creating
the asset artifacts and filling out the asset fields and relationships as necessary. When
complete, the Asset Producer submits the new asset.
279
280
10
Chapter 10.
281
10.1 Introduction
In this chapter, we look at the asset usage life cycle, that is, the consumption of assets. As
shown in Figure 10-1, it is important to remember that this is a cycle. Consumption of assets
happens throughout a project, requests for enhancements and defects will be recorded, and
quite likely, new assets will be identified. This cycle occurs many times both within and across
projects.
Also, we need to remember that there is a connection between the manufacturing cycle and
the usage cycle. This interaction is a key aspect to the success of any asset reuse program.
The Asset Consumer team needs to ensure that they are communicating with the production
team. As part of this communication, the Asset Consumer team needs to keep the production
team informed regarding any consumability or quality issues with the asset. In addition, the
consumers might modify an asset as part of their effort and will find themselves making the
updated asset available as a new asset. Last, but certainly not least, the Asset Consumers
need to alert the Asset Producers to opportunities or needs for new assets as shown in
Figure 10-2 on page 283.
282
283
on the assets. There are many roles from the enterprise which can perform the role of an
Asset Consumer, for example: Manager, Analyst, Architect, Developer, Tester, and so
forth.
This role mainly performs the following tasks:
Search Asset
Use Asset
Provide Asset Feedback
Subscriber: A Subscriber is interested in the activities related to an asset or a specific
search in the Repository. The Subscriber registers interest in the Asset Repository.
Examples of events related to an asset include change in state, submitted rating,
downloads, asset update, and other events. The Subscriber can be notified via e-mail or
Really Simple Syndication (RSS) feeds.
This role mainly performs the Search Asset task.
In this task, the Asset Consumer searches, browses, evaluates, and accepts an asset. This
task is the first step of consuming.
As we make asset reuse a part of the business, it is important that Asset Consumers are able
to successfully find the assets that they need and can use in a timely fashion. This highlights
the fact that not only do we need high quality, well documented and consumable assets, we
also need to make sure that they are stored in a logical manner and can be accessed via
search mechanisms. These search mechanisms can include tagging, keyword search, or
schema navigation. Ideally, we want the search mechanisms to be quick and easy to use.
284
Also, remember that when an asset is produced, there is often a connection to related assets.
When looking for assets to use, the Asset Consumer will take advantage of these
relationships to find other worthwhile and beneficial assets.
This task includes the following four steps:
1. Search for asset: This step is where we search for an asset in the Repository. As the
volume of assets in the Repository grows, we will need to ensure that we are as specific
as possible in our search. Just as it can be discouraging to perform a search and not find
any assets, it can be discouraging to search and find too many assets.
2. Browse asset: This is often an informal step. Based on the information provided in the
search results from the Repository, we make decisions regarding the suitability of an asset
for reuse. Several of the assets will be deemed as not being a good fit and other assets
will be considered fit candidates and therefore will be used as the input into the next step.
3. Evaluate asset: Perform a fit analysis to see if the asset will work or fit in the required
context. This analysis can involve applying the asset into a temporary location and
validating its compliance with your requirements, including testing out variability point
binding and customization ideas.
This step generally implies a more formal style of assessing the applicability of an asset.
There are several key perspectives to evaluate:
Evaluate the assets business fit:
Determine the reuse cost avoidance by using the asset: Another way of saying
this is to determine the potential cost savings to the business by using this asset. To
do this, you must understand the capabilities that the asset provides and what the
cost is for your organization to develop it.
Determine the payoff threshold by using the asset: How many uses will it take
to pay off the costs of purchasing and maintaining the asset?
Determine if the assets terms and licensing fit with your business model: Will
the asset be used in domestic and international locations? Does the asset need to
be distributed to multiple servers?
Identify who owns the task of maintaining the asset: What are the maintenance
support agreements? Will the asset authors provide support? If it is a White box
asset, can your organization maintain the asset?
Determine if all stakeholders will accept the use of the asset: Can your
organization overcome the not invented here mentality? Is the asset viewed as a
threat to any groups or individuals within the organization?
Determine if the asset will be used and accepted on multiple projects: Is there
sufficient need for this asset in other projects? Can the costs of reusing this asset
be amortized to other projects? Understanding the assets capabilities helps in
determining if the asset is a candidate for reuse on other projects within the
organization.
Determine if the use of the asset will fit into your organizations process:
Does this asset require new roles and tasks in the process to develop with it and
support it? Is your organizations process maturity level sufficient to incorporate the
roles and tasks for reuse? Usage information for the asset aids in the evaluation of
the asset fitting into the process, as well as the roles required to work with the
asset.
285
Make sure that tasks and time have been allocated to use and maintain the
asset: Will the assets stakeholders (architects, developers, and so on) be given
sufficient time to comprehend, use, and defend the asset?
Determine functional completeness: Does the asset do what it says and do what
you need?
Evaluate reliability: Exercise and test the asset to determine if the asset will fit
your contexts.
Evaluate error handling: Will the error handling fit into the way that your
organizations software handles errors?
Evaluate cohesion and coupling properties: How many dependencies does the
asset have? What technical assumptions does the asset make? Is the asset
organized along reasonable, functional boundaries?
Evaluate comments from other users: What has been the experience of other
people using the asset?
Understand the level of effort invested in the asset: What reuse metrics come
with the asset? How many person labor months and years are invested in the
asset?
4. Accept asset: This acceptance defines a technical acceptance and does not override the
necessary managerial acceptance needed, if any. The Asset Consumer might take notes
about recommendations for customizing the asset for the required context. This ensures
that what was learned while performing the fit analysis is not forgotten and reduces
duplicate effort between determining if the asset will work and making it work.
286
In this task, the Asset Consumer retrieves, uses, and sometimes extends an asset. Using an
asset is the main purpose of creating an asset.
There are four major styles of reuse:
Black box
Gray box
White box
Glass box
The consumer expects to have an asset that is well built, documented, and supported. From
a producers point of view, there is an expectation that the Asset Consumer will provide
feedback about the asset, share information regarding possible enhancements and defects,
and possibly enhance or create supporting and related artifacts. As discussed in the
introduction to this chapter, there is a strong relationship between these roles, and for a
successful reuse program to emerge, this relationship must be supported.
This task includes the following two steps:
1. Retrieve asset: Retrieve an asset from a Repository and bring the asset into the
development environment.
2. Extend asset: Certain assets can be extended through variability points, which are
locations in an asset or a contained artifact to be customized or extended. It is unrealistic
to expect each asset that has been retrieved to be a 100% fit. In these cases, based on
the fit analysis, the team will need to decide whether the extension of the asset is worth
the effort. Again, a well-engineered asset that supports extension through variability points
and proper documentation can be make this a low-risk situation.
287
288
Note: When sending a survey to the Asset Consumer, there are sample questions to
consider, such as:
How long did it take to use the asset?
What amount of time was saved by using the asset?
What did not go well with using the asset?
On what asset discussion forums have you participated?
On average, how much time do you spend searching for each asset?
Can you estimate what percentage of searches results in not finding what you want?
What assets do you need in the Repository, but you cannot find?
What kinds of assets do you not need?
When you have submitted defects, have you received a timely response on the defect?
How do you generally search for assets: keywords, search filters, custom tags, or a
combination?
Have you subscribed to any assets or searches? If so, have you received notification of
events?
This task includes the following two steps:
1. Identify form of feedback: Select the type of feedback that meets your purpose.
2. Provide feedback: In general, the feedback must be captured in the Repository, where
you can track the relationship of the feedback to assets, Asset Consumers, feedback
providers, and so forth. If a problem or issue is submitted, these relationships are even
more important, because the Asset Owners, Producers, and other teams involved with
authoring the asset plan are notified of the problem and create plans for addressing the
issue.
289
290
291
Search assets using advanced search fields: Click the Advanced link and you will
see a new window, as shown in Figure 10-9, with additional options to allow you to
increase the specificity of your search.
Use as many fields as you want and in any combination as desired toward this goal of
a more focused search. After you type values in the fields, click Search. The search
query that you created by using the fields will be displayed.
You can also restrict the scope of your search to search within artifacts, remote assets
and, forums.
Search assets by tags: Tags are words or phrases that users create and assign to
assets (using the Tag field). You can find assets by using your own tags or tags that
are created by other users. Tags are displayed in confined areas that are known as tag
292
clouds. You can use tags to assign meaningful labels that are more unique and
personally relevant than the predefined categories or types that an Administrator
creates for you. You can view all of the tags and information about how many assets
are using those tags across the Repository in the tag cloud, which is located on the
Search for Assets page in the Tags section as Figure 10-10 shows.
If in Figure 10-10, you click the spring tag, you automatically see a list of all assets
included in the Rational Asset Manager Repository that have been assigned the
Spring tag.
You can view the number of assets in the Repository that share a tag by clicking the
Show tag counts link.
Search assets with filters: Search filters help limit your asset search by using a
combination of community, asset type, state, categories or subcategories, or rating.
You can view filters on the Search for Assets page in the sidebar Filter your search
as shown in Figure 10-11 on page 294.
293
The filters that are displayed change dynamically depending on which assets are
displayed in the search results. As you filter your search, you can apply and remove
any combination of filters. The assets listed in the search results will appear or
disappear depending on the filters that you choose.
For example, if you look only for the assets belonging to the Implementation
community, you click the Implementation link that is under the Community section.
Then, Rational Asset Manager will automatically show you a filter with all of the assets
belonging to the Implementation community as shown in Figure 10-12.
294
As you can see Figure 10-12 on page 294, the Filter your search section has
changed automatically and it has been adjusted dynamically to reflect the filters that
can be applied to the assets displayed in the search results (asset types, categories
assigned, and states).
You click X to remove the filters in any order.
You can also subscribe to your favorite queries using the Subscriptions section of the
Rational Asset Manager Web interface as shown in Figure 10-13.
Search feed: This option creates an RSS (Really Simple Syndication) subscription to
the search query. RSS is a family of Web feed formats used to publish frequently
updated content, such as blog entries, news headlines, or podcasts. RSS makes it
possible for people to keep up with their favorite Web sites in an automated manner
that is easier than checking the Web sites manually. RSS content can be read using
software called a feed reader or an aggregator. The user subscribes to a feed by
entering the feeds link into the reader or by clicking an RSS icon in a browser that
initiates the subscription process. The reader checks the users subscribed feeds
regularly for new content, downloading any updates that it finds.
Subscribe to this search: You will receive an e-mail notification when any asset that
meets the search criteria that you have selected is changed or updated. You can
configure the name of this subscription and the frequency of the e-mails you will
receive (daily, weekly, or monthly).
Add search engine to browser: This option installs a search engine to your browser
so that you can search within the asset Repository from any open browser window
using browser shortcuts.
You can also add the bookmark of the Web page displaying the search query results
that you have selected using your Internet browser menu and come back to it later.
Tip: You can also make subscriptions (RSS feeds and e-mail notifications) to individual
assets to receive notifications when the individual asset is changed or updated.
295
2. The Search Results list showed that there were two versions of the Spring Framework
already loaded into the Rational Asset Manager Repository as shown in Figure 10-14.
Figure 10-14 Search Results list for the Spring open source framework
3. Because Deb wanted to be informed of changes in the Spring framework, she clicked the
Subscribe to this search link in the Subscriptions section to receive an e-mail notification
when the Spring asset was changed or updated.
4. Deb was reviewing both versions of the Spring Framework plug-in, navigating through the
General Details and Content tabs. Based on this initial review, she decided to use the
Spring Framework Version 2.1 asset to build her Java component. To download it, she
clicked the Spring Framework Version 2.1 link, and clicked Download as shown in
Figure 10-15 on page 297.
296
5. Rational Asset Manager processed her request and checked if Deb had permissions to
download the asset. Because she was a developer with consumer permissions in the
Implementation community, she was authorized to download the asset to her local disk.
Note: If another user without download permissions had wanted to download the asset,
the user must request access to the asset by clicking the Request permission button.
This request is then sent directly to the Community Administrator.
297
b. Al Aarkashan, the Asset Owner, saw that there was a new forum topic, checked it, and
modified the asset to fix the documentation problem. When he finished the
modification, he replied to the obsolete documentation reference topic saying that the
problem had already been solved as shown in Figure 10-17.
298
c. Because Deb was subscribed to the Spring search list, she automatically received an
e-mail when Al updated the documentation, and she went to Rational Asset Manager
to download the updates.
Note: Optionally, Forum Topics can be automatically synchronized with Rational
ClearQuest record types. Refer to Appendix A, Rational Asset Manager: Installation and
administration on page 637 for additional information.
When Deb finished building her code component, she submitted the new version to the
Rational Asset Manager Repository, and she created a Uses open source framework
relationship between this component and the Spring asset that she used to build it as shown
in Figure 10-18 and Figure 10-19 on page 300.
299
Establishing relationships between assets helps Rational Asset Manager users to analyze the
impact of changes in other assets. For example, if Al Aarkashan had wanted to update the
Repository with a new version of the Spring framework asset, he might have used the
relationships that developers established with this asset to know how many components
might be impacted by a change in this asset. To analyze this impact, he just had to go to
Rational Asset Manager to see the details of the Spring Framework version that he wanted to
change (for example, Spring Framework Version 2.1), and the Related Assets section of the
General tab shows all assets that had used this version of the framework to build their
applications as shown in Figure 10-20.
During the meeting that developers had with Deon to learn how to search for assets, Deon
told to them that he wanted to have their input (using the Ratings functionality of Rational
Asset Manager) to record which assets were most valuable for developers. So, Deb searched
for the Spring asset Version 2.1 that she used to build her Java component and selected the
Ratings tab to rate this asset. She clicked the Leave Feedback link and left her feedback as
shown in Figure 10-21 on page 301.
300
This feedback can be used later by Deon to generate metrics, as well as by other users of the
asset as they determine whether they will use the asset. We look further into the rating,
metrics, and evaluation topics in Chapter 15, Managing service assets on page 425.
301
302
11
Chapter 11.
303
11.1 Introduction
As we learn how asset management plays a role in our asset reuse initiative, we need to keep
the following definitions in mind:
Governance: The ongoing, recursive process of establishing decision rights (chains of
responsibility, authority, and communication), measurements, policies, standards, and
control mechanisms to enable people to carry out their roles and responsibilities
Governance Solution: A work product of Governance; a set of governance decisions
applicable to a specific context and scope of activities
Management: The activities of goal setting, decision making, oversight, enablement, and
guidance that implement a governance solution in pursuit of a set of defined objectives
In this chapter, we focus on the management aspect of assets and reuse. As per the previous
definition, we want to make sure that goals have been set, decision making occurs,
enablement is in place, and there is oversight in place - all while reaching the objectives of the
organization.
Also, as shown in Figure 11-1, we see that management is not an event that occurs in
isolation. Management plays a key role in supporting asset production and asset
consumption.
Without having asset management in place, the integration, steps, and roles as found in
Figure 11-2 on page 305 likely fall into chaos.
304
305
306
5. Integration Administrator: This role is responsible for integrating the Repository with
development life cycle tools, such as Source Configuration Management (SCM) tools,
change management tools, and service registries.
This role mainly performs the Configure Repository task.
307
Assets can be used by an unspecified number of users in various contexts and environments.
Consequently, the review process needs to be able to take multiple perspectives and
requirements into account. For example, assets must be reviewed from the viewpoint of
reusability, such as:
The asset must be easy to use, customize, and apply to another context.
The asset must possess the characteristics of sound engineering: tight internal cohesion,
loose coupling with other assets, and sufficient capabilities.
The assets purpose and intent must be easy to understand.
Conducting fit analysis must be easy in order to be able to determine the assets match to
a particular context.
Several key perspectives to evaluate are (See 10.2.2, Search asset on page 284):
Assets business
Assets organizational fit
Assets process fit
Assets engineering fit
This task includes the following four steps:
1. Submit asset for review: The Asset Owner or Producer has completed their refinements
of the asset and now submits the asset to the review and approval process. The Asset
Owner or Producer might have suggestions of subject matter experts who can fill the role
of Reviewers.
2. Notify parties: The Repository must handle the activities of notifying the Reviewers of the
asset to be reviewed. However, in practice, the Asset Owner or the Review Board might
need to provide reminders.
3. Conduct review: There are many aspects of an asset that can be included as part of the
review, including:
Asset name: The proposed asset name is evaluated in regard to conveying the
purpose and use of the asset.
Classification: The classification aligns with the manner in which target Asset
Consumers will search for the asset.
308
Functional compliance: The asset goes through typical functional testing, executing
test cases and using testing tools to validate the asset.
Non-functional compliance: The asset goes through non-functional testing to verify the
assets performance, scalability, security, and so forth.
Packaging: Verify that the asset contains the necessary support material, making it
easy for the Asset Consumer to use. Also, support contact information is present and
accurate, and the support team is ready to support the asset.
Asset similarity: The asset is evaluated compared to other assets to determine if the
implementation overlaps or is similar to other assets in the Repository.
Subject matter expert: A fit for purpose evaluation is conducted, examining if the asset
fulfills the purpose properly and aligns with the Asset Specification.
When a Reviewer completes a review, they submit the review files (if any) and cast a vote.
4. Review board vote: If the Review Board is enabled, the members of the Review Board
cast their vote on approving or rejecting the asset. If the asset is rejected, it returns to an
early submission state, such as Draft; otherwise, it transitions to another state, such as
Approved.
An asset that is Approved is made visible to the anticipated Asset Consumer audience
through the Repository. An asset can transition to other states, as well, after it has been
approved. For example, if the asset is a service, it can be published to a service registry,
which can change the state to Published.
In this task, the asset is released to the Consumer, either in the scope of the Repository or in
another tool. The target for the released asset will depend on the asset type. For example, a
309
pattern asset or code component will be released within the asset Repository. In the case of a
service asset, it is likely that the asset will be published to a service registry and Repository.
This task includes the following three steps:
1. Select approved asset in Repository: If the asset Repository is enabled, the
Administrator selects the asset to be published.
2. Select the target registry or other Repository: If the asset Repository is enabled, the
Administrator selects the target registry of the runtime type and deployable asset or other
Repository.
3. Publish the assets contents to the target Repository: If the target Repository is
enabled, the Administrator publish the assets contents to the target Repository. If not, the
Administrator publishes the assets contents into the target (Consumer) environment.
After the publication, the Administrator must notify the Consumer of the publication.
In this task, the Administrator must keep the Repository well-classified and appropriately
accessible for the Consumer. The concept of this task can be applicable to the Administrator,
who has no Repository.
The two major steps of this task are access control for the asset and its classification. The
access control determines the control of the asset logistics while avoiding unauthorized
reuse, and the asset classification influences the visibility of the asset and helps to define the
metrics for the Reuse Strategy.
Chapter 8, Configure your Asset Repository on page 195 provided an overview of how ZYX
Electronics configured their asset Repository. If you recall from that discussion, a key concept
is that of a community. A community is a Repository structure that facilitates user interaction
with a group of related assets. Communities are formed by users, their roles, and permissions
and their assets and review processes.
310
After the stakeholders have agreed upon the category schemas, the category schemas
are loaded by the Repository or Community Administrator into the Repository.
2. Specify asset types: The Administrator specifies the asset types that will be supported by
the Repository. Recall that an asset is composed of one or more artifacts. We need to
analyze how these artifacts will group into assets, and as part of the effort, specify the
name of this asset type, provide a description, detail the artifacts that comprise the asset,
and define the relationships among the asset types. Again, the use of visualization can
help both define and then socialize the resulting set of asset types.
3. Specify communities and access control: The Administrator specifies communities and
access control for the assets.
4. Specify review process: The Administrator specifies and configures the review process
for assets.
5. Configure Repository users: The Administrator defines and configures Repository
users. The users can come from existing directory services, such as Lightweight Directory
Access Protocol (LDAP).
6. Configure Repository integrations: When appropriate, the Administrator must integrate
the Repository with various tools, such as SCM tools, change management tools, service
registries, and so forth, to provide a seamless interaction for the software development
workflows.
7. Configure system timers and notifications: The Administrator defines the policy for
scheduling the types of regular events, such as a publication to the target registry, asset
subscriptions, indexing, and so on. The Repository needs to be configured to provide a
balance of optimal performance and timely updates.
311
In this task, the Administrator removes an asset from the Repository. The typical situations
where this need arises are:
Asset usage levels: The asset is dormant, and it has few searches, few browses, few
downloads, little feedback, and so forth.
Funding termination: The sponsor changes or terminates funding support, perhaps due
to business prioritization.
Need for solution diminishes: The problem either goes away, or a new solution is
available, or the level of effort to maintain this asset becomes prohibitive.
There are three levels of removing an asset from a Repository. These levels include retiring
an asset, archiving an asset, and deleting an asset:
Retire asset
Archive asset
Delete asset
A case must be prepared to determine the level of removing the asset. Enough insight
must be collected to answer the question, Does the asset need to be retired, archived, or
deleted?
3. Obtain approval to remove: The Administrator obtains approvals from Managers and
other stakeholders to remove the asset.
4. Remove the asset: The Administrator removes the asset from the Repository according
to the appropriate level.
As discussed in Chapter 6, Value, impact, and return on investment on page 103, the
gathering and analyzing of asset metrics is a key activity as you decide where to make
investments.
In this task, the Administrator collects reports from various sources, such as:
Asset Consumers: Asset Consumer metrics generally include qualitative metrics, such
as reusability ratings (4 out of 5 stars) or text feedback in the form of comments and
discussions. Typically, these metrics are stored in the Repository.
Asset Owners, Producers, and Reviewers: Asset Owners, Producers, and Reviewers
tend to create asset-level metrics. These asset-level metrics include the anticipated level
of effort for an Asset Consumer to use the asset, the level of effort to create a given
version of an asset, and so forth. The metrics also include size, such as the number of
bytes, lines of code, or number of components. Typically, these metrics are stored with the
asset in the Repository.
Repository: Repository metrics are largely quantitative. These metrics the number of
downloads for a given asset version, the number of searches and kinds of searches, and
the number of browses from searches, as well as information about which Asset
Consumers conducted certain downloads. Other metrics can be Repository activity over a
period of time, such as the number of Repository accesses, asset submissions, and so
313
forth over a certain period of time. The Repository can also track the number of problems
or defects associated with an asset.
Derived for Managers: In general, repositories are not tracking the cost side of asset
development. This cost is typically tracked in project management and financial reporting
tools. Bringing together the metrics from Asset Consumers, Asset Owners, Producers,
Reviewers, and the Repository with costing metrics gives you a foundation for derived
metrics. Several of these metrics include project reuse percentage, project productivity
gains, and return on investment.
This task includes the following three steps:
1. Practitioners provide values: As described earlier, the Asset Owner, Reviewer, and
Consumer provide both qualitative and quantitative values for assets.
2. Repository and assets used: Managers, Administrators, Asset Owners, Reviewers, and
Consumers interact with the Repository and the assets, therefore, creating the basis for
generating reports.
3. Generate report: Reports can be generated graphically or textually. The metrics can be
exported from the Repository into reporting tools, or the Repository can render the reports.
Managers often require reports on a periodic basis, which generally means repositories
need a way to run reporting jobs and send them to the appropriate stakeholders.
Repositories must be integrated with portfolio and project management tools to aid in the
generation of derived metrics.
Prerequisites
Before starting the migration of existing assets, it is imperative that you have a good
understanding (and documentation) of the existing Repository, its user community, business
purpose, general structure and schema, size, and types of assets.
Considerations
Make sure that you:
Ensure that you have the right resources to define the migration strategy:
Do they have the authority to speak for the community, database owners, and so
forth?
What is their internal review and approval process for this migration? Who are the
ultimate owners and decision makers?
Is there an internal review process in place and documented for this community or
area?
314
Templates
Ensure that you have a:
Migration questionnaire to assist the teams in deciding on a migration strategy
High-level Migration Strategy document
High-level Communication Plan (which can be included in the Migration Strategy
document)
Deliverables
You need to produce a:
High-level Migration Strategy document
High-level Communication Plan
Prerequisites
You must have Asset Taxonomy documentation.
Considerations
The steps and considerations to remember during this task include:
Create a high-level Architectural Design document
If all assets are not being migrated:
Determine the criteria for migrating assets. Examples of criteria include:
Only include assets that have been used within a certain time frame (that is, two
months)
315
Determine how assets that are not being migrated will be handled:
Is there a notification process documented for assets that are not moving?
Templates
You must have an Asset Mapping spreadsheet.
Deliverables
Ensure that you produce a:
Completed Asset Mapping spreadsheet
Architectural Design document
Prerequisites
You need the completed Asset Mapping spreadsheet and Architectural Design document.
Considerations
Consider:
Will you migrate data manually or via automation using the provided Asset Manager APIs?
You need to define the resources and responsibilities for one or both options.
For batch upload, map existing metadata to asset metadata.
Determine if an adapter is required to handle additional existing storage types that are not
handled as part of the utility. Document the requirements and determine if adapters are
available from other sources that can be used as a starting point.
Define and document the batch migration process:
Selection criteria, time lines, roles, and responsibilities
Approval process
Funding and resources identified and in place
Communication plan to stakeholders that outlines the process and time line
Define initial or test case for initial batch load (including success criteria)
Testing process
Success criteria defined and documented
Define the phases for the migration with a batch utility following a successful pilot
316
Templates
Use a:
Communication plan
Detailed Migration plan
Deliverables
The deliverables need to be a:
Communication plan
Detailed Migration plan (including a test migration case scenario)
At this point, you must also consider whether it makes sense to first run a test migration
before proceeding with a full migration. Steps and considerations for these migrations
include:
Initial test case migration:
Test case migration is documented and resources are in place
Run test
Success criteria met
Document results and lessons learned
Deliverables:
Test plan
Full migration:
Lessons Learned from initial migration
Revisit Architecture Design Document (if required)
Revisit and revise Detailed Migration plan (if required)
For example, did the initial batch migration results require changes to your overall
migration plan as far as scope, rollout phases, timing, and so forth?
Communicate changes to constituents
Deliverables:
317
318
When a new asset is submitted into Rational Asset Manager and if it has been configured to
follow a customized Rational ClearQuest review process, it will automatically create a new
review process request in ClearQuest that will go to the first state configured in the Submit
action. At this point, the review process passes the control to Rational ClearQuest, so
reviewers must use the Rational ClearQuest interface to change the states of the review
process (represented on the right of Figure 11-12).
Figure 11-12 Synchronization of Rational Asset Manager and Rational ClearQuest states
319
When the Community Administrator configures the synchronization between both review
processes, the Community Administrator must map the approved and rejected states of the
review process in Rational Asset Manager and ClearQuest as shown in Table 11-1.
Table 11-1 Mapping of Rational Asset Manager and Rational ClearQuest states
State
Rational ClearQuest
Approved
Approve
Draft
Rejected
This way, when the Rational ClearQuest review process request reaches the Approved or
Rejected states, it will automatically move the asset state in Rational Asset Manager to the
corresponding state.
After Deon configured the integration between the Rational Asset Manager and the Rational
ClearQuest review processes following the previous guidelines, Al Aarkashan (the Architect
at ZYX Electronics) used the Ant open source framework to test whether the review process
just described had been configured correctly. Al checked the submission and approval
process in this manner:
1. Al submitted the Ant Framework (Version 1.7.0) to the Implementation community as a
Framework asset type with Framework Type category value equal to Open source and
submitted it for review.
2. Richard Compliton, the Director of the Risk, Security, Audit, and Compliance Department,
logged in to the Rational ClearQuest Web interface and verified that there was a new
review process request created to review the new Ant open source framework. The new
Ant open source framework was created automatically by Rational Asset Manager when
Al submitted the Ant Framework asset for review, as shown in Figure 11-13.
Figure 11-13 Rational ClearQuest query with Rational Asset Manager assets
3. So, Richard opened the Ant Framework Rational ClearQuest request to see the details as
Figure 11-14 on page 321 shows (Rational Asset Manager automatically synchronized the
Headline field with the asset name and the Description field with the URL to access the
asset details using the Rational Asset Manager Web interface).
320
4. Richard Compliton clicked the URL link in the Description Field to see the content of the
asset. Richard selected the Content tab to see the terms and conditions of the open
source framework that were included in the license.txt file as shown in Figure 11-15.
5. Richard opened the license.txt file from the Web interface to check the special terms and
conditions of the open source framework. Because Richard needed to have a more
detailed review of its content, he changed the state of the review process to Legal (using
the ClearQuest action change State LegalScanRequired and clicked Save) using the
Rational ClearQuest Web interface as shown in Figure 11-16 on page 322.
321
Figure 11-16 Changing the state of the Rational ClearQuest review process request to Legal
The state change moved the ClearQuest review process request to the Legal state as
shown in Figure 11-17. While the review process request was in this Legal state, no other
users can change the state. Only Richard Compliton has permissions to change the state
to Review Board state and continue with the review process.
322
If Al had wanted to know the review process state using Rational Asset Manager interface
(selecting the Review Process tab), Al can see that the Ant Framework was still in the
Review Board state. There is a special link to go to directly to Rational ClearQuest to see
the request details. The Review History Link shows that the Rational ClearQuest-driven
review process was still in progress as shown in Figure 11-18.
6. When Richard Compliton finished and accepted the review process of the special legal
terms and conditions of the open source license, Richard logs in to Rational ClearQuest
Web to complete the legal scan process and moved the review process request to the
ReviewBoard state (Change State Legal Scan Completed).
7. From this state, Patricia Moon, the project manager, who had permissions to move the
Rational ClearQuest request to other states, logs in to the Rational ClearQuest Web
interface. Patricia did not want developers to use this Ant Framework, because ZYX
Electronics had already developed an internal application to provide similar functionality,
so Patricia changed the state to Rejected (Change State Reject).
8. The configuration between Rational Asset Manager and Rational ClearQuest had been
set up so that the Rejected state of the Rational ClearQuest request was mapped to the
Rejected state of Rational Asset Manager. Therefore, the synchronization between both
tools automatically moved the state of the Ant Framework to the Draft state in Rational
Asset Manager. Figure 11-19 on page 324 shows how the states were synchronized
between both tools.
323
Figure 11-19 Synchronization of Rational Asset Manager and Rational ClearQuest states
In the ZYX Electronics example, because Patricia had rejected the review process and
made a transition in Rational ClearQuest to the Rejected state, this change was
automatically propagated to Rational Asset Manager moving the asset state to Draft.
324
If the Asset Owner and Administrators wanted to maintain the asset in the Repository but
have the asset available only to the Asset Owner or to Administrators and not the rest of the
users, they must ask the Repository Administrator to change the asset to the Retired state.
The Repository Administrator was the only role in Rational Asset Manager with permissions
to change any asset to this state. The content of the asset remains available in the Repository
to the Asset Owners or Administrators, but the content of the asset cannot be downloaded
unless the state was changed again to the Draft state. To move an asset to the Retired state,
Deon just had to log in as a Repository Administrator and select the Retire link that is
available in the Asset Detail Tools section as shown in Figure 11-21.
325
If the users wanted to permanently delete the asset from the Rational Asset Manager
Repository, they needed to ask the Repository Administrator or the Asset Owner, who are the
only roles with Delete permissions, to use the Delete link. After the asset is deleted, it is no
longer available in the Repository. To delete an asset, the Asset Owner just had to log in to
Rational Asset Manager and select the Delete link that is available in the Asset Detail Tools
Section as shown in Figure 11-22.
Administrator tab to have access to the global metrics available in the Repository Statistics
Section as shown in Figure 11-23.
Figure 11-23 represents the list of the reports that can be generated. Deon can select the
period of time to use as the basis for the report.
To generate the reports, Deon clicked the link for the report that he wanted and the report
was automatically generated. This is a list and examples of the reports Deon generated:
Repository Contents: This report is used to generate graphs and statistics about assets.
It shows the number of assets by community, type, and state as shown in Figure 11-24.
Figure 11-24 Report example showing the number of assets by type and state
Most of the asset types generated by Rational Asset Manager users were frameworks,
and all of the assets were already approved except one asset that was still pending
Chapter 11. Manage reusable assets
327
review. Other asset types generated by developers were code components that reused
the open source frameworks to build the code.
Important: This report is not affected by the selected date range, because it shows the
current distribution of assets in the Repository.
Asset Activity: This report is used to generate statistics about the number of times that
any asset in the Repository had been downloaded and subscribed to as shown in
Figure 11-25.
The latest Version 2.1 of the Spring Framework was the asset that was most used by the
developers, because it was the first in the list with the maximum number of downloads.
User Activity: This report is used to show how many licenses have been acquired by
each user as shown in Figure 11-26 on page 329.
328
Al Aarkashan, the architect responsible for loading all Java open source frameworks, was
the person most active in using Rational Asset Manager.
Search History: This report is used to show the most popular search strings used, listed
in order of popularity as shown in Figure 11-27.
Because all open source frameworks and code components were stored in the
Implementation community, the Community: Implementation search string was the
Chapter 11. Manage reusable assets
329
search pattern most often used by the Repository users (in order to get a list of all assets
belonging to that community). The Spring framework, which was the second most
common search in the list, was the open source framework most requested by
developers.
Activity Audit: This report is used to show how many times various actions had been
performed over a period of time as shown in Figure 11-28. Deon selected various actions
to generate the report and the starting and end dates for each audit.
The Spring Framework with 5 starts was one of the highest-rated assets by the Rational
Asset Manager users. Other open source frameworks with high ratings (5 stars) were the
Struts and Hibernate Java frameworks, and also the OpenCobol framework to compile
COBOL code.
So, Deon just had to copy and paste each one of the previous graphs into his presentation to
show his managers the usage of the Rational Asset Manager Repository during the last three
months.
Deon also exported and downloaded each report as a comma-separated value (CSV) text file
and included these files in the documentation to send for the meeting. Providing CSV files to
the management team allows them to create other reports and graphs driven by the audit
report data.
With all of this material and the feedback received from the users, Deon was able to make a
magnificent presentation and was congratulated by his managers for the great work.
330
331
Reduce the time necessary to reuse open source frameworks and components from
project to project, therefore, being capable of project estimates with greater accuracy.
And the Rational Asset Manager implementation was possible without modifying any
development processes already used in ZYX Electronics. The strategy followed to start
producing open source frameworks and code components as reusable assets helped other
departments to maintain their development processes and way of work, while starting to
integrate several of these reusable assets.
Benefits experienced by the developers (they were the main consumers of the produced
assets) were:
They reduced the time spent looking for information and new versions of open source
frameworks.
Several of the first reusable assets loaded into the Rational Asset Manager Repository
implemented tedious and marginal functions that they had implemented by themselves, so
they were happy to eliminate these tasks and use existing components instead.
Several of the new open source framework assets loaded into the Repository introduced
new technology new to them, so they had a change to use state-of-the-art technologies
that they might not have brought into the project on their own.
They had an easy way to look for the technical expert with deep knowledge of the asset
produced (they just had to look for the Asset Owner) in order to ask that person technical
questions about how to use it.
With the subscription mechanism of Rational Asset Manager, they were automatically
informed by e-mail when a new version of the asset was published into the Repository.
Nevertheless, these benefits were not possible without management funding support and the
commitment of ZYX Electronics directors, as well as developer support for the reuse of open
source frameworks and components.
Involving developers in this Reuse Strategy was to key to the successful deployment of a
central Repository. Their involvement also resulted in a configuration suited specifically to
their terminology and needs.
Thanks to benefits obtained reusing development assets and the management commitment
to software reuse, several new asset types were candidates to include in Rational Asset
Manager. Following the incremental adoption of reuse that ZYX Electronics had selected to
follow, the next step for the deployment of Rational Asset Manager at ZYX Electronics was to
include new service asset types and other WebSphere tools to help to transition to a
service-oriented architecture (SOA) approach, where service reuse was key. You will see this
progression in Part 3, Service Assets in an SOA on page 333 of this book.
332
Part 3
Part
Service Assets in an
SOA
In this part of the book, we look into the details of producing, consuming, and managing
services, which are a key form of reusable assets in a service-oriented architecture (SOA).
Part 1:
Introduction
Part 2:
Reusable Assets
Introduction to
Asset-Based
Development
Adopting
Asset-Based
Development
Process and
Tooling
Configuring
Asset
Management
Case Study
Overview
Produce,
Consume, and
Manage Assets
Part 3:
Services
Services as Assets
Produce, Consume,
and Manage Service
Assets
Appendixes
Rational Asset
Manager
Installation and
Administration
Process
Integration
Part 4:
Patterns
Patterns as Assets
Produce, Consume,
and Manage Pattern
Assets
333
334
12
Chapter 12.
335
336
We can also look at the relationship between Asset-Based Development and RUP/SOMA
from another perspective. As shown in Figure 12-2 on page 338, the Asset-Based
Development life cycle plays a role in each of the phases within RUP/SOMA, for example:
In the Describe the Current Business phase, you first determine if an existing
WebSphere Business Model asset for this portion of the business is already available.
In the Realization phase, we can leverage Pattern-based assets to assist in the generation
of services.
When a service has been completed, we can leverage the Manage aspects of the
Asset-Based Development guidance for promoting the service to a runtime Repository.
This is certainly not an exhaustive list of examples, but hopefully it shows that assets play a
key role in creating SOA solutions.
Chapter 12. Introduction to service assets
337
The SOA-Governance plug-in for Rational Method Composer overlaps with the Asset-Based
Development Governance plug-in. This part of the book explains the relationship between the
two plug-ins.
338
The services within an SOA solution need to be reusable across different business
processes. Making the services reusable gives the flexibility to change existing processes
and implement new processes easily, thus leading to business agility. In the book ordering
example, each of the identified services (search, shopping cart, payment, and user
management services) can be reused in different processes. For example, a back-end
process for ordering stock from the vendors for delivery to the warehouse can be built using
the same payment processing service. This reuse not only reduces the time required to
automate the new business process, but it also makes it easy to implement changes to the
payment process across the multiple business processes in the organization (when there is a
change made to the organization policies in relation to the payment processing). In this way,
integrating the business as a set of linked services is called service orientation.
A formal definition of a service-oriented architecture is:
339
340
time, through a service interface, and must have many implementations with different access
protocols. This type of definition helps to increase the reusability of any service definition.
341
From the IBM SOA Foundation: An Architectural Introduction and Overview white paper (see
the following shaded box for a link to this white paper):
The Model phase includes the process of capturing your business design - from an
understanding of business requirements and objectives - and translating that into a
specification of business processes, goals, and assumptions, creating an encoded model
of your business.
The Assemble phase concerns assembling the information system artifacts that will
implement the business design. The enterprise architect - working with the business
analyst - can begin to convert the business design into a set of business process
definitions and activities, deriving the required services from the activity definitions.
The Deploy phase includes a combination of creating the hosting environment for
service-based (composite) applications and the actual deployment of those applications.
This phase includes resolving the applications resource dependencies, operational
conditions, capacity requirements, and integrity and access constraints.
The Manage phase addresses the maintenance of the operational environment and the
policies realized by the deployed SOA applications. This phase includes monitoring the
performance of service requests and the time lines of service responses, maintaining
problem logs to detect failures in various system components, detecting and localizing
those failures, routing work around them, recovering work affected by those failures,
correcting problems, and restoring the operational state of the system. The manage phase
also includes managing the business model and tuning the operational environment to
meet the requirements of the updated business design.
Note: For more information, refer to IBM SOA Foundation: An Architectural Introduction
and Overview at:
http://www-128.ibm.com/developerworks/webservices/library/ws-soa-whitepaper/
The rationale for SOA Governance is that in order to achieve the benefits of SOA, it is
important to establish chains of responsibilities, authority, and communication to empower
people to bring about the necessary changes for service orientation and to sustain those
changes, so that the organization does not default to business as usual. As seen in
342
Figure 12-4 on page 342, SOA Governance is applied to all of the four stages in the life cycle
of services.
Service registration
Service versioning
Service ownership
Service discovery and access
Deployment of services and composite applications
Security for services
The agility provided by SOA also provides a set of challenges to the IT organization.
Undisciplined development and deployment of services can do more harm than good. Hence,
organizations must address a set of key questions if they are to obtain value from SOA:
1. How do organizations regulate the deployment of composite applications?
2. What organizational change is required? What new organizational roles and structures
facilitate service identification, design, and sharing?
3. How do you organize the IT function to build and leverage service-oriented capabilities?
4. What metrics support the investment, maintenance, vitality, and sharing of services?
5. How do businesses decide to invest in service creation and maintenance?
As a specialization of IT Governance, SOA Governance addresses how an organizations IT
Governance decision rights, policies, and measures need to be modified and augmented for
a successful adoption of SOA.
343
As shown in Figure 12-5, the governance process consists of four phases, which we discuss
next. Note the process is repeated cyclically. Each cycle provides an opportunity for improving
the governance approach:
Plan: As previously discussed, good IT and SOA Governance results in better alignment
of the IT organization and the needs of the business. It is in the plan phase that the needs
and priorities of the business are documented along with the role of the IT organization in
meeting these needs. Also, the state and maturity of the current IT organization
governance is assessed, and gaps are identified. The governance vision and strategy, as
well as the roadmap and plan, are documented from all of this analysis.
In the plan, the governance measures are put in place. These measures are used to
assess how well the IT organization is aligned with the business and how well the
business needs are met.
Define: In the define phase, the detailed governance plan is put in place for the current
cycle. In particular, the processes to be governed are specified and prioritized, and the
decision rights, policies, and measures for these processes are defined.
In preparation for the next phase, detailed deployment plans are set. In certain cases,
these plans can include specifying or updating the structure and staffing of the SOA
Governance Center of Excellence (CoE).
Enable: The enable phase is when the defined solution is rolled out to the organization. In
this phase, roles are assigned, the staff is trained, the decision rights can be automated in
workflow tools, and the metrics collection and report mechanisms are put in place.
Measure: In this phase, the governance approach is executed and tuned. The
governance metrics that show alignment with the business are gathered. These metrics
are used in the next cycle to revise the governance approach.
344
As seen in Figure 12-6, there is an overlap between SOA Governance and Asset
Governance. This means that SOA Governance deals with the aspects of Asset Governance,
because an SOA treats services as reusable assets. The processes, roles, and competencies
that might be required to produce, consume, and manage service assets might be similar to
those defined by Asset Governance. However, the scope of SOA Governance is much more
than just Service Asset Governance. It includes process, policy, role, and responsibility
definitions for a larger set of activities that are part of the service life cycle in an SOA.
Similarly, an Asset Governance body in an organization can perform governance activities for
assets that might not necessarily be services, even though the organization might be
undergoing an SOA transformation. This distinction explains the non-overlapping portion of
the Asset Governance ellipse in Figure 12-6.
SOA Governance and Asset Governance can coexist in an organization. SOA Governance
can address the issues of Asset Governance at relevant stages in its life cycle. For example,
during the define stage of SOA Governance, asset repositories can also be defined for
service assets. Workflows can be defined for publishing services to the repositories. Policies
can be defined for service reuse. Based on the IT Governance policies of an organization,
there can be common members in the SOA Governance and Asset Governance boards to
align the activities of both the governance bodies.
345
Service interfaces
Basic services (service interface and implementation)
Choreographed services
Business services
Composite Business Services
A service interface is just a standards-based interface for services. It does not contain any
implementation attached to it. The implementation aspects are left to the application that
consumes this asset.
The importance of having service interfaces as assets is to lay a standard for performing
certain tasks across the organization. This standard enhances the interoperability between
applications, because one application that needs to interoperate with another application
knows what to expect from the other application based on the standard interface.
Furthermore, even if application integration is unimportant, it makes sense to have service
interfaces defined for certain tasks that are likely to be implemented by different applications
in the organization. Having the interfaces and data types defined reduces the development
time needed to create them.
At a physical level, a service interface asset is usually a Web Service Description Language
(WSDL) file along with the related XML Schema Definition (XSD) files.
A basic service is a service that performs a certain generic task. As a reusable asset, it is
used as a building block for implementing process choreographies. It is usually implemented
using the Web service standards in order to make it easy to integrate into applications that
want to consume this service. At a physical level, a basic service asset contains a service
interface (WSDL and XSD files) and implementation files.
A choreographed service is a process implementation that is exposed as a service. It is built
using basic services. It has the business logic that drives the business process in it. These
assets can be used as part of other larger process choreographies. The industry standard for
implementing process choreographies is using the Business Process Execution Language
(BPEL). At a physical level, a process implementation contains the files related to BPEL and
the files related to the basic services.
A business service is a business function whose execution can be adapted at run time based
on business policy and user context. It is a matured form of a choreographed service that is
more dynamic and flexible than the choreographed service. It is designed at the business
level to represent a discrete business function. It is derived from disparate IT resources, such
as existing systems, custom applications, independent software vendor (ISV) systems, and
third-party services. It is provisioned through multiple communication channels, such as Web
portal, Business-to-Business (B2B), Fax, or any other channel relevant to the business. It is a
reusable asset in the sense that it can be combined with other business services to create
loosely coupled applications and processes.
To understand these features of a business service, look at the example shown in Figure 12-7
on page 347. A Credit Check service is a business function to evaluate the credit score of a
consumer. It encapsulates a business process that performs credit score lookup, applies
credit rules to determine acceptance, updates the consumer credit profile, provides
notification of acceptance or failure. It is derived from disparate IT resources and comprised
of Web services, such as credit lookup (third-party), credit eligibility (existing), update profile
(packaged application), and notification (custom). It can be provisioned through a Web portal
346
Communication Channels
Web Portal
IVR
Role-Based
Users
CRM
Pre-Approval
Policies
Risk Assessment
Policies
Business
Service
Technical and industry standards compliance
CSR
Consumers
Operational Capabilities
Credit Lookup:
3rd Party Service
Credit Eligibility:
Legacy System
Customer Profile:
Packaged CRM
Customer Notification:
Custom J2EE
A composite business service is a collection of business services that work together with
existing applications to provide a specific business solution. Figure 12-8 on page 348 shows a
pictorial representation of the concept of Composite Business Services. The service
performing a generic task in Figure 12-8 on page 348 can be either a basic service or a
choreographed service, which is not as dynamic as a business service.
347
A composite business service is a composition of business services that are selected and
executed dynamically to deliver adaptive and personalized behavior. The individual business
services can be derived from existing, third-party, or custom-packaged applications. Thus,
Composite Business Services enhance reuse of IT assets by leveraging these business
service assets. Furthermore, by being able to create Composite Business Services
incrementally, organizations have the advantage of reduced risk in building composite
business service assets. When compared to assets developed as traditional monolithic
applications, Composite Business Services provide greater flexibility at a lower cost due to
their ability to dynamically adapt behavior at run time using policies, instead of hard coding
new or duplicate functionality.
By reusing Composite Business Services to build larger business processes, organizations
can achieve faster time to market, because Composite Business Services automate part of
the business process and are easy to adapt and configure using business context and
content-based policies.
To summarize, a composite business service has the following attributes:
Composable: Composite Business Services support an asset-based approach to building
an SOA solution leveraging services exposed from existing, ISV, third-party, and partner
assets to incrementally automate a core business process.
Subscribable: Users subscribe to Composite Business Services, and the subscribers of
services are managed with an integrated entitlement model that enables licensing,
packaging, and billing of business level services.
Describable: Composite Business Services and the constituent business services are
described via metadata that can be annotated and published in a catalog for easy
discovery; this type of metadata must include business, application, technical, and
informational architectural elements.
Flexible: Composite Business Services are built with points of variability. These points of
variability within the underlying business processes are dynamically implemented based
on an externalized set of directives. These directives are derived from business,
application, technical, and informational architecture elements including quality of service,
348
industry semantics, and business policies. In this case, a policy is a business rule that
constrains the behavior of a business process.
Visible: Composite Business Services provide contextual visibility to service behavior so
that business services can be optimized or evolved during execution.
Governable: Composite Business Services have the ability to be managed and versioned
through their life cycle from creation through upgrades to end of life.
349
350
Eclipse Web Tools Platform (WTP): This platform includes basic tooling for Web
developers. It includes source editors for HTML, JavaScript, cascading style sheet
(CSS), JavaServer Pages (JSP), SQL, XML, document type definition (DTD), XML
Schema Definition Language (XSD), and Web Services Description Language (WSDL);
graphical editors for XSD and WSDL; J2EE project natures, builders, models, and a J2EE
navigator; a Web service wizard and explorer, and Web Services Interoperability
Organization (WS-I) test tools; and database access and query tools and models.
In addition, Rational Software Architect offers other features, such as the selection of ready to
use transformations and patterns. For detailed information about these features, refer to
Part 4, Patterns on page 455 in this book.
351
management products, such as Rational Asset Manager, to help you consume and publish
assets from and to the Repository.
All of the types of service assets can be created and tested using the Integration Developer. It
provides an Eclipse-based integrated development environment to code, test, debug, and
deploy SOA solutions. The product is based on industry standards for Web services, such as
SOAP, WSDL, XSD, and Web Services Business Process Execution Language (WS-BPEL),
thus, enabling reuse of the services developed using its environment across multiple
platforms.
WebSphere Integration Developer simplifies integration by using an industry standard
programming model called Service Component Architecture (SCA). SCA is a specification
that describes a model for building applications and systems using an SOA. It decouples
service implementation and assembly from the details of infrastructure capabilities and from
the mechanisms for invoking external systems. By developing service-based assets as SCA
components:
Consumers can integrate the asset as part of their application assembly in a standard
way.
Client programs can use a standard API to invoke the services.
Integration developers can configure the deployment time parameters, such as service
binding information, without having to change the code.
Thus, service reuse can be enhanced to a great extent by using the SCA programming model
to render existing IT assets as service components.
WebSphere Integration Developer enables rapid assembly of business solutions by wiring
reusable service components. It enables the construction of process and integration solutions
using drag-and-drop technology without the need to have a working knowledge of Java. This
capability helps in the quick development of service assets that involve process
choreography, such as business services and Composite Business Services.
352
IBM Business Services Foundation Pack provides the integrated runtime and manage-time
environment:
Provides a highly scalable runtime policy definition and enforcement engine that enables
dynamic service assembly and service behavior adaptation based on content, context,
and contract.
Controls and automates entitlement of business services for subscribers, enabling
creation, control, and management of service packages to subscribers across the
ecosystem. It integrates with leading security and identity management products.
Provides visibility and monitoring of service-oriented processes and applications. It
includes multi-perspective views and enables the drill-down analysis of events and
exceptions.
Provides end-to-end governance of business services through design time, run time,
deploy time, and manage time.
Stores and manages business services, policies, and business service entitlements.
IBM Business Services Tool Pack provides the design-time environment and tools:
Provides tools to maintain, manage, and govern services metadata, subscribers, policies,
and governance processes.
Enables domain-experienced software architects to model, create, publish, and manage
industry-specific service metadata models and policies around data, processes,
resources, policies, and domains.
Provides a visual assembly environment for creating and managing industry specific
business service metadata models and policies.
The Industry Content Packs provide reference business services templates optimized to
industry standards that contain the following prebuilt SOA assets:
Reference business services templates that include definitions of business assertions,
business roles, and business channels; all based on a common industry business
glossary
Industry business glossary that presents a taxonomy of industry terms, with associated
relationships and properties
Industry standards-based data types and Web service interfaces that enable
interoperability across disparate systems in the enterprise ecosystem
353
Payments Status
Fund Transfer
Bill Payments
Other
Industry
Composite
Business Service
Product
Composite
Business
Services
Industry
Content
Packs
Other
Industry
Packs
W ebSphere
Business
Services
Fabric
354
355
Figure 12-12 Major functions and components of WebSphere Studio Asset Analyzer
356
After inventorying an application, its metadata becomes the source of application insight,
which can be used for, among other things, rapid application understanding and change
impact analysis. It is accessible in multiple ways:
People access this application insight through a browser interface
Other tools and programs use a Web service interface or make direct DB2 SQL calls
357
358
13
Chapter 13.
359
360
In the case of Figure 13-2 on page 362, we can see that the Asset-Based Development
guidance can be used throughout RUP/SOMA.
361
In the following sections, we look in more detail at the Service Identification, Service
Specification, and Service Realization phases of RUP/SOMA.
362
363
Note: For detailed information about locating services in WebSphere Service Registry and
Repository and WebSphere Business Services Fabric, refer to Chapter 14, Consuming
service assets on page 399.
364
There are several ways to find specific assets in WebSphere Studio Asset Analyzer:
If you know the name of the asset for which you are looking, you can search on that name.
If you know only part of the name, you can use wildcards and search attributes to find the
asset.
If you know only certain aspects of the asset but not the name, you can drill down in a
likely container, such as the enterprise application archive (EAR) file, one of which must
contain the asset for which you are looking.
WebSphere Studio Asset Analyzer can help you to find:
Which applications perform screen or data I/O or both
Which applications appear to be the hub applications
Which applications are the largest, most complex, or most often invoked by other
applications
365
The advanced search allows searching on interesting attributes, as well as asset name
patterns. You can, for instance, select CICS programs that perform or do not perform terminal
I/O. Extending this idea, you can combine these attributes in custom queries to identify just
the programs in which you are interested.
After finding candidate assets from the asset Repository, you can proceed with the Existing
Asset Analysis process to identify candidate services. A detailed discussion about this
process is out of the scope of this book.
The key thing to remember is that even if an organization is not yet leveraging reuse, the
organization likely has code that is suitable to find its way into an asset (service or otherwise).
WebSphere Studio Asset Analyzer can be a key tool to help you analyze the code and
artifacts that are already tested, understood, and in use within your organization. WebSphere
Studio Asset Analyzer can provide you with the insights needed to further leverage that
investment.
Tooling considerations
In addition to the tools mentioned in this section, Rational Software Architect and its
integration features with other tools, such as Rational RequisitePro and WebSphere Business
Modeler, can be used to perform service identification.
Rational Software Architects RequisitePro integration allows you to work on RequisitePro
projects from within the Software Architect Integrated Development Environment (IDE).
Almost all of the capabilities provided by the RequisitePro native client are also provided,
except administration capabilities and the ability to create new projects. There is a
Requirement perspective, which supports working with RequisitePro requirements and the
linkage (traceability) of design elements to requirements.
366
relationship between two independent services, because they both implement the same
specification.
If the Existing Asset Analysis phase resulted in identification of deployed services in the
WebSphere Service Registry and Repository, you can use the impact analysis feature in the
WebSphere Service Registry and Repository to analyze the dependencies between these
services. The vast majority of objects that are stored in the WebSphere Service Registry and
Repository do not exist in isolation. Each object can define a number of predefined
relationships (also known as modelled relationships) or user-defined relationships that
connect them to other objects in the WebSphere Service Registry and Repository, forming an
object graph. These relationships indicate dependencies that exist between the objects in the
object graph. They can be traversed in order to determine which objects might be affected by
changes to other objects in the graph. However, for any non-trivial object graph, attempting to
perform this task manually is a time-consuming process.
The impact analysis functionality within the WebSphere Service Registry and Repository can
automatically traverse the relationships in an object graph to determine the list of dependent
objects. More specifically, the impact analysis component recursively navigates the
relationships that originate from a specified object, building a list of all of the reachable
objects in the object graph. It is this list that is returned as a result of running impact analysis.
It represents the collection of objects in the WebSphere Service Registry and Repository that
might be affected by a change to the specified object. This can help in the existing asset
analysis process to understand the impact of choosing to reuse a specific service from the
Repository.
During service specification, it is important to identify the non-functional requirements for the
desired Qualities of Service (QoS), which can be related to security, performance, and
availability. When the service asset is consumed, the non-functional requirements will be
used to commit resources for service components that offer the services and to fund the
realization and maintenance of service components that will ensure the delivery of the QoS
over time. For more general information about non-functional requirements for assets, refer to
Part 2, Reusable Assets on page 123 of this book.
When candidate services have been selected and documented in the (categorized) Service
Portfolio, we then need to determine which ones must be exposed as services. Although, in
theory, any candidate service can be exposed by exporting its interface as a service
description, not every candidate service must be. It might not be economically and practically
(non-functional requirements might be compromised) feasible to do so.
In particular, the naive decision to expose all methods from all classes will result in an
overwhelming and often unmanageable number of services leading to the Service
Proliferation Syndrome. This creates huge performance and service management problems,
not to mention the fact that we might be giving away the companys intellectual capital.
Moreover, we must remember that there is a cost associated with every service that we
choose to expose: the funding, governance, and the underlying infrastructure (its security,
performance, and management) of the service and the components that will implement them
must be taken into account. Hence, a service litmus test is conducted on the candidate
services to make the right exposure decisions. Table 13-1 on page 368 summarizes the steps
involved in a service litmus test.
367
Description
Ensure service is
business-aligned
The first test of a service is about its business alignment. If the service
is not traceable back to a business task or goal, it might not yield the
benefits required for SOA implementation. The following questions, if
all are answered positively, mean that the service is aligned with the
business:
Does the service provide a required business functionality that
supports business processes and goals?
Is the business willing to fund the service through its life cycle:
provisioning, management, governance, and maintenance?
Is the business willing to share the service internally or externally
with clients or business partners? For example, implications might
be additional costs, business secrets, security, and so forth.
Are there existing or future opportunities within the enterprise to
reuse the service?
Ensure service is
composable
368
Name
Description
Ensure service
has an external
description
Ensure service is
reusable
Ensure service is
technically
feasible
Candidate services that pass all four parts of the Service Litmus Test must then be exposed
as services in the SOA.
There can be candidate services that did not pass the Service Litmus Test but which are still
implemented as services. Service Litmus Test is an aid to determine which services to
expose; if a business chooses to expose candidate services that did not pass the Service
Litmus Test, the implication is that benefits associated with an SOA will not be realized and
the organization might end up spending resources on assets that might not give returns from
reuse.
Candidate services that do not meet the Service Litmus Test will have to be implemented,
because they are required to fulfill business needs. They can be implemented as methods on
service components and not require the generation of WSDL or other forms of service
definitions; or they can be used as non-exposable entities.
While design patterns can be incorporated any time during the design, the service
specification stage is a good time to start. Patterns in UML can be transformed to code using
the transformation capabilities in Rational Software Architect. You can also create your own
model to text transformation in Rational Software Architect. These transformations are
reusable assets that help improve developer productivity. For a detailed discussion about
pattern assets, refer to Part 4, Patterns on page 455 in this book.
Tooling considerations
Rational Software Architect is the tool that is primarily used for specifying services. UML is a
generic language, designed for all possible software systems, applications, and solutions.
Although it is possible to represent services using only UML, it is a better idea to use a
specific profile designed for services, because it specializes the modeling language to the
369
task. Therefore, when we need to represent, analyze, and design an SOA solution with IBM
Rational modeling tools, we can use the UML profile for Software Services.
We recommend that you use this profile mainly in conjunction with the service identification
and service specification phases of SOMA, but not with the service realization phase.
Therefore, services are identified and specified here. Even if this specification is well detailed,
it does not represent a White box view or realization of services.
This profile extends an existing UML element (we can call them meta classes) by defining new
stereotypes that provide additional semantic and visual representation on UML meta classes.
In Figure 13-4, we can observe these stereotypes and which meta classes they extend. Refer
to the official documentation for the formal specifications of this profile.
Note: In Version 6 of the Rational Software Architect, this profile was provided as a tool
add-in (through IBM developerWorks). In Rational Software Architect Version 7, this profile
is provided automatically with the product. For a complete description of the profile, refer
to:
http://www-128.ibm.com/developerworks/rational/library/05/419_soa/
Note that there are few differences between Rational Software Architect Version 6 and 7 for
this profile; stereotypes, such as <<serviceModel>>, have been added in Rational
Software Architect V7.
370
The third and fourth options provide the most flexibility, because they use the existing
function but do not continue to expose the function as is to clients. However, the first and
second options can introduce issues with wrapping existing functions as services, because
the performance of Web service protocols and mismatches between native data formats and
XML can introduce performance concerns.
371
You need to analyze existing software assets and their dependencies and interfaces in order
to determine if changes are required to support the business functionality. For example, in
order to create a Web services interface for an existing implementation of a business
function, analysis might involve the examination of the composition and flow of online
transactions or batch jobs, or persistent data stores that help perform that function. The
current design of these existing applications might need to change to support the
functionality. You also need to identify any potential barriers to creating a Web services
interface with the desired quality of service. For example, a monolithic batch implementation
of a business function might require sub-second response time when invoked as a service.
In certain cases, however, it is expedient to develop an existing service partition where a set
of low-level existing functions are exposed individually as services. This partition is only
accessible to higher level services that utilize the functions in presenting a more granular
business-aligned specification to consumers. This encapsulation of the existing functions
must be seen as a temporary solution and must only be undertaken if the performance
characteristics of the wrapping technology is well understood.
During the realization of assets, it is important to know the layer in the architecture to which
the service will be reused. Knowing the layers in which their asset resides, developers know
on what services they can rely in the coding environment. As a rule, components must not
make use of features provided by components on a higher layer, because this makes it
difficult to replace the higher layers without changing the lower ones.
Intermingled business logic: The business logic that you want to use might be sprinkled
across a number of programs and intermingled with screen or data I/O and related data
validation, which can make it more difficult to isolate for reuse.
Application pattern: Your applications pattern might not be optimal for the kind of reuse
that you want to perform. In particular, you might have business tasks handled in batch
mode, which complicates the effort to offer them as synchronous services. Here are
examples:
Your application writes transactions to a journal, and the journal is then processed in
batch mode at a later time, typically at night.
Multiple business tasks are done in one job step as an optimization of I/O processing
372
Your batch application assumes data transformations in a specific sequence, that is, A
and B must run before C, but you only want to reuse C in your service.
Data might not be immediately accessible, for example, if the application uses
sequential files; your program must read the file from the beginning.
Tooling considerations
Rational Software Architects modeling, patterns, and transformation capabilities are used in
the SOMA realization phase. Service components and their relationships are designed in
UML by using relevant design patterns and are prepared for transformation to the next level
of abstraction by using the appropriate profiles.
373
374
You can make the realization decisions for the services. The WebSphere Business Services
Fabric Industry Content Packs provide interfaces for services without providing the
implementation. This avoids multiple interfaces for the same service to be published to the
Repository for potential service clients to look up, while allowing different applications to
provide custom implementations. Realization decisions need to be made on the
implementation of these services. The functionality for this type of a service can be provided
by open source software or a commercial product that can be wrapped as a service, in which
case, the decision might have been made as part of the identification phase.
The implementation of the composite business service is preceded by the detailed design
activities similar to those performed for traditional J2EE applications using the principles of
object-oriented analysis and design. This can require the use of design patterns, which is
detailed in Part 4, Patterns on page 455 of this book. The data model might be designed for
the composite business service using Rational Data Architect. The inputs and outputs of the
services that were specified in the service model can be used as input for designing the data
model for the composite business service.
375
earlier in the section 13.2, SOMA insights for asset development on page 360 can be used
as input for the transformation capabilities in Rational Software Architect to transform the
services to WSDL files and Java skeleton implementations. Figure 13-6 shows the typical
transformations that you can use to move from one level of abstraction to the next.
Figure 13-6 shows that the service model can be transformed to WSDL files, and Web
service skeleton code can be generated using these WSDL documents. Also, the design
model, which contains the detailed designs for each of the service-oriented parts in the
service model, namely, the service consumers and service providers, can also be
transformed to source code using transformations in Rational Software Architect.
You can also create your own model to text transformations in Rational Software Architect
and reuse them as assets. For more information about how to create your own
transformations, refer to Part 4, Patterns on page 455 of this book.
Note: For detailed information about how to use the features of Rational Software
Architect for performing the SOMA tasks, refer to Building SOA Solutions Using Rational
SDP, SG24-7356, at:
http://www.redbooks.ibm.com/abstracts/sg247356.html?Open
The interfaces and datatypes are used for several tasks during development:
The interfaces are attached to the partner links in the BPEL. The data types are used for
typing the various variables in the BPEL.
They are used to generate the implementation for the services in Integration Developer.
These documents are used by Integration Developer to generate the corresponding Java
source code files.
They form the basis for invoking the services that are defined in the interfaces. This
means that all service clients will use these documents to invoke the service.
These documents are used in assembling business services and their composites using
the Composition Studio tool that is part of the WebSphere Business Services Fabric.
376
When the service has been implemented and is ready for deployment, these documents
are published to the WebSphere Service Registry and Repository to serve as runtime
metadata for clients that might want to use the service.
Note: Care must be taken to use the correct namespaces and names for the various
elements in the WSDL and XSD documents, because they are reused in several other
tasks during development. Changes to these documents at a later point of time have an
impact on various pieces of the solution. A complete and reviewed service model
document can help you produce these artifacts correctly. The service model might have
identified the existence of service interfaces (and implementations) in the WebSphere
Business Services Fabric Industry Content Packs or in the asset Repository. These
interfaces need to be sourced from the identified sources for reuse.
After the BPEL is complete, you have to create the SCA assembly for the composite business
service in the Integration Developer. The assembly diagram will give you an end-to-end view
of the composite business service, with the business process wired to all of the referenced
services in it. The assembly diagram is used to provide the implementation details, such as
the binding information, the endpoints, and other transaction details for the services
referenced by the BPEL.
Tip: The BPEL process that is implemented is a generalized process. The BPEL process
designed until now does not have dynamic capability support. For example, there is no
conditional logic provided in a BPEL process to determine which set of services to call if
the customer is a gold level customer compared to a silver level customer. If you are using
the WebSphere Business Services Fabric and require dynamic capability support, you
need to use the SCA Dynamic Assembler component in Assembly editor while composing
the application. WebSphere Business Services Fabric leverages the SCA model and
provides a Dynamic Assembler component, which simplifies the business service
programming model.
Using the SCA Dynamic Assembler component eliminates the static binding between
service consumers and the service provider. The SCA Dynamic Assembler enables
dynamic policy assembly and service selection based on the context, content, and
contract. The SCA Dynamic Assembler provides business agility through the policy-driven
runtime assembly of business services.
You can test the BPEL in the integrated test environment by using Integration Developer,
without having to provide an implementation for all of the services. The Integration Developer
gives you the option to use emulators for the services referenced by the BPEL. Alternatively,
you can provide mock implementations for the services and use them to test the correctness
of the flow of the BPEL.
The composition of a composite business service can be tested through mock services and
emulators without having any knowledge of how the service has been or will be implemented
in reality. This decoupling of the choreography from the actual implementation of the services
makes Composite Business Services flexible SOA assets that allow the business process to
be changed at any time without having to consider the technicalities of the actual service
implementation.
377
378
Note: If you use the WebSphere Service Registry and Repository for registering services
deployed in your organization, you can source the interfaces and data types from the
WebSphere Service Registry and Repository.
Figure 13-7 summarizes the composite business service development tasks.
As seen in Figure 13-7, the business process model in WebSphere Business Modeler is
exported as a BPEL, which is imported into the WebSphere Integration Developer. The BPEL
and SCA assembly wiring are completed in parallel with service implementation in the
WebSphere Integration Developer. The composite business service is then assembled in the
Composition Studio and published to the business services Repository. Figure 13-7 also
shows that the service metadata can be sourced from WebSphere Service Registry and
Repository. Service invocations in the BPEL are routed through the dynamic assembler,
which at run time, selects a suitable endpoint based on the context, content, and the contract
associated with the request.
The Rational Asset Manager is shown as the central Repository where all service artifacts are
stored. The business process models, service interfaces, implementation artifacts, and
reusable metadata in the form of ontology files that are used through the rest of the
composite business service creation process can be sourced from the Rational Asset
Manager. The Rational Asset Manager Eclipse plug-in helps developers source the relevant
379
assets in WebSphere Integration Developer. Rational Asset Manager can be integrated with
WebSphere Service Registry and Repository to publish and synchronize service metadata
with the service Repository. These links between the products are not shown explicitly in
Figure 13-7 on page 379.
380
describe these styles further in Chapter 14, Consuming service assets on page 399. Test
cases can be written based on the reuse style of the service.
Industry standards are key drivers for reusability. Using relevant industry standards enhances
the chances of reusability of a service. For example, Web services can follow the Web
Services Interoperability Organization (WS-I) standards to ensure that they are interoperable
across multiple platforms. WS-I is an open industry organization chartered to promote Web
services interoperability across platforms, operating systems, and programming languages.
Test cases can be written to ensure relevant standards compliance.
Potential consumers can use any of the various points of variability of the services that awe
describe in Chapter 14, Consuming service assets on page 399. Test cases must be written
to test these various points of variability.
Because reusable assets services can be deployed in a variety of target environments, test
cases can be written to test the services in the various environments in which they are
expected to be reused. This can involve various client technology and operational
environment considerations.
381
Tools
Defect management/metrics
Rational ClearQuest
Performance
Rational PurifyPlus
Rational Application Developer
Test automation
Test management
Rational ClearQuest
Rational Manual Tester
Change management
Rational ClearCase
Requirements tracking
Tools
Rational ClearCase
Defect tracking
Rational ClearQuest
Test management
Rational ClearQuest
Rational Manual Tester
Test automation
Code inspection
Metrics
Rational ClearQuest
Rational PureCoverage
Rational Application Developer
382
Area
Tools
Defect management
Rational ClearQuest
Performance
Area
Tools
Test automation
Test management
Requirements tracking
Change management
Rational ClearCase
Note: For more information about these tools, refer to Building SOA Solutions Using
Rational SDP, SG24-7356, at:
http://www.redbooks.ibm.com/abstracts/sg247356.html?Open
383
goes first. Hence, when a service asset that has been published to the Rational Asset
Manager is ready for deployment, the service metadata might be published to the
WebSphere Service Registry and Repository. When a Rational Asset Manager assets
artifacts are passed onto the WebSphere Service Registry and Repository, they are now
owned and managed in the WebSphere Service Registry and Repository as runtime
documents.
The definition of a service in this respect is broad, including:
Traditional Web services implementing WSDL interfaces with SOAP/HTTP bindings
A broad range of SOA services that can be described using WSDL, XSD, and WS-Policy
decorations, but might use a range of protocols and be implemented according to a variety
of programming models
Business services and Composite Business Services are business level services, which
contain service metadata from a business perspective. Beyond the technical metadata, there
are interfaces and data types of a service and there are business services that include
metadata, such as channels, roles, and so forth. WebSphere Business Services Fabric as a
platform for assembling Composite Business Services contains a Repository called the
business service Repository for storing business service metadata. Developers assembling
Composite Business Services can source the technical service metadata from the
WebSphere Service Registry and Repository into the business service Repository and add
business context information to compose business services. After passing through a
governance process, the service metadata for the business services gets stored in the
business service Repository. At run time, Composite Business Services use this metadata for
the dynamic selection of endpoints based on the business context, content, and contract
metadata associated with the business service.
For more information about using WebSphere Service Registry and Repository with
WebSphere Business Services Fabric, refer to Chapter 14, Consuming service assets on
page 399.
Note: During the development of a service, the service artifacts are typically maintained in
a configuration management system, such as Rational ClearCase. The services are
maintained in Rational ClearCase until they are developed and tested. This approach is
not unique to services; it is true across all types of assets.
This section discusses only the primary repositories that are relevant to services. For
detailed information about Rational Asset Manager and Rational ClearCase positioning
and integration, refer to Appendix A, Rational Asset Manager: Installation and
administration on page 637.
The three repositories are used for three distinct purposes during the life cycle of a service
asset, as shown in Figure 13-8 on page 385.
384
The following points summarize the distinction between the Rational Asset Manager and the
WebSphere Service Registry and Repository:
The Rational Asset Manager is seen as a development time registry targeted at
development teams and the WebSphere Service Registry and Repository is a runtime
registry that deals with documents and logical services derived from the service artifacts in
the Rational Asset Manager. WebSphere Service Registry and Repository does not
contain all service artifacts, such as the service implementation files. These service
implementation files are stored in the Rational Asset Manager. Only the service metadata
is published from the Rational Asset Manager to the WebSphere Service Registry and
Repository.
When a Rational Asset Manager assets artifacts are passed onto the WebSphere Service
Registry and Repository, they are free to change and to be governed as needed by the
runtime organization. However, it is useful for both development and the runtime
organization to preserve linkages between the development assets and their runtime
counterpart documents. This way you can understand the linkages between developed
assets and the deployed documents.
Rational Asset Manager manages information that is useful for developing, reusing, and
managing all types of reusable assets. It gives you the ability to define asset types, create
and manage assets, and provide traceability and details, and includes collaboration
software. WebSphere Service Registry and Repository manages information that is useful
for the runtime operation, management, and development use of services. It gives you the
ability to select service endpoints dynamically in an SOA run time, govern runtime
changes to service metadata, set and get runtime policies for service execution, and get
deployed service details, such as endpoints and service definitions. Together, the two
385
products create seamless, reusable asset tracking mechanisms through development and
runtime activities.
The following points summarize the distinction between the WebSphere Business Services
Fabric and the WebSphere Service Registry and Repository:
WebSphere Service Registry and Repository does not manage all service metadata, and
it does not manage service metadata across the whole SOA life cycle. It focuses on a
minimalist set of metadata that describes capabilities, requirements, and the semantics of
deployed service endpoints. It interacts and federates with other metadata stores that play
a role in managing the overall life cycle of a service. The business service Repository in
the WebSphere Business Services Fabric contains business-related metadata and
industry semantic models for use in dynamic service selection and assembly. The
business service Repository includes business-related policies, semantics, metadata, and
subscriptions. The WebSphere Business Services Fabric leverages and extends the
WebSphere Service Registry and Repository to source technical service metadata
information and provides business context through the use of the business service
Repository.
The integration between the WebSphere Service Registry and Repository and the
WebSphere Business Services Fabric is a convenience mechanism in the WebSphere
Business Services Fabric to source the service metadata from a central location and to
accelerate the assembly of Composite Business Services. It does not result in physical
links that can be used to navigate from the metadata in the WebSphere Service Registry
and Repository to the business metadata in the WebSphere Business Services Fabric
unlike the case of the WebSphere Service Registry and Repository and the Rational Asset
Manager integration.
present in WebSphere Service Registry and Repository, and hence, you do not have to
publish the service metadata artifacts to WebSphere Service Registry and Repository.
Important: A variation to this option is to publish the metadata early in the service life
cycle to Rational Asset Manager and then publish it to WebSphere Service Registry
and Repository for life cycle management. The other artifacts for the service asset can
be updated when they have been developed and tested. While this is a technically
feasible option, we do not recommend that you follow this path, because the service
metadata that is published in the early stages of the service is likely to change.
We recommend that you store only tested and reviewed assets in Rational Asset
Manager.
For the same reason, you might want to only replicate service metadata from services
that have matured enough for reuse from WebSphere Service Registry and Repository
to Rational Asset Manager. You can achieve this by having multiple instances of
WebSphere Service Registry and Repository. Services, which are not yet in a state
where they can be reused, can be maintained in a separate instance of WebSphere
Service Registry and Repository. Service metadata from this instance must not be
replicated into Rational Asset Manager.
Publish the tested asset to Rational Asset Manager and publish service metadata to
WebSphere Service Registry and Repository.
In this option, you can publish service assets to any of the repositories only when they
have been developed and tested. These assets are published to Rational Asset Manager.
You can then publish the necessary metadata to WebSphere Service Registry and
Repository. This option does not make good use of the service life cycle management
feature in WebSphere Service Registry and Repository.
In situations where the services are not developed from scratch, they are first published to
Rational Asset Manager as assets and then published to WebSphere Service Registry
and Repository. These cases are common when services are sourced from third parties,
open source resources, or from software resulting from acquisitions.
Note: In both of these governance options, technical service metadata to assemble
Composite Business Services can be ideally sourced in WebSphere Business Services
Fabric from WebSphere Service Registry and Repository.
387
Figure 13-9 shows the list of asset types, relationship types, asset attributes, and category
schemas in the sample SOA model for the Rational Asset Manager.
Figure 13-9 Configuration elements in the sample SOA model for Rational Asset Manager
As seen in Figure 13-9, the basic types that are typically required in an SOA implementation
have been included in the model. Figure 13-10 on page 389 gives a UML representation of
these asset types. It shows that a service interface asset can have implementations, design,
and test cases attached to it. It can fulfill architectural requirements and can also serve as the
contract for business processes. The artifacts from RUP/SOMA identification, specification,
and realization phases typically are business process and service design types. The
implementation assets fall under the service interface, service implementation, and
component types. Test cases are the Service Test type. Requirements and other higher level
architecture documents have their corresponding types defined as well.
Important: It is important to note that this model is not an exhaustive listing of the asset
types and other configuration elements for your SOA assets. It helps you get a jump start
in setting up the configuration for the SOA requirements in your organization.
388
Figure 13-10 Asset types in the sample SOA model for Rational Asset Manager
Figure 13-11 on page 390 shows the communities that are part of the sample SOA model for
Rational Asset Manager and the assets that are contained in them. These communities have
sample business processes, interfaces, and service documentation assets. You can create
new communities or customize these communities based on your organizational policies.
389
Figure 13-11 Communities and assets in the sample SOA model for Rational Asset Manager
The sample SOA Model for Rational Asset Manager also comes with three connection
configurations for development, test, and production WebSphere Service Registry and
Repository instances, which we do not show in Figure 13-11.
390
these asset types. Alternatively, you might choose to use other metadata, such as asset
attributes, or a generic asset type to distinguish between the assets.
You can use the following guidelines to define custom service asset types in the Rational
Asset Manager:
Different service assets contain different artifacts. For example, a choreographed service
contains the process choreography files in addition to the candidate service interfaces and
their implementations. You might have to define an asset type for choreographed services
to lay a restriction on the artifacts that are published to the Rational Asset Manager. Based
on the type of the asset, the Rational Asset Manager has capabilities to check that the
correct artifacts are being published to the Repository.
A business service typically contains artifacts including a business process
implementation, service interfaces and implementations, service metadata (typically .fca
files for the WebSphere Business Services Fabric), and supporting documentation. The
artifacts for a composite business service are the same as that of a business service.
However, you might still want to define a custom type for Composite Business Services if
you have different access requirements for users of business services and users of
Composite Business Services. For example, if you want the Composite Business Services
to be published by the architects and not by programmers, you might have to create a
specific asset type for the two types of services.
In the Rational Asset Manager, you might want to relate the business services to
Composite Business Services or relate the Composite Business Services to the business
services, because Composite Business Services are by definition composites of business
services. This enables the Rational Asset Manager users to see what business services
are used in a specific composite business service or the compositions in which a particular
business service has participated (thus, reflecting the reusability of the asset). To be able
to define these relationships, the Rational Asset Manager requires you to define different
asset types for the participants in the relationship.
Based on your SOA implementation, you might want to define a type to hold ontologies.
Part 2, Reusable Assets on page 123 of this book details the basics of an ontology.
Ontologies are usually represented in Web Ontology Language (OWL) and the artifacts
that represent them are .owl files. Ontologies are used to represent the business object
models and business service metadata in WebSphere Business Services Fabric. The
Industry Content Packs ship with industry-specific ontologies. You can extend or define
the ontology for your industry. Furthermore, you can define your own service life cycles in
WebSphere Service Registry and Repository using ontologies. Defining an Ontology type
might help you to manage these ontology artifacts.
Tip: For a step-by-step guide for Administrators to create new classification systems and
life cycles for WebSphere Service Registry and Repository, go to:
http://www-128.ibm.com/developerworks/websphere/library/techarticles/0703_shore
/0703_shore.html
391
standards, which can be another possible Rational Asset Manager attribute for the asset.
For example, possible values for a health care business service might be HIPAA or HL7.
Number of endpoints: Business services and their composites might have multiple
endpoints to access them. Typically, Rational Asset Manager users can use this as an
indication to know that the service has been enabled to adapt to different environments
based on context-based business policies. Note that this attribute can be used for basic
Web services as well. A variant form of this attribute indicates the number of services with
multiple endpoints which comprise a composite business service. This number is an
indication of the flexibility of the composite business service.
Business process type: The business process that is implemented by a composite
business service can be either a long running process with several human tasks, or it can
be a quick process that runs completely in a single invocation. This attribute helps the
Rational Asset Manager users to understand the complexity of the composite business
service, because long running processes typically run several days or weeks and hence
require system resources for longer durations than the short processes.
Requires open source or third-party software: This attribute can be used to indicate
that the composite business service uses open source or third-party software for its
service implementations. This can be used as an alert about additional costs and licensing
issues for potential consumers of the asset. Note that this attribute can be used for all
types of assets and not just service assets.
392
393
Figure 13-12 Communities and assets in the sample SOA model for Rational Asset Manager
394
Rational Asset Manager located two business process models in the Service Analysis
community. Bob reviewed the content and discussion forums attached to them and
discovered that one of the business process models that had been created, Account Opening
Business Process Model, was similar to what he required.
Bob downloaded the Account Opening Business Process Model asset and used it as a base
to model the new process model for the Determine Applicant Eligibility business process.
Because he had producer permission, when he finished modeling the new process model
with WebSphere Business Modeler, he created a new process model asset in Asset Manager
called Determine Applicant Eligibility, as shown in Figure 13-14.
Figure 13-14 Submit Determine Application Eligibility business process model asset
395
The Business Process asset type had associated the constraint of having at least one artifact
with a label of ProcessModel as shown in Figure 13-15. Therefore, Bob had to attach the
new process model files with the ProcessModel label.
As shown in Figure 13-16, Bob also created a relationship between both process model
assets (the old Account Opening Business Process Model and the new one that Bob
created) to make it clear that these assets were related. It must be clear to future users of the
Repository that there is a connection between these assets.
Bob completed all asset information and verified that there were no errors in the information
provided. Note that Rational Asset Manager shows red messages when the constraints
associated to the asset type are not met. Next, Bob submitted the asset to the Repository,
and it followed the default review process configured in Rational Asset Manager. When the
review was accepted by the project manager, the new asset moved to the Approved state.
For more information about how you can configure and create the review process in Rational
Asset Manager, go to Chapter 9, Produce reusable assets on page 237.
396
After submitting the new process model to the Rational Asset Manager Repository, Bob sent
an e-mail to Al Aarkashan (the SOA architect at ZYX Electronics), as shown in Figure 13-17.
The purpose of the e-mail was to inform Al that there was a new asset submitted to Rational
Asset Manager for the Determine Applicant Eligibility business process, and Al can start to
create the requirements specification, design models, and initial implementation of this
service.
Figure 13-17 Bob sent an e-mail about the new business process asset to Al
397
398
14
Chapter 14.
399
400
stored in the registry. The search is performed on the entire registry using an exact-case
match on the text entered. It is matched against the name and description properties of
any object. The text is used as a partial match; for example, a search for Echo returns
both Echo.wsdl and MyEcho. You can specify an asterisk character (*) in any part of
the search text to denote that any number of other characters are permitted to occur at
that position in the search results.
Query Wizard: The Web interface for the WebSphere Service Registry and Repository
provides a query wizard that can be used to search for service metadata based on the
following criteria:
The wizard walks the user through a series of windows to select the previously mentioned
criteria to create a search query and then displays all of the service metadata in the
Repository that matched the criteria.
View query definitions: The WebSphere Service Registry and Repository view query
system is a highly customizable method of creating predefined queries against the
contents of the registry. It uses a simple XML file that defines the parameters of each
query, associating that query with a unique identifier. These queries then form the main
method of providing links from the navigation tree to show relevant views in the Web user
interface. Users can customize existing or new navigation trees in the user interface by
defining additional view queries in a new view query definition file and then referencing the
new queries in the navigation tree.
Eclipse Plug-in: The Eclipse plug-in for the WebSphere Service Registry and Repository
is primarily a tool used to search for and publish documents from the development
environment. It contains a search feature that is highlighted here for the sake of
completeness of the content with respect to its query capabilities.
From the Service Registry view of the WebSphere Service Registry and Repository
Eclipse plug-in, you can search WebSphere Service Registry and Repository using one or
more of the following criteria:
The objects uniqueness identifier or any part of it. If you search on only one or two
parts of the identifier, more than one object can be returned in the search results.
The type, or types of objects that you want to retrieve. For example, you can search for
XML and WSDL documents.
One or more properties and property values of the object
The classification of the object in the WebSphere Service Registry and Repository. If
you specify a high-level classification, all of the objects in all of the classifications
beneath it are returned in the search results.
Programmatic query: Although we do not go into detail here, because it is out of our
scope, the WebSphere Service Registry and Repository provides other programmatic
query capabilities that can be used for searching for assets for reuse.
401
book in the Java application programming interface (API) Enterprise Java Bean (EJB) and the
Web Services API. These APIs can be used to locate services at run time.
402
403
on page 404 shows the positioning of the WebSphere Service Registry and Repository with
respect to the WebSphere Business Services Fabric.
Figure 14-2
404
Any metadata deleted from the Business Service Repository that is a replicated instance from
the WebSphere Service Registry and Repository will be restored back from the WebSphere
Service Registry and Repository upon their next connection.
WebSphere Business Services Fabric validates the contents of the WSDLs based on the
Web Services Interoperability Organization (WS-I) standards before it replicates the
metadata into the Business Service Repository. Specifically, the following validations are
performed on the WSDL file:
1. Endpoint fields must have a display name (port name), address (per port soap address),
and support service (per portType).
2. Addresses must have a valid HTTP URL.
3. Web service display name (portType name) must be specified.
4. Service operations must have input and output messages
(wsdlInput/wsdlOutputMessage).
Note: Web Services Interoperability Organization (WS-I) is an open industry organization
chartered to promote Web services interoperability across platforms, operating systems,
and programming languages. For more information about WS-I, refer to the Web site:
http://www.ws-i.org/
The WebSphere Business Services Fabric validation validates WSDLs based on WS-I
standards while trying to replicate from WebSphere Service Registry and Repository to
Business Service Repository. Only the WSDLs that pass the validation checks are replicated.
Any WSDLs that fail the validation will not be replicated. Therefore, the best practice is to
ensure that WSDLs published to WSRR are WS-I compliant.
405
406
Important: As discussed earlier, a goal for the organization must be to support all forms of
reuse. Therefore, although typically White box reuse has a lower value than Black box and
Gray box approaches to reuse, it can still provide a significant amount of value.
A key aspect to the Composite Business Services is that they are intended to provide
organizations with a best practice approach to building services within a specific industry.
However, there is also a need to allow each business to provide their unique, and likely
competitive differentiating, approach to the algorithm within the services. Therefore, there
is a balance between providing a standards-based set of services and providing an
organization with room to innovate.
Last but not least, when the composite business service has been customized to a
particular organization, it then migrates to the Black box and Gray box reuse models as
others in the organization consume this completed set of services.
Technically it is possible to reuse a composite business service as a Gray box by configuring
the business level service metadata, such as channels, roles, and policies.
Common points of variability of service assets are:
Business level service metadata: Business services and their composites are
characterized by business level metadata, such as channels, roles, and policies. This
metadata can vary based on the consuming application. WebSphere Business Services
Fabric helps externalize this metadata to a business service Repository. It uses
externalized policies to select specific implementations of a service based on the context,
content, and contract associated with a service request. This makes it easy to change
policies that govern the business process without having to write or change the source
code. Changes to metadata, such as what roles can access the business service through
what channels, can also be made declaratively, making it easy to customize the business
services and their composites for specific solutions. Changes to this metadata are made
using the WebSphere Business Services Fabric Composition Studio tool.
Service Endpoints: Endpoints of Web services are the most common points that vary
based on the deployment environment of the service. In the case of Composite Business
Services, new endpoints can be added for a specific service in the business service
Repository by using the Composition Studio tool. At run time, the WebSphere Business
Services Fabric dynamic assembler then uses the new endpoint as part of the dynamic
endpoint selection process.
The actual endpoint URL itself can vary based on the deployment server configuration.
Endpoint URLs for basic services can be edited using the WebSphere Process Server
administration console.
Messaging protocol: The protocol that is used to communicate with a service can vary
based on the application requirements. The most common protocols that are in use are
SOAP/HTTP and SOAP/Java Message Service (JMS). Implementing a service as a
Service Component Architecture (SCA) component gives you the flexibility to choose the
binding protocol at the time of service creation or assembly of Composite Business
Services. WebSphere Process Server provides three binding protocols: SOAP/HTTP and
SOAP/JMS for Web service bindings, JMS binding, and SCA binding.
Service implementation: Services that are intended for White box reuse expose the
implementation source code for customization by consumers. Customizing existing
implementation is usually a cumbersome task if it involves understanding existing code.
The best practices that can help facilitate a service implementation change are:
Externalize all probable application-specific variability points in an application. This
reduces the chances of having to change the service implementation code.
Chapter 14. Consuming service assets
407
Keep the service implementation cohesive and use the right design patterns to
separate the logical layers and specific products used by the composite business
service into logical modules. Using adapters to connect to third-party and open source
software makes it easy to switch between alternatives for this software.
Implementing services as SCA components gives you the flexibility to select one of the
implementation types at the time of service creation or assembly of Composite Business
Services.
Business process: Business agility is one of the key goals of service orientation.
Organizations need to change their business processes as quickly as possible to meet the
demanding market needs. Hence, the business process implemented by business
services and their composites is a key point of variability of these services. At a technical
level, common changes to the Business Process Execution Language (BPEL) include
adding completely new services to the choreography, changing conditions that select
specific services for invocation, or selecting specific implementations of a service based
on the context.
There are multiple ways of varying a specific service in the business process
implementation. These methods vary in terms of the degree of the flexibility that they bring
to the business process and their ease of implementation. These options are described
here in brief:
Baseline SCA implementation: This approach is the simplest and most
straightforward option to implement service endpoint selection. It involves using the
choice elements in the BPEL to select a specific service based on the evaluation of a
condition. The SCA assembly for the business process will have the actual endpoints
configured. These endpoints can be changed using the WebSphere Process Servers
administrative console.
Selectors: Selectors are special purpose SCA components that are part of
WebSphere Process Server. You can use a selector to indirectly wire a workflow with
one or more SCA import components. When a workflow sends a request through a
selector, the selector routes the request to an endpoint based on a selection criteria
that is evaluated for each request.
Integration Developer 6.0.2 provides predefined support only for selectors that use
date as a variable in selection criteria. Extending the selectors to use more complex
criteria, specified using Java, requires that you write custom code that implements the
SelectionAlgorithm interface.
At run time, the selectors can be modified using the administrative console, though this
applies only to the Integration Developer-supported selectors. Custom selectors
implementing the SelectionAlgorithm interface do not qualify. The console has
windows for editing selector tables that can point to specific service endpoints
compliant with the selectors Web service operation. There is also support for
protocol-independent aliasing using a selector table. Because each entry in a selector
table resolves to an SCA component, an entry can be an import component with HTTP
or a JMS binding. Selectors also support runtime dynamicity of endpoint choices.
When an SCA module is deployed to a process server, the modules binding
components can be added as entries in a selector table.
Selectors can be good candidates for a points of variability implementation. However, it
is important to assess the risks of deploying selectors to production and to fully
understand the capabilities of the points of variability implementations based on
mediation modules, service registries, and dynamic assembly.
The selector-based implementation requires access to the WebSphere Process Server
administrative console. It might not be suitable in environments where security requires
separation of access rights for the role responsible for editing the selector choices and
408
the role of the Process Server Administrator. This security risk is particularly serious in
cases where selectors are used to implement points of variability in business logic that
must be inaccessible to system Administrators. In many production environments,
business users must not have the capabilities of a Process Server Administrator
(stopping or deleting applications, changing system configuration, and so on).
Points of variability implementations that rely extensively on selectors are also a
regression risk for development organizations. When deploying a new version of an
application, developers must update the runtime selector tables from an existing
version of an application before an upgrade. When the selector tables change
frequently, this can mean downtime for existing applications.
Because selector tables are modified through the WebSphere Process Server
administrative console, they do not allow invocation time dynamicity for service
endpoints. WebSphere Process Server provides scripted access to the administrative
console capabilities, including selection table modification, but the performance impact
of using this scripting interface at endpoint invocation time is unacceptable to most
applications.
Mediation modules: In Enterprise Service Bus (ESB)/Process Server terminology, a
mediation module is a type of SCA component. Mediation modules are designed to
perform message transformations, usually between application specific and generic
business objects. Mediation modules are not limited to mediating content; each
modules implementation, called mediation flow, can contain alternative service
invocation steps, along with associated logic routing the control flow to a specific step.
Mediation modules can alias across different protocols (for example, from SOAP/HTTP
to SOAP/JMS) and across different message exchange patterns.
Although mediation modules lack runtime and administrative user interfaces to access
and modify routing logic, ultimately they are more flexible than selectors for service
endpoint aliasing.
Mediation modules are a step up from selectors in terms of flexibility and tooling
support. WebSphere Integration Developer provides a collection of mediation
primitives that assist you in developing complex protocol and endpoint independent
implementations. For example, there are primitives available for logging, event
notification, and request routing.
Mediation with service registry: Thus far, our discussion of options for implementing
endpoint selection ignored the issue of managing service endpoint choices.
Implementations based on selectors, business rules, and mediation modules do not
provide a standard approach for storing, querying, and manipulating information about
service endpoints.
WebSphere Service Registry and Repository can be used in conjunction with
WebSphere Enterprise Service Bus or WebSphere Process Server to enable
dynamicity of service endpoint choices at run time. WebSphere Service Registry and
Repository exposes Java and Web service APIs for managing service endpoints in an
internal registry. WebSphere Service Registry and Repository can also keep track of
classification metadata for describing service endpoints. For example, an endpoint can
be stored in WebSphere Service Registry and Repository along with:
Business information, such as the name of the company hosting the service
endpoint
409
Action rules containing endpoint invocations that are executed depending on the
outcome of selection criteria evaluation
At run time, an application can use the Process Server Business Rule Manager to
modify the business rules. When selection criteria is specified purely in the business
rules expression language, the criteria can be rewritten entirely. Naturally, at run time,
the criteria can only be modified within the limits of the input parameters that are
passed to the business rule. This limitation can be anticipated and mitigated by
passing the entire workflow state to the rule. When the selection criteria is captured
using a Java snippet, it cannot be modified using the rule manager application.
Dynamic assembler: WebSphere Business Services Fabric provides dynamic
assembly capability for workflows. Implementations based on dynamic assembly differ
from the other options, because they rely on an out-of-workflow scope evaluation of
selection criteria for service endpoints. A business analyst can implement the selection
criteria in Composition Studio (a tooling part of WebSphere Business Services Fabric)
using a simple expression language without any need for Java programming skills.
A points of variability implementation using WebSphere Business Services Fabric is
the approach that offers the most flexibility to developers of Composite Business
Services. When deciding to use WebSphere Business Services Fabric, however, it is
important to understand the additional development requirements of WebSphere
Business Services Fabric. For example, preexisting BPEL workflows cannot be
retrofitted to leverage WebSphere Business Services Fabric without changes to the
workflows and the implementation of additional data and logic structures for the
dynamic assembly engine.
410
Given that Composite Business Services are much more complex than basic Web services,
the following points must be considered while customizing composite business service during
their consumption:
Note: Many of these considerations are relevant not only to services but to all kinds of
assets that solve business problems and can be reused as customizable applications in
larger solutions.
Composite business service assets need to be tested for non-functional requirements,
such as performance, security, and availability based on certain benchmarks. The test
results along with the operational environment that was used to conduct the tests need to
be published as part of the supporting documentation for the asset. This will help the
consuming team to tune the environment of its solution for the composite business
service. In fact, publishing these details as attributes of the asset in the asset Repository
can help you decide whether to reuse the asset in a specific context.
The use of commercial or open source third-party software in composite business service
assets needs to be evaluated prior to consumption. This can have a cost impact on
reusing the asset due to licensing issues. You might also consider replacing certain
commercial or open source software used by the composite business service with other
software that might be available for use at a lower cost or that has been mandated for use
by the governance policies.
The use of commercial or open source third-party software in a composite business
service (and in all kinds of assets in general) can cause technical issues related to version
dependencies. For example, the composite business service can require a certain version
of the third-party software and the consuming application can need a different version.
These two versions might or might not reconcile to a single latest version based on the
technicalities of the specific open source software. This can require packaging or
structural changes in the consuming project and the composite business service.
User interfaces are usually built for a composite business service primarily to be able to
test and demonstrate the capabilities of an asset to solve a domain specific problem.
These interfaces are most likely to be customized to match the look and feel of the
consuming application, at a minimum. In certain cases, the user interface can be
discarded, and the business process implementation alone can be reused.
The user registry used by a composite business service is likely to vary based on the
consuming application requirements. As a best practice, we recommend not to use any
registry-specific APIs in the composite business service. Using a standard API, such as
Java Authentication and Authorization Service (JAAS), ensures that the composite
business service is user registry-independent. Consuming applications can switch
registries, most likely to Lightweight Directory Access Protocol (LDAP), based on their
requirements.
411
specific solution. They follow industry standards, such as ISO 200022, NACHA in the banking
domain, and HIPAA and HL7 in healthcare, to name a few.
The assets that are part of the Industry Content Pack are:
Reference business services templates: The reference business services templates
consist of the business services, metadata that includes decompositions of business
services and Web services, and the associated definitions of business policy assertions,
business roles, and business channels, based on the industry business glossary.
Industry Business Glossary that presents a taxonomy of industry terms, with associated
relationships and properties
Industry standards-based Web service interfaces and data types that enable
interoperability across disparate systems in the enterprise ecosystem
Industry-common services that contain specific implementations that are consistently
reused in multiple solutions to enable transactional industry-specific functions, such as
validation, bulking, debulking, transformation, and so forth. These services follow
industry-specific standards.
Industry Business Object Model used as a semantic model for design and development of
service-oriented business solutions
Knowledge assets that can accelerate the use and extension of the prebuilt SOA content
contained in the industry content packs
To understand the content of these assets, let us look at the Banking Payments Pack.
Figure 14-3 summarizes the assets in the Banking Payments Pack. Similar assets are
available as part of the Healthcare, Insurance, and Telecom content packs.
The IBM Banking Payments Pack supports payment processes for financial institutions.
412
Benefits of reusing this content pack to develop composite business service assets are:
The Banking Payments Business Glossary contains a banking payments common
vocabulary that represents the taxonomy of banking terms with associated relationships
and properties based on ISO 20022 payments standards, Electronic Payments
Association, formerly the National Automated Clearing House Association (NACHA)
payments standards, and the IBM Information Framework (IFW) business object model.
You can choose one of the models based on your requirement as the semantic model for
your Composite Business Services. This model forms the basis for defining assertions,
channels, roles, and other metadata for your Composite Business Services. The glossary
is used to define business metadata for reference business service templates that are part
of the content pack as well.
The assets within the Banking Payments Pack leverage payments standards from ISO
20022, NACHA, and IFW. This ensures that the assets that you develop using the content
pack comply to the industry standards.
The business service templates contain a decomposition of the domain into the
application suites, applications, and business services. These business services
represent the reference templates. Each business service has been configured with
channels that can be used to access the service and roles for which the service can be
personalized. The associated Web services that are required by the business service
have been mapped in the template. Sample policies are defined for each template using
the context, content, and contract-based assertions sourced from the business glossary.
Reusing these business services and metadata reduces the time required to assemble
Composite Business Services.
The Banking Payments Business Object Model is an ISO 20022 payments
standards-based business object model that represents the conceptual view of the
payments domain through business objects. The Business Object Model is a logical data
model that can be used for implementing operational data stores for your Composite
Business Services.
The Banking Payments Service Interfaces contain banking payment-specific schemas
and Web service interfaces based on a subset of Interface Design Model (IDM) of IFW.
The Banking Payments Common Services is based on ISO 20022 and NACHA payments
standards. These are basic interfaces and services that can be reused in your Composite
Business Services.
The following steps summarize the tasks that need to be done to develop a composite
business service reusing the assets in the content packs:
Note: The following summary of steps gives an overview of the key tasks that need to be
performed to reuse the assets in the Industry Content Pack. An exhaustive list of steps
required to reuse these assets is out of the scope of this book.
1. Leveraging the Service-Oriented Modeling and Architecture (SOMA) process, identify the
assets from the content pack that can be reused.
Important: Steps 2 through 6 are performed using WebSphere Integration Developer.
2. The business services templates are available as SCA modules. Service interface assets
are represented as SCA libraries. Import the templates and libraries that have been
identified for reuse. Note that the use of a template might mandate the need of the
common services and interface libraries, because these libraries are reused by the
templates.
413
414
Use WebSphere Service Registry and Repository as a central service Repository in the
organization and use the integration features of WebSphere Service Registry and
Repository and IBM Tivoli Composite Application Manager to feed operational
information about service usage from the management infrastructure to WebSphere
Service Registry and Repository. WebSphere Service Registry and Repository stores
information, such as metadata, associated with the related services for users and
applications to access it when needed. For more information, refer to Chapter 15,
Managing service assets on page 425.
Rational Asset Manager contains a feature to rate assets that are stored in it. Services
consumed from the asset managers can use the feedback facility provided by the
repositories. Refer to Chapter 10, Consume reusable assets on page 281 for more
information about Rational Asset Managers feedback capability.
415
Al Aarkashan, the SOA architect, received the notification sent by Bob and logged in to
Rational Asset Manager to look at the newly created business process, as shown in
Figure 14-5.
Figure 14-5 Search for Determine Applicant Eligibility process model asset
Al then used Rational Requisite Pro to create the requirements specification of this process
and Rational Software Architect to create analysis and design models. When Al finished, he
also used Rational Asset Manager Web interface to submit these new assets to the
Repository (he created new Requirement and Software Design assets). He also created a
relationship between these new assets and the business process asset submitted by Bob.
Al then sent an e-mail notification to Deb Devak (the Service Developer at ZYX Electronics) to
inform her about the newly loaded assets and to request that Deb start to design and
implement the service. Deb received the e-mail, searched in Rational Asset Manager for the
newly produced assets, and looked at the skeleton implementation produced by Al.
Deb used WebSphere Integration Developer and WebSphere Process Server to assemble
the process choreography and to implement and test the necessary services that are part of
the choreography.
Deb had previous experience using Spring from her time at a previous employer. However,
rather than download the asset from the Internet, she searched in the Repository to learn
whether it was available to be used and if so, what version. As shown in Figure 14-6 on
page 417, Spring Version 2.1 was indeed available for reuse on ZYX projects.
Important: According to the governance policy in ZYX Electronics, developers need to use
Rational Asset Manager for reusable frameworks, such as the Spring framework, in order
to avoid individual employees downloading content from the Internet, which might have
potential copyright and licensing issues.
416
Deb then proceeded to download the artifacts associated with the Spring V 2.1 asset. Also,
based on her previous experience with the asset, she decided to rate this asset and gave it 5
stars using the Rating tab as shown in Figure 14-7.
When Deb verified that the service implementation worked correctly, she generated the
Eligibility EAR to be used for deployment. When she generated this EAR file, she decided to
add the implementation and service interface to Rational Asset Manager and associate them
with the business process they support and the design model, which drove the creation, as
shown in Figure 14-8 on page 418.
417
Because Deb already used Eclipse, she used the Rational Asset Manager Eclipse interface
to create these new Service Implementation and Service Interface assets. To create the new
Determine Applicant Eligibility Service Interface asset, she followed these steps:
1. Switch to the Asset Management perspective by clicking Asset Management as shown
in Figure 14-9.
Deb had already created a connection to the Rational Asset Manager Repository, so she
did not have to create it again. For detailed steps of creating a connection to the Rational
Asset Manager Repository using the Rational Asset Manager Eclipse Interface, go to
A.2.3.2, Eclipse client installation on page 655
2. Right-click in the whitespace of the Asset Explorer view and select New Asset as
represented in Figure 14-10.
3. Complete the New Asset window as shown in Figure 14-11 on page 419, and click Next.
418
4. Click Next to skip the next window in the wizard, because Deb did not enter any asset
attribute information.
5. Select the Business Planning and Sales categories for the asset and then click Next as
shown in Figure 14-12 on page 420.
419
420
6. Select the Determine Applicant Eligibility.DOC and Eligibility.wsdl files from her
workspace to be associated to the asset and click Finish as shown in Figure 14-13.
After Deb completed these steps, the Eligibility Service Interface asset icon representation
contained a red X as shown in Figure 14-14, which means something was missed with the
asset, and Deb was unable to complete the submission process until it is resolved.
To fix the problems, Deb went to standard Eclipse Problems view and she discovered that
she had not associated the WSDL file to the asset as Figure 14-15 on page 422 shows.
421
This constraint is added by default to the Service Interface asset type to verify that all service
interface assets have at least a WSDL file describing the service.
So Deb selected the Content tab to add the Eligibility.wsdl file to the asset. And, because she
had also forgotten to create a relationship between this service interface and the process
model, she created a Fulfills relationship between these assets as shown in Figure 14-16.
Figure 14-16 Establish relationship between service interface and process model assets
To submit the asset to the Rational Asset Manager Repository, Deb clicked Submit.
Because it was configured by default in the SOA Model, the Service Interface asset must
follow a review process, so Deb selected to follow this review process as shown in
Figure 14-17.
Figure 14-17 Submit the asset for approval through the review process
The review process configured for the Service Interface asset type is similar to the one
described and explained in Chapter 11, Manage reusable assets on page 303 for reviewing
open source frameworks. Chapter 11, Manage reusable assets on page 303 provides more
information about the review process and how reviewers can use the Rational Asset Manager
Web interface and Rational ClearQuest to review the asset.
After adding the Eligibility service interface to Rational Asset Manager, the service
implementation code needed to be added and associated with this service interface. Deb
used the same Rational Asset Manager Eclipse interface and followed the same steps
previously described for the Service Interface asset type. The only difference was that the
constraints associated to each asset type were different. The Service Implementation asset
type has three possible constraints placed upon it:
First, it must be related to a Service Interface asset.
422
It must contain at least one artifact labeled as Binary. In the case of service
implementation, this must be the .war, .ear, or other executable file supporting the
services implementation and able to execute.
One other optional constraint is the labeling of a deployment descriptor file.
423
424
15
Chapter 15.
425
This section provides details about integrating these repositories for effective asset
management. Before we go into the details, it is important to understand how this integration
can help you in better service management. Assuming that the products mentioned here
have been configured for integration:
Consider this scenario regarding a under-performing service:
You can use the service operational data that is fed into WebSphere Service Registry
and Repository from IBM Tivoli Composite Application Manager to identify defects in
the services.
You can find this service in WebSphere Service Registry and Repository and navigate
to the corresponding asset in Rational Asset Manager directly from WebSphere
Service Registry and Repository and raise a defect in Rational ClearQuest using the
Rational Asset Manager-ClearQuest forum integration feature.
You can track the status of the defect from Rational Asset Manager. Using the
integration between ClearCase and Rational Asset Manager, developers can source
the asset from Rational Asset Manager into ClearCase to fix the defect. When the
asset has been updated in Rational Asset Manager with the fix, and its review process
has been completed, you can publish the service back to WebSphere Service Registry
426
and Repository. In this way, you can effectively manage assets from a central
Repository (Rational Asset Manager) while using Rational Asset Managers integration
features to work with the capabilities of other related products.
By sourcing technical service metadata from WebSphere Service Registry and Repository
to assemble Composite Business Services in WebSphere Business Services Fabric, you
can manage updates to service metadata from a single Repository (WebSphere Service
Registry and Repository) without having to make changes in multiple repositories, thus
improving developer productivity and metadata consistency across the organization.
The following sections detail the integration of Rational Asset Manager with WebSphere
Service Registry and Repository and the integration of WebSphere Business Services Fabric
with WebSphere Service Registry and Repository.
For details about integration of Rational Asset Manager with Rational ClearQuest and
Rational ClearCase, refer to Appendix A, Rational Asset Manager: Installation and
administration on page 637.
427
As a result of synchronization:
A category called service registry is created in the Rational Asset Manager for the data
retrieved from WebSphere Service Registry and Repository. All of the classifications,
WSDLs, XSDs, and other data brought in from WebSphere Service Registry and
Repository are stored in this category.
The unique ID of the document in WebSphere Service Registry and Repository is also
brought in to the Rational Asset Manager to help users relate between the Asset Manager
and WebSphere Service Registry and Repository.
A link called bsrURI is created and associated with the replicated document in the
Rational Asset Manager. Users can click this link to navigate to view the service metadata
in the WebSphere Service Registry and Repository Web interface.
WSDL
XSD
XML
Web Services Policy Framework (WS-Policy)
Service Component Architecture (SCA) Module
You need to create a WebSphere Service Registry and Repository server configuration in
order to be able to publish services to the WebSphere Service Registry and Repository. Refer
to Appendix A, Rational Asset Manager: Installation and administration on page 637 for
more details about how to configure the Rational Asset Manager for the WebSphere Service
Registry and Repository connectivity. When an asset is published into the WebSphere
Service Registry and Repository:
A concept is created in the WebSphere Service Registry and Repository with the name of
the asset. This new concept contains the ID and the version of the asset that was in the
Rational Asset Manager.
Note: A WebSphere Service Registry and Repository concept can be used to represent
anything that does not have a physical document in the WebSphere Service Registry
and Repository. For detailed information about WebSphere Service Registry and
Repository concepts, refer to the WebSphere Service Registry and Repository
Handbook, SG24-7386.
The individual artifacts that are selected for publishing, such as WSDLs, XSDs, and so
forth, are then published. You can overwrite the authentication credentials for the
WebSphere Service Registry and Repository that are part of the WebSphere Service
Registry and Repository configuration information in the Rational Asset Manager with a
new set of credentials while publishing service metadata to the WebSphere Service
Registry and Repository. You can select specific documents that are part of the Rational
Asset Manager asset to be published to the WebSphere Service Registry and Repository.
After the artifacts are successfully published, you might see them as custom relationships to
the new concept that was created for the asset in the WebSphere Service Registry and
428
Repository. You can also see the link to the Rational Asset Manager asset as a custom
property of the published document in the WebSphere Service Registry and Repository.
When Rational Asset Manager tries to synchronize its contents with WebSphere Service
Registry and Repository, it creates a single asset shadowing the WebSphere Service
Registry and Repository service metadata concept that was created as a result of the publish
operation. Rational Asset Manager also creates a content artifact for each WebSphere
Service Registry and Repository service document related to the WebSphere Service
Registry and Repository service metadata concept. The shadow asset is linked to the original
asset that was used to publish to WebSphere Service Registry and Repository. This is
necessary, because these services can undergo any kind of versioning or life cycle changes
at the WebSphere Service Registry and Repository level when they are in the WebSphere
Service Registry and Repository. By having the asset in the Rational Asset Manager linked to
the published data in the WebSphere Service Registry and Repository, users can know which
artifacts were originally used to publish the service and what the current status of the service
is in the WebSphere Service Registry and Repository.
Figure 15-2 summarizes the publish and synchronization tasks that happen as part of the
Rational Asset Manager and the WebSphere Service Registry and Repository integration.
Figure 15-2 Rational Asset Manager and WebSphere Service Registry and Repository integration
429
Figure 15-2 on page 429 shows the steps that are performed by Rational Asset Manager
when the CreditCheckService asset is published to the WebSphere Service Registry and
Repository. The box with a dotted outline in Figure 15-2 on page 429 represents a logical
grouping of the concept and the documents in WebSphere Service Registry and Repository
that resulted from the publish operation.
Figure 15-2 on page 429 also shows the steps that are performed by Rational Asset Manager
when it is configured to synchronize service metadata from WebSphere Service Registry and
Repository. Figure 15-2 on page 429 shows two synchronize operations to differentiate the
steps that are performed during the synchronization of WebSphere Service Registry and
Repository content that has been published from Rational Asset Manager from the steps that
are performed to synchronize content that was found in WebSphere Service Registry and
Repository but was not published from Rational Asset Manager. However, in reality, these
two types of assets are synchronized during a single attempt to synchronize.
Note that there is only one shadow asset for the CreditCheckService. This shadow for the
WebSphere Service Registry and Repository concept holds the CreditCheck.wsdl and
Account.xsd as its contents. The Transformation.wsdl is an example of a service found in
WebSphere Service Registry and Repository that was not published from Rational Asset
Manager.
430
User-defined roles
The access control provided by the use of J2EE security roles within WebSphere Service
Registry and Repository is very coarse-grained. It is only able to control who can access the
WebSphere Service Registry and Repository Web user interface or the WebSphere Service
Registry and Repository API methods themselves. It is not able to control access to the
objects on which the WebSphere Service Registry and Repository API methods operate.
In order to provide more fine-grained access control functionality, WebSphere Service
Registry and Repository provides an authorization component that allows additional roles to
be defined and for permissions to be added to these roles. User or group principals must be
explicitly mapped to these roles in order for the principal to have the entitlement (permissions)
associated with the role.
When a method is invoked on the API, WebSphere Service Registry and Repository uses the
authorization component to determine whether the user is authorized to perform the
Chapter 15. Managing service assets
431
requested action on the target object or objects. Therefore, in a secure environment, each
method invocation on the WebSphere Service Registry and Repository API results in the user
being authorized twice: one time for standard J2EE role-based access control and one time
for the more fine-grained access control provided by WebSphere Service Registry and
Repository.
Note: Any roles that are defined to the authorization component in WebSphere Service
Registry and Repository are completely separate from the J2EE security roles defined
within the deployment descriptors for the WebSphere Service Registry and Repository
application. At run time, WebSphere Application Server is only aware of the Administrator
and User J2EE security roles.
To simplify the installation and configuration of WebSphere Service Registry and Repository,
the installation process creates roles within the WebSphere Service Registry and Repository
authorization component that match the J2EE security roles. That is, the installation process
creates an Administrator and a User role within the WebSphere Service Registry and
Repository authorization component. It also maps the same users and groups to these roles
that are mapped to the J2EE security roles.
Permissions
As shown in Figure 15-3, a permission within WebSphere Service Registry and Repository
encapsulates an action and the target objects on which it can be performed. Adding a
permission to a role grants the users who are mapped to that role the permission to perform
the specified action on the specified target objects.
Permissions can be configured with name, action, and target properties. The name of the
permission is used to identify the permission within WebSphere Service Registry and
Repository. The action property for a permission specifies the operation that the permission
432
authorizes. In addition to the create, retrieve, update, and delete operations, other valid
actions include control over state transitions and governance of the objects in WebSphere
Service Registry and Repository. The target property for a permission specifies the objects in
WebSphere Service Registry and Repository to which the permission applies. Examples of
valid targets are an XSD document, a WSDL document, and a SCA Module, to name a few.
Default permissions
WebSphere Service Registry and Repository adopts a permissive approach to access control
in the authorization component. This means that access to all of the artifacts in WebSphere
Service Registry and Repository is unrestricted by default. This approach allows users to
continue to access objects in WebSphere Service Registry and Repository when security is
enabled without the need to define permissions that explicitly grant them access to these
objects. However, when a role is explicitly granted access to a set of target objects in
WebSphere Service Registry and Repository, all other roles are implicitly denied access to
that set of objects. In this situation, in order for other roles to access the same set of target
objects, each role must also be explicitly granted access to the set of objects.
For example, if you add a permission to the Administrator role that granted its members
permission to create WSDLDocument objects in WebSphere Service Registry and
Repository, all other roles that were defined to the authorization component can no longer
create WSDLDocument objects. In order to grant users in a Developer role the permission to
create WSDLDocuments, you need to add the same permission to this role.
WebSphere Service Registry and Repository also defines default permissions for
Administrator and User roles.
433
434
Manage changes business service: To view, approve, or reject metadata changes and
to publish approved changes to IBM Business Services Repository: The governance
process enqueues the service metadata changes in an approval system for immediate
pass-through. While automatic approval of changes is the preferred process in a
development environment, deployments in other environments might necessitate a
designated approver for all metadata changes. Using the Manage Changes business
service, the approver can sanction or reject business service metadata submitted by IBM
Business Services Composition Studio users. After approving the changes, the approver
or the designated user must publish the approved change lists to IBM Business Services
Repository. Thus, only authorized individuals can approve and publish or reject the
proposed changes to business services metadata.
View change history business service: To view metadata changes that have been
processed through the governance system: Using this business service, a change
Administrator can trace metadata changes published to IBM Business Services
Repository, through visibility into their status, and other pertinent details, as they pass
through the various approval stages.
Import/export business service: To transport content: between environments, for
translation, and for version control: When changes have been made and it is time to
deploy the metadata created in a development Repository to another environment for
testing and ultimately promotion, this is where the import and export of a Fabric Content
Archive is needed. A Governance Administrator can export part or all of the data for a
project to a Fabric Content Archive file, and then import or update this project on to
another system.
Usage scenarios
The following scenarios exemplify the usage of the governance business services:
Scenario 1: Consider an example where an enterprise wants to develop a credit check
business service that will automate the assessment of the credit-worthiness of customers.
Using the Configure Projects and Configure Namespaces business services, you can
create a development project workspace and assign a development team with controlled
access to the business service metadata during the development process.
Scenario 2: To develop and test the credit check business service, you might require two
separate environments. Using the Configure Environments business service, you can
create two named environments, develop and test, and define a scope for each
environment. You can associate one or more of these environments to endpoints defined
by using IBM Business Services Composition Studio. Using the Configure Repository
business service, you can associate these environments with Repository instances.
Scenario 3: During the development process or later, you can export the project that you
created in Scenario 1 to other deployments, such as a test or production environment. A
prerequisite to exporting a project is exporting the environments associated with the
project. Therefore, you export the develop and test environments that you have created
in Scenario 2 before you export the project.
Other requirements, such as providing multilingual support for the business service to cater to
a global market, necessitate externalizing and translating user-facing service elements.
Maintenance of the service versions, such as the alpha, beta, and release versions, is also a
key requirement. The Import/Export business service provides the functionality to fulfill these
requirements.
435
Figure 15-4 WebSphere Service Registry and Repository and SOA Management
Registered services are managed in the WebSphere Service Registry and Repository. This
information is accessed by multiple actors, including the Service Provider (registering
services) and the Service Consumer (looking for services to consume).
The monitoring and management infrastructure uses this information about registered
services to enhance its understanding of the topology and characteristics of the services in
the monitored SOA. This information can include immediate details about service endpoints.
It can also consist of a meaningful description of service interfaces and behavior, or it can
provide a formal description of relationships across services and other SOA citizens, such as
business processes, consumers, and providers. Based on this information, the Monitoring
and Management infrastructure can enhance its view of the managed resources and their
topologies.
The monitoring and management infrastructure then feeds back operational data that it
collects about the observed services to the service registry and Repository. This data has
been captured and collected at run time by the observation points from the running services
that are part of the managed resources. Various elements of the runtime behavior of the
services can be collected, such as the average response time, the fault rate, the size, the
frequency of the messages, and so on.
These operational elements are used to further enrich the service information model
managed by the service registry and Repository, therefore, allowing other factors in the SOA
to use this information.
437
IBM Tivoli Composite Application Manager for SOA provides the management function for
managing the services and mediations in a service-oriented architecture (SOA) running on
multiple application servers and SOA infrastructures. For supported environments, IBM Tivoli
Composite Application Manager for SOA monitors and performs simple control of message
traffic between Web services in the SOA. IBM Tivoli Composite Application Manager for SOA
relies on a distributed network of data collectors to feed data into IBM Tivoli Monitoring for
analysis and management.
The integration between IBM Tivoli Composite Application Manager for SOA and WebSphere
Service Registry and Repository can be broken down into two key scenarios:
WebSphere Service Registry and Repository Discovery Library Adapter (DLA) discovers
services and static relationships between service artifacts that are registered with
WebSphere Service Registry and Repository. The data discovered by the DLA is
displayed in the new Services Management Workspace within the Tivoli Enterprise Portal.
This integration also includes the ability to discover and display certain XML-based
metadata files associated with a service and extracted from WebSphere Service Registry
and Repository.
IBM Tivoli Composite Application Manager for SOA sends status events back to
WebSphere Service Registry and Repository when a situation is detected for a service
port and operation. This mechanism can be used to enrich service metadata in
WebSphere Service Registry and Repository with additional operational information that is
monitored and fed back by IBM Tivoli Composite Application Manager for SOA. Providing
coarse-grained information about service health allows registry users, such as mediations,
to dynamically select services and human beings to choose a specific service to access.
This book focuses on how the exchange of information between the WebSphere Service
Registry and Repository and the IBM Tivoli Composite Application Manager for SOA can be
used to gain insights about services as reusable assets. In other words, it tries to show how
the integration of the two products can be used to answer questions, such as:
Which of the services are registered in the WebSphere Service Registry and Repository
but not being used?
Which of the services are being used but are not registered in the WebSphere Service
Registry and Repository?
Which of the registered services fault frequently?
The answers to these questions coupled with the integration features of the various IBM
repositories help you better manage your assets, thus enhancing their reusability across the
organization.
Important: A detailed description of the integration of the WebSphere Service Registry
and Repository and IBM Tivoli Composite Application Manager for SOA is out of the scope
of this book. For more information about how to configure the products for integration and
the benefits of the integration, refer to the WebSphere Service Registry and Repository
Handbook, SG24-7386.
438
Tivoli Composite Application Manager for SOA monitoring agents and retrieved from Tivoli
Enterprise Monitoring Server.
WebSphere Service Registry and Repository Library Adapter discovers the
relationships between service ports, operations, services, port types, and metadata
documents from WebSphere Service Registry and Repository. WebSphere Service
Registry and Repository can process Web Services Description Language (WSDL) and
other definition files to determine these static relationships.
Business Process Execution Language for Web Services Discovery Library Adapter
discovers the relationships between port types, operations, and business processes from
BPEL files.
Using these adapters:
Observed services are discovered using IBM Tivoli Composite Application Manager for
SOA Discovery Library Adapter from the running agents monitoring operational
applications and services.
Registered services are discovered using WebSphere Service Registry and Repository
Discovery Library Adapter by querying WebSphere Service Registry and Repository for
published services and related information.
IBM Tivoli Composite Application Manager for SOA captures all this information in a
Repository called the Common Object Repository. The information in the Common Object
Repository must be reconciled to link observed and registered services together and ensure
consistency between designed and operational states of services.
After configuring the adapters and other integration elements of the WebSphere Service
Registry and Repository and IBM Tivoli Composite Application Manager for SOA, the service
information can be viewed in the Tivoli Enterprise Portal using the Services Management
workspace.
This workspace provides topology views to help you with the following tasks:
View the services and service relationships that are registered with WebSphere Service
Registry and Repository that have been discovered by WebSphere Service Registry and
Repository DLA and imported into the Tivoli Common Object Repository.
View service metadata documents from WebSphere Service Registry and Repository.
View the service ports and operations that are discovered by the IBM Tivoli Composite
Application Manager for SOA DLA and imported into the Tivoli Common Object
Repository. Compare a set of service definitions with a set of discovered services in order
to verify that services are implemented and operating as designed.
View the business processes that use activities that are implemented by Web services
that are discovered by the IBM Tivoli Composite Application Manager for SOA DLA or the
WebSphere Service Registry and Repository DLA.
The business process and service relationship data is discovered by the BPEL DLA and
imported into the Tivoli Common Object Repository.
439
Reconciliation of the observed and registered service information helps to point out the
following situations regarding asset (service) reuse:
Services observed but not registered: Assuming that registering a service in the
WebSphere Service Registry and Repository is a prerequisite to a broader reuse of that
service, this situation might reflect one of the following scenarios:
The operational services, which are currently observed, are not the ones targeted for
exposure and reuse. These observed services might be only test services whose
implementation is due to change.
The observed services can reflect the existence of service assets in the Rational Asset
Manager that are not registered in the WebSphere Service Registry and Repository.
The observed services can reflect the existence of reusable assets in the organization
that have not been published and registered in the repositories.
Knowing these facts about the assets can help enforce governance policies on the assets,
thus, enabling better reuse.
Services registered but not observed: This situation might indicate:
The fact that the common services, which are registered in the WebSphere Service
Registry and Repository and potentially highly reused, are missing monitoring
capabilities
The fact that certain registered services are not being used by consumers probably
due to defects in the service, such as poor performance and so forth
This information about the assets can lead to the identification of defects in the services,
thus, helping to improve their quality.
Services registered and observed: This situation can prove to be a sound foundation to
enable and understand common service reuse.
Fault_610:
MessageSize_610
MaxMessageSize_610
ResponseTimeCritical_610
ResponseTimeWarning_610
MaxResponseTimeCritical_610
MaxResponseTimeWarning_610
These situations are triggered when there are faults caused by Web services, messages
sizes, and response times for the Web services that exceed the configured thresholds. These
predefined situations can be configured with custom threshold values or custom situations
can be defined to monitor specific attributes of the services. When a situation event is
detected, the properties of the service in WebSphere Service Registry and Repository are
updated with the operational metadata.
From a service management perspective, you can use this information to measure the
utilization of the service assets and plan service migration/retirement strategies accordingly.
The effectiveness of the SOA can be captured in the service information where service usage
can directly reflect the success of the overall reuse policy of services across consumers.
Defects might be identified in the services (for example, based on the fault situation event)
and might be raised in Rational ClearQuest by tracing the asset artifacts from WebSphere
Service Registry and Repository to Rational Asset Manager and utilizing the integration
features of Rational Asset Manager and Rational ClearQuest.
This section highlights these reports with a focus on how these reports can help you better
manage service assets.
441
442
5.3.1, Asset governance on page 66 mentions the various models through which the reuse
team can be funded during the Planning phase. One variation to the Payment for assets and
services model is to pay the reuse team based on every usage of an enterprise-wide
common set of services, which can be reused at run time by multiple departments in the
organization. This report can be used to find the amount that needs to be charged to the
departments that use the services, and a percentage of this amount can be used to maintain
the reuse team.
The report in Figure 15-5 also shows the Claims Submission asset being used by multiple
organizations. It also shows the volume of usage by each organization and gives the total cost
charged to the organization.
443
response time in milliseconds. The number of transactions for the service is an indication of
how well the service is being used at run time similar to the volume metric for the business
service in the Service Usage report.
A similar type of service performance report can be generated at the service endpoint level,
as shown in Figure 15-6, for fine-grained information about which specific endpoint is getting
used the most or the least. Note that the performance reports can be filtered based on the
context parameters, such as the organization, duration, business services, and so forth.
Figure 15-6 Service Endpoint Performance report in WebSphere Business Services Fabric
The report also shows the ratio of the Web service requests that are serviced to the total
number of Web service requests made. This metric can be used to analyze the availability
requirements that are expected from the service at run time. A low availability value can
indicate a defect in the asset with respect to non-functional requirements.
444
The Service Maturity Model has seven maturity levels from silo to dynamically reconfigurable
services. It also has seven domains, each of which has an increasing level of maturity.
Figure 15-7 on page 446 shows the maturity levels and the characteristics of each of the
domains at the various levels of maturity: the level of decoupling and the amount of flexibility
achievable at each stage of maturity.
445
https://w3.webahead.ibm.com/w3ki/download/attachments/733007/SIMM+Models+3.0+V2+-+July+6+2007.ppt?version=1
446
a contract among suppliers, consumers, and brokers who can build their own ecosystem
for on demand interaction.
Level 6 - Virtualized services: In this virtual infrastructure level, the organization creates
a virtualized infrastructure to run applications. It achieves this level after decoupling the
application, its services, components, and flows. It externalizes its monitoring,
management, and events (common event infrastructure).
Level 7 - Dynamically reconfigurable services: The organization, in the ecosystem
integration level, now creates a virtualized infrastructure to run applications. It achieves
this level after decoupling the application, its services, components, and flows. It
externalizes its monitoring, management, and events (common event infrastructure).
Note: Refer to the article Increase flexibility with the Service Integration Maturity Model at
this Web site for more information about the Service Integration Maturity Model:
http://www-128.ibm.com/developerworks/webservices/library/ws-soa-simm/
447
2. Rational Asset Manager knows which file types can be published to the WebSphere
Service Registry and Repository so it only showed Duncan the WSDL file as the file to be
published to the service registry (although the asset also had other artifacts, such as a
Word document explaining the service interface) as shown in Figure 15-9.
Figure 15-9 Select WSDL file to publish to WebSphere Service Registry and Repository
3. Duncan selected the EligibilityService.wsdl file. Duncan then clicked Next to go to the
following windows where he selected the registry to which to add the asset and entered
his user name and password as shown in Figure 15-10.
4. Duncan clicked Confirm to verify that the asset information and selected Repository were
correct, and then clicked Publish as shown in Figure 15-11 on page 449.
448
Figure 15-11 Confirmation page to publish WSDL file to WebSphere Service Registry and Repository
5. When Duncan clicked Publish, the publishing process began. It took a few minutes for
Rational Asset Manager to communicate and publish the Eligibility Service Interface to the
development WebSphere Service Registry and Repository. When completed, Duncan was
presented with a message indicating that the publishing was successful, as shown in
Figure 15-12.
The publishing process from Rational Asset Manager to WebSphere Service Registry and
Repository created:
A new service metadata concept in WebSphere Service Registry and Repository as
shown in Figure 15-13 on page 450. There was a link to the Rational Asset Manager asset
as a custom property of the published concept in the WebSphere Service Registry and
Repository.
449
Figure 15-13 New service metadata concept in WebSphere Service Registry and Repository
A new service document for the WSDL artifact was selected in Rational Asset Manager as
shown in Figure 15-14.
Figure 15-14 New service document concept in WebSphere Service Registry and Repository
A custom relationship from the service metadata concept was established to the service
document artifact as shown in Figure 15-15 on page 451.
450
Figure 15-15 Custom relationship between service metadata concept and service document
Upon execution of the Rational Asset Manager and WebSphere Service Registry and
Repository synchronization process, a new asset was created in Rational Asset Manager
representing the published artifact as shown in Figure 15-16.
451
Figure 15-17 Rational Asset Manager and WebSphere Service Registry and Repository integration
After the service was published to the service registry, Patricia Moon, the Product Manager at
ZYX Electronics, received a notification that the Eligibility service had been published to the
service registry and that it was ready for use in applications that need the service. She sent a
notification to Irene Devin (the Service Assembler at ZYX Electronics) to inform Irene of the
availability of the service.
The browser-based portal applications that needed the account verification reused the
Eligibility service. However, this service did not solve the reuse issue completely.
Over a period of time, as ZYX Electronics was getting deeper into its SOA transformation,
more and more processes needing the Eligibility service were identified. The Eligibility
process needed to be accessed by other process automations similar to the Business to
Business (B2B) channel interaction. These interactions posed security constraints on who
was allowed to access the service through the B2B channel compared to the portal channel.
In addition, according to ZYX Electronics business policies, the portal channel needs a
higher priority of service than the B2B channel, because the portal channel runs in real time.
452
To enhance the reusability of this service, ZYX Electronics decided to re-engineer the
Eligibility service, which is a simple choreographed service, into a business service that can
behave dynamically based on the context (in this case, the channel of access) of the request.
Irene, the service assembler, sourced this service from WebSphere Service Registry and
Repository into the Business Service Repository (that is part of WebSphere Business
Services Fabric) by using the WebSphere Service Registry and Repository integration
features in WebSphere Business Services Fabric. Irene then used the WebSphere Business
Services Fabric Governance Manager to create the Eligibility business service. She then
used the Composition Studio plug-in for Eclipse and created the necessary channel, role, and
policy metadata for the business service. Multiple service implementations were coded for the
Eligibility service to handle various levels of performance. The policies were designed to
select high performance endpoints for the service requests that were made on the portal
channel. The service was tested and deployed. The service artifacts were updated in Rational
Asset Manager.
Based on these updates, the Eligibility business service was made available with enhanced
reusability. Consuming applications can easily configure the channels, roles, and policies
associated with the service based on their requirement without having to write code. The
business level metadata updates were controlled by governance mechanisms and were
driven by visual tooling that eliminates the need for technical resources to change service
metadata. Thus, ZYX Electronics moved one step ahead in reusability by bringing its IT into
alignment with its business.
453
454
Part 4
Part
Patterns
In this part, we introduce a specific type of assets known as Patterns. As shown in Figure P-4,
we will look at patterns as assets and then how we can produce, consume, and manage
these assets. This section builds on the content that was described in Part 2, Reusable
Assets on page 123. In addition, there is a relationship between the content in Part 3,
Service Assets in an SOA on page 333 and in this part. Service assets can be generated by
Patterns. In addition, we will use best practices in Services as the basis for creating Pattern
assets for generating Services.
Part 1:
Introduction
Part 2:
Reusable Assets
Introduction to
Asset-Based
Development
Adopting
Asset-Based
Development
Process and
Tooling
Configuring
Asset
Management
Case Study
Overview
Produce,
Consume, and
Manage Assets
Part 3:
Services
Services as Assets
Produce, Consume,
and Manage Service
Assets
Appendixes
Rational Asset
Manager
Installation and
Administration
Process
Integration
Part 4:
Patterns
Patterns as Assets
Produce, Consume,
and Manage Pattern
Assets
455
456
16
Chapter 16.
Introduction to patterns
This chapter introduces patterns, pattern-based engineering, and how they relate to
Asset-Based Development.
457
458
16.2 Patterns
A pattern is defined as a proven solution to a recurring problem. The concept was originally
developed in architecture (of buildings), but it has been adapted to software development
starting with Design Patterns: Elements of Reusable Object-Oriented Software, by Gamma et
al.
Gamma and the other authors describe each of their twenty-three (23) patterns by specifying
a name, a problem description, a solution, and the consequences from use. We call this
description a pattern specification.
The solution that a pattern describes is abstracted from the reference solution. The value of
using a pattern comes from reusing the object roles and interactions, rather than by reusing
concrete algorithms or bodies of code. Concrete implementations can vary significantly.
Implementation language, naming conventions, and the choice of algorithms and data
structures can differ. As a result, considerable effort is still required to apply a pattern in a
particular situation.
When a particular design pattern is repeatedly applied in similar contexts, it has proven
effective to create a tool that helps automate the application. We call this tool a pattern
implementation.
Pattern specification
Pattern recipe
Patterns, or more properly, pattern specifications are clearly reusable assets. But, so are
pattern implementations. This part is about pattern implementations as assets: How to create
them, how to use them, and how to manage them.
459
10010011000100100100100
10010011000100100100100
10010011000100100100100
10010011000100100100100
10010011000100100100100
10010011000100100100100
10010011000100100100100
10010011000100100100100
10010011000100100100100
10010011000100100100100
10010011000100100100100
Problem
Exemplar
(Solution)
Pattern
Pattern
Specification Implementation
Pattern
Recipe
A user pattern
Pattern author
Pattern implementation author Develops the tool that implements the pattern
Asset librarian
Table 16-1 shows how these roles relate to those roles defined in Rational Method Composer
plug-in for Asset-Based Development.
Table 16-1 Pattern author roles and their corresponding Asset-Based Development roles
Pattern authoring role
Pattern user
Asset Consumer
Pattern author
Asset Producer
Asset Producer
Asset Producer
Asset librarian
A single person can, of course, fulfill more than one role. Typically, a pattern authors primary
job responsibilities are in areas other than pattern production. The pattern authors time is
valuable and limited. Because the creation of pattern specifications or pattern
implementations requires specialized knowledge or tools, it can be more cost-effective to
460
have those roles fulfilled by specialists rather than by the pattern author. If the pattern author
also specifies and implements a pattern, close collaboration between the pattern author and
the pattern specification and pattern implementation authors is required.
Models
Transformations
Pattern implementations
Metamodels
Standards
461
Pattern-based engineering is not only a process of pattern selection and application. It is also
a process for pattern identification and for the development of pattern implementations.
Tooling is an essential ingredient to making the development of pattern implementations
cost-effective. Next, we assume that this tooling exists and describe the pattern-based
engineering process.
Figure 16-2 RUP Architecture showing projects phases plotted against disciplines
462
Quality
Budget
463
464
465
Results
The results are:
Pattern implementation tooling not only generated over 50% of the code, but it minimized
the number of components needed in the framework:
Modeling was based on Rational XDE.
466
Pattern implementation tooling was created with the Design Pattern Toolkit (DPTK)
from alphaWorks. DPTK is a precursor of JET.
The team was enabled to make an aggressive schedule for showcasing the next
generation system based on Java/J2EE:
Identified other opportunities for pattern tooling, such as test cases
Factored naming conventions to maximize maintainability of MDD tools
Lessons learned
Test extensively during inception:
Bad news
Good news
Results
The results are:
Identified a pattern and pattern specification, which was distributed to developers
Ultimately, developed a pattern implementation that drastically reduced the work for
developers, while increasing implementation consistency and product quality.
The development team used Rational Application Developer 6.0. The pattern
implementation was developed with Design Pattern Toolkit from alphaWorks.
Lessons learned
Documenting pattern specifications is sometimes not enough to ensure successful pattern
usage:
Good news
Bad news
Good news
467
468
17
Chapter 17.
469
Java beans
In just about every project on which Deb has worked, she sees Java beans. A Java bean is a
simple Java object with a number of properties that are accessed by getter methods and
updated by setter methods. Example 17-1 illustrates a typical Java bean.
Example 17-1 A typical Java bean representing information about a book
package com.zyx.exemplar.beans.library;
/**
* Define a Book Java bean
*
*/
public class Book {
private String author;
private int numberOfPages;
private String title;
/**
* Package private constructor prevents instantiation except through factory
*/
Book() {
}
470
/**
* Return the book author
* @return the author the author
*/
public String getAuthor() {
return author;
}
/**
* Return tne book number of pages
* @return the numberOfPages the number of pages
*/
public int getNumberOfPages() {
return numberOfPages;
}
/**
* Return the book title
* @return the title the title
*/
public String getTitle() {
return title;
}
/**
* Set the book author
* @param author the author to set
*/
public void setAuthor(String author) {
this.author = author;
}
/**
* Set the book number of a pages
* @param numberOfPages the number of pages to set
*/
public void setNumberOfPages(int numberOfPages) {
this.numberOfPages = numberOfPages;
}
/**
* Set the book title
* @param title the title to set
*/
public void setTitle(String title) {
this.title = title;
}
}
Deb is frustrated about Java beans, because:
They are numerous.
They result in little intellectual value in return for the time that is invested to create them.
No two developers at ZYX manage to produce exactly the same results.
471
This latter point is a particularly sore point for Deb, because she had carefully produced a ten
page document discussing how Java beans were to be used at ZYX for the other developers.
package com.zyx.exemplar.beans.library;
/**
* Factory class for beans in the library package
*/
public class LibraryFactory {
/**
* Singleton instance of the LibraryFactory
*/
public static final LibraryFactory INSTANCE = new LibraryFactory();
/**
* Private constructor prevents instantiation.
*/
private LibraryFactory() {
}
/**
* Create a new book instance
* @return the new Book object
*/
public Book createBook() {
return new Book();
}
/**
* Create a new library instance
* @return the new Library object
*/
public Library createLibrary() {
return new Library();
}
}
472
package com.zyx.exemplar.beans.library;
import java.util.ArrayList;
import java.util.List;
/**
* Implement a Java bean representing a Library
*
*/
public class Library {
private final List books = new ArrayList();
... other fields removed
/**
* Return the list of books in the library
* @return a list of Book objects. Will not be <code>null</code>
*/
public List getBooks() {
return books;
}
... other methods removed...
}
Reference solution
Recalling the consultants admonitions, Deb put together a representative Java bean solution.
With the solution, Deb started IBM Rational Software Architect 7.0 and got to work.
These products are based on the open source Eclipse platform. Eclipse was developed by
the Eclipse Foundation. IBM is a member of the Eclipse foundation and contributes
473
significantly to Eclipse development. JET is built on and for the Eclipse platform. In the rest of
this chapter, any reference to Eclipse includes all of the previously mentioned IBM products.
JET is a template language. A template is a sequence of text interspersed with special
annotations that are interpreted by the template language. When a template is expanded,
these annotations are interpreted and typically turned into content. An example of a template
is a form letter created in a work processor. A form letter contains special annotations to draw
names and addresses from a database into the form letter. When the word processor
expands the template against a particular set of database rows, a number of customized
instances of the form letter are produced.
The form letter example illustrates an important element of template languages. Templates
are expanded in a certain context. Form letters are expanded in the context of a word
processor and a backing database. JavaServer Pages (JSP), which are templates, are
expanded in the context of a Web browsers request to a Web application, and that
applications response to the browser.
JET templates are also expanded in a context. In the case of JET, the context is an Eclipse
workspace and an input model. The term input model is a sophisticated term for a form of
structured data. JETs prototypical data model is an eXtensible Markup Language (XML)
document, but JET can be adapted to many other data structures. In this chapter, however,
we will stick with XML.
JET templates are typically not invoked in isolation. Instead, they are grouped together into a
transformation, which evaluates related templates against a single input model. The results
of these template evaluations are then written to the Eclipse workspace. A lot of JETs appeal
is that it lets developers create transformations without much knowledge of Eclipse, its
extension mechanisms, or its application program interfaces (APIs). In fact, JET solutions can
be developed even without knowledge of Java, the language in which Eclipse is typically
extended.
Modeling Project. The M2T goal is to support the development and use of model-to-text
languages within Eclipse. In spite of this move, the EMFT JET name has been retained
(the potential for confusion with JET1 remains).
The M2T project plans to graduate in 2008. At that point, EMFT JET will completely
support the original JET1. Then, the EMFT prefix will be dropped from the name and the
integrated product will be called simply JET. But, this integrated version of JET is not likely
to make its way into IBM products until late 2008.
This book uses EMFT JET (JET2) exclusively. As a result, the book refers to EMFT JET
simply as JET. In screen captures and instructions, however, you will often see the text EMFT
JET.
475
1. Jet Authoring
Input
Model
Reference
Solution
(Exemplar)
JET Transformation
Figure 17-1 JET exemplar-based authoring: working backward from a reference solution
This approach integrates with 16.5, A process for pattern-based engineering on page 462.
The JET authoring tools permit the development of a pattern implementation from a
candidate architecture (as described in 16.5.3, Develop candidate architecture on page 464
at a cost that is incremental to the cost of developing the candidate architecture initially).
Figure 17-2 illustrates the value proposition of using JET authoring for pattern-based
engineering.
Timelines to Value
Solve the problem, solve similar problems via manual pattern application
Legend:
Search asset repository for applicable assets
Solve problem manually
Author pattern implementation to automate solution
Use pattern implementation to solve problem
Figure 17-2 Time to value using JET authoring and pattern-based engineering
Authoring goals
JET authoring has several goals:
Define an input model structure that reveals the patterns abstractions and the desired
points of variability in the pattern.
Account for every file, folder, and project found in the reference solution (these are known
as exemplar artifacts). For each exemplar artifact, either match it to a model element from
which it is directly derived, or mark it as not-of-interest to the transformation.
477
In the next section, we will work with Deb Devaks Java bean problem to illustrate this
process in detail.
478
479
When the exemplar project is in the workspace, create a project to contain the pattern
implementation by following these steps:
1. Click File New Project.
2. Enter jet to filter the available choices.
3. Click EMFT JET Project with Exemplar Authoring, and then click Next.
4. Enter a project name: com.zyx.patterns.beans and click Next.
Note on project naming that JET transformations are extensions (plug-ins) to the Eclipse
environment. Therefore, JET transformations must follow established naming
conventions. The convention is to use reverse domain name order, starting with your
organizations internet domain name (in reverse order). Because ZYX Electronicss
internet domain is zyx.com, the project name starts with this name is reverse order,
com.zyx.
5. Finally, select com.zyx.exemplar.beans (the reference bean solution) in the Exemplar
Scope list, and click Finish.
The wizard creates the JET transformation project and opens the JET transformation
authoring editor. Figure 17-5 shows the editor.
Figure 17-5 The newly created JET project and the JET transformation authoring editor
480
that the pane includes files and folders that are normally hidden by certain Eclipse view
filters. (Notice the .project and .classpath files and the bin directory.)
The right pane, which is titled Transformation Input Schema and Output Actions, declares
the structure of the input model and the transformation actions. Transformation actions
are responsible for the creation of files, folders, or projects.
Finally, the Properties view provides detailed information about the current selection in
the editor.
With the JET transformation project created, Deb is ready to start the exemplar analysis
process.
Questions to ask
When identifying abstractions, it is helpful to ask the following questions:
Is this artifact a manifestation of an abstract concept?
What other artifacts are manifestations of the same concept?
Are aspects of this concept points of variation in the pattern?
Is this concept a subsidiary to another concept that has not already been identified?
481
Figure 17-6 The JET authoring editor after the creation of the first abstraction called beanPackage
482
Figure 17-7 The JET authoring editor after the bean abstraction has been defined
You can read the model description on the right pane as:
A model has a single root element.
The root element has zero or more beanPackage elements.
Each beanPackage element has zero or more bean elements.
483
484
Figure 17-8 The exemplar view with bin deleted and the other files ignored
485
486
Figure 17-10 The renamed action for creating the bean factory class
Deb next considers the artifacts Book.java and Library.java. These are both manifestations of
a single concept, bean. They both represent the Java class that implements the bean.
Therefore, only one action is required to create them. Create the action:
1. Drag Library.java onto bean in the right pane. Name the action bean.java.
2. Drag Book.java onto the Create File: bean.java action.
Figure 17-11 shows the resulting input action.
Figure 17-11 The bean.java action with Book.java and Library.java associated with it
487
The tree in the right pane now indicates that the transformation has two actions:
For each bean instance, Create File: bean.java will be executed. The reference solution
includes two artifacts that must be produced by this action: Book.java and Library.java.
For each beanPackage instance, Create File: factory.java is executed. The reference
solution includes one artifact, LibraryFactory.java, that must be produced by this action.
Each action has a number of action parameters. JET authoring has set several of these
values based on the properties of the exemplar artifact that is used to define the action.
Typically, the pattern implementation author must examine each of these parameters to
determine whether any part of the parameter must derive from the input model or a
calculation based on the input model.
488
Do not hard code the factory class name as LibraryFactory. Deb decides that this class
name derives from the already identified name for the bean package with the text Factory
appended.
Create the new attributes:
1. Right-click beanPackage in the right pane, click New Attribute, and enter srcFolder.
2. Right-click beanPackage again, click New Attribute, and enter basePackage.
3. Right-click beanPackage a final time, click New Attribute, and enter name.
Figure 17-13 shows the results of these actions.
The dialog lets you select a model attribute and insert it in place of the selected text.
Expand beanPackage, select srcFolder and click OK. Figure 17-15 on page 490 shows
the resulting value for the path parameter.
489
Figure 17-15 The XPath expression inserted by the Replace with Model References dialog
The string {$beanPackage/@srcFolder} has replaced the original selection. This is an XML
Path (XPath) expression. JET uses XPath to reference data in the input model. The
expression is interpreted as:
The braces delimit the expression from the surrounding text.
$beanPackage is a reference to the XPath variable beanPackage. JET authoring
defines a variable for each element type. By default, the variable name is the same as
the element type. You can view and change the variable name in the Properties view
for each element type.
The slash (/) separates the steps in the expression, similar to a file system path.
@srcFolder references the srcFolder attribute of the beanPackage element.
You can learn more about XPath in 17.5, An XPath primer on page 518.
3. Define the derived attribute for the directory to contain the generated factory and bean
classes. Select the text com/zyx/exemplar/beans/library, right-click it, and click Replace
with Model Reference.
4. Expand and select beanPackage in the dialog. There is no attribute representing the
directory for the bean classes. To create one, ensure beanPackage is selected, and then
click New. Figure 17-16 shows the resulting Create new derived attribute dialog.
The dialog lets you define an attribute whose value is derived from a calculation. It shows
the attributes name, the text that you selected to create in step 3 (the exemplar text), and
the calculation of the value. The calculation is initially the same as the exemplar text. For
the time being, we will leave the calculation unchanged.
5. Enter dirBeans in the Attribute Name field and click OK. Click OK again in the Replace
with Model References dialog. Figure 17-17 on page 491 shows the resulting path value.
490
Figure 17-17 The path parameter after replacing the beans directory (dirBeans)
6. Define a derived attribute for the factory class name. Select LibraryFactory, right-click it
and click Replace with Model Reference.
7. Expand and select beanPackage and click New.
8. Enter clsFactory as the Attribute Name.
9. In the Calculation field, select Library, and then click Insert Model Reference.
10.Expand beanPackage, click name, and click OK. Figure 17-18 shows the Create New
Derived Attribute dialog.
11.Prior to closing this dialog, modify the XPath expression $beanPackage/@name so that it
ensures that the name is properly formatted for Java names by calling the XPath function
camelCase. Enter camelCase($beanPackage/@name) in place of the original XPath
expression. Remember to retain the braces. Figure 17-19 shows the final result.
Figure 17-19 The clsFactory derived attribute calculation using the XPath camelCase function
12.Click OK to close the dialog, and click OK again to close the Insert Model References
Dialog. The final value of the path parameter is shown in Figure 17-20 on page 492.
491
The action Create File: factory.java is now completely parameterized. However, the
calculation of the derived attribute dirBeans is not complete. In order to complete it, create
another derived attribute representing the Java package into which the bean classes will be
written. Follow these steps:
1. Right-click beanPackage in the right pane, and click New Derived Attribute.
2. Enter pkgBeans as the Attribute Name.
3. Enter com.zyx.exemplar.beans.library as the Exemplar Text and as the Calculation (we
will modify the calculation in the next step).
4. Select com.zyx.emplar.beans in the Calculation field, click Insert Model Reference,
expand beanPackage, select the basePackage attribute, and click OK.
5. Select library in the Calculation field, click Insert Model Reference, expand
beanPackage, select the name attribute, and click OK.
6. Modify the XPath expression $beanPackage/@name by calling the lower-case function,
and creating the XPath expression lower-case($beanPackage/@name). Figure 17-21
shows the final calculation.
7. Next, update the calculation for the dirBeans calculation. Click dirBeans in the right tree.
8. In the Properties view, look at the Calculation parameter. Replace the value with:
{translate( $beanPackage/@pkgBeans, ., / )}
This value uses the XPath function translate to replace the dots in the package name with
the slash character (/).
Figure 17-22 on page 493 shows the final calculation.
492
Finally, the derived attribute calculation for dirBeans depends on the calculated value for
pkgBeans. It is important to ensure that the calculations occur in the correct order.
1. Click the Sort on Calculation Order icon in the JET authoring editor. Figure 17-23 shows
this icon circled.
Figure 17-23 The Sort on Calculation Order icon in the JET authoring editor
2. Right-click pkgBeans and click Move Up. Repeat until pkgBeans is listed higher than
dirBeans in the tree.
3. Click the Sort Alphabetically icon (to the left of the Sort on Calculation Order icon).
493
2. Right-click bean and click New Attribute. Type name and press Enter.
3. Click Create file: bean.java.
4. In the Properties view, select com.zyx.exemplar.beans/src (the Java source folder),
right-click and click Replace with Model Reference.
5. The Replace with Model Reference dialog appears with the srcFolder derived attribute
already selected. (This was the last value that replaced the selected text).
6. Click OK to insert the reference.
7. Select com/zyx/exemplar/beans/library, right-click and click Replace with Model
Reference. The dirBeans derived attribute is automatically selected. Click OK to insert the
reference.
8. Select Library, right-click and click Replace with Model Reference. This time, a new
derived attribute will need to be created to represent the bean class name. Expand the
tree to reveal bean, select it, and then click New.
9. Enter clsBean as the Attribute Name.
10.In the Calculation field, select Library, and click Insert Model Reference. Expand the
tree to reveal bean and its contents, and select the name attribute underneath bean. Click
OK.
11.Surround the XPath expression $bean/@name with a call to the XPath function
camelCase. Figure 17-24 shows the final calculation.
12.Click OK to create the derived attribute. Click OK again to insert the reference into the
path parameter. Figure 17-25 shows the final value for the bean.java actions path
parameter.
Figure 17-25 The completed path parameter for the Create File: bean.java action
494
templates/main.jet
schema.xsd
templates/beanPackage/factory.java.jet
templates/bean/bean.java.jet
Subsequent updates will only update the first two files, unless new actions are created, or one
of the action templates is removed or renamed.
495
Figure 17-26 The JET template factory.java.jet showing editor annotations of replaceable text
496
Figure 17-27 The Problems view shows the information marker for replaceable text
To replace highlighted text with a model reference, you can use the editors quick fix
command:
1. Click anywhere in the text.
2. Press Ctrl-1. Figure 17-28 shows the pop-up list quick fix actions.
497
To finish replacing text, use the navigation and quick fix commands to replace each
highlighted text string with the first proposed fix. There is one exception: the string Library
when it is embedded in the longer string createLibrary, and it is desirable to create a derived
attribute representing the entire string.
3. Create a new derived attribute representing the name of the method that instantiates a
bean. One method is required for each bean, so the derived attribute must be defined on
bean. Expand the tree to find and select bean, and click New.
4. Enter mthdCreate for the Attribute Name.
5. Select Library in the Calculation field, and click InsertModelReference.
6. Click clsBean, and then click OK. Figure 17-30 on page 499 shows the resulting derived
attribute dialog.
498
7. Click OK to create the attribute, click Replace, and then click Close to insert the model
reference and close the Find/Replace dialog.
499
/**
* Create a new library instance
* @return the new <c:get select="$bean/@clsBean" /> object
*/
public <c:get select="$bean/@clsBean" /> <c:get select="$bean/@mthdCreate" />() {
return new <c:get select="$bean/@clsBean" />();
}
}
Follow these steps to make the block repeating:
1. Just prior to the Java doc comment for the parameterized create method, insert a JET
c:iterate tag:
<c:iterate select=$beanPackage/bean var=bean>
2. At the end of the parameterized method, insert a closing c:iterate tag:
</c:iterate>
3. Remove the method createBook and its Java doc comment. It is not needed in the
template.
Example 17-5 shows the modified template with the iterate block highlighted in bold.
Example 17-5 The factory.java.jet template with a repeated block.
500
One final change is required. The Java doc comment in the create method block still
references the text library. Replace it with a reference to the bean name:
1. Select the text library. Right-click and click Find/Replace with Model Reference.
2. Expand the tree to expose bean and its attributes. Select the attribute name.
3. Click Replace and then Close.
The factory template is now complete. Save and close the editor. Click File Save and then
File Close.
mthdSetter
varField
varLocal
The name of a Java local variable that will contain the value
501
varField
502
/**
* Set the <c:get select="$beanPackage/@name" /> <c:get select="$property/@name"
/>
* @param <c:get select="$property/@varLocal" /> the new <c:get
select="$property/@name" />
*/
public void <c:get select="$property/@mthdSetter" />(<c:get
select="$property/@type" /> <c:get select="$property/@varLocal" />) {
this.<c:get select="$property/@varField" /> = <c:get select="$property/@varLocal"
/>;
}
</c:iterate>
<%-- define getter methods for 'listProperty' elements --%>
<c:iterate select="$bean/listProperty" var="listProperty">
/**
* Return the list of <c:get select="$listProperty/@name" /> in the <c:get
select="$beanPackage/@name" />
* @return a list of <c:get select="$beanPackage/bean[@name =
$listProperty/@containedBeanName]/@clsBean" /> objects. Will not be
<code>null</code>
*/
public List <c:get select="$listProperty/@mthdGetter" />() {
return <c:get select="$listProperty/@varField" />;
}
</c:iterate>
}
503
d. Enter the file name beans.xml and specify a location in the root folder of the project
created in step 1. Click Next. (With RSD and RSM, click Finish, and skip the next
step).
e. Click Select file from workbench and select com.zyx.patterns.beans/schema.xsd
as the XML schema. Click Next, and then click Finish.
4. Enter data. Example 17-7 models a simple archive. Note that the XML Editor (not available
in RSD and RSM) has two tabs: Design and Source. Click the Source tab to enter the
example text.
Example 17-7 Test input describing a simple archive
504
Figure 17-31 The Run dialog defining the test launch of the zyx beans transformation
f. Click Run.
As the JET transformation executes, it produces progress information in the Console view.
Figure 17-32 shows the console output.
The transformation ran, and the Java beans were created, just the way that Deb liked them.
505
Deb wondered if these setup instructions can be automated with JET, too.
The answer is yes, and a pattern com.zyx.patterns.beans.setup has been included in the
Appendix C, Additional material on page 725 inside the ABD-Part 4-Projects.ZIP for the
ch16transform.setup.zip file.
/**
* Return the library years open (derived)
* @return the years open
*/
public int getYearsOpen() {
return java.util.Calendar.getInstance().get(java.util.Calendar.YEAR)
- getYearFounded();
}
But, Deb still has the problem of how to integrate this into the bean.java.jet template. A
straightforward modification of the template means that each time that the pattern was run on
the same input, any custom code previously entered is lost.
What Deb needs is a strategy for dealing with aspects of a reference solution that are too
complex (or too inconvenient) to capture in the transformations abstraction. We call this
problem an incomplete abstraction. Another term is a leaky abstraction.
506
Files that the users own and that the transformation will not modify
Shared files
Shared files require additional contract terms, indicating how and when users and the
transformation can modify a file, how their changes will be identified, and how conflicts will be
resolved.
Tip: Avoid having shared files in your transformations, if at all possible.
507
Deb has rejected the first option as impractical. While the calculations can be included in the
model simply as strings, this approach leads to a significantly degraded editing environment
for the derived property calculations. She has identified four other approaches:
Shared file approaches:
Use JETs generic user region tags to protect user-entered calculations in the bean
classes.
Use JETs Java-specific jmerge tags to implement a more sophisticated mechanism
to protect user-entered code in the bean classes.
User file approaches:
Modify the bean class to delegate the derived property calculation to a utility class. The
utility class is a user file, while the bean class remains a non-modifiable file.
Modify the bean class to declare the getter method derived property as abstract, and
modify the factory to instantiate a concrete class that implements the abstract method.
The concrete class is a user file.
package com.zyx.exemplar.beans.library;
/**
*
*/
public class UserRegionLibrary {
... other text removed for clarity
/**
* Return the library years open (derived)
* @return the years open
*/
public int getYearsOpen() {
//Place your custom code between the begin/end comments below
//begin getYearsOpen()
return java.util.Calendar.getInstance().get(java.util.Calendar.YEAR)
- getYearFounded();
//end getYearsOpen()
}
}
@generated Javadoc annotation. The transformation will overwrite any class member that
has an @generated tag. The transformation will not modify any member that does not have
the tag or where the tag has been modified. Example 17-10 shows an exemplar bean with
appropriate @generated markup. Note that the derived property getter getYearsOpen does
not have the @generated markup.
Example 17-10 A typical implementation compatible with the java:merge tag
package com.zyx.exemplar.beans.library;
/**
* @generated
*/
public class JMergeLibrary {
/**
* @generated
*/
private int yearFounded;
/**
* Package private constructor prevents instantiation except through factory
* @generated
*/
JMergeLibrary() {
}
/**
* Return the library year founded
* @return the year founded
* @generated
*/
public int getYearFounded() {
return yearFounded;
}
/**
* Set the library year founded
* @param yearFounded the new year founded
* @generated
*/
public void setYearFounded(int yearFounded) {
this.yearFounded = yearFounded;
}
/**
* Return the library years open (derived)
* @return the years open
*/
public int getYearsOpen() {
return java.util.Calendar.getInstance().get(java.util.Calendar.YEAR)
- getYearFounded();
}
}
509
package com.zyx.exemplar.beans.library.derived;
import com.zyx.exemplar.beans.library.UtilityLibrary;
/**
*
*/
public class UtilityLibraryUtil {
/**
* Utility method to calculate years open (derived)
* @param library the library
* @return the years open
*/
public static int getYearsOpen(UtilityLibrary library) {
return java.util.Calendar.getInstance().get(java.util.Calendar.YEAR)
- library.getYearFounded();
}
}
package com.zyx.exemplar.beans.library.derived;
import com.zyx.exemplar.beans.library.AbstractLibrary;
/**
*
*/
public class DerivedAbstractLibrary extends AbstractLibrary {
/*
* (non-Javadoc)
*
* @see com.zyx.exemplar.beans.library.AbstractLibrary#getYearsOpen()
*/
public int getYearsOpen() {
return java.util.Calendar.getInstance().get(java.util.Calendar.YEAR)
- getYearFounded();
}
510
Complete solutions for each reapply strategy are included in the additional materials
described in Appendix C, Additional material on page 725 inside the ABD-Part
4-Projects.zip file for the ch16transform.derived.zip file. The zip file contains the following
projects:
com.zyx.exemplar.beans
An updated exemplar project that includes implementations of examples of each of the
reapply strategies
com.zyx.patterns.beans.derived.userregion
The zyx beans pattern that uses JET user regions
com.zyx.patterns.beans.derived.jmerge
The zyx beans pattern that uses JMerge
com.zyx.patterns.beans.derived.utility
The zyx beans pattern that generates user-owned utility classes
com.zyx.patterns.beans.derived.subclass
The zyx beans pattern that generates user-owned concrete subclasses
com.zyx.patterns.tests
A project containing test inputs for each of the previous patterns
In this next section, we discuss the highlights of these implementations.
name
type
mthdGetter
511
Example 17-13 JET template code creating a derived property getter method
<%-- Mark this template as requiring a merge with existing content --%>
<java:merge/>
package <c:get select="$beanPackage/@pkgBeans" />;
512
<%-- only generate list imports if list properties are defined --%>
<c:if test="$bean/listProperty">
import java.util.ArrayList;
import java.util.List;
</c:if>
/**
* Implement bean <c:get select="$bean/@name"/>
* @generated
*/
public class <c:get select="$bean/@clsBean" /> {
<%-- define fields for 'property' elements --%>
<c:iterate select="$bean/property" var="property">
/**
* @generated
*/
private <c:get select="$property/@type" /> <c:get select="$property/@varField" />;
</c:iterate>
<%-- define fields for 'listProperty' elements --%>
<c:iterate select="$bean/listProperty" var="listProperty">
/**
* @generated
*/
private final List <c:get select="$listProperty/@varField" /> = new ArrayList();
</c:iterate>
/**
* Package private constructor prevents instantiation except through factory
* @generated
*/
<c:get select="$bean/@clsBean" />() {
}
<%-- define getter and setter methods for 'property' elements --%>
<c:iterate select="$bean/property" var="property">
/**
* Return the <c:get select="$beanPackage/@name" /> <c:get select="$property/@name" />.
* @return the <c:get select="$property/@name" />
* @generated
*/
public <c:get select="$property/@type" /> <c:get select="$property/@mthdGetter" />() {
return <c:get select="$property/@varField" />;
}
/**
* Set the <c:get select="$beanPackage/@name" /> <c:get select="$property/@name" />
* @param <c:get select="$property/@varLocal" /> the new <c:get select="$property/@name" />
* @generated
*/
public void <c:get select="$property/@mthdSetter" />(<c:get select="$property/@type" />
<c:get select="$property/@varLocal" />) {
this.<c:get select="$property/@varField" /> = <c:get select="$property/@varLocal" />;
513
}
</c:iterate>
<%-- define getter methods for 'listProperty' elements --%>
<c:iterate select="$bean/listProperty" var="listProperty">
/**
* Return the list of <c:get select="$listProperty/@name" /> in the <c:get
select="$beanPackage/@name" />
* @return a list of <c:get select="$beanPackage/bean[@name =
$listProperty/@containedBeanName]/@clsBean" /> objects. Will not be <code>null</code>
* @generated
*/
public List <c:get select="$listProperty/@mthdGetter" />() {
return <c:get select="$listProperty/@varField" />;
}
</c:iterate>
<%-- define getter methods for 'derivedProperty' elements --%>
<c:iterate select="$bean/derivedProperty" var="derivedProperty">
/**
* Return the <c:get select="$beanPackage/@name" /> <c:get select="$derivedProperty/@name" />
(derived).
* @return the <c:get select="$derivedProperty/@name" />
* @generated
*/
public <c:get select="$derivedProperty/@type" /> <c:get select="$derivedProperty/@mthdGetter"
/>() {
// TODO Complete this method
// Step 1) Remove @generated for the method Java doc comment
// Step 2) Code this method.
throw new UnsupportedOperationException();
}
</c:iterate>
}
The most significant changes in the template are:
Each generated Java class, method, and property includes an @generated Javadoc tag in
its document comment.
The template includes a <java:merge> tag at the beginning, indicating that the generated
contents must be merged with the existing contents already on disk.
While JMerge is certainly easy to use, it does have a number of disadvantages:
Users have to remember to remove (or deface) @generated tags from Java elements that
they modify.
Users can take over the responsibility for generated elements that are essential for the
correct functioning of the pattern, and that the pattern author had not intended.
JMerge only works with Java code.
514
Example 17-15 Portion of the bean template that calls a utility class for derived properties
<%-- We call java:merge to add any new methods to the existing class --%>
<java:merge/>
package <c:get select="$beanPackage/@pkgDerived" />;
import <c:get select="$beanPackage/@pkgBeans" />.<c:get select="$bean/@clsBean" />;
/**
*
*/
public class <c:get select="$bean/@clsDerivedUtility" /> {
<c:iterate select="$bean/derivedProperty" var="dp">
/**
* Utility method to calculate <c:get select="$dp/@name" /> (derived)
* @param <c:get select="$bean/@varLocal" /> the <c:get select="$bean/@name" />
* @return the <c:get select="$dp/@name" />
*/
public static <c:get select="$dp/@type"/> <c:get select="$dp/@mthdGetter" />(<c:get
select="$bean/@clsBean" /> <c:get select="$bean/@varLocal" />) {
// TODO not implemented
throw new UnsupportedOperationException();
}
</c:iterate>
}
Note that the template contains a <java:merge> tag, but no @generated Javadoc tags, which
takes advantage of JMerge behavior in the case where the generated code includes an
element that is not in the current version of the class. Even without @generated tags, JMerge
will copy the new element into the existing class. Thus, if a new derived property is added to a
bean, the <java:merge> tag will ensure that the method gets added to the existing utility
class. Without the <java:merge> tag, the new getter method is missing from the utility class,
and the generated bean class contains a compilation error.
515
The main.jet template has been modified (in a user region created for these purposes) to
create internalHasDerived elements.
Example 17-17 shows the manually entered code in main.jet.
Example 17-17 Custom main.jet code to create an internalHasDerived element
516
Figure 17-34 Setting the replace parameter on the Create File: concrete.bean.java action
517
The proposed quick fix for the utility class approach is to create the missing method on the
utility class.
The proposed quick fix for the subclass approach is to create the missing method on the
subclass.
In both cases, the Java errors effectively draw user attention to incomplete code, and the
proposed quick fixes lead the user to take the correct action. However, the subclass
approach is superior, because the Java error occurs in the user-owned file that requires
attention.
518
</bean>
<bean name="artifact">
<property name="catalog number" type="int"/>
<property name="description" type="String"/>
<property name="date entered" type="java.util.Calendar"/>
</bean>
</beanPackage>
</root>
A Boolean value
A numeric value
A string value
A node set, which is a collection of model elements
XPath has rules for converting between these results. Most XPath expressions that reference
a model return a node set, unless the expression explicitly converts the result to another type.
Referencing an element
A step that references an XML element can be coded as the element name. These are known
as child steps.
The following example refers to the element root of the XML document in Example 17-18 on
page 518.
/root
The following refers to the element beanPackage in the same document.
/root/beanPackage
These child steps do not necessarily match only one element. The following expression
matches both bean elements in Example 17-18 on page 518.
/root/beanPackage/bean
And, this expression matches all property elements.
/root/beanPackage/bean/property
To be more precise, we must explore attribute references, relative path expressions, and
predicates.
519
Referencing attributes
Attribute references are XPath steps, technically known as attribute steps. An attribute step
starts with a commercial at sign character (@) and is followed by a name. Note that attribute
steps are steps and must be separated from a previous step by a slash.
This expression returns the name of the beanPackage in Example 17-18 on page 518.
/root/beanPackage/@name
520
If the predicate expression returns a string, the string is converted to a Boolean value by
testing for equality to true. Note that attribute references, such as @name, are not string
values, but instead they are node sets. The following expression does not have the result
that the casual reader might expect:
/root/beanPackage[@someAttrKnownToContainTrueOrFalse]
This expression, in fact, selects any beanPackage that has
someAttrKnownToContainTrueOrFalse set to any value whatsoever, including false. To
get the desired Boolean conversion, the expression must be written as:
/root/beanPackage[stringValue(@someAttrKnownToContainTrueOrFalse)]
17.5.3 Variables
XPath expressions can include variables. Variables can contain any of the XPath data types
(Boolean, number, string, or node set). In an expression, a variable is prefixed by a dollar sign
character ($). Variable names are a sequence of letters, digits, and a few special characters
(hyphen or underscore) and begin with a letter or underscore.
Several JET tags create XPath variables. The most frequently used tag of this type is
<c:iterate>, which creates a variable to refer to the current model element in an iteration
block. Almost all JET authoring-generated XPath expressions are of one of two forms:
A child step from a variable:
$variable/someChildElement
An attribute step from a variable:
$variable/@someAttribute
In JET, all XPath variables are globally visible. Variables created by <c:iterate> are visible to
all active templates while the <c:iterate> block is active. When the <c:iterate> block is
finished, the associated variable is destroyed.
You can define your own JET variables using <c:setVariable>. Examples include:
<c:setVariable var="pi" select="3.1415926535" />
<c:setVariable var="radius" select="4" />
<c:setVariable var="area" select=" pi * radius * radiaus" />
However, there is surprisingly little need for JET transformations to use <c:setVariable>.
17.5.4 Functions
Functions are an important aspect of XPath expressions. Functions manipulate the XPath
result. The XPath specification supplies a number of standard functions. As well, JET
contributes a dozen functions that are useful in string manipulation. In addition, user-written
XPath functions can be contributed to JET.
The following examples are XPath functions that are used frequently in JET transformations:
translate
upper-case
lower-case
uppercaseFirst
521
lowercaseFirst
camelCase
Create a value Java identifier out of a group of words. All white space
and illegal Java characters are removed, the first character of each
word is changed to upper case, and all remaining characters are
changed to lower case.
The standard XPath functions are documented by the XPath 1.0 specification, which is at:
http://www.w3.org/TR/xpath#corelib
The additional XPath functions contributed by JET are found in the online help. Search for
Additional XPath Functions.
522
523
Purpose
org.eclipse.jet.resource.name
org.eclipse.jet.resource.type
org.eclipse.jet.resource.location
org.eclipse.jet.resource.rawLocation
org.eclipse.jet.resource.project.name
org.eclipse.jet.resource.fullPath
org.eclipse.jet.resource.projectRelativePath
org.eclipse.jet.resource.fileExtension
org.eclipse.jet.resource.fileName
org.eclipse.jet.resource.parent.name
org.eclipse.jet.resource.parent.location
org.eclipse.jet.resource.parent.rawLocation
org.eclipse.jet.resource.parent.fullPath
org.eclipse.jet.resource.parent.projectRelativeP
ath
It is important to note that the variables are only defined if the JET transformation loads the
input model from an Eclipse resource. The JET APIs provide other mechanisms for providing
a JET transformation with an input model. These mechanisms do not set the variables just
mentioned. In particular, the mechanism used in 17.6.4, JET support for different types of
models on page 525 does not set these variables.
524
<c:load url="{$org.eclipse.jet.resource.project.name}/plugin.xml"
urlContext="workspace"
var="myPluginXML"
loader="org.eclipse.jet.emfxml"
type="xml"/>
The tags attributes are defined as:
The url attribute specifies a location of the file as a path. It can include a protocol, such as
http://, but most often, it is a relative path.
The urlContext attribute indicates that the url attribute value is relative to the Eclipse
workspace. The default is to treat url as though it is relative to the JET project itself.
The var attribute is set to the document root of the loaded document, which is the
equivalent of / on the default input model.
The loader attribute specifies the JET model loader to use to load the resource. JET ships
with support for three model loaders. The specified loader loads an XML document with
the help of the Eclipse Modeling Framework (EMF).
The type attribute specifies the file type to the model loader. In this case, the type attribute
is redundant. The XML model loader can determine the type from the file extension of the
url attribute.
525
Figure 17-35 The plug-in manifest editor Extensions tab showing the modelLoader property
Figure 17-36 shows the structure of a UML model, as presented by the Model explorer.
526
The following XPath expressions both match the class one bean:
/Model/Package[@name = test package]/Class[@name = one bean]
/contents/nestedPackages[@name = test package]/ownedTypes[@name = one bean]
In the case of UML models, many uses do not know the feature names (such as
nestedPackages and ownedTypes), but they do know the class names.
Note that JETs support for UML models has the following limitations:
There is no way to access stereotype information.
JET authoring cannot cope with the complexity of the UML meta-model. UML models are
inappropriate direct input for JET transformations that are modeled with the Exemplar
authoring tools. Instead, use the approach described in Chapter 18, Produce:
Model-to-model on page 529.
@name
@location
@fullPath
@projectRelativePath
@fileExtension
@fileName
527
528
18
Chapter 18.
Produce: Model-to-model
This chapter describes the production of pattern implementations that generate models. It
demonstrates how a graphical editing environment for model-to-text transformation models
use the Uniform Modelling Language (UML).
529
18.1 Introduction
This chapter discusses model-to-model transformations. In particular, this chapter discusses
how to present graphical interfaces to non-graphical models, such as the XML-based
models typically used by JET model-to-text transformations.
530
http://www.eclipse.org
http://www.eclipse.org
531
532
3. If the Development capability has a check beside it, click OK. No further steps are
needed. Otherwise, click Advanced.
4. Expand Development in the tree. Figure 18-2 on page 534 shows the advanced dialog.
533
534
Figure 18-3 Setting the base package for EMF code generation
535
The Java API for accessing, loading, and saving the model
Edit code
Editor code
Test code
Generated model code is placed into the EMF project. Edit, editor, and test code are each
written to separate projects, which will be created if necessary.
In this case, only the model code is required. Right-click within the input.genmodel editor, and
click Generate Model Code.
After the model code generation is complete, the EMF project needs to contain the following
three Java packages:
com.zyx.patterns.beans.model.inputSchema: Java interfaces defining the model API
com.zyx.patterns.beans.model.inputSchema.impl: Java classes implementing the
previous API
com.zyx.patterns.beans.model.inputSchema.util: Utility Java classes
You can examine this code, but it is not necessary to edit it.
536
8. Click Finish.
The wizard will:
Create the profile project com.zyx.patterns.beans.profile.
Create the profile file ZYXBeans.epx.
Open the ZYXBeans.epx file.
Offer to switch you to the modeling perspective. If prompted to switch, click Yes.
The profile editor itself is not used extensively during profile creation. Instead, two key views
provide the essential editing capabilities:
Project Explorer
Properties
Figure 18-5 on page 538 shows the profile editor and the two essential views.
537
Figure 18-5 The profile editor: Project Explorer view and Properties view
538
sourceFolder
3. Click the Insert new attribute icon just over the red X on the right side of the view.
4. Click the Name value of the new attribute and enter basePackage.
5. Click the Type value of the new attribute, and then click the ellipsis ... button.
6. Enter String and click OK. Figure 18-8 on page 540 shows the Select Element for Type
dialog.
539
540
Profile version information is tracked by releasing the profile. Typically, a profile is released
when it has been tested, but before it is published to users. Any subsequent profile updates
will require another profile release. Models using the old profile release will then be upgraded
to the new profile.
Now that the ZYX Beans profile is fully defined, it is time to release it:
1. Click the profile editor window.
2. Click on the most recent profile version (it is most likely version 1). Figure 18-10 shows the
latest version selected in the profile editor.
Figure 18-10 The ZYXBeans profile with the latest version selected
3. Click Release.
4. Enter 1.0.0 as the Release Label, and click OK.
5. Close the profile editor. Click File Close.
541
The conversion wizard makes a number of additions to the profile project, including adding a
file META-INF/MANIFEST.MF that is the plug-in manifest, which describes the characteristics
of the plug-in.
The next step is to publish by adding the extension. An extension is an implementation of a
predefined extension point in the Eclipse platform. To publish the profile, two extensions must
be defined:
A pathmap extension must be declared. A pathmap is a method of defining a location that
is independent of the Eclipse environment. The pathmap will be used to define the profile
location.
A UMLProfile extension must be declared. This extension references the epx file that we
have just created.
Define these extensions:
1. Double-click META-INF/MANIFEST.MF, which opens the Plug-in manifest editor.
2. Select the General tab, change the value of Name to ZYX Beans Profile. Note that this
change is a cosmetic change.
3. Click the Extensions tab.
4. Click Add.
5. Clear the Show only extension points from required plug-ins check box.
6. Enter *pathmap in the Extension point filter. Figure 18-12 on page 543 shows the state of
the dialog.
542
543
Figure 18-15 Binary build options modified to include the ZYXBeans.epx profile
544
24.Save and close the plug-in manifest editor. Click File Save.
Figure 18-16 Selecting the Plug-in with Transformation Mapping new project wizard template
545
Figure 18-18 The mapping editor opens on the new ZYXBeansFrontend.mapping file
Custom transformations
Submap transformation
547
Figure 18-19 The new map with critical editor icons annotated
Figure 18-20 The new map with input and output objects defined
5. Right-click Model and click Feature Filters Intermediate, which shows extra items
under Model.
548
6. Drag nestedPackage from within Model to beanPackage within Root, which creates a
submap, which is shown in Figure 18-21.
Figure 18-22 The Details tab of the submap between nestedPackage and beanPackage
549
Figure 18-23 Completed submap shows the PackageToBeanPackage map is visible in the Outline view
10.Click the small yellow arrow on the submap. The mapping editor will shift focus to the
PackageToBeanPackage map.
11.Add a reference to the BeanPackage stereotype on the input object for the
PackageToBeanPackage map:
a. Right-click Package and click Delete.
b. Click the Add an input object icon.
c. Click Package from the Element list.
d. Click Add Model.
e. Click Browse Workspace.
f. Find and select com.zyx.patterns.beans.profile/ZYXBeans.epx. Click OK. Click OK
again to return to the Add Input dialog. Figure 18-24 on page 551 shows the resulting
Add Input dialog.
550
Figure 18-24 The add input dialog showing the ZYXBeans profile
Figure 18-25 Package object with the BeanPackage stereotype and attributes
551
13.Define the map backing the submap between packagedElement and bean:
a. Click the submap that was created in step 12d.
b. In the Properties view, click the Details tab.
c. Click New in the Properties view.
d. Enter ClassToBean for the Map name.
e. Click the small yellow arrow on the submap to navigate to the new ClassToBean map.
14.Add a more specific type for the input object on the ClassToBean map:
a. Right-click PackagedElement and click Delete.
b. Click the Add an input object icon.
c. Click Class in the Elements list, and click OK.
15.Map from Class to Bean:
a. Drag name from Class to name on Bean.
b. Drag ownedAttribute from Class to property on Bean, which creates a submap.
c. Drag ownedAttribute from Class to listProperty on Bean, which creates a submap.
d. Drag ownedAttribute from Class to derivedProperty on Bean, which creates a
submap.
552
16.Apply an input filter on the ownedAttribute to derivedProperty submap so that the map will
only receive UML properties that have the derived attribute set to true:
a. Click the ownedAttribute to derivedProperty submap.
b. In the Properties view, click the Input Filter tab.
c. Check Filter Input Elements.
d. Enter:
return ownedAttribute_src.isDerived();
Click Apply.
Figure 18-28 on page 554 shows the Input Filter tab of the Properties view.
553
17.Apply an input filter on the ownedAttribute to listProperty submap so that the map will only
receive UML properties that are ends of an association to another bean:
a. Click the ownedAttribute to listProperty submap.
b. In the Properties view, click the Input Filter tab.
c. Check Filter Input Elements.
d. Enter:
return ownedAttribute_src.getAssociation() != null;
Click Apply.
18.Apply an input filter on the ownedAttribute to property submap so that the map will only
receive UML properties that are not associations and are not derived:
a. Click the ownedAttribute to listProperty submap.
b. In the Properties view, click the Input Filter tab.
c. Check Filter Input Elements.
d. Enter:
return !ownedAttribute_src.isDerived() &&
ownedAttribute_src.getAssociation() == null;
Click Apply.
19.Create maps for each of these submaps. The map names will be:
PropertyToDerivedProperty
PropertyToListProperty
PropertyToProperty
554
Note that the type name map can count on the UML Property type being non-null,
because this is a structural requirement of the association end Property on which the rule
is acting.
22.Complete the PropertyToProperty mapping. Logically, this is same as the
PropertyToDerivedProperty mapping. However, for the sake of demonstrating various
mapping techniques, PropertyToProperty will be mapped as:
a. In the Outline view, click PropertyToProperty. The editor displays the map.
b. Drag name on Property to name on Property.
c. Drag type on Property to type on Property. This creates a custom transformation.
d. Click the Details tab of the Properties view.
555
e. Enter:
Property_tgt.setType("String");
Click Apply.
This statement ensures that the target type is always set. For cases where the source
property has a non-null type, the following mapping will apply.
f. Right-click Property and click Feature Filters Advanced.
g. Drag name under type on Property to type on Property.
h. Click the move map.
i. Click the Condition tab of the Properties view.
j. Click Apply a condition to this transformation.
k. Enter:
return Property_src.getType() != null;
Click Apply.
The execution order of these two mappings is important. You can view the order in the
Outline view, and you can change the order by right-clicking an item in the Outline
view or in the editor, and clicking Execution Order Move Up or Execution
Order Move Down.
Figure 18-30 on page 557 shows the completed mapping.
556
Figure 18-30 Completed mapping for PropertyToProperty using an alternative conditional mapping technique
The mapping definition is now complete. Save the mapping file by clicking File Save.
557
The code generator creates a Java class for each mapping that is defined. Fortunately, most
of this code will never need to be handled manually.
/**
* Creates a root transformation. You may add more rules to the transformation
here
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @param transform The root transformation
* @!generated
*/
protected RootTransformation createRootTransformation(ITransformationDescriptor
descriptor) {
return new RootTransformation(descriptor, new MainTransform()) {
protected void addPostProcessingRules() {
558
559
Figure 18-32 The Run dialog with the New icon highlighted
560
Figure 18-33 Completed Main tab for the ZYX Test configuration
561
Figure 18-34 The Configuration tag of the ZYX patterns launch configuration
8. Click Run.
Note that a launch configuration only needs to be created one time. The same configuration
can be relaunched from any of the following locations:
Click Run Run, select the launch configuration and click Run.
Click Run Run History, and click the configuration from the list of recently used
configurations.
Click the Run icon on the tool bar (this selection launches the most recently used
configuration).
Click the small down arrow to the right of the Run icon on the toolbar, which shows the
launch history.
Figure 18-35 Specifications for the test beans project (a Java project)
5. Click Finish.
The test Java project will be used as the output for the bean transformation.
563
Figure 18-36 The UML editor open on the newly created TestBeans UML model
9. Scroll to the bottom of the Stereotypes tab. Note the Stereotypes Properties table, which
contains the basePackage and sourceFolder properties of the BeanPackage stereotype.
10.Click the Value cell for basePackage and enter com.zyx.tests.
11.Click the Value cell for sourceFolder and enter my.test.beans/src.
Figure 18-37 shows the stereotyped bean package and the Properties view.
Figure 18-37 The stereotyped bean package and the Stereotypes tab of the Properties view
Figure 18-38 The model assistant and the Add attribute icon
565
a string
Figure 18-40 The Name and transformation page of the new transformation configuration wizard
567
Figure 18-41 Completed source and target page of the new transformation configuration wizard
When finished, the wizard creates the file Test ZYX Beans.tc and opens the transformation
configuration editor on it. Figure 18-42 shows this editor. This editor can be used to change
the configuration at a later date.
Figure 18-42 The transformation configuration editor open on Test ZYX Beans.tc
568
569
Figure 18-43 Advanced properties of a UML Class showing feature names in the Property column
The UML Properties dialog shows all multi-valued references and containments. It can be
accessed by right-clicking any model element, and clicking UML Properties. The dialog lists
feature names on the left side. When a feature is selected, the right side of the dialog shows
information about the objects that are referenced or contained by the feature. You can also
use the dialog to distinguish derived features. Derived features will not have a tool bar on the
far right of the dialog (which, when present, is used to add and remove elements in the
feature). Figure 18-44 on page 571 shows the UML Properties dialog for a UML Class.
570
Figure 18-44 The UML properties dialog for a Class shows all multi-valued features
To identify a feature, browse through the advanced properties or UML properties on your
reference model until you see the object or objects that you want. If you plan to update model
elements, make sure that you have a feature that is not derived. Finally, consider the feature
name. Is it a reasonable name for your purpose? One of the frustrations of UML can be that
the same object can appear in many different features. Try to use a feature that is descriptive
of your purpose; you will be more likely to be successful.
571
In this section, we work through a UML Pattern that helps users correctly configure a ZYX
Electronics model in preparation for running the ZYX Beans pattern. The pattern will:
Create the UML Package to contain the beans.
Apply the BeanPackage stereotype to that package.
Prompt for values for the source folder and base package.
Capture the beans to be created in the bean package.
Maintain a diagram of beans in the package.
572
573
574
6. Save and close the plug-in manifest editor. Click File Save, and then click File
Close.
575
576
577
a diagram node representing the added bean to the diagram created by the Name parameter.
Finally, it forces the diagram to lay out the shapes in the diagram again.
9. Click on the square at the end of the Name parameter line. The model assistant will
appear. Click the Enter argument name or value icon (the last icon). Figure 18-46 on
page 579 shows the model assistant.
578
10.Type test two for the Name parameter and press Enter.
11.Repeat the same process for the Source Folder parameter. Type my.test.beans/src and
press Enter.
12.Repeat the same process for the Base Package parameter. Type com.zyx.pattern.tests
and press Enter.
13.Add a value for the Beans parameter. Type bean one and press Enter.
14.Add another value for the Beans parameter. Type bean two and press Enter.
Figure 18-47 shows the final pattern instance.
Explore the model as the pattern parameters are entered. Figure 18-48 on page 580 shows
the Project Explorer contents and the generated diagram. All of the contents are created as
part of the pattern expansion. Note the contents of the test two package and the shapes
added to the Main diagram in this package.
579
580
Figure 18-49 The new UML Model wizard showing standard template models
In this section, we create a UML template model that pre-configures a UML model for working
with the ZYX Beans transformation and ZYX BeansPackage UML pattern. The steps are:
Create a UML model (.emx file) that will serve as the template.
Create a description file (.templatedef.ve file) that describes the template name, location,
and icon.
Place the template model and description file in a plug-in project, and register the files with
the com.ibm.xtools.modeler.ui.wizards.template extension point.
The template model created here will have the following characteristics:
The ZYX Beans profile will be applied.
There will be a Bean Package pattern instance already in the main diagram of the model.
The main diagram will include instructions for how to add other pattern instances, how to
create a target Java project, and how to configure a transformation configuration.
581
1. Launch the test configuration. Click Run Run History Test ZYX patterns and
transformations.
2. Right-click the Models folder under my.test.models and click Create UML Model. The
new UML model wizard starts.
3. Make no changes on the first wizard page. Click Next.
4. Type zyxBeansTemplateModel for File Name. Click Finish.
5. Ensure that the Properties view is visible, and then click the zyxBeansTemplateModel
element in the Project Explorer view.
6. In the Properties view, click the Profiles tab.
7. Click Add Profile.
8. Select ZYX Beans from the Deployed Profiles drop-down list and click OK.
9. Switch to the Pattern Explorer view.
10.Drag an instance of the Bean Package pattern onto the Main diagram.
11.In the palette, click Note, and then click the Main diagram. Enter the text in Example 18-6.
Press Ctrl-Enter to create a new line in the note. Press Enter to finish editing the note.
Press F2 to start editing the note again.
Example 18-6 The instructions for the template model note
Instructions:
1) Create a Java project to contain the generated beans.
2) Enter bean package parameters.
3) Open the diagram for the generated bean package.
4) Create attributes on the beans.
5) Create a Transformation Configuration for ZYXBeansFrontend transformation.
12.Save the model. Close File Save.
13.Close the model. Right-click zyxBeansTemplateModel in the Project Explorer view and
click Close.
14.Show the Navigator view:
a. Click Windows Show View Other.
b. Select General Navigator and click OK.
15.In the Navigator view, right-click zyxBeansTemplateModel.emx and click Copy.
16.Return to the development workbench (leave the test workbench open).
17.Add a folder to the UML pattern project:
a. In the Project Explorer, right-click com.zyx.patterns.beans.umlpattern and click
New Folder. Type templateModels and press Enter.
b. Right-click the templateModels folder and click Paste. A copy of
zyxBeansTemplateModel.emx will appear in the folder.
c. Right-click the templateModels folder and click New File. Type
zyxBeansTemplateModel.templatedef.ve and press Enter. A text editor will open on the
new file.
582
#
# Define a the zyx beans template model
#
id = com.zyx.patterns.beans.umlpattern.template
name = ZYX Beans Model
description = Create a model for defining ZYX Beans
icon = ../icons/sample.gif
templateFile = zyxBeansTemplateModel.emx
The file defines a unique identifier for the template, a display name and description, an
icon, and a reference to the template model itself.
18.Publish the template model using the com.ibm.xtools.modeler.ui.wizards.template
extension:
a. Double-click plugin.xml in the project com.zyx.patterns.beans.umlpattern, which
opens the plug-in manifest editor.
b. Click the Extensions tab.
c. Click Add.
d. Clear Show only extension points from the required plug-ins.
e. Type *.template in the Extension Point filter field to filter the list.
f. Select com.ibm.xtools.modeler.ui.wizards.template and click Finish.
g. Click Yes when prompted whether to add the plug-in
com.ibm.xtools.modeler.ui.wizards to the list of plug-in dependencies.
h. Right-click com.ibm.xtools.modeler.ui.wizards.template and click New
directory.
i. In the path field, enter templateModels.
j. Save the changes. Click File Save.
19.Include the template model files in the plug-in build:
a. With the plug-in manifest editor still open, click the Build tab.
b. Check templateModels in the Binary Build list (on the left).
20.Save and close the plug-in manifest editor. Click File Save, and then click File
Close.
21.Exit the test environment started in step 1. The test environment must be restarted for the
template library to be visible. Click File Exit.
583
Figure 18-50 The new UML model wizard with the ZYX Beans Model template
Finally, the entire solution (JET transformation, front-end mapping transformation, UML
profile, UML pattern, and template model) constitutes a pattern, although more complex
than the others. There are pattern implementations for aspects of this pattern, but nothing
that coordinates the generation of an entire solution.
The previous situation is a typical experience in pattern-based engineering. The discovery
and automation of one pattern leads to the discover of other patterns. But, you do not need to
automate all patterns. Before embarking on a pattern implementation, consider that:
A pattern is a proven solution to a recurring problem:
Investigate how often the problem occurs.
Determine how much effort is involved in implementing a manual solution. Remember
to include test and debug time.
Estimate how much effort will be involved in creating an automated pattern
implementation.
Implement the patterns that will have the biggest payback in a short period of time first.
Different tooling has different learning curves and associated costs. In general, JET-based
model-to-text transformations are much faster to produce than model-to-model and UML
patterns. Table 18-1 summarizes the skill requirements of the pattern implementation
technologies that we have discussed so far.
Table 18-1 Skill requirements for different pattern technologies
Pattern technology
Summary
Learning requirements
JET (model-to-text)
Lightweight
Basic XML
Basic XPath
Exemplar authoring
Model-to-Model mapping
transformations
Medium weight
Basic EMF
Mapping editor
UML meta-model
Java programming
Basics of Eclipse plug-in
development
UML Patterns
Heavy weight
No matter how pattern implementations improve productivity, time will likely remain a
constraint in any project. The corollary is that pattern automation efforts must be carefully
budgeted. The multi-layered solution approach described in this chapter aims to support
this approach. Build pattern implementations incrementally; stop when the returns on
investment start to diminish. In particular:
Start with JET-based model-to-text transformations. Evaluate their effectiveness prior
to investing in UML-based front ends, UML Patterns, and so forth.
Estimate the costs and savings of model-to-model front ends and UML patterns prior to
implementing them.
585
586
19
Chapter 19.
587
19.1 Introduction
Chapter 17, Produce: Model-to-text pattern implementations on page 469 and Chapter 18,
Produce: Model-to-model on page 529 described the creation of pattern implementations.
Because pattern implementations are software, they must be installed in a software
developers workbench in order for them to be used. This chapter discusses the packaging
and distribution options available.
Pattern implementation
technology
JET-based solutions
(Chapter 16, Introduction to
patterns on page 457)
Pattern implementations
developed and shared within a
single project
JET-based solutions
(Chapter 16, Introduction to
patterns on page 457)
588
589
Strengths
Configuration Management
(ClearCase)
Source code
Build environment
Debs analysis concludes that Web sites and shared folders were the least desirable
Repository, but that they have their uses. For example, most software products can be
updated from the Internet. Integral to most distributions is a shared Web server or shared
network location.
The distinction between an SCM Repository and RAM is more subtle to Deb. SCM
repositories are the most appropriate for tracking the constituents of a software asset during
its construction. RAM is more appropriate for distributing completed software, as well as
many other types of assets.
In the end, Deb decides to use a mix of ClearCase and RAM. Table 19-3 summarizes her
choices.
Table 19-3 ZYX Bean assets and storing Repository
Asset
Repository
ClearCase
ClearCase
Pattern specification
RAM
Example inputs
RAM
versioned object base (VOB) or Unified Change Management (UCM) component for pattern
implementation projects.
591
The wizard will create a file projectSet.psf. This file can be renamed.
It might be useful to create several project sets:
One project set that contains essential projects
One project set that contains supplemental projects, which are necessary only for specific
purposes. Exemplar projects are an example of supplemental projects. They are only
required if a JET project will be modified and regenerated.
Note that the Developer Resources project is a candidate for sharing assets in the RAM
Repository. New developers can then search RAM for the Developer Resources assets,
install it, and then proceed to extract the source code from the SCM Repository.
592
You create a RAM asset through the New Asset wizard. To start the wizard, click File
New Other, select Asset Management Asset, and click Next. The details of the wizard
are beyond the scope of this chapter.
The RAM Eclipse client is capable of publishing Eclipse projects or parts of Eclipse projects.
When re-imported into Eclipse, the original project is always recreated. The RAM Web client
is capable of publishing folders and files. When imported into an Eclipse workspace, the user
is prompted to select a project to contain these files and folders.
Table 19-3 on page 590 describes the RAM assets to create, the RAM client to use, and the
artifacts to be included in them. (Note that several of these files were not explicitly created in
Part 4).
Table 19-4 RAM assets to create and their contents
Asset
Publishing client
Included artifacts
Pattern specifications
file: beans.pattern.spec.doc
file: bean.setup.sample.xml
file: bean.sample.xml
593
Developer installation
594
Team project sets for the JET and exemplar projects (in case further development
is required)
Tools to facilitate the JAR exporting (One JAR will be created shortly.)
2. The file system location of this project is required in subsequent steps. It can be found by:
a. Right-clicking the resource project, and click Properties.
b. On the Info tab, copy the value for the Location field to the clipboard. (Select the text
and press Ctrl-C.)
3. Select and right-click the JET projects to export and click Export.
4. Enter deploy to filter the list of available export wizards. Click Deployable plug-ins and
fragments. Click Next.
Figure 19-3 shows the filtered list.
Figure 19-3 Selecting the Deployable plug-ins and fragments export wizard
5. Ensure that the selected JET projects are checked in the Available plug-ins and
fragments list.
6. Ensure that the Directory option is enabled, and then click Browse.
7. Choose a directory to contain the exported JET pattern implementation. Use the location
that you have copied in step 2. Click OK.
Figure 19-4 on page 596 shows the export wizard state.
595
Figure 19-4 Setting the destination for the exported JET pattern implementation
8. Click the Options tab, and confirm that only Package plug-ins as individual JAR
archives is checked.
9. Click Save as Ant script, and specify the file build.plugin.jars.xml in the location saved
in step 2.
Figure 19-5 shows the correct settings.
Figure 19-5 The options tab for the exported JET pattern implementation
10.No changes are required on the JAR Signing tab. Click Finish.
The wizard shows a progress dialog while it executes. When it completes, right-click the
developer resources project that were created in step 1, and click Refresh. The following
items appear:
A plug-ins directory containing JAR files for each exported JET pattern implementation
A file build.plugin.jars.xml
596
597
598
Figure 19-6 Specifying an additional location for the JET pattern implementation
599
Feature
Update site
Plug-ins
All functionality in an Eclipse-based application is contributed via plug-ins. In Chapter 17,
Produce: Model-to-text pattern implementations on page 469 and Chapter 18, Produce:
Model-to-model on page 529, we created a number of plug-in projects. These plug-in
projects can made deployable either by exporting them using an export wizard (as seen in
19.3.3, Deployment preparation on page 594) or by using a mechanism called Plug-in
Development Environment (PDE) build. Here, we shall use the export wizards, because the
PDE build environment is beyond the scope of this book.
600
JET transformations
Model-to-model mapping projects
The UML profile project created in Chapter 18, Produce: Model-to-model on page 529
EMF projects
UML pattern projects
Features
A feature is a group of related plug-ins. Features are the unit of installation of Eclipse platform
extensions. Typically, a feature groups one or more plug-ins into a logical function. An
important aspect of features is that multiple features can include the same plug-in. The
Eclipse platform ensures that a plug-in that is referenced by multiple features only gets
installed one time.
Features are defined in feature projects.
Update sites
An update site is a directory containing a special file (site.xml), which describes features
available for installation by Eclipse. The update site also contains copies of the features and
the referenced plug-ins available for installation. Update sites can be local directories,
network shares, or can be posted to Web servers. The Eclipse Update Manager can scan
update sites for new and updated features and install them.
Note that update sites are generally pulled to a users Eclipse installation; they require an
explicit action by each user to find and install an update.
Update sites are defined in update site projects.
601
The wizard:
Creates a feature project
Creates a feature manifest named feature.xml
Creates a build properties file named build.properties
Opens the Feature Manifest Editor, which allows you to edit both feature.xml and
build.properties
To add plug-ins to the feature, follow these steps:
1. If not already open, double-click feature.xml to open the Feature Manifest Editor.
2. Click the Plug-ins tab.
3. Click Add. The list of available plug-ins will appear. This time, the dialog includes a filter
box.
Figure 19-7 shows the dialog.
com.zyx.patterns.beans.derived.subclass
com.zyx.patterns.beans.frontend
com.zyx.patterns.beans.model
com.zyx.patterns.beans.profile
com.zyx.patterns.beans.umlpattern
602
Figure 19-8 The required plug-ins for the ZYX bean pattern feature
Notes on features
Features are a packaging mechanism. As a result, they provide a fair degree of flexibility in
determining which plug-ins are distributed:
A plug-in can be included in more than one feature.
For example, it is possible to create two features for the ZYX beans pattern: a basic
feature that just provides the bean code generator and a complete feature that contains all
of the bean solution projects.
A feature can contain plug-ins that are already installed.
For example, a ZYX beans solution can include the JET engine plug-ins, which permits
the feature to be installed into Eclipse-based workbenches that did not already include
JET.
603
3. The Feature Selection dialog shows all available features. You can enter text to filter the
list. Select the features to add to the update site and click OK.
Note that the list of available features is composed of those feature projects currently open
in the workspace, plus those features that are installed in the workbench.
4. Optionally, categories can be created via the New Category button. Categories allow you
to organize features in an update site. When a category is created, features can be
dragged onto the category.
If no categories are defined, or if a feature is not included in a category, the feature is
added to a category named Other.
5. Click Build All, which starts a build process that exports all of the features and plug-ins to
JAR files in the features and plug-ins subdirectories of the update site project. (This task
can take time.)
The update site can be deployed by copying site.xml and the plug-ins and features directories
to a local or network folder or to a Web server. These artifacts can also be included in a RAM
asset.
604
3. The first time that an update site is used, it must be added to the list in the dialog. To copy
update sites to a local directory or network folder, click New Local Site. To copy Web
server-based sites, click New Remote site.
4. In either case, enter a name for the site, and enter its location, either as a file system path
for local sites or as a Web address for remote sites.
5. When added, ensure that the update site is checked. Only checked update sites will be
searched. Click Finish.
A search will be performed for the selected update sites. After a wait, the Updates wizard
will appear. Figure 19-10 shows the updates wizard showing available updates (features)
organized by update site and category.
605
Figure 19-11 Setting the installation location for the new features
19.4.6 Using features and update sites with IBM Rational Asset Manager
As with 19.3, Exporting JET projects on page 594, the process of deploying assets to
development projects typically has many steps:
The pattern developer creates a feature and update site.
A project lead selects one or more pattern implementation features for use. To simplify the
life of the developers, the project lead might create a team-specific update site that
includes required features.
Individual developers install the selected features.
These assets can be stored in RAM. For update sites, there are two alternatives:
Store the update site (site.xml and plug-ins and features directories) in RAM.
WIth this approach, the update site assets must first be extracted to a users machine, and
the update site must be configured using 19.4.5, Using an update site on page 604.
606
Asset name
Contents
Deployment preparation
Developer installation
Project development
resources
607
Note that the use of features and update sites is compatible with the other distribution
mechanisms described in sections 19.2, Sharing JET projects on page 588 and 19.3,
Exporting JET projects on page 594. Thus, it is possible for a development team to
simultaneously use:
Shared JET projects for project-developed pattern implementations
Exported JET plug-ins for pattern implementations that are JET only
Features and update sites for more complex pattern implementations that require UML
profiles, model-to-model transformations, UML patterns, and UML template models
Developer installation
A primary goal of the asset selection process is to make developer installation of these assets
as easy and consistent as possible. Meeting this goal increases the likelihood that all
developers have the same development environment.
Developer installation must be straightforward:
Find the teams developer resources asset and install it.
Install any required pattern implementations from update sites and exported JET plug-ins.
Extract the source code from the Source Configuration Management (SCM) Repository
using a team project set.
If, during development, any of these assets change, the developer only needs to:
Update the developer resources project in the developers workspace.
Run the update manager to search for updates to pattern implementation features.
Refresh the developers source code from the SCM Repository, and, if new projects are
added, re-import the team project set.
Figure 19-12 The RAS Asset (location and manifest) export wizard page
4. Click Next.
5. Enter an asset description on the RAS Asset Description page:
a. Enter bean-feature for Name.
b. Enter descriptive text for the short description and the description.
c. Click Next.
6. In the RAS Asset Artifacts page, select the feature project:
a. Check com.zyx.patterns.beans-feature.
b. Check Export as a deployable feature, fragment or plug-in.
Figure 19-13 on page 610 shows the completed wizard page.
609
Figure 19-13 The RAS Asset Artifacts page showing the selected feature
7. Click Finish.
The wizard builds the feature and places the built plug-ins and features into the specified RAS
file. The RAS file can then be deployed to other users using any of the methods described
earlier, including placing the asset into a RAS Repository.
610
611
612
20
Chapter 20.
Consuming pattern
implementations
This chapter describes consuming pattern assets, such as those pattern assets developed in
Chapter 17, Produce: Model-to-text pattern implementations on page 469, Chapter 18,
Produce: Model-to-model on page 529, and Chapter 19, Produce: Packaging for
deployment on page 587.
613
20.1 Introduction
The previous chapters in this part have been concerned with the production of pattern
implementations. This chapter discusses aspects of their use.
614
Integrated pattern
application
Transformation
configurations
Generated user-owned
artifacts
Generated non-modifiable
artifacts
615
The name of the file is the name of the launch configuration with a .launch extension. The file
contains an XML document describing the launch parameters and values.
616
Where possible, include all of the attributes on the same line as the start tag.
Keep attributes organized in a canonical order. For example, attributes can be sorted
alphabetically by name.
617
Description
Resolution
Orphaned file
Renamed file
Dead code
Renamed code
Shared files
Files that are modified both by the user and the transformation.
618
<?xml version="1.0"?>
<!-- ======================================================================
builds.autobuild
Build Beans automatically
====================================================================== -->
<project name="builds.autobuild" default="build">
<description>
Build Beans automatically
</description>
<!-- =================================
target: build
619
================================= -->
<target name="build" description="--> Build Beans automatically">
<jet.transform
transformid="com.zyx.patterns.beans.derived.subclass"
source="com.zyx.patterns.tests/beans.xml"/>
</target>
</project>
The jet.transform element is the Ant task that launches a JET. The tag runs a
transformation com.zyx.patterns.beans.derived.subclass with the file
com.zyx.patterns.tests/beans.xml as input. The path name for the source file is workspace
relative, so the first segment refers to a project.
To run the build, follow these steps:
1. Create an Ant build file in the project containing the input:
a. Right-click the project, and click File New File.
b. Enter build.xml, and click Finish.
2. Open the file in the text editor and enter the text shown in Example 20-1 on page 619.
Save and close the editor.
Note that Eclipse includes an Ant editor, but it does not open automatically if the file name
is not build.xml. If you want a different name, the best approach is to create a file named
build.xml, and then rename it after saving.
3. Right-click the build file, and click Run As Ant Build. Note that there are two Ant Build
entries in the context menu. Choose the second Ant Build entry, which is the one with the
ellipsis (Ant Build...). Figure 20-2 shows the correct context menu.
Figure 20-2 Context menu to run Ant Build after providing additional information
620
6. Click Run. A console view will appear, and the transformation will execute.
621
3. Click Import, and select the Ant launch configuration created in The jet.transform Ant
task on page 619 and click OK.
Figure 20-5 shows the updated Builders pane in the dialog.
Figure 20-5 The Builders pane updated with the new Ant build
4. Click the new builder, and click Edit. An Ant launch configuration dialog will appear.
5. Click the Targets tab.
By default, the Ant build is set to run only for clean and manual builds.
6. Click Set Targets next to the Auto Build list.
7. No changes are required in the Set Targets dialog. Click OK.
The Ant builder is now set to run whenever an automatic build is run. However, the builder
will run whenever any file in the project changes.
622
623
Figure 20-6 The properties of a Java .class file showing the Derived property
In a JET transformation, file actions (implemented by the ws:file tag) can set the derived
attribute. When using JET authoring, you set this attribute in the JET authoring editor:
1. Double-click transform.tma in the JET project to open the JET authoring editor.
2. In the rightmost tree, click a file action that generates non-modifiable files.
3. In the Properties view, find derived under Action Parameters, and set its value to true.
Figure 20-7 on page 625 shows setting the derived action parameter.
624
4. Right-click any element in the rightmost tree, and click Update Project.
The generated JET ws:file tag has a corresponding derived attribute:
<ws:file derived="true"
path="{$beanPackage/@srcFolder}/{$beanPackage/@dirBeans}/{$bean/@clsBean}.java"
replace="true" template="templates/bean/bean.java.jet"/>
625
626
Figure 20-8 The JET transformation properties in the plug-in manifest editor
5. In the overrides field, enter the ID of the transformation being overridden. For the case
study, enter com.zyx.patterns.beans.derived.subclass.
6. Save and close the editor. Click File Save, and then File Close.
The new JET project now has access to all of the templates that were defined in the original
JET transformation. The next step is to create new versions of the templates requiring
changes.
627
Modify main.jet
To modify the main.jet template:
1. Double-click the file templates/main.jet. The file will open in the editor.
2. Select the entire template text, and replace it with the code from Example 20-3.
Example 20-3 Main.jet template modified to execute the overridden version of the template
/*
* Copyright <f:formatNow pattern="yyyy"/> ZYX Electronics
*/
4. Save and close the template. Click File Save and then File Close.
The f:formatNow tag returns the current year.
<c:include template="templates/copyright.java.jet"/>
<c:include template="templates/bean/bean.java.jet" super="true"/>
6. Save and close the editor. Click File Save and File Exit.
7. Create a similar template templates/beanPackage/factory.java.jet.
Example 20-6 on page 629 shows the code.
628
<c:include template="templates/copyright.java.jet"/>
<c:include template="templates/beanPackage/factory.java.jet" super="true"/>
8. Create a similar template templates/internalHasDerived/concrete.bean.java.jet.
Example 20-7 shows the code.
Example 20-7 The overridden concrete.bean.java.jet template
<c:include template="templates/copyright.java.jet"/>
<c:include template="templates/internalHasDerived/concrete.bean.java.jet"
super="true"/>
629
630
21
Chapter 21.
Managing pattern
implementation assets
This chapter describes the management of pattern implementation assets.
631
21.1 Introduction
In this chapter, we discuss the management of pattern implementations as reusable assets.
We discuss the following topics:
Encouraging asset creation
Enabling multiple versions of an asset to coexist in a single workbench
There are a number of possible solutions. Arranged roughly in order of increasing complexity,
these solutions are:
1. Change the plug-in ID whenever new versions are developed.
2. Do not install conflicting plug-ins. Instead, keep them as workspace projects and force the
developer to open and close the appropriate projects when the developer switches
contexts. This solution is only viable for JET transformations. Model-to-model
transformations and Uniform Modelling Language (UML) pattern plug-ins must be
installed.
3. Force developers to maintain two (or more) product installations and to switch between
them.
4. Ensure compatibility between plug-in versions so that only the latest version is installed
and active.
Although option four is the best technical solution, it is more costly solution to implement. In
particular, it imposes a cost on the pattern implementation author every tim that e the pattern
evolves. The author must consider the impact of any changes on other projects and design a
compatible enhancement. The extra effort to maintain compatibility is not likely to be of
immediate benefit to the pattern implementation author or the current project. The extra effort,
however, can be of value to the organization as a whole. In these situations, the organization
must have a method of funding extra effort for the common good.
Failing the necessary funding support for option four, option one is a reasonable solution,
especially in the context of pattern-based engineering, where paybacks on pattern
implementation development are expected within a single project. Reuse outside the existing
project can result in the duplication of pattern implementation code, but at a net cost
reduction. (The reusing team is more productive at no additional cost to the originating team.)
The explosion of pattern versions can be controlled by encouraging teams to move toward
the latest (and hopefully most highly evolved) version of the pattern implementation over time.
633
634
Part 5
Part
Appendixes
635
636
Appendix A.
637
W eb Client
Application Server
Database
M etada ta
Asset
HTT P/HTT P S
Artifac t
Web Services /
HTT P/HTT P S
Artifac t
Artifac t
Integrations
LDAP System
ClearC ase
ClearQ uest
WebSp here Ser vice
Reg istry and R epos itory
Eclipse Client
Figure A-1 Rational Asset Manager architecture
Assets are a collection of artifacts, or files, that provide a reusable solution to a specific
business problem. To facilitate reuse, assets contain descriptive information that explains
their purpose, use, and relation to other assets. This additional information is called metadata.
The database holds metadata information about the assets loaded into the Repository (name,
description, GUID, version list of artifacts, and so forth) and the Rational Asset Manager
configuration (communities, forums, permissions, asset types, categories, attributes,
relationship types, and so forth).
The asset itself is packaged as a .ras file (according to the Reusable Asset Specification
(RAS) specification) and stored on the Disk Storage (file system or ClearCase, and you can
configure it), ready to be consumed. When a user wants to download an asset, Rational
Asset Manager uses the persistence adapter to retrieve the assets or artifacts by the GUID
and version.
638
To improve performance in searches, Rational Asset Manager does not use the performance
adapter to retrieve the assets. Everything is driven from the database or the index files that
are used to search for assets.
Rational Asset Manager can integrate with a Lightweight Directory Access Protocol (LDAP)
registry to reuse existing user and group information and to authenticate a users
authorizations for access.
Rational Asset Manager can also integrate with external tools to help development teams to
produce, consume, and govern any kind of asset.
Figure A-2 represents an overview of the tools with which Rational Asset Manager can be
integrated.
639
WebSphere Service Registry and Repository into Rational Asset Manager, helping
developers to search for already published service assets and their supporting development
assets. A.3.1, Integrating Rational Asset Manager with WSRR on page 661 gives more
detailed information about how this integration works and how to configure it.
Rational Asset Manager server can use Rational ClearCase to store assets as an alternative
to using the file system. Rational Asset Manage also recognizes when artifacts that are going
to be submitted to its control are under the control of a version control system, such as
Rational ClearCase or Concurrent Versions System (CVS), and records this information to
use later when the user wants to download or import the asset. A.3.3, Integrating Rational
Asset Manager with Rational ClearCase on page 688 describes the details of the integration
with Rational ClearCase. For more details about the integration with the Concurrent Versions
System (CVS) tool, go to the online Help of the Rational Asset Manager product.
The Asset Management Eclipse perspective of Rational Asset Manager allows users of
Eclipse-based tools, such as Rational Software Architect, to use a flexible user interface to
quickly find and package assets without having to leave the development environment.
A specific integration exists between Rational Asset Manager and Rational Software Architect
through the Rational Asset Manager Configurator Plug-in. This plug-in allows the user to
export as XML Metadata Interchange (XMI) models the Rational Asset Manager configuration
data, such as communities, asset types, categories, attributes, and relationships, using
Rational Software Architect and importing it into Rational Asset Manager. A.5.1, Rational
Asset Manager configurator tool on page 711 gives detailed information about how to install
and use this plug-in.
Note: You can download this plug-in from developerWorks:
http://www.ibm.com/developerworks/rational/library/07/0814_larsen/
Scalability
Availability
Maintainability
Security
Product integrations
You can obtain more information about these topics in greater detail at:
http://www.ibm.com/developerworks/rational/downloads/07/ram_plan_config_guide/inde
x.html?S_TACT=105AGX15&S_CMP=LP
Scalability
Scalability defines how easily a site will expand. The number of users, assets, and
communities for a given Rational Asset Manager installation must expand, sometimes with
little warning, and grow to support an increased load. The increased load can come from
many sources, such as adding additional teams or departments to the existing set of Rational
Asset Manager users or importing large sets of historical assets into Rational Asset Manager.
Most often, scalability is achieved by adding additional hardware to the WebSphere
configuration. Scalability, however, is an architectural consideration that must drive the
design of your WebSphere architecture. Simply adding new hardware to the configuration
might not improve performance and throughput or improve scalability.
640
The choice between scaling-up and scaling-out is usually a decision of preference, cost, and
the nature of your environment. However, application resiliency issues can change your
preferences. Scaling-up means to implement vertical scaling on a small number of machines
with many processors and large amounts of addressable user space memory. This can
present fairly significant single points of failure (SPOF), because your environment is
composed of fewer large machines. Scaling-out, however, means using a larger number of
smaller machines. This can generally be thought of as significantly more resilient, because it
is unlikely that the failure of one small server is adequate to create a complete application
outage. However, scaling-out introduces a higher maintenance overhead.
Availability
Also referred to as fault-tolerance or resiliency, availability is the term frequently used to
describe the ability of a system to provide operational continuity despite the incidence of
failed components and systems. Architectural decisions, such as horizontal compared to
vertical scaling and utilizing backup load balancers (that is, dispatchers), will have an impact
on the availability of your Rational Asset Manager application. Availability must be considered
for all shared resources, networks, and disk storage systems that comprise your Rational
Asset Manager environment.
A fault-tolerant design allows an application or server to fail but still allows other members of
the cluster to continue to service clients. There are two categories of failover: server failover
and session failover. When server failover occurs, sessions on the failed cluster member are
lost (a user will have to log in again) but services are still available to the clients. In session
failover, the extant sessions are resumed by other members of the cluster as though the
cluster member had not failed (although it is possible that the last transaction might have
been lost).
Rational Asset Manager supports server failover provided that a redundant infrastructure is
configured to support it.
Maintainability
Maintainability is the ability to keep the system running before, during, and after scheduled
maintenance. When considering maintainability in performance and scalability
considerations, remember that maintenance periodically needs to be performed on hardware
components, operating systems, and software products in addition to the application
components.
While maintainability is somewhat related to availability, there are specific issues that need to
be considered when deploying a topology that is maintainable. In fact, maintainability factors
are at cross purposes to availability. For instance, ease of maintainability dictates that you
must minimize the number of application server instances in order to facilitate online software
upgrades. Taken to the extreme, this results in a single application server instance, which of
course does not provide a high availability solution and the entire server needs to be taken
off-line for maintenance. In many cases, it is also possible that a single application server
instance cannot provide the required throughput or performance.
Having a minimum of two application servers on two separate physical servers will allow for
better availability. You must, however, ensure that a single server can handle the entire
application load during that maintenance period.
Security
Sites using Secure Sockets Layer (SSL) to communicate between the client and Web server
must consider utilizing a form of SSL accelerator hardware in the server, or even an external
device that off-loads all SSL traffic prior to communication with the Web server to help
improve performance.
641
Product integrations
If a Rational Asset Manager installation is meant to be integrated with optional integrations,
such as Rational ClearCase, Rational ClearQuest, or WebSphere Service Registry and
Repository, considerations must be made for a common authentication strategy, such as
LDAP. Connectivity to each of the constituent components must also be considered. If the
products will cross firewall boundaries, the appropriate ports will need to be open for each of
the integrated products.
Configure assets: Define the infrastructure and criteria for assets as they are
submitted into the Repository. This task will include defining asset types, asset
attributes, asset relationships, and category schemas.
642
Category
Schemas
Asset
Attributes
Relationship
Types
External tools
Installation
Configuration
Community X
Community Y
There can be an additional Administrator role when Rational Asset Manager is integrated with
external tools called Integration Administrator. This role is responsible for integrating the
Rational Asset Manager Repository with other development life cycle tools, such as Rational
ClearCase, Rational ClearQuest, and WebSphere Service Registry and Repository.
Administrators will use specific Administrators menus available in the Rational Asset
Manager Web client to configure metadata information (this functionality is not available in the
Rational Asset Manager Eclipse client. For more information about differences between these
client types, go to A.2.3, Installing Rational Asset Manager clients (Web and Eclipse) on
page 655.
Optionally, if the Administrator wants to have a visual representation of an specific Rational
Asset Manager configuration, the Administrator can use the Rational Asset Manager
Configurator plug-in and Rational Software Architect that provide a Uniform Modelling
Language (UML) visualization of the configuration and allow the import and export of these
configurations into an XMI file. There is a specific section at the end of Appendix A that
covers the use of this additional plug-in.
643
644
Note that if you have a large amount of memory space on your application server, you must
consider Vertical Scaling (adding additional WebSphere Application Server instances to the
same machine). Vertical scaling deals with the efficiency of using a systems memory. A
client request to the server causes the server to allocate memory, which is later released by
the garbage collection thread in the Java virtual machine (JVM). When the garbage
collection process runs, it often creates large CPU overhead. On a 64-bit machine (large
memory space), having multiple WebSphere Application Server instances running will help
distribute the garbage collection penalty over time.
645
A load balancer distributes the load across a number of systems. A load balancer is required
if you have more than one HTTP server. A software-based load balancer, such as Edge
Component, is appropriate for moderately sized deployments. A hardware-based load
balancer is faster and more appropriate for larger deployments, which must support a very
large number of concurrent users.
A forward caching proxy system caches application data for clients and relieves load from
other server systems. One forward proxy system is needed when your Rational Asset
Manager server must support a moderate number of concurrent users. Additional proxy
systems might be needed if your Rational Asset Manager server must support an extremely
large number of concurrent users.
The Rational Asset Manager EAR is comprised of two WAR files: the Repository and Web
application and the Web services WAR. The Rational Asset Manager EAR must be deployed
on every WebSphere Application Server instance in the cluster. In addition, Rational Asset
Manager provides a Help and a RUP WAR file. Deploying these WARs is not required by
Rational Asset Manager. If high availability is not required for the Help and RUP support
function, you can deploy them on a single WebSphere Application Server instance or on an
external WebSphere Application Server container.
To support a heavy user load, you need to modify many of the default WebSphere Application
Server settings.
The Rational Asset Manager Repository is normalized for searches and data retrieval, which
means that data is stored in a manner that makes it efficient to search for data, browse
artifacts, and download assets. To do so, every Rational Asset Manager server instance will
build a local index for assets and a local index for artifacts. This design optimizes search
performance, relieves database load, and enhances scalability in a clustered environment.
Our research indicates that local index directories (particularly on a RAID 0 disk) performed
better than sharing the index across nodes.
The most important consideration in choosing database hardware is the number of disks in
the machine and the RAID schema that it uses. We suggest that a RAID array contain six to
10 drives per CPU.
Assets need to be shared across WebSphere Application Server instances. A concurrently
accessed file system is generally the best approach. Rational Asset Manager only accesses
646
these files during uploads, downloads, artifact indexing, and significant changes to the
Rational Asset Manager model that requires an asset manifest update.
A.2.1.3 Database
Rational Asset Manager requires a database for asset and data storage. You can use any of
the officially supported databases, such as DB2, Oracle, or SQL Server. (For detailed
information of specific database versions officially supported, read the release notes of the
Rational Asset Manager version that you install).
The user, who configures the database tables and schema, must have database
Administrator privileges.
A.2.1.5 Integrations
Optionally, you can integrate with Rational ClearQuest, Rational ClearCase, and WebSphere
Service Registry and Repository. Client applications must be installed on the same machine
as the server and Rational Asset Manager server application. To improve performance, the
Appendix A. Rational Asset Manager: Installation and administration
647
servers for these applications typically reside on machines other than the application server.
For detailed information about how these integrations work and how to install these additional
products, see A.3, Rational Asset Manager integrations on page 661 of this appendix.
648
c. When the installation of IBM Installation Manager completes or if the required version
is already installed on your system, Installation Manager starts and automatically
opens the Install Packages wizard to start the Rational Asset Manager installation (see
the following step to install Rational Asset Manager server software on your
workstation).
4. Install Rational Asset Manager Server code.
There are three options to install Rational Asset Manager server as shown in Figure A-6:
649
650
Rational products and will continue to service your existing client machines when you
make the upgrade.
Follow these steps to install and configure the license software and licenses to use
Rational Asset Manager:
a. Install the correct version of the Rational License Server.
Note: For details about installing Rational License Server v7.0.1 for Windows, see the
IBM Rational License Management Guide at:
http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rcl/701/do
cs/install_instruction/install.html
For details about installing Rational License Server v7.0.o.1 for UNIX and Linux, see
the IBM Rational License Management Guide at:
http://download.boulder.ibm.com/ibmdl/pub/software/rationalsdp/v7/rcl/7001/d
ocs/install_instruction/license_admin.pdf
b. Connect to the Rational License Key Center to get the permanent license key or talk
with your IBM Rational marketing representative to get a Rational Asset Manager
evaluation license. You will receive a .upd file containing the valid license keys to use
Rational Asset Manager software.
c. Import the license key and configure your Rational License Server:
i. Download the .upd file to the server where Rational License Server software is
installed and double-click the file to import the license. Accept the confirmation
message and click Import.
ii. IBM Rational License Key Administrator application will run automatically (click No
to the restart license server message).
iii. Go to Settings Client/Server Configuration menu and click the Use License
Server check box and add your machine name and port 27000 (leave Server Type
as Single unless you have chosen to use redundant servers).
iv. Click Show Licenses to test that you have made the correct selections.
v. Select OK when done and Yes to any messages that appear.
vi. Reboot the Windows Flex LM License Server service to ensure that the license
server works properly.
If you have other .upd files, including licenses for other Rational products, just follow
the same steps to import these additional licenses.
d. Configure Rational Asset Manager to communicate with the license server. This step
must be done after you have completed the Rational Asset Manager Server
installation.
6. Configure the Rational Asset Manager Server Application.
To finalize the configuration of the Rational Asset Manager server application, you have to
access the Rational Asset Manager Configuration menu as Figure A-7 on page 652
shows (using the URL:
http://localhost:<port>/com.ibm.ram.repository.web/home.faces
651
Use the user ID admin and the password admin to perform the following steps:
a. Specify license server path: Configure the path to the Rational license server that was
configured in the previous step 5 by following the format 27000@<server name> as
Figure A-8 shows.
b. Specify server path: Configure the server that will be listed in the manifest of all asset
files as Figure A-9 shows.
c. Specify documentation path: Configure the URL that will be used to access the help
application as Figure A-10 shows.
d. Configure disk storage: You can use Rational ClearCase or the file system to store
data. The persist type and location indicate how and where assets will be stored. If you
652
select to use the file stem, the persist folder is where the assets will be stored and the
local folder is used to store data, such as search indexes and assets, before they are
stored in the Repository as Figure A-11 shows.
For more information about how the Rational Clearcase integration works, go to
A.3.3, Integrating Rational Asset Manager with Rational ClearCase of this
appendix.
Restriction: You must not change the persist type and folders after assets have
been added to the Repository.
e. Configure web services path: Configure the URL that will be used to access the Web
services application as Figure A-12 shows.
f. Configure e-mail: Set up servers for e-mail if your organization will use the
subscriptions and user notification functionalities of Rational Asset Manager.
g. Configure job schedules: Schedule jobs to run at an interval or at a specific time every
day or week. Make these configurations to ensure the best possible performance for
users.
7. Add additional Repository Administrators to the Repository.
The Repository Administrator can assign any number of users with Repository
Administrator permissions. To perform this task, go to the Administration tab, click
Repository Administrators from the Repository Administration sidebar, and click Add
Administrator to search for the users who will be added as additional Repository
Administrators as shown in Figure A-13 on page 654.
653
654
655
To verify that the Rational Asset Manager Eclipse client installation was successful, launch
Eclipse, and open the Asset Management perspective:
1. Click Window Open Perspective Other.
2. Select Asset Management from the list.
3. Click OK.
To access to the Rational Asset Manager Repository server from the Eclipse client interface,
you need to create a valid connection to the Rational Asset Manager Repository server by
following these next steps:
1. Launch Eclipse.
2. Go to the Asset Management perspective.
3. Right-click with your mouse in the My Repositories view and select the option New
repository connection.
4. Complete the following information to connect to a valid Rational Asset Manager server
repository as Figure A-16 on page 657 shows:
Name: Type a name to identify your connection.
656
URL: Web server path to the Rational Asset Manager server Repository. The default
value is (check this value with your Rational Asset Manager Repository Administrator):
http://localhost:13080/com.ibm.ram.repository.web
User name: A valid user name with permissions to access the server Repository
Password: The password for the user name specified
You optionally can check to connect as an anonymous user (with permissions only to
search for assets).
657
When initially installed, the Rational Asset Manager server application uses file-based
security for user authentication. If you perform the installation scenario where you install the
Rational Asset Manager server with an embedded WebSphere Application Server, the default
installation will automatically configure file-based security for user authentication for you.
If you install Rational Asset Manager onto an existing WebSphere Application Server, you
must configure the user authentication mode yourself.
We do not recommend the file-based authentication model for a production Repository. For
production, you are likely to use the Rational Asset Manager integration with organization
user registries, such as LDAP (you can customize the Rational Asset Manager registry
adapter to use the specific LDAP system that your organization uses). This way, Rational
Asset Manager will automatically search and add users and all of their profile information
from it.
658
659
7. Click Configure.
8. On the Custom User Class Configuration page, complete the form to configure the
relationship between Rational Asset Manager and the LDAP registry schema. If you leave
a text field blank, it will revert to the default value. If you want a value to be null, enter a
space ( ).
a. LDAP servers URL: The URL to the LDAP server; for example, ldap://<url>:389. For
secure communication, use ldaps://<url>:636.
b. Users Distinguished Name: A users name to use to log in to the registry in order to
gain access. Enter the distinguished name of the user, for example,
uid=123456,c=us,ou=exampleorganization,o=example.com.
c. Users Password: The password for the previous user
d. Users Unique ID property: The property name of the users objectClass instance that
represents the unique users ID, for example, (objectClass) persons serialNumber
property or the (objectClass) users sAMAccountName property
e. Users Login ID property: The (objectClass) property that a user uses to log in. Even
though it is common for the Unique ID and login ID to be the same, it is possible that
the registry can be set so that a user logs in using another ID (for example, using an
e-mail address).
f. Users Phone Number property: The (objectClass)s property representing the users
telephone number, for example, (objectClass) persons telephonenumber property
g. Users E-mail property: The (objectClass)s property representing the users e-mail
address, for example, (objectClass) persons mail property
h. LDAP User base searching: To avoid searching parts of the registry that do not
contain user objects, enter the value of the path of the root from where to start the
search, for example, ou=exampleorganization,o=example.com.
i. User search filter: The template to use when searching for a user. The %v represents
the search term that was entered from an input text field. The search will perform as
though a wild card is appended to the search term. The default search template is
constructed to find all person objectClasses where either the mail property or the name
property is the same as the search term.
j. LDAP Group base search: Similar to a users base search just mentioned, this is the
base search for searching groups, for example,
ou=memberlist,ou=groups,o=example.com.
k. Group search filter: Similar to the user-based filter, this is the filter for searching
groups. The default searches any of groupOfUniqueNames (static group),
groupOfNames (static LDAP group), groupOfUrls (dynamic LDAP group), or group
(Active Directory defined group) for the search term entered by the user.
l. Image URL template: It is common to store images somewhere other than an LDAP
registry. It is possible to retrieve a users image using a URL; configure this template to
retrieve the image at the same time as the user information in the registry. In the
template, ${property} represents an LDAP objectClass property of the user object that
is going to be replaced when the image is retrieved, for example, for a user with a uid
property=123456, the default template https://<ImageServer url>/photo/${uid}.jpg
results in the URL https://<ImageServer URL>/photo/123456.jpg.
The Rational Asset Manager Web application is now properly configured to use LDAP for
user authentication and user information retrieval. Community Administrators can now bind
user groups to groups in the LDAP registry on the User Groups page for their community. If
you want to authenticate users by using LDAP, you must configure it from the WebSphere
660
Application Server administrative console. Look for detailed instructions in the Installation
Manual of your WebSphere Application Server.
By default, Rational Asset Manager provides the LDAPUserInformationFactory class to
interface with an LDAP v3 registry. If this method or the default file-based security
mechanism is not what you want, you can configure Rational Asset Manager to use a custom
user class. To do so, place your customized UserInformationFactory class on the containers
classpath and designate its name on the Configuration page of the Rational Asset Manager
Web application. You must have Repository Administrator permissions to use a custom user
class.
Although LDAP is a common user registry, it is possible that user information is provided from
other type of registries, for example, file systems, services, content managers, and so on.
Even in the case of LDAP, it is possible that the manner in which the information is stored is
beyond the capabilities of the default user class to retrieve. Therefore, it is possible to use
any other class that extends the abstract CustomUserInformationFactory class.
When the users and groups have been created or updated in the flat files that store user and
groups authentication or the connection with the LDAP has been set up, the Community
Administrator will start to create, configure, and assign permissions.
661
manages information that is useful for runtime operation, management, and development use
of services. It gives you the ability to select service endpoints dynamically in an SOA run time,
govern runtime changes to service metadata, set and get runtime policies for service
execution, and get deployed service details, such as endpoints and service definitions.
Together these two products create seamless, reusable asset tracking mechanisms through
development and runtime activities.
Assets managed by Rational Asset Manager that contain Web service definitions can be
published to the WebSphere Service Registry and Repository using the integration already
provided in Rational Asset Manager. The integration between both tools also allows you to
synchronize information from WebSphere Service Registry and Repository into Rational
Asset Manager, helping developers to search for already published service assets and their
supporting development assets.
Figure A-17 shows how Rational Asset Manager and WebSphere Service Registry and
Repository tools are integrated.
D e v e lo p m e n t
D e p lo y m e n t / R u n -tim e
R a tio n a l A s s e t M a n a g e r
D e fin e
S e arch
C re a t e
M easure
W e b S p h e re S e r v ic e R e g is try a n d R e p o s ito r y
P u b lis h
G ov ern
M a n a g e s a s s e t in fo r m a tio n fo r
d e v e lo p m e n t a n d r e - u s e
9
9
9
9
F in d
E n r ic h
M anage
G o v e rn
M a n a g e s s e r v ic e in fo r m a tio n f o r d e p lo y m e n t
a n d r u n tim e o p e r a tio n
9
9
9
9
D e fin e a s s e t ty p e s
C re a te s a n d m a n a g e a ll ty p e s o f a s s e ts
P ro v id e a s s e t tra c e a b ility a n d d e ta ils
C o lla b o ra te o n a s s e t d e v e lo p m e n t
S e le c t s e rv ic e e n d p o in ts d y n a m ic a lly a t ru n tim e
G o v e r n r u n tim e c h a n g e s to s e rv ic e m e ta d a ta
S e t r u n tim e p o lic ie s fo r s e rv ic e e x e c u tio n
R e c e iv e d e p lo y e d s e rv ic e d e ta ils
.w s d l
A rtifa c t
.d o c , .u m l
.x m l
Asset
C la s s ifie r
.p p t, .d o c
F e d e r a te d S e a rc h
A n d P u b lis h
R e u s a b le A s s e t
S p e c ific a tio n (R A S )
Type
P o lic y
.x s d
S e rv ic e
C la s s ific a tio n
C la s s ifie r
R e la tio n s h ip
M aps
L ife c y c le
M e ta d a ta
Figure A-17 Rational Asset Manager and WebSphere Service Registry and Repository
662
By default, Rational Asset Manager will make non-secure calls to WebSphere Service
Registry and Repository. If you want, you can configure WebSphere Application Server so
that Rational Asset Manager can make secure Web service calls to WebSphere Service
Registry and Repository by following these steps:
1. Set up Secure Socket Layer (SSL) Configuration Repertoire:
a. Start the server and log in to the WebSphere Application Server administrative
console.
b. Click Security SSL.
c. Click New JSSE Repertoire.
d. In the Alias text field, type a name, for example, WSRRSSLConfig.
e. In the Protocol list, select SSL_TLS.
f. In the Key file name text field, type the path to the DummyClientKeyFile.jks file. You
can enter a relative or full path name. An example full path is
<drive>:\<WAS-Installation>/profiles/<profile-name>/etc/DummyClientKeyFile.jks. An
example relative path is ${USER_INSTALL_ROOT}/etc/DummyClientKeyFile.jks.
g. In the Key file password text field, type the password of the key file. For the
DummyClientKeyFile.jks, it is WebAS.
h. Click OK.
i. Under Messages, click Save.
j. Under SSL configuration repertoire, click Save. An entry will be created.
2. Specify the SSLConfiguration in the VM parameter:
a. Click Servers Application Servers.
b. Click the name of the server.
c. Under Server Infrastructure, click Process Definition.
d. Click New.
e. In the Name text field, type ssl.configName.
f. In the Value text field, type the value of the SSL configuration repertoire, for example,
<node_name>/WSRRSSLConfig.
g. Click OK.
h. Click Save.
i. Restart the server.
The Community Administrator will be the role responsible for creating and configuring the
connections between Rational Asset Manager and WebSphere Service Registry and
Repository for each community.
The connection between both tools must be created before publishing any asset to
WebSphere Service Registry and Repository
To create a new connection, the Community Administrator must follow these steps:
1. Log in to the Rational Asset Manager Web application as a Repository or Community
Administrator.
2. Go to the Administration tab.
3. Select the community that you want to edit.
4. Open the Connections page.
663
To create new connections to the WebSphere Service Registry and Repository instance in
the same community, repeat the actions from Step 5.
664
The indexing interval value specified in step 6.h will determine when the automatic
synchronization of the information between both Rational Asset Manager and WebSphere
Service Registry and Repository starts. However, if for any reason, you need to synchronize
the information, you can force this synchronization to happen. To force the synchronization,
click the link Synchronize that appears to the right of the connection name as shown in
Figure A-19. The synchronization between Rational Asset Manager and WebSphere Service
Registry and Repository will start immediately.
If you want to modify any parameter of an existing WebSphere Service Registry and
Repository connection, just click the name of the connection that you want to modify and it
will open a page with the connection parameters. Modify the information that you want and
click OK to save the changes.
To delete an existing WebSphere Service Registry and Repository connection, click the link
Delete that appears to the right of the connection name and the connection will be
automatically deleted. You can also use the Delete All link to delete all active connections.
665
Note: You do not need to use Rational ClearQuest to take advantage of Rational Asset
Managers review process capability. However, if your company wants to implement a
customized workflow for the review process that is different from the default workflow
defined in Rational Asset Manager, you can use Rational ClearQuest to create this
custom review process easily.
Rational ClearQuest workflows can be customized to manage any type of activity, such as
defects, enhancement requests, new implementations, review processes, and so forth. Each
of these activity types is called a record type in Rational ClearQuest, so if you want to map
discussion forums associated with assets with Rational ClearQuest, you will have to create a
specific record type in Rational ClearQuest to manage this information. If you are using
Rational ClearQuest to create a customized review process for a reusable asset, you will
need to define a a new record type in Rational ClearQuest called review process (or the name
you want to give to it). This appendix will give you detailed information about how you must
create and configure these record types in Rational ClearQuest and how to map them to
Rational Asset Manager.
With Rational ClearQuest, you can also customize all of the metadata information associated
to each record type that you define. This means that with Rational ClearQuest, you can
customize the states and transition actions of the review process, the roles that have
permissions to perform each transition, the information associated to each review or
discussion, and you can even add additional code scripts to automate actions when there is
any state change (for example, you can easily add a script - hook code in Rational
ClearQuest - to make a call to an external application when the review process has been
completed).
To customize these workflows, you can use the Rational ClearQuest Designer tool, which is
installed as part of the Administrator tools component that can be selected when installing the
ClearQuest software.
To learn more about Rational ClearQuest, refer to:
http://www-306.ibm.com/software/awdtools/clearquest/index.html
The next sections give you detailed steps about how to install, configure, and integrate
Rational ClearQuest and Rational Asset Manager in this order:
Installing Rational ClearQuest
Setting up a Rational ClearQuest configuration
Creating Rational Asset Manager and Rational ClearQuest connections
Using Rational ClearQuest to create an asset discussion forum
Using Rational ClearQuest to create a custom review process:
a. Create or customize a new review process record type in Rational ClearQuest.
b. Configure and integrate the new Rational ClearQuest review process in Rational Asset
Manager.
Figure A-20 shows the installations and connections needed to set up the integrations
between Rational Asset Manager and Rational ClearQuest.
Rational ClearQuest
database machine
Rational ClearQuest
database
Rational ClearQuest
rich client
Rational ClearQuest
Web machine
Rational Asset Manager
server
Rational ClearQuest
W eb server
To integrate Rational Asset Manager with Rational ClearQuest, you must install Rational
ClearQuest v7.0.0.0 or later.
For detailed information about ClearQuest client installation, refer to the installation manual
IBM Rational ClearQuest and Rational ClearQuest Multisite: Installation and Upgrade Guide.
After ClearQuest has been installed, you must include the dynamic libraries in the path on the
Web server and the ClearQuest cqini.jar must be set to be loaded by the base classloader of
the Web Server. For detailed information about how to perform these steps, refer to the
Rational Asset Manager Help.
667
Schema Repository
User Databases
Schema A
Version 1
Version 2
Version 3
Schema B
Version 1
Version 2
Version 3
A Rational ClearQuest schema is the metadata for the process model defined in Rational
ClearQuest. This metadata includes a complete description of how record types (as asset
review workflows) have been customized in Rational ClearQuest (description of the states
and transition actions, structure of the data associated with the review workflow, additional
code scripts developed to implement specific business rules, forms, and reports used to view
information about asset reviews). The Rational ClearQuest Administrator can create and
modify schemas using the Administrator tool Rational ClearQuest Designer.
A Rational ClearQuest Schema Repository is the database where Rational ClearQuest stores
the schemas. One Schema Repository can include various schemas (each one, for example,
managing different record types: one schema to manage asset review processes and a
different schema to manage defects). The Schema Repository can also store multiple
versions of the same schema as Figure A-21 shows.
A Rational ClearQuest user database is where Rational ClearQuest stores all of the
information that users are introducing, that is, if you are using Rational ClearQuest to manage
the asset review process, the user database will be where all information about the created
review process is stored. You can use one user database to store all community review
processes, or you can also have different user databases for the review processes of each
community. Different user databases can be associated to the same schema or configuration,
so if you are using a different user database by each asset community, all can be associated
with the same schema so that all of the assets are following the same review process
workflow.
The major benefit of having all review processes in the same user database is that you can
easily collect metrics and reports about the state of the review processes and compare
results for all of the communities using the default capabilities provided by Rational
ClearQuest. However, having all review processes information in the same user database
implies that you have to establish security mechanisms if you do not want to share
information among communities (although these security mechanisms can be implemented
quite easily with the ClearQuest Designer Administrator tool).
668
A Rational ClearQuest connection is a database set that consists of one Schema Repository
and all of its associated databases. The connections are created using the Administrator tool
called Rational ClearQuest Maintenance tool.
The next steps summarize the steps that you have to follow to create and set up a new
Rational ClearQuest connection to be connected with Rational Asset Manager:
Important: The following steps assume that you are using a machine that has the Rational
ClearQuest Administrator and client components installed and that you have a valid
license to use the product.
You also must have created at least two databases: one for the Rational ClearQuest
Schema Repository and another database for the User Database. Rational ClearQuest
supports the most popular databases available in the market, such as Microsoft Access,
Microsoft SQL Server, Oracle, and IBM DB2. For detailed information about the versions
and databases officially supported, consult the latest release notes of the Rational
ClearQuest product.
1. Launch Rational ClearQuest Maintenance Tool.
2. Create a new Schema Repository using the menu: Schema Repository Create.
Select the vendor database that you are using and the connection parameters. For this
example, you will use MS_ACCESS as the database vendor, and you will give the path for
a valid Microsoft Access database name in the Physical Database Name field as
Figure A-22 shows and click Next.
3. Select the Rational ClearQuest data code page that you want for the new Schema
Repository and click Next.
4. Clear the check box to create a sample database and click Finish.
Appendix A. Rational Asset Manager: Installation and administration
669
5. Wait for the creation of the database and when it has finished, click Done.
6. Select in the left window the connection you have just created, right-click and select the
option Rename.
7. Call the new connection that you have just created CQ_ZYXElectronics.
8. Exit Rational ClearQuest Maintenance tool.
9. Launch the Rational ClearQuest Designer tool.
10.In the Rational ClearQuest Designer login window, type admin as the login without any
password and click OK.
11.The next window shows you a list with the default Rational ClearQuest schemas available
by default (these are standard configurations available in Rational ClearQuest just in case
you want to reuse them). Because you are going to use this Rational ClearQuest
configuration to associate discussion forums and review processes to Rational Asset
Manager, you will use the DefectTracking Schema that has already created a record type
called Defect that will be mapped with Rational Asset Managers forum discussions. For
the review process, you will create a new record type. So, select the DefectTracking
Schema and click Next.
12.Type a comment for the new version of the schema that you are creating and click Finish.
In the following sections of this appendix, you will see in detail how to use Rational
ClearQuest Designer to create a custom review workflow process.
13.Close the blank schema that you have just created by using File Close Work, but leave
Rational ClearQuest Designer open.
14.To create an empty Rational ClearQuest user database, select Database New
database and give the following information during the wizard:
a. Logical Database Name: Logical name for the user database. Give the name USER.
b. Comment: Comment for the user database. Enter User database to store asset
review process information.
c. Click Next.
d. Select MS_ACCESS as the database vendor and give the path for a valid Microsoft
Access database name in the Physical Database Name field.
e. Select Production Database.
f. Click Next.
g. Accept the default values for Timeout and Poll Interval fields.
h. Click Next.
i. Select the DefectTracking Schema as the Schema to be associated with the new user
database that you are creating.
j. Click Finish.
k. If the database has been created correctly, you will receive a window confirmation
message saying that the Database was created successfully as shown in
Figure A-23 on page 671.
670
After you have completed the previous steps, you have the needed information to configure
the connection between Rational Asset Manager and Rational ClearQuest (see A.3.2.3,
Creating Rational Asset Manager and ClearQuest Connections on page 671).
In sections A.3.2.4, Using Rational ClearQuest to create an asset discussion forum on
page 673 and A.3.2.5, Using Rational ClearQuest to create a custom review process on
page 674, you will see in detail how to use Rational ClearQuest Designer to create a forum
discussion topic or a customized review process.
671
To create a new connection, the Community Administrator must follow these steps:
1. Log in to the Rational Asset Manager Web application as a Repository or Community
Administrator.
2. Go to the Administration tab.
3. Select the community that you want to edit.
4. Open the Connections tab.
5. Under Change Management Connections, click New connection.
6. In the Choose Repository Type window, select ClearQuest from the list and click OK.
7. On the Repository Connection Details page, complete the form with the details for your
ClearQuest installation as Figure A-24 on page 673 shows:
a. Name: This is a name that you provide for the connection. Name the connection
CQ_ZYXElectronics.
b. Description: Optionally, you can create a description of the connection. The
description can have spaces and special characters.
c. Schema repository: This is the database that is used to store and manage a group of
schemas, including all versions of those schemas and their associated user
databases. This list is populated from the list of connections set up in the Rational
ClearQuest Maintenance Tool on the server machine. The name used for Schema
Repository must be the same name configured on the ClearQuest server. If a different
name is used, you will not be able to access the information from the Rational Asset
Manager server.
Type CQ_ZYXElectronics.
d. Database: This is the particular database within the Schema Repository to which you
want to connect.
Type USER.
e. CQWeb URL: This is where you specify the fully qualified URL to the Rational
ClearQuest Web application.
f. User name: This is the user ID of a user who is authorized to access Rational
ClearQuest. This user will be the user who owns any requests opened in the external
Repository.
Type admin.
g. Password: The users password for accessing Rational ClearQuest.
Do not type any password. Leave it blank.
672
Figure A-24 Rational Asset Manager and Rational ClearQuest connection details
8. Click OK to create the new Rational ClearQuest connection with the information that you
have provided.
673
You can also add new queries to find records in your change management system in the
Queries section. For example, you can add a query to list all reported problems in the system.
674
The use of a Rational ClearQuest-driven review process helps you to extend the default
review process defined in Rational Asset Manager and include additional information, states,
and transition actions during the review states of the default review process (Plan Review,
Review, and Evaluate Review) highlighted in Figure A-26 with the yellow box.
Figure A-26 Review states that will be extended with the Rational ClearQuest-driven review process
Rational Asset Manager uses a batch process to keep the state value in Rational Asset
Manager up-to-date with the state movement of the corresponding record in Rational
ClearQuest. This happens between the Draft and Approved states, otherwise Rational Asset
Manager manages the state.
When you configure the integration, you must define which are the Approved and Rejected
states of your ClearQuest workflow. This way, the synchronization between the tools will
automatically move the state of the asset to the Approved state in Rational Asset Manager
when the review process reaches the Approved state of Rational ClearQuest or to the Draft
state in Rational Asset Manager when the review process reaches the Rejected state of
Rational ClearQuest. This way, the user does not have to synchronize states and information
manually in both tools. Rational Asset Manager and Rational ClearQuest integration takes
care of this synchronization.
Tip: You do not need to give the same name in Rational ClearQuest to the Approved and
Draft states. You will have a mapping section in the configuration menu where you will be
able to select the specific state names given in Rational ClearQuest.
When you have customized the integration between both tools for the review process, each
time a Rational Asset Manager user submits a new asset for review, then a new record will be
Appendix A. Rational Asset Manager: Installation and administration
675
created automatically in Rational ClearQuest. Reviewers will then use the Rational
ClearQuest interface (using any kind of ClearQuest interface client) to go through the review
process, changing the state and information of the ClearQuest record. When the asset
reaches one of the Approved or Rejected states, this information will then be synchronized
and updated into Rational Asset Manager automatically and visible to other Rational Asset
Manager users.
The integration will also allow you to customize the Rational ClearQuest information fields
that you want to synchronize against Rational Asset Manager fields and allow you to perform
this mapping. For example, for the review process you are implementing, you want to
automatically update the name of the asset review record in Rational ClearQuest with the
name of the Rational Asset Manager that is part of the review process.
Restriction: An important aspect that you must remember when configuring the Rational
ClearQuest review process is how to synchronize users and permissions between both
tools. You must establish a mechanism to have the same user reviewers and permissions
in both tools so that only Rational Asset Manager reviewers have permissions to perform
state transitions in Rational ClearQuest for the record that represents the review process
for the asset.
If an asset has different reviewers, although the states and transitions are the same, you
must implement and map the Rational Asset Manager review process to different Rational
ClearQuest record types, each one with different permissions on state transitions.
To simplify user administration in both tools, we recommend that you use an LDAP registry
to manage users and groups. Rational Asset Managers LDAP integration automatically
reads this information for the LDAP registry, but in Rational ClearQuest, the LDAP
integration is only for authentication, so you still have to define the users in Rational
ClearQuest (you can automate this task using the API or the Rational ClearQuest User
Administration Import tool).
676
You will identify this review process as the CQReviewProcess record type in Rational
ClearQuest, and the Rejected and Approved states will be the states to synchronize with
Rational Asset Manager Draft and Approved states respectively.
You must follow the next steps in the Rational ClearQuest Designer tool to create and
customize the CQReviewProcess record type:
1. Launch Rational ClearQuest Designer tool.
2. Type admin as the login and leave the password blank.
3. Click OK.
4. Select Checkout a schema to edit or continue editing previously saved work.
5. Select DefectTracking schema and click Finish.
6. Select the Record Types folder in the left window, right-click, and select Add.
7. Name the new record type CQReviewProcess.
8. Expand the contents of the CQReviewProcess folder as shown in Figure A-28 on
page 678. This represents the information that you will customize for the new Rational
ClearQuest-driven review process.
677
Where:
Fields: This is the information associated to the review process that users must
complete.
State Transition Matrix: This is the matrix representing the workflow that will follow a
review process when it is submitted into Rational ClearQuest. For this example, we
implement the workflow represented in Figure A-27 on page 677.
Actions: This is the list of actions that will produce a change in the workflow. For
example, an state change action will be the action Approve that will produce a
transition of the review process from the FinalReview state to the Approved state.
Behaviors: This represents the status of the information fields in each of the defined
states of the workflow. For example, if we have created an information field called
Headline to give a name to the review process, you can configure that this field will
be Mandatory in the ReviewBoard state. This means that the user must obligatorily
complete this field when a new review process is created (and it goes to the first state
ReviewBoard).
Forms: It is the place where you define the form with the review process information
that will be shown to the users.
Record Scripts: It is the place where you will be able to define code scripts or hooks
(programs that perform or trigger a specific task when a specified set of conditions
exists) that can later be associated to a state transition action or to a field value
change.
9. To add new information fields to the CQReviewProcess record type:
a. Double-click Fields and a new window will be displayed to the right with the default
internal fields already created in Rational ClearQuest in gray.
b. Place the cursor over the window to the right, right-click with the mouse anywhere and
select Add Field as represented in Figure A-29 on page 679.
678
Figure A-29 How to add new fields to the Rational ClearQuest review process record type
c. In the CQReviewProcess Fields window, type Headline for the name of the field that
you want to add (it will automatically create a DB Column Name for you) and the type
of the field (SHORT_STRING), as Figure A-30 shows for the Headline field.
Figure A-30 How to define fields to the Rational ClearQuest review process record type
d. Close the window and the changes will be automatically stored in the Rational
ClearQuest schema.
e. Create another field for the CQReviewProcess record type called Description of type
MULTILINE_STRING, repeating steps 9.b, 9.c, and 9.d.
10.To add new states to the CQReviewProcess record type:
a. Double-click State Transition Matrix and a new window will be displayed to the right
where the new states need to be created.
b. Place the cursor over the window to the right, right-click with the mouse anywhere and
select Add State as represented in Figure A-31 on page 680.
679
Figure A-31 How to add new states to the CQreviewprocess record type
c. In the Add State window, enter the name of the state that you want to add,
ReviewBoard, and repeat this process for each of the following states that you want to
add to the Rational ClearQuest record type: Legal, PeerReview, FinalReview,
Approved, and Rejected, so the final list of states is similar to what is shown in
Figure A-32.
11.To add the new actions that will produce state transitions to the CQReviewProcess record
type:
a. Double-click Actions and a new window will be displayed to the right with the default
internal actions already created in Rational ClearQuest in gray.
b. Place the cursor over the window to the right, right-click with the mouse anywhere and
select Add action as represented in Figure A-33 on page 681.
680
Figure A-33 How to add new actions to the Rational ClearQuest review process record type
c. For the LegalScanRequired action, which will produce a state change from the
ReviewBoard state to the Legal state, complete the following information:
i. In the General tab, enter LegalScanRequired for Action Name and CHANGE_STATE
for Type.
ii. In the State tab, select ReviewBoard for the Source State and Legal for the
Destination State.
d. Follow the sub-steps of step c to complete the other actions with the following
information represented in Table A-1.
Table A-1 Actions to create the CQReviewProcess record type
Action name
Type
Source state
Destination state
LegalScanRequired
CHANGE_STATE
ReviewBoard
Legal
LegalScanCompleted
CHANGE_STATE
Legal
ReviewBoard
OpenToPeers
CHANGE_STATE
ReviewBoard
PeerReview
PeerApprove
CHANGE_STATE
PeerReview
FinalReview
Approve
CHANGE_STATE
FinalReview
Approved
Reject
CHANGE_STATE
ReviewBoard
PeerReview
FinalReview
Rejected
The final list of actions must be similar to what is shown in Figure A-34 on page 682.
681
e. To synchronize the review process, you must have the same users and permissions
created in Rational Asset Manager and Rational ClearQuest, so you have to configure
that only the reviewers have permissions to perform state transitions in the
CQReviewProcess record type. To implement this restriction, you must create a User
Group in Rational ClearQuest with the individual reviewers and then associate this
group to the state transition that you want to restrict. You have to follow these steps:
i. To create new users and groups in Rational Asset Manager, we recommend to
integrate with an LDAP registry.
ii. To create new users and groups in Rational ClearQuest, you can use the API to
create and synchronize user and group information automatically with your LDAP
system, or you can use the Rational ClearQuest User Administrator tool to create
users and groups. To simplify user administration, this tool also allows you to import
and export user information automatically from a text file so you do not have to do
this operation for each user, one at a time. When you have created the users and
groups in Rational ClearQuest, the tool will use LDAP authentication to validate the
user login and password.
iii. To assign permissions to state change options, you must select the action to which
you want to add the restriction, and in the Access Control column, select the User
Groups that will have permissions to perform the review process (click User
Groups and select the groups that you want) as Figure A-35 shows.
12.If you want to change the default OPTIONAL behavior of the information fields added in
the previous step 9, double-click Behaviors and a new window will be displayed to the
right with the default behavior (in gray) for all fields and states that have already been
created as Figure A-36 on page 683 represents.
682
To make the Headline field mandatory for the ReviewBoard state, right-click with the
mouse on the cell that defines the default behavior for this field and state and change its
value from OPTIONAL to MANDATORY. The final matrix of behaviors is similar to what is
shown in Figure A-37.
13..To organize the information fields associated to the CQReviewProcess record type and to
customize how this information is displayed to the user, you will create a new Form:
a. Select Form Folder, right-click with the mouse and select Add. This will create and
automatically open a new empty form with two tabs and two additional windows: one
with the list of the information fields that can be added to the form and the other with
the palette of controls that can also be added to the form, as shown in Figure A-38 on
page 684.
683
b. To change the name of the tabs, double-click its name and enter a new name for it,
such as General.
c. To add the information fields that you want to show on the tab, just select the Headline
field in the field list window and drag and drop the field name over the form. This action
will automatically create the label and the edit box for the Headline field in the form.
Repeat the same actions for the ID, State, and Description fields and resize them in
the tab so that the General tab looks similar to what is represented in Figure A-39.
d. Repeat the same actions of the previous steps to add a new tab (to create a new tab,
go to the Edit Add Tab menu) that will display the History field (this field will
automatically show the history of all of the Rational ClearQuest actions associated to
each created review process, such as an state change, a modification, and so forth.
The final tab needs to be similar to what is shown in Figure A-40 on page 685.
684
14.After you have completed all of the modifications to the CQReviewProcess record type,
save the changes (File Save Work) and validate the changes using File Validate
Work. If there is any error or warning in your configuration or schema, Rational
ClearQuest Designer will show a description of it in the Validation Output window at the
bottom. Fix all of the existing errors, if any.
15.Check in the new version of the schema that you have just created using File Check-in
and give a description for the changes. You will receive an information message, click OK,
and the schema will close.
16.To apply the changes that you have already made to the Rational ClearQuest database,
follow these steps:
a. Select Database Upgrade Database. You receive a message warning that these
upgrades cannot be reversed. Click Yes to this warning.
b. Select the User Database that you created previously (USER) and click Next.
c. Select the schema version that you have just created and that you want to apply to the
Rational ClearQuest user database and click Finish. You will receive a confirmation
message that the Database has been upgraded successfully.
685
Figure A-41 Select ClearQuest driven review process as the review process type
686
Figure A-43 Map Rational Asset Manager and Rational ClearQuest states
iv. You can also map and synchronize information fields between both tools, so
associate the Rational ClearQuest headline field with the asset name in Rational
Asset Manager and the Rational ClearQuest description field to the asset URL link.
To map these fields, click Update to automatically synchronize the fields and select
the corresponding Rational Asset Manager and Rational ClearQuest fields using
the Insert value link as Figure A-44 shows.
Figure A-44 Map Rational Asset Manager and Rational ClearQuest information fields
e. Add review board members, reviewers, and user groups to this review, including users
or user groups that you have already created. Optionally, select the Make reviews
private check box so that reviewer names are not visible to other users.
Important: Remember that you must synchronize user information and permissions
so that the reviewers that you define in Rational Asset Manager must be active
users of Rational ClearQuest, and they must have been configured to have
permissions to perform state transitions with the Rational ClearQuest Designer tool.
f. Optionally, set reminders to send e-mail notifications on the schedule that you choose
in the lists. For example, configure 3 Days, which will send an e-mail reminder every
three days to the reviewers that you specified.
13. Click OK to save the changes.
If you have created other review processes for assets in the same community, you must give
priority to this new review process that you have created to open source frameworks. This
way, Rational Asset Manager will give high priority to this customized review process for open
source frameworks compared to other asset types submitted to the community that go
through the standard Rational Asset Manager review process. To give high priority to the
custom review process, go to the Review Processes tab for the Implementation community,
select the review process that you have just created for open source frameworks (ClearQuest
driven review) and click Move Up as Figure A-45 on page 688 shows.
687
Figure A-45 Give high priority to the Rational ClearQuest custom review process
688
Both Rational Asset Manager and Rational ClearCase have the concept of version but it
represents different things for each tool:
Rational ClearCase controls and manage versions of individual artifacts or files (file
elements for Rational ClearCase), so each element can have different versions (a version
is a specific revision of an element) as Figure A-46 shows.
hello.java
library.jar
Element
properties.xml
Version
Version tree of
the element
Rational Asset Manager controls and manages versions of individual assets. Assets will
be composed of individual artifacts (that can be under the control of Rational ClearCase or
not) and additional metadata information to complete the asset information, such as
name, description, asset type, category to which the asset belongs, and so forth. All of this
information will be packaged in accordance with the Reusable Asset Specification (RAS)
standard.
So, there are generally two major levels for versioning with assets: the asset version and the
artifact version. The artifact version is typically managed and dictated by the source control
management system (Rational ClearCase), whereas the asset version is generally dictated
by the policies of the enterprise and managed by the Repository. Figure A-47 illustrates these
two major levels for versioning.
689
Structural changes include altering the content of the asset, which are the artifacts and the
assets relationships. So, if the content of an artifact is changed, thereby creating a new
version of the artifact in Rational ClearCase, and the asset now needs to point to this new
version of the artifact, this requires a new version of the asset as shown in Figure A-48.
When there is a new asset version, Rational Asset Manager creates a relationship between
the previous asset version and the current asset version. Preserving these relationships
between asset versions provides traceability and impact analysis. Rational Asset Manager
maintains the same value of the Unique Id field for all asset versions that are created.
Changing or adding relationships to an asset is also considered a structural change and
requires a change in the assets version. So, if as in Figure A-47 on page 689, the XYZ
Component had a new relationship to another test asset, such as ABC Integration Test, the
XYZ Component version must be updated.
To create a new version of the asset due to structural changes in that asset, you must select
the link Create new asset that is available in the Asset Detail Tools section as shown in
Figure A-49.
When you create a new asset version, non-structural changes include those changes that
affect certain metadata of the asset. The metadata structure for assets is described by the
Object Management Group (OMG) Reusable Asset Specification (RAS). For more
information about RAS, go to http://www.omg.org. However, certain metadata does describe
690
structural aspects of the asset, such as artifact metadata and asset relationship metadata.
Figure A-50 illustrates the candidate non-structural metadata in RAS. The intent is that if the
non-structural metadata changes, no new asset version is required.
To update the asset content due to non-structural changes in that asset, you must select the
link Modify that is available in the Asset Detail Tools section as shown in Figure A-51.
691
Figure A-52 Replication of Rational Asset Manager and Rational ClearCase repositories
In the second topology, a single Rational Asset Manager Repository exists in the
organization with distributed Rational ClearCase repositories at each site as Figure A-53
shows. The single asset Repository references artifacts in the distributed Rational
ClearCase repositories. There are no asset replication issues to address, but certainly
there are issues of artifact replication and ensuring that the asset metadata points to the
proper location for artifacts.
Figure A-53 Single Rational Asset Manager Repository with distributed Rational ClearCase
repositories
692
Server Integration: Rational Asset Manager can use the Rational ClearCase Repository
to store uploaded assets instead of using the file system. This is a server administration
configuration option, and it is completely transparent to the Rational Asset Manager user.
Client Integration: When Rational Asset Manager is using Eclipse and Rational
ClearCase to develop and store the assets and when these assets are submitted to the
Rational Asset Manager server control, Rational Asset Manager will recognize that the
submitted assets come from a version control tool and will create a reference to its source
and will store this information with the asset. And this integration will work; although, the
Rational Asset Manager server has not been configured to use Rational ClearCase to
store the submitted assets.
Note: Restriction: This client integration with Rational ClearCase will only work if using
the Rational Asset Manager eclipse client.
Although assets submitted come from a Rational ClearCase Repository, Rational Asset
Manager will create a local copy of them (and not a reference to Rational ClearCase
information) in the file system or in the Rational ClearCase view configured as the disk
storage location for the server. The reason for this duplication is that Rational Asset
Manager caches the artifacts for faster indexing, browsing, and so forth, and this way,
Rational Asset Manager does not have to go to external repositories to look for information
that slows down the Rational Asset Manager performance.
693
Important: Because asset information related with development assets can be repeated in
Rational Asset Manager and Rational ClearCase repositories, it is important to establish a
process in the organization to force all users to use Rational Asset Manager as the central
Repository to manage all assets when the development has finished and assets are
validated and ready to be reused by other users. Use Rational ClearCase as the
configuration management Repository used by the software development teams to control
software development of the artifacts contained in the assets.
Development users need to use the Rational Asset Manager interface to download or
import asset artifacts that they want to reuse. These files or artifacts will be added to
Rational ClearCase source control automatically using the Rational Asset Manager and
Rational ClearCase integration, and they must not get that information by directly
accessing the Rational ClearCase Repository. That way, Rational Asset Manager
manages the asset life cycle, and users access the correct asset version, which has been
verified for use (composed of artifacts and metadata information).
Rational Asset Manager will always store the validated asset version (metadata and
artifacts,) and Rational ClearCase will be the Repository to manage and control multiple
versions of the individual artifacts during development. Rational ClearCase users must not
create a new asset version each time that they modify a new artifact version in Rational
ClearCase. They must only create a new version of the asset when all artifacts that
compose the asset are finished and validated to be reused by other users. So, developers
can create five versions of a file in Rational ClearCase and just update the last one to
Rational Asset Manager to create a new asset version.
Because there is not a mechanism implemented in the tools to manage this process,
clients must define this process in their organizations and, if possible, implement an
automatic mechanism in the tools through customization to force users to follow this
process. An easy example of automation is to implement a trigger or extension to the
Rational ClearCase checkout operation. This trigger warns the user that the element that
the user wants to modify is included in an asset, so the user must download or import the
asset from the Rational Asset Manager.
When any user wants to import any of these assets (submitted from Rational ClearCase and
with SCM information) back from the Eclipse client, Rational Asset Manager will ask the user
where the user wants to import the asset: to the local system deleting all SCM information
(because, for example, the user is not a developer and does not have permission to access
the Rational ClearCase Repository) or to the Rational ClearCase Repository. You will see
how this integration in the client works in A.3.3.4, How ClearCase integration works in the
client on page 696.
Figure A-54 on page 695 explains the difference between both integrations ( Rational Asset
Manager-Rational Clearcase server integration in blue and the Rational Asset
Manager-Rational ClearCase Eclipse client integration in green).
694
RAM Server
Disk Storage
Location
File System as Disk
Storage Location
or
ClearCase as Disk
Storage Location
RAM-ClearCase
Server Integration
RAM-ClearCase
Client Integration
RAM VOB
Server
VOB
Development
ClearCase Server
Figure A-54 Rational Asset Manager and Rational ClearCase server and client integrations
695
696
b. Because you selected the asset type of Framework, you have to give additional
information for the attributes associated to this asset type and click Next as shown in
Figure A-57.
c. You have to categorize the asset by selecting values for the categories represented on
the left side of Figure A-58 and click Next to continue.
d. Next, you have to select the files and folders from the available artifacts in your
workspace to include in the asset and click Finish as Figure A-59 on page 698 shows.
697
e. Because the artifacts to be included in the asset are under Rational ClearCase version
control, and if you are using Rational ClearQuest integrated with Rational ClearCase,
you have to select the activity to record the new versions of the files and click OK as
Figure A-60 shows.
The asset can have a red icon showing that you have not attached all of the required
information to the asset. To review the problems, go to the Problems view and fix them.
f. After filling all required information fields, click Submit, which is available in the asset
editor, to submit the new asset to the Rational Asset Manager Repository as shown in
Figure A-61.
698
submission process, Rational Asset Manager will ask you if you want to add additional
artifact resources to Rational ClearCase and check them in as Figure A-62 shows.
This additional artifact resource contains information about the artifacts relations with
Rational Clearcase and will be used later by Rational Asset Manager when another
user imports the asset.
i. Click OK to check in these additional artifact resources to Rational ClearCase.
j. When the asset has been submitted correctly to the Rational Asset Manager
Repository, you will see that the asset icon in the Asset Explorer turns green, and the
asset editor shows the information associated to the asset as shown in Figure A-63.
Because the asset is still in the Review state, the reviewers assigned to this asset type
must review it in order to change its state to Approved.
Rational Asset Manager stores the manifest file with the asset metadata and artifacts
information (as Figure A-64 on page 700 shows) in Rational ClearCase.
699
Figure A-64 Rational Asset Manager manifest file created in Rational ClearCase
You can use this manifest file to compare differences between two asset versions if the files
are submitted from Rational ClearCase.
If the asset was uploaded from the Eclipse client and the files are source-controlled, the SCM
information will be attached to each artifacts meta-information. You can verify it by opening
the asset in the Rational Asset Manager Web client, going to the assets content tab, and if
you click the icon by the artifact, it opens a context information dialog with the SCM
information in it as Figure A-65 shows.
When you or another user downloads assets that were created with SCM information on
them, Rational Asset Manager will give you the option to get an asset by value and will not
attach you to the SCM information or the option to use the VOB/view reference information
and import it again in Rational ClearCase.
To import the asset that was created with SCM information from the Eclipse client, follow
these steps:
1. Open the asset in the Eclipse interface and click Import as shown in Figure A-66 on
page 701.
700
Figure A-66 Import asset with SCM information from the Eclipse interface
2. Rational Asset Manager will then show you a window with the projects listed that are
included in the asset and that will be installed into your workspace. Click Next.
3. If the resources that you want to import already exist in your workspace, you will receive a
warning message. Accept the option to overwrite them, or delete the resources from your
workspace, and click Finish.
4. Because Rational Asset Manager knows that the artifacts assets were submitted from
Rational ClearCase, it will show a window with three options as shown in Figure A-67.
Import latest from current branch: Click this option to import the file using the
original branch where the asset was created.
Import from other existing branches: If there are branches that were created
since the publication, Rational Asset Manager will list for you the existing branches
701
so that you can attach the files on the selected branch. Click to import the file using
a different branch than where the asset was originally created. Choose the
branches from the list.
Import by creating a new branch: If you plan to create a branch from the latest,
you will choose to create a new branch. By creating a new branch, you are breaking
the development streams and adding a new instance of the asset to develop
independently of the other branches and a new stream.
Tip: You must have configured in your Eclipse preferences (Asset Management Source
Control Management ClearCase) the network view shared folder to connect
downloaded assets to Rational ClearCase.
702
703
extension
application/java
class
application/java-archive
jar
application/msword
doc
application/vnd.ms-excel
xls
application/vnd.ms-powerpoint
pps
application/vnd.ms-powerpoint
ppt
audio/mpeg
mp3
image/png
png
704
Figure A-69 Folder structure to customize Rational Asset Manager home layout
6. Modify the cascading style sheets, and modify or replace images as desired. You can use
the tools if you prefer to make these changes.
7. Create a new archive containing the updated files. You can give the archive any name, but
the archive must have the same folder structure as the original (that is, the folder named
theme must be the root folder). The following files must be in the theme archive, even if no
changes were made to the files:
header.jspf: Contains the logo image and the Help and Extensions links
homeContent.jspf: The content area of the home page
homeBanner.jspf: The banner area of the home page, including the sign-on form
requestAccess.jspf: Appears beneath the sign-on form on the sign-on page. In the
default theme, there is nothing in this fragment, but you might want to add a link, such
as Forgot password or Register, which is common for Web applications.
requestAccessForm.jspf: Appears beneath the sign-on form on the home page. In
the default theme, there is nothing in this fragment, but you might want to add a link,
such as Forgot password or Register, which is common for Web applications.
advanced.css: Advanced cascading style sheet (CSS) for sizing and positioning
basic.css: Basic CSS for images, backgrounds, and font styles
hideRightColumn.css: CSS that is included on pages that do not have a right column
pageLayout.css: CSS for the general page layout
8. In the Manage Themes section of the Tools page, click Browse.
9. Navigate to your new archive.
10.Click Upload.
The new theme is applied immediately. You do not need to restart the Web application. If you
do not see the changes immediately, click the browsers refresh or reload button. View
several pages of the Web application to verify that the theme was applied as expected. If you
see unexpected results, try uploading the theme again.
Keep a copy of your theme archive. If the Web application is redeployed, the default theme
will be applied and you will need to upload the custom theme. If you need to restore the
original theme, click the Restore the default theme link.
705
searches and filters (that reflect the assets related to each of the components in the
diagrams):
1. Export the current theme from the Administration Configuration page. (See A.4.5, How to
customize the home layout on page 704 to know how to export the current theme).
2. Modify the homeContent.jspf using an HTML editor or notepad.
3. Insert an image map or table that represents the architecture or deployment topology.
Insert it right after the </style> tag and before the <div id="launch_points">.
4. Add the company logo to the home page. Put the image in the following directory.
C:\Program
Files\IBM\RAM\ram\ewas\profiles\profile1\installedApps\vmuseridxxxeNode01Cell\R
AM1WebApplication.ear\com.ibm.ram.repository.web.war
5. Update the currentTheme.zip with the changed homeContent.jspf file.
6. Re-import the currentTheme.zip from the Administration Configuration page.
Next, Example A-1 shows how to modify the homeContent.jspf file to include a table that
represents the Business Administration and New Business Development ZYX Electronics
competencies. The table has been modified to include a graphical navigation to the assets of
the Business Planning and Sector Planning business areas.
Example: A-1 Example HTML content to create a search navigation model
</style>
<table width="15%" cellspacing="1" cellpadding="1" border="1" align="center">
<caption><font size="4"><strong>ZYX Component Business Model<img
width="100" height="30" alt="" src="ZYXLogo.gif" /></strong></font></caption>
<tbody>
<tr>
<td style="background-color: rgb(153, 204, 255);">
<table width="15%" cellspacing="1" cellpadding="1" border="0"
align="center">
<caption><strong><font size="3">Business
Administration</font></strong></caption>
<tbody>
<tr style="background-color: rgb(204, 255, 204);">
<td><a href="
http://localhost:9083/com.ibm.ram.repository.web/search/_rlvid.jsp.faces?_rap=p
c_Search.search&_rvip=/search/index.jsp&a=business_administration%2Caccount_adm
inistration&n=Classification%2Cbusiness_domain&s=_name_&sart=false&sshdw=false&
forum=false" >Account Administration</a></td>
</tr>
<tr style="background-color: rgb(204, 255, 204);">
<td>Business Planning</td>
</tr>
<tr style="background-color: rgb(204, 255, 204);">
<td>Business Unit Tracking </td>
</tr>
<tr style="background-color: rgb(204, 255, 204);">
<td>Staff Appraisals</td>
</tr>
<tr style="background-color: rgb(204, 255, 204);">
<td>Product Administration</td>
</tr>
<tr style="background-color: rgb(204, 255, 204);">
706
<td>Purchasing</td>
</tr>
<tr style="background-color: rgb(204, 255, 204);">
<td>Branch/Store Operations</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
<tbody>
<tr>
<td style="background-color: rgb(153, 204, 255);">
<table width="15%" cellspacing="1" cellpadding="1" border="0"
align="center">
<caption><strong><font size="3">New Business
Development</font></strong></caption>
<tbody>
<tr style="background-color: rgb(204, 255, 204);">
<td><a href="
http://localhost:9083/com.ibm.ram.repository.web/search/_rlvid.jsp.faces?_rap=p
c_Search.search&_rvip=/search/index.jsp&a=new_business_development%2Csector_pla
nning&n=Classification%2Cbusiness_domain&s=_name_&sart=false&sshdw=false&forum=
false" >Sector Planning </a></td>
</tr>
<tr style="background-color: rgb(204, 255, 204);">
<td>Sector Management</td>
</tr>
<tr style="background-color: rgb(204, 255, 204);">
<td>Product Management</td>
</tr>
<tr style="background-color: rgb(204, 255, 204);">
<td>Product Directory</td>
</tr>
<tr style="background-color: rgb(204, 255, 204);">
<td>Marketing Campaigns</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
<div id="launch_points">
707
To check that the Rational Asset Manager (RAM) service is running, use the following
command:
pushd <install dir>\ram\ewas\bin call serverStatus.bat server1 -username admin
-password admin popd
708
Integrating with WebSphere Service Registry and Repository: The first time
synchronization with WebSphere Service Registry and Repository occurs (either
according to schedule or manually invoked), it is likely that many assets will be brought
into Rational Asset Manager, which can impact bandwidth consumption.
Next, we provide recommendations to improve Rational Asset Managers performance while
under large concurrent user loads:
Improvements to WebSphere Application Server:
Increase Maximum JVM Memory: WebSphere Application Server sets the maximum
Java virtual machine (JVM) memory size to 256 MB by default. You must set the
minimum JVM memory size to 1024 MB and the maximum JVM memory size to 1300
MB.
Disable Performance Monitoring Infrastructure (PMI): WebSphere Application
Server enables PMI by default. While running Rational Asset Manager, you must
disable PMI for better performance.
Raise Thread Pools: By default, WebSphere Application Server has low threadpool
counts for the Default and WebContainer. These can be found in the WebSphere
Application Server Administrative Console under Application servers
SERVERNAME Thread Pools. You must raise the Default and WebContainer,
Minimum size and Maximum size to 50.
Raise Max Connection Pools: WebSphere Application Server sets the Maximum
number of Connection Pools to a very low number. This can be found in the
WebSphere Application Server Administrative Console under JDBC providers DB2
Universal JDBC Driver Provider Data sources RAM DB2 Datasource
Connection pools. You must set Maximum connections to 1000.
Improvements to DB2 Database:
You must make a number of database adjustments to improve database
responsiveness and stability. Each of these settings can be found by opening the DB2
Control Center, right-clicking on the Rational Asset Manager database (RAMDB) and
choosing Configure Parameters. To change a value, click inside of the value box, and
click the ellipsis (...). For all values in the table, open them and check Set
Automatically By DB2 if available; which causes the values to shrink or grow as
needed based on the user load. Additionally, here is a list of the suggested values for a
heavy user load:
MAXAPPLS: AUTOMATIC(1134)
MAXLOCKS: AUTOMATIC(91)
APP_CTLHEAP_SZ: AUTOMATIC(256)
DATABASE_MEMORY: AUTOMATIC(247520)
DFT_PREFETCH_SZ: AUTOMATIC(32)
LOGFILSIZ: AUTOMATIC(250000)
LOCKLIST: AUTOMATIC(90000)
NUM_IOCLEANERS: AUTOMATIC(7)
NUM_IOSERVERS: AUTOMATIC(3)
SHEAPTHRES_SHR: AUTOMATIC(8457)
SORTHEAP: AUTOMATIC(763)
709
Also, the following global database settings will help your setup. These settings can be
changed by going to All Systems SYSTEMNAME Instances DB2. Right-click
DB2 and click Configure Parameters. You must set the following settings:
MAXAGENTS: 134
MAXCAGENTS: 134
MAX_CONNECTIONS: 134
MAX_COORDAGENTS: 134
MaxKeepAliveRequests: 0
ThreadLimit: 4096
ThreadsPerChild: 3072
710
For detailed information about how to install and use this plug-in and to download a copy, go
to the following developerWorks Web site:
http://www.ibm.com/developerworks/rational/library/07/0814_larsen/
711
712
Appendix B.
Integrating Asset-Based
Development into a process
In this appendix, we look at how we can leverage the capability patterns provided by the
Asset Governance and Asset-Based Development plug-ins. We discuss how the Rational
Unified Process (RUP) and Rational Method Composer (RMC) support the integration of this
guidance. Note that if you leverage a non-RUP-based process, you can still leverage the
Asset-Based Development plug-ins and associated guidance. Many of the concepts and
ideas presented in this appendix prove useful in integrating the Asset guidance into other
processes.
713
B.1 Introduction
A capability pattern is defined as:
...describes a reusable cluster of Activities in common process areas that produces a result
of observable value. (RUP)
The Asset-Based Development capability patterns and associated content are generally
inserted into the current enterprise processes. If the enterprise is using RUP, the
Asset-Based Development processes can be inserted in any phase, in any discipline, or
within any iteration, an example of which is illustrated in Figure B-1. Note that this is just one
possible example out of many possible and equally valid variations.
The Asset-Based Development workflows can be inserted into other software development
processes, such as the one shown in Figure B-2 on page 715. In this example, the
Asset-Based Development workflows are inserted into each of the process phases. In certain
cases, the business-related assets are only used on the software project and are not
produced on the project, whereas each of the software-related phases produce and consume
assets on the project. This example does not address a situation in which there are one or
more central or cross-project asset manufacturing teams.
714
715
It is crucial for the success of the project that the delivery process is relevant for the current
project, its size, and the formality of its requirements.
Because the Rational Unified Process provides guidance about a wide range of software
engineering principles, you typically need to understand which parts of the process
framework can be fully adopted and which parts can be modified or even excluded. Tailoring
the process is just one part of implementing a process for a project. After the process has
been tailored, the project manager instantiates and executes it for the specific project. An
instantiated process is an unactable project plan (it includes actual iterations, activities, tasks,
and work products for an actual project). Instantiation is done as part of project planning.
We recommend tailoring the Rational Unified Process using Rational Method Composer. By
using Method Composer, the resulting process Web site has the exact same functionality,
look, and feel as the classic Rational Unified Process Web site. Also, if Method Composer is
used, a Delivery Process can be instantiated by exporting it from Method Composer and then
importing it into a project management tool, such as Rational Portfolio Manager, where
actual work products can be identified, actual resources can be assigned to roles, and so
forth. Before starting a plug-in project, we highly recommend that you spend time looking at
existing plug-ins on both the Method Composer and IBM-sponsored Rational Unified Process
Web sites, because you might find new, already available methods and processes that fit
your project:
To learn more about Rational Method Composer, go to:
http://www.ibm.com/developerworks/rational/downloads/06/rmc_plugin7_1/
To learn more about Rational Unified Process, go to:
http://www-128.ibm.com/developerworks/rational/library/4686.html
716
717
[1]
[2]
[4]
[3]
718
Process Element
A Method Element can be seen from two important perspectives: From the perspective of the
Method Designer, who defines the method structure and hence identifies Method Elements
and their relationships, or from the perspective of the Method Author, who writes the
description (that is, textual and graphical content) of the Method Elements. This second
perspective is particularly significant, because a large proportion of the method development
effort is spent authoring Method Elements. For this reason, a separate work product called
Method Element Description is used to refer to the content of a Method Element (even
though the Method Element Description work product is included into the Method Element
work product).
The other essential work products specific to method development are summarized in
Table B-2 on page 720 (together with the role responsible for each work product) and further
presented in the paragraphs that follow.
719
Role
Method sketch
Outline of the method, identifying candidate method elements, and
possibly including their relationships and early description
Method definition
Well-formed definition of a method in terms of its Method Elements
(including their descriptions), their relationships, and characterization of
one or more Method Configurations.
In RMC, a Method Definition is a composite work product
encompassing all Method Plug-ins and Method Configurations relevant to
the method under construction.
Method plug-in
Well-formed definition of a component of a method (or of the entire method
if the method is defined using only one component) in terms of its Method
Elements (including their description) and their relationships
In RMC, a Method Plug-in is a container for Method Packages:
Method Package
In RMC, a Method Package is a container for Method Elements (and
other Method Packages).
Method Element
Content Element (Role, Task, Work Product, or Content Guidance) or
Process Element (Activity, Capability Pattern, Delivery Process, or
Process Guidance). Refer to Table B-1 for definitions.
Method designer
Oversees the definition
of the overall method
Synonyms:
Method Architect,
Method Engineer, or
Process Engineer
Method configuration
Characterization of a method configuration or version of the method.
In RMC, a Method Configuration defines how to compose a Method
Web site based on the Method Elements included in a selection of Method
Plug-ins and Method Packages, as well as the views that will be presented
in the Method Web site tree browser.
Method Web site
Main outcome of a method development project. It makes the method, or
method framework, available through a set of interconnected Web pages.
In RMC, a Method Web site is automatically generated from a Method
Definition (one Method Web site can be generated per Method
Configuration).
Method element description
Description (that is, textual and graphical content) of a Content Element
Method author
Writes the content of a
method element
Early in the project, we recommend that you outline the method using a Method Sketch. The
goal of the Method Sketch is to help the team identify candidate Method Elements and their
relationships and to propose an early description for many of the key elements. To do so, and
depending on the project type (creation of a new method from scratch, extension of an
existing method with content elements only, extension of an existing method with content and
process elements, and so forth), the Method Sketch might take various forms. For instance, it
might include one or more of the following elements: A walkthrough of the life cycle; a brief
description of candidate roles, tasks, and work products, and their relationships; a list of
candidate method guidance (templates, examples, white papers, and so forth); an early Work
Breakdown Structure (WBS); or a mock-up of the method Web site.
The Method Sketch can be documented on a white board, in a word document, a
spreadsheet, a visual model, or using any other support. This framework is meant to
encourage creative thinking and allow the team to define and review several first sketches of
720
the method using the content, format, notation, and support that best fit their needs and skills.
After the new method, or part of the method, starts to emerge from the Method Sketch, it is
time to launch Rational Method Composer (RMC), where the method is more formally and
completely defined. The Method Sketch can be abandoned at this point, kept to explore other
ideas, evolve into a method roadmap (process guidance), or simply evolve into the list of all of
the method elements to be authored, for instance. In that case, it can be used to assign
responsibility and track progress.
The method is then well defined within a Method Definition. A Method Definition is a well
formed definition of a method in terms of its Method Elements (including their description) and
their relationships. A Method Definition also characterizes one or more configurations, or
versions, of the method by identifying, for each configuration, which elements are presented
to the practitioners and how. In RMC, a Method Definition is a composite work product
encompassing all Method Plug-ins and Method Configurations relevant to the method under
construction. In other words, a Method Definition corresponds to the subset of the RMC
Library relevant to the method under construction.
A Method Configuration is a characterization of a version of the method, such as RUP for
Small Projects and RUP for Large Projects. In RMC, a Method Configuration defines how to
compose a Method Web site based on the Method Elements included in a selection of
Method Plug-ins and Method Packages (because you might not want to publish all of the
Method Elements defined in the method in the context of a specific configuration). The
Method Configuration also defines the views that will be presented in the Method Web site
tree browser. As mentioned at the beginning of this appendix, the Asset-Based Development
plug-ins contain only capability patterns. They do not constitute a process unto themselves.
You integrate the content from these plug-ins into another process as part of a Method
Configuration.
The Method Web site is the key outcome of a method development project. It makes the
newly defined method, or method framework, available to the practitioners through a set of
interconnected Web pages. In RMC, a Method Web site is automatically generated from the
Method Definition (one Method Web site can be generated per Method Configuration).
To summarize the role of the constituents of a Method Definition, we can use the analogy of a
bookstore specialized in selling book sets at a discounted price. A Method Plug-in can be
compared to a bookstore department (travel, comics, children, and so forth). A Method
Package can be compared to a set of books packaged to be sold together, the Method
Element to an individual book, the Method Configuration to your shopping list, and the
Method Web Site to the shopping bag full of books that you take home after shopping.
In the case of a new method built from scratch, the Method Definition is empty at the
beginning of the project. In the case of a method customization, the Method Definition already
contains the plug-ins relevant to the existing method (not the existing configurations,
however, because a configuration is specific to a particular method and consequently is not a
reusable asset).
Then, you add at least one new Method Plug-in (referencing the existing plug-ins) in order to
define the Method Elements specific to your new method and add one new Method
Configuration in order to configure your new Method Web site. Your new Method Elements
can be built from scratch or by leveraging elements of the existing method using variability
relationships, such as contribute, extend, or replace. For more information about variability
relationships, refer to the IBM training: PRJ350, Essentials of IBM Rational Method
Composer v7.1.
721
Figure B-5 Essential tasks, the roles that perform the tasks, and the input and output work products
Table B-3 on page 723 provides the description of the Sketch Method task. The task is
independent from the actual strategy adopted by the project team to define the method, such
as top-down (the definition of the overall life cycle in terms of phases and their objectives
drives the identification of the content elements) or bottom-up (the identification of the content
elements drives the definition of the life cycle). In practice, project teams generally use a
combination of the two strategies. However, whenever applicable, we recommend favoring a
top-down strategy, which tends to produce more cohesive methods, because each content
element is more clearly tied to one or more phase objectives.
722
723
It is not only the project managers job to decide which activities and tasks to perform in each
iteration of the RUP Phases; it is the teams decision. The project manager takes into account
the directions provided by the teams members and subsequently plans, tracks, and manages
the risks accordingly.
After the team decides what iterations, activities, and tasks need to be performed (by using a
Development Case, for instance, or any other artifact), the project manager creates the plan
accordingly. The last step after determining the activities and tasks is to include key input or
output work products. The work products affect your plan in terms of milestones and the
evidence of deliverables.
724
Appendix C.
Additional material
This book refers to additional material that can be downloaded from the Internet as described
next.
725
ABD-Part 4-Projects.zip
This file contains zips of projects created in Part 4. Each included ZIP file contains one or
more projects, which can be imported into one of IBM Rational Software Architect 7.0, IBM
Rational Software Modeler 7.0, IBM Rational Systems Developer 7.0, or IBM Rational
Application Developer 7.0.
ZYX-Artifacts.zip
This file contains a set of PDF documents related to the ZYX Electronics case study, which
includes:
ZYX Reuse Assessment
ZYX Reuse Strategy
ZYX Community Map
To read the documents, you will need a PDF viewer.
726
Glossary
Artifact
assets
727
728
Related publications
The publications listed in this section are considered particularly suitable for a more detailed
discussion of the topics covered in this book.
Other publications
These publications are also relevant as further information sources:
Jeffrey S. Poulin, Measuring Software Reuse, Addison-Wesley Professional, 1996,
0-201-63413-9
Wayne C. Lim, Managing Software Reuse, Prentice Hall PTR, 2004, 0-13-552373-7
Ivar Jacobson, M. Griss, and P. Jonsson, Software Reuse: Architecture, Process and
Organization for Business Success, Addison-Wesley Professional, 1997, 0-201-92476-5
Scott W. Ambler, John Nalbone, and Michael J. Vizdos, The Enterprise Unified Process:
Extending the Rational Unified Process, Prentice Hall PTR, 2005, 0-131-91451-0
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements
of Reusable Object-Oriented Software, Addison-Wesley, 1994, 0-201-63361-2
Online resources
These Web sites are also relevant as further information sources:
IBM DeveloperWorks: In general, you can find many useful and helpful articles at:
http://www.ibm.com/developerworks/
In particular, consult the following:
IBM Rational Asset Manager Configurator, Grant Larsen
http://www.ibm.com/developerworks/rational/library/07/0814_larsen/
Rational Asset Manager Made Practical: Part 1: Determine Your Audience, Grant Larsen
http://www.ibm.com/developerworks/rational/library/sep07/larsen/
IBM Rational Asset Manager made practical, Part 2: Establish the governance, Grant
Larsen
729
http://www.ibm.com/developerworks/rational/library/oct07/larsen/
Building SOA applications with reusable assets, Part 1: Reusable assets, recipes, and
patterns Grant Larsen and Eoin Lane
http://www.ibm.com/developerworks/webservices/library/ws-soa-reuse1/
Asset lifecycle management for service-oriented architectures, Grant Larsen and Jack
Wilber
http://www.ibm.com/developerworks/rational/library/oct05/wilber/
Introducing IBM Rational Asset Manager, Carlos Ferreira
http://www.ibm.com/developerworks/rational/library/jul07/ferreira/
Explore the role of service repositories and registries in Service-Oriented Architecture
(SOA), Boris Lublinsky
http://www.ibm.com/developerworks/library/ar-servrepos/
Best practices for lean development governance: Part 1: Principles and organization,
Per Kroll and Scott Ambler
http://www.ibm.com/developerworks/rational/library/jun07/kroll/
Best practices for lean development governance: Part II: Processes and measures, Per
Kroll and Scott Ambler
http://www.ibm.com/developerworks/rational/library/jul07/kroll_ambler/
Best practices for lean development governance: Part III: Roles and policies, Per Kroll
and Scott Ambler
http://www.ibm.com/developerworks/rational/library/aug07/ambler_kroll/
Capacity Planning and Configuration guide, Bryan Miller
http://www.ibm.com/developerworks/rational/downloads/07/ram_plan_config_guide/i
ndex.html?S_TACT=105AGX15&S_CMP=LP
Rational Edge
http://www.ibm.com/developerworks/rational/rationaledge/
IBM Systems Journal
http://www.research.ibm.com/journal/sj/
Model-driven development: assets and reuse, IBM Systems Journal, July-Sept, 2006, by
Grant Larsen
Related publications
731
732
Index
A
accept asset review 272
account
activation 26
application 26
sales 26
activities within the Definition capability pattern 73
activity 51
activity audit report 330
adapt process ceremony to lifecycle phase 54
adapt the process 53
adapt your plans using an iterative process 55
add attribute constraints to the asset type 228
add new artifact constraints to the asset type 227
add new relationship constraints to the asset type 228
add user-group-based reviewers 234
ad-hoc organization template 133
administrator role and associated deliverable 69
administrator role and associated task and deliverable in
support of the Access Control Definition activity 76
administrator role and deliverables in support of the environment activity 80
adminstrator approval for assets submited As-Is 235
align applications with business and user needs 54
Ant Framework Rational ClearQuest request details 321
anti-patterns 53
aproduce reusable assets
review and test asset 248
architect a system only to meet the needs 54
architect for resilience 56
architecture-driven 59
artifacts within reusable assets 9
build artifacts 10
components 9
deployment descriptors 10
design documents 9
domain specific languages 10
frameworks 9
model templates 10
models 910
patterns 9
requirements documents 9
test artifacts 10
test plans 10
test scripts 10
UML profiles 10
web services 9
assess status in the first two thirds 55
asset as a collection of artifacts 8
asset classified from multiple classification schemas 208
asset consumer and key deliverables 95
asset consumer role and associated deliverables 89, 97
asset Consumer role and deliverables 93
asset Governance Board and associated tasks and deliv-
733
734
scope 142
self-governed 133
services as assets roll-out 185
software process 149
training model 192
versioning and configuration management 153
vision 162
ZYXs asset governance 137
Asset-Based Development and Asset Governance Rational Method Composer plug-ins 61
adoption guidance 62
asset governance 66
asset governance plug-in 66
asset process views 98
consume reusable asset 95
activities and tasks 97
key deliverables 98
roles, tasks, and deliverables 97
creating extensions 99
definition 73
activities and tasks 73
access control definition 74
types and rules definition 73
workflow definition 74
key deliverables 76
roles, tasks, and deliverables 75
access control definition 76
types and rules definition 75
workflow definition 75
enablement 78
activities and tasks 78
environment 79
organization 78
key deliverables 81
roles, tasks, and deliverables 79
environment 80
organization 79
governance 64
introduction 62
manage reusable assets 91
activities and tasks 92
administration and monitoring 93
review and approval 92
key deliverables 95
administration and monitoring 95
review and approval 95
roles, tasks, and deliverables 93
administration and monitoring 94
review and approval 93
manufacturing and usage cycle 84
measurement 81
key deliverables 83
roles and deliverables 82
determine metrics to track 83
report on asset 83
tasks 82
determine metrics to track 82
report on asset 82
planning 67
activities and tasks 67
funding 68
preparation 67
key deliverables 70
roles, tasks and deliverables 69
funding 70
preparation 69
produce reusable asset 87
activities and tasks 88
key artifacts 90
asset specification 90
reusable asset 91
roles, tasks, and deliverables 89
when to use these processes 98
Asset-Based Development defined 8
Asset-based Development Motivations 158
Asset-based Development Tooling Infrastructure 173
Asset-Based Development tools 33
asset repositories 39
Rational Asset Manager 39
WebSphere Service Registry and Repository 39
Eclipse 35
Java development environment 35
open source community 35
tool integration platform 35
IBM tools 33
Rational Application Developer 36
Rational ClearCase 37
Rational ClearQuest 38
Rational Modeling Platform 35
Rational RequisitePro 37
Rational Software Architect 35
Rational Software Modeler 36
Rational Systems Developer 36
WebSphere Business Modeler 36
WebSphere Integration Developer 36
WebSphere Studio Asset Analyzer 38
Asset-Based Development within SOMA 338
assets and their artifacts 159
assets belonging to the Implementation community 294
assets pending to review 271
attack major technical, business and programmatic risks
early 55
B
balance asset reuse with user needs 54
balance competing stakeholder priorities
anti-patterns 54
benefits 54
balance plans and estimates with level of uncertainty 54
barriers to innovation 34
benefits derived from applying the principle 53
bringing together adoption, pilot, governance and development 139
business
improvement 31
business driven development 4
Business Service Example 347
C
calculating cost of the asset implementation 119
calculating project risk 119
capability pattern 51
capability pattern for Consume Reusable Asset 97
capability pattern for enablement 78
capability pattern for Manage Reuseable Assets 92
capability pattern for measurement 82
capability pattern for planning 67
capability pattern for Produce Reusable Asset 88
CEO survey results 5
change spring.jar artifact version 276
change state of Rational ClearQuest review process request to Legal 322
characteristics of organization templates 132
CICS 22
collaborate across teams 54
anti-patterns 55
pattern 55
collaboration 54
Community Administrator role and associated deliverables 90, 94
community roles, user groups, users and permissions
199
comparing Rational Asset Manager to WebSphere Service Registry and Repository 42
complete all unit testing before doing integration testing
56
complete all unit testing before integration testing 56
component business model heatmap for ZYX Electronics
143
components using the Spring Framework 300
composition of business services 348
conduct in-depth peer-review of all intermediate artifacts
56
conduct recurring problem analysis 240
configure asset repository 195
administration roles 209
community administrators 210
integration administrators 210
repository administrator 209
asset types specification 205
asset attributes 208
asset types 206
artifacts 206
attributes 206
categories 206
relationships 206
category schemas 207
relationship types 208
asset workflow specification 203
best practices to customize your repository 211
asset type specification 211
asset workflow specification 211
Community Map 211
general 213
Community Map 197
criteria for creating a community 202
creating asset types, category schemas, relationship
types, and attributes 218
Index
735
736
619
source code management of user and shared files
619
overriding templates 627
creating the copyright template 628
modify main.jet 628
override templates to include copyright notices
628
running transformations with integration builds 623
saving JET launch configurations in the workspace
615
supporting parallel development on input models 616
merging UML input models 617
merging XML input models 616
reconciling generated transformation output 617
dead code 618
orphaned file 618
renamed code 618
renamed file 618
types of pattern usage 614
generated non-modifiable artifacts 614
generated shared artifacts 614
generated user-owned artifacts 614
input model management 614
transformation configurations 614
using the jet.transform Ant task with headless builds
623
consuming service assets 399
case study
SOA service reuse at ZYX Electronics 415
consuming service metadata from WSRR for CBS assembly 403
customizing composite business services 410
locating services for consumption 400
locating services in WebSphere Business Services
Fabric 402
locating services in WebSphere Service Registry and
Repository 400
locating services at development time 400
eclipse plugin 401
programmatic query 401
query wizard 401
quick search 400
view query definitions 401
locating services at runtime 401
points of variability of service based assets 406
black box reuse 406
business level service metadata 407
business process 408
baseline SCA implementation 408
business rules 410
dynamic assembler 410
mediation modules 409
mediation with service registry 409
selectors 408
gray box reuse 406
messaging protocol 407
service endpoints 407
service implementation 407
white box reuse 406
D
default community roles 200
default Rational Asset Manager review process 204
define, understand, and prioritize business and user
needs 54
delete assets 326
delivery
process 51
demonstrate value iteratively 55
anti-patterns 55
benefits 55
pattern 55
Develop Asset Specification 290
develop asset specification 242
developerWorks 59
development
iterative 56
difference between without RAS and with 244
document precise requirements at the outset of the
project, force stakeholder acceptance of requirements 54
lock down requirements up-front 54
negotiate any changes to the requirements 54
primarily perform custom development 54
download Spring open source framework 297
Driven 4
duplicate asset content 278
duplicate asset templates process 279
E
earlier insight into progress and quality 56
early risk reduction 55
e-business 21
Eclipse 35
Process Framework 50, 60, 717
elaboration 58
elevate level of abstraction
anti-patterns 56
pattern 56
embrace and manage change 55
enable feedback by delivering incremental user value in
each iteration 55
encourage cross-functional collaboration 55
end-to-end
methodology 23
ensure team ownership of quality for the product 56
enterprise full organization template 136
enterprise partial organization template 135
EPF 717
estsblish a relationship between component and framework assets 300
example of visualization for category schema 311
F
filter your search 294
focus areas within Asset Governance 67
focus continuously on quality
anti-patterns 56
pattern 56
focus on architecture first 56
framework reusable method content and process building
blocks
RUP 52
functional
testing 382
G
Generations of Basic Technology Advancements 148
geographic area 222
goals of IT Governance 65
governed organization template 134
guidance 51
H
have highly specialized people equipped with powerful
tools 55
heart of RUP 52
high level view of asset lifecycle 12
high level view of tools and roles 351
higher predictability throughout the project 55
higher quality 56
high-level ABD process steps 165
Index
737
I
IBM asset repository strategy 44
Configuration Management Database (CMDB) 44
Rational Asset Manager 44
Rational ClearCase 44
WebSphere Metadata Server 44
WebSphere Service Registry and Repository 44
IBM platform for Composite Business Services 354
IBM Rational Unified Process 49
introduction 49
identify phase iterations, activities, and tasks to execute
724
impact and ROI 103
improve the process continuously 54
inception 58
increased project agility 53
incrementally build test automation 56
integrate business, software, and operation teams 55
integrating asset guidance into a process based on the
Rational Unified Process 63
integrating Asset-Based Development into a process 713
create a project plan specific to your project 723
creating project plan 724
customize the Rational Unified Process using Rational
Method Composer 718
identify the phase iterations, activities, and tasks to execute 724
method development tasks 722
method development work products 719
Rational Method Composer 717
Rational Unified Process 715
integrating with a non-RUP based process 63
integration between usage and manufacturing cycles
238, 283, 305
interaction between manufacturing and usage cycle 85
introduce new forum topic 298
introduction to patterns 457
case study 1
A large banking application 466
large banking application
lessons learned 467
results 466
case study 2
an IBM product development team 467
IBM product development team
lessons learned 467
results 467
critical success factors 468
customize development process 465
develop candidate architectur 464
developing a pattern 460
establish project constraints 463
budget 463
function 463
quality 463
identify respresentative use cases 464
improving productivity in software development 458
next steps 468
pattern based engineering 461
model driven development 461
738
metamodels 461
models 461
standards 461
transformations 461
pattern harvesting 466
patterns 459
process for pattern-based engineering 462
reality check
does pattern-based engineering really work? 466
roles in developing pattern implementations 460
asset librarian 460
pattern author 460
pattern implementation author 460
pattern specification author 460
pattern user 460
iRational Asset Manager - installation and administration
mport and export a repository model 702
iteration 57
iterative
development 5657
K
key concepts 56
architecture-driven 59
iterative development 57
phases 58
construction 58
definition 66
elaboration 58
enablement 66
inception 58
measurement 66
planning 66
transition 58
RUP summary chart 57
key concepts in RUP 51
L
level of abstraction 55
lifecycle efficiency 53
M
major functions and components of WebSphere Studio
Asset Analyzer 356
manage evolving artifacts 55
manage reusable assets 303
asset cleansing, defining and mapping 315
asset cleansing, defining, and mapping
considerations 315
deliverables 316
prerequisites 315
templates 316
asset management 305
asset management roles 306
asset review board 306
asset reviewer 306
community administrator 306
integration administrator 307
Index
739
N
no special conditions for the review process 233
nurture heroic developers 55
O
OMG 50, 717
optimize business value 54
organization chart for the CIO 142
organization chart for the IT organization 214
organizational
structure 31
overview of the structure of the book 15
overview of ZYX Electronics 18
P
packaging assets 11
pattern of behavior that best embodies the principle 53
peer-review all artifacts 56
plan the whole lifecycle in detail 55
principles
RUP 53
prioritize projects and requirements and couple needs
with software capabilities 54
process 51
process and methodology support 45
Rational Method Composer 45
Rational Portfolio Manager 46
Rational Project Console 46
Process Framework 50
process framework
Rational Unified Process 50
process levels 72
produce - model to model 529
build a model-to-model mapping transformation 545
build a template model 580
build a UML pattern 571
build a UML profile 536
build an EMF model 532
case study 530
comments on the patterns seen in this chapter 584
complete the parameter implementations 574
add access to the UML Modeler and diagram utilities 574
handle base package parameter changes 576
handle beans parameter changes 577
handle changes to the Name parameter 575
handle source folder parameter changes 576
control the EMF code generation 535
create a profile project 536
create a UML template model 581
create an EMF project 534
create mappings 547
740
Index
741
introduction 237
publish or deploy asset 251, 279
recurring problem analysis 253
Open Source C++ Components 255
Open Source COBOL Components 255
Open Source Java Components 253
Ant 254
Aurora 255
DWR 253
Eclipse 254
Hibernate 254
JEdit 254
JFreeChart 254
JUnit 254
Maven 254
MGui 255
MyFaces 255
Net-Beans 254
Open Scene Graph 255
OpenCOBOL 255
OSCache 254
SmartWin++ 255
Spring 255
Struts 254
review and test asset 270
update asset 249, 272
identify or discover a problem with an asset 250
plan asset update activity 251
search for the asset 251
update the asset 251
ZYX Electronics
produce reusable assets 252
producing service assets 359
assembling a composite business service 375
implementing the services and the user interface
377
WebSphere Business Services Fabric 378
case study
SOA service reuse at ZYX Electronics 392
creating a composite business service asset 373
creating service assets 360
current state of service reuse at ZYX Electronics 392
deploying a composite business service 380
governance options for publishing services 386
IBM products for SOA testing 382
modeling a composite business service 374
publishing assets to Rational Asset Manager 387
extending the sample SOA model for Rational Asset Manager 390
publishing service assets to the repository 383
Rational Asset Manager configuration for ZYX Electronic 393
repositories in the life of a service asset 383
service identification 362
domain decomposition 362
existing asset analysis 363
goal-service modeling 363
searching for assets 363
tooling considerations 366
using WebSphere Studio Asset Analyzer for asset
742
identification 364
service realization 371
addressing reuse challenges with WebSphere
Studio Asset Analyzer 372
application pattern 372
intellectual control 372
intermingled business logic 372
run unit remediation 373
fine grained mapping of existing assets 371
integrate the function into the service 371
use an adapter more amenable to service invocation 371
wrap and replace existing function with a service 371
wrap existing function as a service 371
tooling considerations 373
service specification 366
tooling considerations 369
SOMA Insights for asset developmen 360
testing service assets in an SOA 380
at what level should services be tested? 381
testing for reusability 380
productivity 56
progression cross stages of Reuse Maturity 131
provide asset feedback 288
provide effective collaborative environments 55
Publish or Deploy Asset 252
publish or deploy asset 309
Q
quality 56
quality, understandability, complexity control. 56
R
ratings - leave feedback 301
Rational
software development process 49
Rational Asset Manager 39
Rational Asset Manager - installation and administration
637
administrator roles and tasks in Rational Asset
Manager 642
community administrators 642
integration administrator 643
repository administrator 642
add the MIME types for a WAS installation 703
API 710
create a graphical navigation search navigation model
705
customize the home layou 704
import and export data 702
installing Rational Asset Manager clients (Web and
Eclipse 655
Eclipse client installation 655
Web client installation 655
installing Rational Asset Manager Server 648
integrating Rational Asset Manager with Rational
ClearCase 688
Index
743
S
sample asset ROI calculator 121
sample process for a pilot 126
SAP 22
Search Asset 307
search asset 284
search for assets using advanced search fields 292
search for assets using keywords 292
search for assets using tags 293
search for Spring assets to establish a relationship 299
search history report 329
search results list for the Spring open source framework
296
744
T
task 51
task within the Organization activity 79
tasks within the Access Control Definition activity 75
tasks within the Administration and Monitoring activity 93
tasks within the environment activity 79
tasks within the funding activity 69
tasks within the preparation activity 68
tasks within the Review and Approval activity 92
tasks within the types and rules definition activity 74
tasks within the Workflow Definition activity 74
team productivity 54
test early and continuously in step with integration of demonstrable capabilities 56
tools, tasks and roles 34
track variances against plan 55
transition 58
trust among stakeholders 55
two-sided relationship types 209
U
UMA 717
understand what assets we can leverage 54
Unified Method Architecture 717
unit testing 382
tools 382
update asset 250
usage cycle 85
use asset 287
use case 59
use higher-level tools and languages 56
user activity report 329
user productivity cost calculation 119
V
value of using assets 6
value, impact and return on investment 103
asset reuse strategy 117
additional calculations 120
asset creation/acquisition approaches 117
asset type 117
calculations 118
cost of reuse failure 120
reuse scope 117
tooling and methodology 117
gathering data 111
impact and ROI 103
not all assets are equal 105
alignment with business 110
alignment with business directionrategy 110
cost of addressing underlying problem manually 110
domain 110
frequency of underlying recurring problem
110
fund creation 110
support/maintenance funding 110
asset consumption 106
asset usage 107
assets alignment with iterative development
109
complexity 108
consumers required skill level 108
cost to consume 108
customize output of asset 108
customize via points of variability 107
ease of asset consumption 107
ease of learning 108
ease of use 108
expected time to modify
euse asset 108
expected time to modify
euse output from asset? 108
expertise available to support asset 108
import 107
Index
745
W
WebSphere Business Modeler 36
WebSphere Integration Developer 36
WebSphere Service Registry and Repository 39
WebSphere Studio Asset Analyzer 38
work
746
product 51
workflow of management process 305
workflow of manufacturing process 239
workflow of use process 283
Z
ZTX as-is
Software Governance - Generations of Basic Technology Advancements 149
ZTX Electronics ABD Overview Diagram 169
ZYX asset governance deliverables 138
ZYX component business model heat map 24
ZYX Electronics 18
ZYX Electronics case study 17
approach 29
assumptions 31
benefits 30
business composition 23
CEO interview 20
challenges 25
CIO interview 22
information technology 26
organization 18
scope 28
scope and approach 28
the business 26
account activation issues 26
account application issues 26
account sales issues 26
account verification issues 26
ZYX Electronics CEOs organizational chart 18
ZYX Electronics CIOs organizational chart 19
ZYX Electronics Component Business Model Heatmap
151, 161
ZYX Electronics development case 99
content sources for the ZYX Electronics development
case 99
Rational Method Composer 100
Rational Unified Process 99
RUP for Asset-Based Development 99
RUP for Service-Oriented Modeling and Architecture
99
ZYX Electronics best practices 100
ZYX Electronics Organization Chart 170
(1.0 spine)
0.875<->1.498
460 <-> 788 pages
Back cover
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
IBM Redbooks are developed
by the IBM International
Technical Support
Organization. Experts from
IBM, Customers and Partners
from around the world create
timely technical information
based on realistic scenarios.
Specific recommendations
are provided to help you
implement IT solutions more
effectively in your
environment.
ISBN 0738485950