Designing Solutions Using The SOAD Model Accelerator-V1.3

Designing Solutions using the SERVICE-ORIENTED ANALYSIS AND DESIGN MODEL ACCELERATOR
Lee Ackerman Randy Lexvold Craig Rudman
SOA with Emphasys

version 1.3
Designing Solutions using the ServiceOriented Analysis and Design Model Accelerator
Lee Ackerman Randy Lexvold Craig Rudman
The Emphasys Group logo and Service-Oriented Analysis and Design Model Accelerator are trademarks of Enterprise Systems Consulting and Services Corp., d.b.a. The Emphasys Group.
IBM, the IBM logo and Rational are 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 TM ), 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 ibm.com/legal/copytrade.shtml
Disclaimer: The information contained in this documentation is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this documentation, it is provided as is without warranty of any kind, express or implied. In addition, this information is based on The Emphasys Groups current product plans and strategy, which are subject to change by The Emphasys Group without notice. The Emphasys Group shall not be responsible for any damages arising out of the use of, or otherwise related to, this documentation or any other documentation. Nothing contained in this documentation is intended to, nor shall have the effect of, creating any warranties or representations from The Emphasys Group (or its suppliers or licensors), or altering the terms and conditions of the applicable license agreement governing the use of The Emphasys Group software.
Copyright 2012 Enterprise Systems Consulting and Services Corp., d.b.a. The Emphasys Group
the
group
Copyright 2012 Enterprise Systems Consulting and Services Corp., d.b.a. The Emphasys Group. All rights reserved.
Page 2 of 261
Preface !
Getting Started! The Emphasys Group! Contact Information! About the Authors!
8
8 9 10 10
Part I. Introduction to the SOAD Model Accelerator!

Overview! Charting a Course! Business View! Governance! Methods: SOAD and Agile! SOAD! Scaling the Agile Effort! The Importance of Architecture! The Service-Oriented Analysis and Design Model Accelerator! Value Proposition!
12
13 14 16 17 18 20 28 31 33 35
Part II. SOA Modeling!

Introduction! Why Model SOA solutions?! Case Study Background! Service Oriented Architecture Modeling Language (SoaML)! SoaML Modeling Approaches! Exploring SoaML Modeling Approaches! Simple Request-Response Service Interaction!
the group
37
38 38 42 44 47 50 51
Page 3 of 261
Service Contract Based Approach! Service Interface Based Approach! Picking the Right Approach! Need REST?! Related Domain Specic Languages! Business Process Model and Notation (BPMN)! Business Modeling UML Prole!
55 66 68 69 73 73 76
Part III. Pattern Reference !

Introduction! Business Modeling! Business Entity Promotion! Business Goal Decomposition! Structured Business Driven Scenario! Use Case Realization Promotion! Service Identication! Capability Consolidation! Capability Promotion! Capability Usage! Service Catalog! Service Category! Service Specication! Collaborating Interface! Domain Prex! Service Litmus Test! Service Specication: Message Design!
the group
78
79 80 82 90 95 101 107 108 112 116 119 123 126 127 134 137 141
Page 4 of 261
Command Message! Document Message! Event Message! Multipart Message! Service Specication: Participant Design! Coordinating Participant! Participant Subsystem! Simple Request Participant! Simple Service Participant! Single Request Port Participant! Single Service Port Participant! Service Specication: Service Contract Design! Compound Service Contract! Simple Service Contract! Service Specication: Services Architecture Design! Participant Services Architecture! Simple Services Architecture!
143 144 147 149 153 155 158 164 167 170 173 176 177 181 183 183 188
Part IV. SOA Governance !

Overview! Reports! BPMN Complexity! Goal-Service Modeling! Pattern Instances! Service Litmus Test Summary! Service Litmus Test Details!
the group
191
192 194 195 197 200 202 203
Page 5 of 261
Model Constraints! Example: Business Goal KPIs! Example: Capability Responsibility Constraint! Example: Service Litmus Test Constraint! Cheat Sheets! Identifying Project Risk!
204 207 212 213 215 216
Part V. Installation, Conguration & Assistance!

Installation Requirements! Installing the SOAD Model Accelerator! Uninstalling the SOAD Model Accelerator! Accessing SOAD Model Accelerator Help!
218
219 219 224 227
Part VI. Rational Software Architect for WebSphere Tips!

Overview Rational Software Architect for WebSphere Software! Service Realization and Implementation! Service Realization! Service Implementation! Models, Diagrams and Views! Applying UML Patterns! Reapplying UML Patterns! Unapply UML Patterns! Working with Proles! Applying Stereotypes! Model Validation and Constraints! Model Validation and UML Patterns!
the
229
230 230 231 231 231 232 235 236 236 239 242 244
group
Page 6 of 261
Generating Reports! Model Transformations! Service Model Template! Rational SOMA Integration!
245 250 251 252
Part VII. Resources & References!

Resources! SOA and Agile! Frequently Asked Questions! Annotated SoaML Example!
255
256 257 257 258
the
group
Page 7 of 261
Preface
With this book, our products and our services we strive to help you build better software, more quickly. In these efforts, the goal is to help you to answer questions such as how can we: Better design our solutions? Better execute as a team? Prevent defects? Reduce risk? Improve communication? Make better decisions based on information rather than guesses or gut feel? Answering these questions leads to better software and in turn, better business results. This book provides a starting point for a discussion. At a minimum, we hope that the ideas that weve captured here, lead to thoughtful discussions within your organization. Ideally, the discussion goes beyond organizational boundaries and we can engage as a community. Weve put signicant effort into this release and are excited to make it available. In making these updates weve incorporated reader feedback, discussions (and a few arguments!) with peers, presentations and project experiences. We hope that you enjoy this new and improved release of this book (and the Model Accelerator!). If you are familiar with the previous version youll notice that weve almost doubled the size of the book. Part of this growth is due to the many new elements that weve added to the Model Accelerator. The other major growth factor is the additional material important for succeeding with SOA. This include many more examples of working with SoaML, a discussion regarding Agile SOA, and coverage of the OSIMM maturity model. The digital version of this book can be downloaded, for free, from our website: http://www.theemphasysgroup.com. If you nd value in this material, we do ask that you consider: 1. Sending us a note with feedback or suggestions. Wed love to hear from you. 2. Purchasing a license or contacting us about training, coaching or consulting. Development of this book is funded through sales of the SOAD Model Accelerator and our service offerings. 3. Making a donation to Room to Read. Education and reading are critical for a better world for all of us. Donations can be made via: http://www.roomtoread.org. And of course, help to spread the word. Please tell others about the book! Getting Started This book details the capabilities of the SOAD Model Accelerator including UML Patterns, Constraints, Reports and Cheat Sheets. In addition, we provide guidance on realizing an Agile SOA approach through the combined and customized application of The Open Group Service Integration Maturity Model (OSIMM), Service Oriented
the group
Page 8 of 261
Analysis and Design (Rational SOMA, SiSaS), Scaled Agile Framework, SOA Governance and of course the SOAD Model Accelerator. Through these efforts we create models to help us understand, dene, communicate and generate SOA-based software solutions. These models use languages including UML, BPMN, SoaML and the UML Prole for Business Modeling. These languages are all discussed in this book, with guidance provided on how to get more out of these modeling efforts. To get the most out of this book, we suggest that you read Parts I and II in order. After which, the remaining sections of the book are set up as a reference. The Emphasys Group At The Emphasys Group we help our customers build better software, more quickly. We bring years of outstanding experience and expertise to help customers acquire new skills, use tools more effectively and increase their Velocity through our unique and holistic application of Automation, Reuse and Agile best practices.
Building Velocity.
You can purchase the SOAD Model Accelerator via our website: http://www.theemphasysgroup.com/soad-model-accelerator/ We offer individual licenses, site licenses and also would be happy to discuss customization, extensions and training.
Beyond the SOAD Model Accelerator, we also offer Training and Workshops, Consulting and Coaching and additional products. Wed be thrilled to work with you to dene a program that meets the needs of your situation. Bringing together selections from our portfolio including: Software Development Best Practices including Scaled Agile Framework, Eclipse Process Framework, and Rational Unied Process, Collaborative Lifecycle Management with a focus on Rational Team Concert, Rational Requirements Composer, Rational Software Architect Design Manager, and Rational Asset Manager Software Design and Development with Rational Software Architect, Rational Application Developer and Eclipse JEE, Object-Oriented Analysis and Design,
the group
Page 9 of 261
Service-Oriented Analysis and Design, Model-Driven Development, Model-Driven Architecture, Patterns-Based Engineering and Reuse Requirements capture and assessment. Our thought leadership can be seen in our publications, participation in standards efforts (OSLC-Asset Management), products, creation of intellectual capital (training courses, articles, conference presentations and workshops), and patent lings.
Publications written by our team.
Contact Information Wed love to talk to you about your unique situation and how we can help! More information about The Emphasys Group can be found on our website: http:// www.theemphasysgroup.com. You can also contact us through: Email: info@emphasysgrp.com Phone: 1.888.784.7759 Twitter: @EmphasysGroup About the Authors Lee Ackerman, VP Products & CTO The Emphasys Group Lee has spent the last 17 years investigating and evaluating new ideas, designing and developing solutions and helping others to do the same. He has had signicant impact in the area of software reuse with a focus on Patterns-Based Engineering, AssetBased Development and Service-Oriented Architecture. Prior to joining The Emphasys Group, Lee spent 11 years with IBM and in recognition of his technical leadership was designated as an IBM Sr. Certied IT Specialist. During this time with IBM, Lee assisted IBM customers, business partners and IBM employees to improve how they delivered software. Lees books, articles and courses have been used to enable thousands in best practice based approaches to software delivery. Randy LexvoldPresident & CEO The Emphasys Group Randy has 22 years of experience in all aspects of software development, from realtime robotics navigation to on-line grocery web applications. Most recently Randy worked for 8 years at IBM Rational Software as a technical sales specialist, consultant and worldwide subject matter expert in Software Architecture. He has consulted with a
the group
Page 10 of 261
wide range of clients in many market sectors, including nancials, technology, and large government R&D laboratories. Prior to joining The Emphasys Group, Randy was the CTO at CenterPoint Care Solutions. Craig RudmanVP Services & CSO The Emphasys Group Craig is a rare blend of software engineer and organizational change management professional with over 20 years experience planning, implementing, and managing software engineering projects and business process improvement initiatives. His areas of technical expertise are software development lifecycle management, IT governance, processes and tools. He is a creative thinker with strong analytical, problem-solving, decision-making and follow-through capabilities. Craig has over 12 years experience working with the Unied Process and with agile methods. He has helped dozens of organizations raise levels of engagement and overall achievement through planning, technology implementation, process improvement, coaching, training, and communication.
the
group
Page 11 of 261
Part I. Introduction to the SOAD Model Accelerator
the
group
Page 12 of 261
Overview As discussed in numerous articles, books, and presentations, SOA provides a compelling solution. Business agility, exibility, time to market, customer satisfaction, reuse, and cost of ownership are all touted as benets of SOA. With such benets, how could we not like SOA? It would be like having issues with ice cream, rainbows or unicorns. However, its not as simple as just liking the benets. There are challenges along the way such as insufcient focus on architecture, limited skills, poor development practices and lack of governance. Failure to address and overcome these challenges jeopardizes SOA projects and the expected benets are not realized. Complexity is present in creating enterprise solutions, regardless of whether we adopt SOA and associated best practices. Solutions that span the enterprise require both depth and breadth of knowledge. And in spanning the enterprise the complexity of creating successful solutions grows in relation to the sophistication of the underlying business along with the number and variety of participating roles and organizations. To succeed in building solutions that go beyond traditional silo-based thinking, we go beyond traditional IT approaches. By adopting SOA we have tools, techniques and best practices that help us to tackle complexity. We design better solutions, development becomes easier and we have solutions that are easier to maintain and manage. We deliver business solutions that are enabled by IT. Such efforts require the participation and coordination of a number of roles. Each of the roles tends to view and interpret SOA differently. Not too surprisingly, they relate the idea of SOA to the needs of their domain, their expertise and experience. So when we look at the SOA vision we need to be mindful of these roles, their perspectives and goals: Business what is needed to support the business process? Architecture how do we dene and design these services? Implementation how do we implement services through components deployed on the technical infrastructure? Quality Assurance - how do we validate solution quality? Operations - how do we operate and manage these services? In this book, our primary focus is on architecture and the Architect role. Architecture plays a critical role in SOA efforts since it guides and impacts the other aspects. However, as the following gure illustrates, even though our focus is on architecture, we interact with many other roles....architecture does not exist in isolation!
the
group
Page 13 of 261
Architectures critical role in succeeding with SOA
Charting a Course For an architect to succeed, they need a roadmap so that they can understand where they currently stand and to plan where they want to go. As the saying goes, if you dont know where you are going, any road will get you there1. For SOA, we use a maturity model as a roadmap. More specically, we consult The Open Group Service Integration Maturity Model (OSIMM)2. A graphic depicting OSIMM is provided in the following gure. Each row in the diagram highlights a dimension that is required in SOA efforts, including: Business View, Governance & Organization, Methods, Applications, Architecture, Information, and Infrastructure & Management. These dimensions tie in nicely to the recognition that SOA is an enterprise spanning initiative. The columns depict the level of maturity for each of the dimensions with maturity growing as we migrate from left to right.
1 2
Lewis Carroll
The Open Group Service Integration Maturity Model, http://www.opengroup.org/soa/source-book/osimmv2/ index.htm

the group
Page 14 of 261
The Open Group Service Integration Maturity Model3
The following diagram depicts the benets associated with moving to higher levels of maturity.

the group
Page 15 of 261
Benets of achieving higher levels of maturity4.
In the following sections well take a closer look at some of the OSIMM dimensions including Governance, Methods and Architecture. An organizations destination and roadmap is shaped by their skills, existing solutions, technology (tools and platforms), goals and competitive landscape. There is no onesize-ts-all approach to SOA that can be purchased off the shelf and rolled out. Ideally, we pull together an approach that combines the pieces and approaches that bring the most value to the situation. Business View The OSIMM describes the Business View dimension as: ...focused on the business architecture; i.e., the organizations current business practices and policies; how business processes are designed, structured, implemented, and executed. The Business dimension also addresses how the cost of IT capabilities is allocated across the enterprise, and how well the IT capabilities support the exibility of the business, agility, and SLAs. The Business dimension includes IT strategy.5 This denition highlights that the business view with its focus on the business architecture needs to have a view of the enterprise, including strategy, operations and
4

5

the group
Page 16 of 261
IT. And as shown in the following image, SOA is a key component for making the business architecture actionable.
IBMs Actionable Business Architecture6
Governance Governance plays a critical role in the success of our SOA projects. SOA Governance empowers and enables the people within the organization to successfully deliver SOA solutions. We empower people by establishing chains of responsibility, authority and communication. We enable people to carry out their roles and responsibilities by establishing measurement, policy and control mechanisms. We get the team to use a dened set of proven practices and communicate effectively while supporting measurement and traceability. The focus of these efforts is to ensure Business-IT alignment, reduce risk, ensure proper investments, support reuse, and deliver quality solutions in a timely manner. We could try to proceed without SOA Governance. We might even start out successfully. But, without SOA Governance from the beginning, well see a greater usage of resources required to maintain your services, new efforts will get bogged down, and overall the value of moving to SOA in the rst place will be lost. When establishing and rening an approach to SOA Governance, we need to consider both design-time and run-time governance. Having one view on governance without the other leads to disaster. Without design-time governance, how can we be sure that
6
http://www-935.ibm.com/services/us/gbs/bus/html/actionable_business_architecture.html
IBM Whitepaper titled Actionable Business Architecture : http://www-935.ibm.com/services/de/gbs/ applicationinnovation/pdfs/actionable-business-approach.pdf IBM Whitepaper titled Actionable Business Architecture: IBMs Approach: ftp://public.dhe.ibm.com/ common/ssi/ecm/en/gbw03113usen/GBW03113USEN.PDF
the group
Page 17 of 261
we are building the right services in the right way? Without run-time governance, how can we effectively and efciently operationalize and manage the services that are delivered? Sadly, the topic of design-time governance is often neglected. The balance of coverage, support and discussion is skewed toward run-time governance. To help restore some balance, our primary focus is on design-time governance (however, there will be some discussion and guidance regarding run-time governance). Methods: SOAD and Agile If we compare the foundations of SOA and Agile it is clear that there is strong and signicant alignment. Luckily, it is easy to compare these foundations as each approach has a set of materials including a manifesto 7 and principles. Lets start with taking a look at the SOA and Agile Manifestos.
SOA Manifesto
Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation. We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agility and cost effectiveness, in line with changing business needs. Through our work we have come to prioritize: Business value over technical strategy Strategic goals over project-specific benefits Intrinsic interoperability over custom integration Shared services over specific-purpose implementations Flexibility over optimization Evolutionary refinement over pursuit of initial perfection That is, while we value the items on the right, we value the items on the left more.
The SOA Manifesto.
Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
The Agile Manifesto.
In both cases, we need to be careful in paying attention to the concluding statements in the manifesto. Like so many things related to architecture, there are nuanced,
7
The agile manifesto and associated principles are found at: http://agilemanifesto.org. The SOA manifesto and associated principles are found at: http://www.soa-manifesto.org.
the group
Page 18 of 261
shades of grade, judgement calls to make. These statements remind us that while we are placing more value on the items on the left, we cannot disregard or undervalue the items on the right. Lets also take a look at the associated principles for each approach.
SOA Principles
Respect the social and power structure of the organization. Recognize that SOA ultimately demands change on many levels. The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries. Products and standards alone will neither give you SOA nor apply the service orientation paradigm for you. SOA can be realized through a variety of technologies and standards. Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards. Pursue uniformity on the outside while allowing diversity on the inside. Identify services through collaboration with business and technology stakeholders. Maximize service usage by considering the current and future scope of utilization. Verify that services satisfy business requirements and goals. Evolve services and their organization in response to real use. Separate the different aspects of a system that change at different rates. Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change. At every level of abstraction, organize each service around a cohesive and manageable unit of functionality.
The principles underlying the SOA Manifesto.
the
group
Page 19 of 261
Agile Principles
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efcient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indenitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reects on how to become more effective, then tunes and adjusts its behavior accordingly.
The principles underlying the Agile Manifesto.
SOAD as a practice is focused on the steps, techniques, work products and artifacts that are present in SOA solutions. However, modern practices do not strive to be all encompassing, self-contained, one-size-ts-all approaches. A software development process is comprised of a set of practices, that are combined and customized to meet the needs of the organization and the solution. To succeed with SOA, we need an SOA specic practice (i.e. SiSaS, SOMA) and also an Agile practice framework, in this case the Scaled Agile Framework8 . Our quick review of the foundations of SOA and Agile highlights the compatibility between these approaches. To succeed, we need an approach that brings together Agile and SOA, that is, we need an Agile SOA development process. SOAD The concept of Service-Oriented Analysis and Design can be traced back to a developerWorks article where the authors state: ...we will investigate suitable elements from OOAD, EA, and BPM. We will also motivate the need for a hybrid approach that combines elements of all of the disciplines, with a number of distinct, new elements. The resulting,
8
Interested in learning more about the Scaled Agile Framework? http://scaledagileframework.com

the group
Page 20 of 261
interdisciplinary OOAD method facilitating successful SOA deployments, which we refer to as Service-Oriented Analysis and Design (SOAD), has yet to be formally dened. We merely take rst steps into the SOAD space.9
The disciplines that are involved in creating SOA solutions.
SOAD covers these disciplines and adds in SOA specic aspects.
Where the basic elements of SOAD include: Process and notation should be formally dened Structured way to conceptualize services Well-dened quality factors and best practices End-to-end modeling and comprehensive tool support In the following sections, well take a look at two approaches for performing SOAD: IBM Rational Service-Oriented Modeling and Architecture (SOMA) and SINTEF Software as a Service (SiSaS). The biggest different youll nd in examining the two approaches is that SOMA is more practice and goal oriented and SiSaS is more oriented to the artifacts created. Having said that, the two approaches are quite similar and youd be well served by other approach. The SOAD Model Accelerator is wellsuited for working with either approach.
9
This quote and the accompanying gures are sourced from Zimmerman, et al. Elements of ServiceOriented Analysis and Design: An interdisciplinary modeling approach for SOA projects, http:// www.ibm.com/developerworks/webservices/library/ws-soad1/
the group
Page 21 of 261
Service-Oriented Modeling and Architecture (SOMA) IBM Rational Service-Oriented Modeling and Architecture (SOMA) provides guidance on the roles, tasks, workows, deliverables and best practices for performing ServiceOriented Analysis and Design (SOAD). SOMA was originally created by IBM Global Business Services and was derived from eld experiences across a range of customers. This original release was proprietary to IBM GBS and was only available for use by their consultants during engagements. However, in 2006, IBM RUP for SOMA was introduced and was made available commercially. The name of the commercial version has changed a bit to IBM Rational SOMA and it is currently at version 2.9. The following image10 introduces the key workows, or activity groupings, in the Rational SOMA method, including the inuences driving each phase and the artifacts produced. Note that the key artifact manipulated by the method is the Service Model.
SOMA inuences, practices and work products.
Service Identication: focuses on the identication of candidate services from the set of assets from both business and IT. Service Specication: focuses on the selection of candidate services that shall be developed into full services. These services are then allocated to subsystems also identied above and then decomposed into sets of components for implementation.
10
Image from Rational SOMA, copyright IBM.

the group
Page 22 of 261
Service Realization: is primarily a Construction time set of activities, focused on the completion of component design ready for component implementation. Service Implementation: follows on from realization and the focus is on the development (implementation) of the services as specied in the design. The following gure provides a closer look at the Service Model, a key artifact that created when following Rational SOMA. The Service Model is used across Service Identication, Service Specication and Service Realization. Business related constructs would be captured in separate models using notations better suited to describing the needs of the business. The gure also highlights the types of artifacts that are produced across the SOMA phases. As we work through the tasks detailed in Rational SOMA, we often see the Service Model serving as input and output. During the task, additional diagrams, model elements and renements are performed. In reviewing SOMA, make sure that you take the time not only to look at the task summaries, but also examine the task steps to gain an understanding of the work done on the Service Model.
The Service Model11 is created, augmented and rened across Service Identication, Service Specication and Service Realization.
11
Image from Rational SOMA, copyright IBM.

the group
Page 23 of 261
SOAD: SINTEF Software as a Service (SiSaS) Methodology An alternative to Rational SOMA is the SINTEF Software as a Service Alternative? (SiSaS) methodology. The SINTEF In reality, we nd that teams will develop SiSaSmethod providespractices hybrid approaches to the processes that they that containguidelines for how to adopt. In a hybrid approach you pick and dene, specifyand chose elements from a number of sources to implementservice-oriented create the process that best ts their needs. solutionsfrom both a business and an IT perspective.The method adopts Ideally, we start with the process and the OMG Model Driven Architecture practices that most closely align with our (MDA)approach to software needs and then adjust from there (minimizing development and prescribesa set of the amount of customization). In these model artefacts that are used in the sections we look at leading options for development ofservice-oriented SOAD. Organizations would typically pick solutions. The software development one of the approaches as a starting point and practices follow a light-weight, then adjust and augment as needed. model-based adoption of theEnterprise Unied Process (EUP). The method also adopts theScrumpractice which prescribes aniterative and incremental software development process. The method is published under the Eclipse Public License (EPL), meaning that it is free for you to acquire and use. In addition, as it has been written using Eclipse Process Framework Composer12 , it can easily be customized and merged with other method content. The next gure provides an overview of the artifacts produced, their relationships and how they map to levels of abstraction. The levels of abstraction are noted as mapping to the Model Driven Architecture approach to development.
12
More information about Eclipse Process Framework Composer can be found at: http://www.eclipse.org/epf/
the group
Page 24 of 261
Changes made to the software architecture will have a signicant impact on the solution. Experience, guidance from industry, patterns, and frameworks all become key ingredients when dening the architecture. We also automate solution creation, incorporate industry standards, and simplify the language(s) we use in understanding the problem domain and the solution space.
the
group
Page 25 of 261
Overview13 of artifacts, relationships and mapping to MDA levels of abstraction
Two key workows (formally known as capability patterns14 ) are described within SiSaS, one for creating the Business Architecture Model and one for the System Architecture Model.
Workow following in creating the Business Architecture Model
Workow following in creating the System Architecture Model
In reviewing these workows, youll see that there is a simple mapping between the workow activities and the artifacts that you are encouraged to create. For more information concerning SiSaS, please visit: http://epf.thingml.org/wikis/sisas/ index.htm
13 14
Image sourced from SiSaS, please visit: http://epf.thingml.org/wikis/sisas/index.htm Workow images are sourced from SiSaS, please visit: http://epf.thingml.org/wikis/sisas/index.htm
the group
Page 26 of 261
As mentioned when we started this discussion about SOAD, there are many similarities between the SOMA and SiSaS approaches and either would make a ne choice as a starting point for the technical portions of your Methods. As you congure and customize your approach, it is worthwhile to consult both approaches. There are many areas of overlap and also some areas of uniqueness when it comes to tasks, guidance, examples and checklists. The biggest difference between the two is that SiSaS has a simpler, more direct mapping from tasks to artifacts. Whereas, Rational SOMA, has more goal oriented tasks that touch focus upon updates to the Service Model. To understand the changes introduced into the Service Model by a task, the practitioner will need to read the details and steps for the task.
Highlighting the alignment between the two approaches.
the
group
Page 27 of 261
Scaling the Agile Effort Agile principles emerged as a coherent set of best practices for software development in 2001. Since that time, software companies and IT departments have been increasingly embracing agile methods for product development and project management. Along the way, technical practices for agile testing, agile modeling, and continuous integration have been refined. The four-week iteration has been pared down to one or two weeks instead. Use cases have given way to user stories. Agile methods such as Scrum, XP, FDD, DSDM, and Crystal were codified, with Scrum having emerged as the front-runner, and XP coming in second place. Lean principles and Kanban have gained traction and in some instances been interwoven with Scrum and XP. The daily standup and team retrospective have proven to be essential and durable rituals. And even as tool vendors have jockeyed for position to support agile teams with electronic backlogs, task boards, work item tracking and performance metrics, the physical task board with blue painters tape and sticky notes continues to be emblematic of the true spirit of agility. Early adopters of agile methods wereattracted to the promise of reduced project risk, increased product quality, shorter time-to-value, more predictable project economics, happier teams, and improved collaboration between business and technical staff. By 2011, nearly 40% of surveyed IT professionals reported that they followed an agile method of some sort, as reported by the research firm Forrester.15 It comes as no surprise to agile practitioners that size matters. That above-mentioned Forrester report concludes that in many organizations, culture and governance practices have resulted in an approach to agility that is both challenging for the Agile team and fails to realize Agiles business benefits such as faster time-to-market, increased business value, and improved flexibility and responsiveness. Not surprisingly, as organization size increases these challenges become increasingly apparent. In addition to the adoption challenges posed by organizational culture and governance practices, there are additional reasons why organizations encounter increasing resistance as the size of the organization goes up. With an emphasis on face-to-face communication and co-located teams, agile organizations are subject to the inevitable friction that increases as the number of communication pathways goes up, as described by Fred Brooks in The Mythical Man-Month (1975). Agile software development is highly social, so it is natural that the social sciences would have something to bring to the table as well. In 1992, Robin Dunbar observed that community cohesion begins to degrade when the number of individual members approaches a mean value of about 150 (the high-confidence interval being 100 to
15
Forrester/Dr. Dobbs Global Developer Technographics Survey, Q3 2010

group
the
Page 28 of 261
230). Dunbar theorizes that there is a biological basis for these limits. He believes that the size of the neocortex in the brain which is responsible for language, spatial reasoning, and sensory perception, among other functions limits the number of personal relationships that an individual can maintain. If we allow that communication degradation and community cohesion are social factors which limit agility at scale, and we similarly accept that culture and governance practices are organizational factors which limit agility at scale, we can reasonably assert that any strategies which attempt to overcome these obstacles would have to address both the social and organizational dimensions. Such strategies necessarily fall into two categories: avoidance or management. Either the organization divides itself into smaller functional units to maintain communities below the critical mass and in so doing avoids the scaling problem, or the organization optimizes planning and communication mechanisms to facilitate inter-team coordination to and actively scales the agile effort. This first strategy avoiding the issue by limiting organizational size can be very effective if complete value chains are the basis of community formation. In this model, all of the participants required for delivering business value form autonomous, multidisciplinary subgroups outside of formal, hierarchical management structures. Malcolm Gladwell describes an effective application of this strategy at the firm W. L. Gore and Associates in the The Tipping Point, first published in 2000. Today, W. L. Gore and Associates continues to be known as a leading innovator, and is among just five workplaces to appear on every list of the "100 Best Companies to Work For" since the rankings debuted three decades ago. For most organizations such radical teaming strategies are beyond reach. Departments, management hierarchies, job descriptions, and budget practices may be deeply rooted and difficult to change. The second strategy introducing additional mechanisms to manage and scale the agile effort overwhelmingly tends to be more likely and practical approach. Dean Leffingwell has been at the forefront of developing techniques for addressing the formidable challenges that confront organizations attempting to adopt agile methods at scale. In Scaling Software Agility: Best Practices for Large Enterprises (2007), Leffingwell wrote, barriers to agile adoption at the enterprise arise from two sources: the apparent limitations of the methods themselves and the impediments that exist within the enterprise. Both must be addressed to achieve enterprise agility. Leffingwell's work with contributions from Drew Jemilo, Colin ONeill, Alex Yakyma and Alan Shalloway has resulted in the Scaled Agile Framework (SAFe).
the
group
Page 29 of 261
Scaled Agile Framework! Big Picture
Scaled Agile Framework big picture that brings it all together16
The Scaled Agile Framework addresses the social dimension of the scaling problem by organizing group cohesion around the Program. In the SAFe, the Program represents a value chain that links customers, suppliers, business participants, and technical staff in a coordinated effort to deliver new solutions to meet business demands. The Program coordinates the efforts of multiple agile teams, synchronized to a common cadence to deliver value releases at a continuous and sustainable pace. The organizational dimension of the scaling problem is addressed by doing away with the project metaphor and instead allowing agile teams to be self-organizing, selfmanaging and cross-functional. Additional teaming is necessary at the Program level to integrate the work produced by agile teams into value-producing features and coordinate the activities required to deliver these changes into the business.
16
Image sourced from the Scaled Agile Framework. Interested in learning more about the Scaled Agile Framework? http://scaledagileframework.com
the group
Page 30 of 261
Finally, the SAFe addresses the management and governance of the Program by describing an agile approach to portfolio management in the Portfolio layer. Having done away with the project metaphor in favor of a continuous flow approach, the Portfolio layer integrates lean concepts by describing business strategy and technology oversight as a pull-based, Kanban approach. In this approach, business needs and technology initiatives are identified and prioritized with strategic vision and financial constraints in mind. Management and governance is achieved by paying attention to the flow of work through the Program. By watching the work queues, information is made available to the teams at the Program and Team levels as feedback and opportunities for improvements are continuously encouraged to increase flow where desired. In summary, the Scaled Agile Framework has evolved over six years of development in real-world situations to effectively address the social and organizational barriers to agility at scale. The Importance of Architecture At this point, weve touched upon SOA, OSIMM, SOMA, SiSaS, and SAFe. In each case weve seen references to the enterprise and architecture. Weve also seen, as shown in the gure below, that architecture is critical in coordinating the roles and deliverables across many disciplines. Why do we care about these practices? Coordinating across roles? Taking an enterprise perspective? We care because good software does not happen by accident. Meeting the needs of the enterprise does not happen by accident. These practices help us to make decisions, leverage the experiences of others and enable a team to collaborate and align in reaching a common objective.
the
group
Page 31 of 261
Importance of Architecture
As a foundation, lets get started with a denition. Software architecture is comprised of the signicant decisions about the: 1. Organization of the elements within the system 2. Selection of structural elements and the interfaces used to represent them 3. Behavior amongst the elements 4. Composition of the elements into larger components and subsystems Typically, an architect will be guided by an architectural style (for instance SOA) and the associated principles and patterns related to that architectural style. In doing so, the architect is able to guide the project, manage complexity and maintain system integrity. Successfully adopting this architectural style will lead to SOA solutions that exhibit the following characteristics:
the group
Page 32 of 261
1. 2. 3. 4.
Loosely coupled, business aligned services Services invoked using standard protocols Services that are choreographed into composite applications Separation of concerns; service description, implementation, service binding.
The Service-Oriented Analysis and Design Model Accelerator Breaking down silos, working across organizational boundaries and achieving business agility is only possible by having a technical team that is equally agile. An important phrase from the Agile Manifesto that we should revisit is the idea that we place more value on Individuals and interactions over processes and tools. However, this does not mean that we do not need processes nor tools. Just that we place more value on individuals and interactions. Ideally, we have processes and tools that support the individual and interactions. This is where the Service-Oriented Analysis and Design Model AcceleratorTM comes in. The SOAD Model Accelerator is for software architects that want to amplify their efforts in realizing an Agile SOA approach. The SOAD Model Accelerator infuses best-practices into SOA designs, reduces mechanical steps, enhances solution focus, magnies creativity and problem solving skills, and sharing information to support interaction and collaboration. The SOAD Model Accelerator provides a set of automations that include patterns, constraints, reports and cheat sheets. As shown in the following gure, these automations work together and reinforce one another in an iterative and incremental approach
the
group
Page 33 of 261
SOAD Model Accelerator automations.
The SOAD Model Accelerator is focused on assisting software architects in four critical areas: 1. Business Modeling: Do we understand the needs of the business? 2. Service Identication: Are we investing in the right services? 3. Service Specication: Are we designing the services correctly? 4. SOA Governance: Are we applying proper governance within our design time efforts?
the
group
Page 34 of 261
Overview of SOAD Model Accelerator impact areas
From a technical implementation point of view, the SOAD Model Accelerator amplies the out of the box experience provided by Rational Software Architect for WebSphere Software. Value Proposition In creating the Model Accelerator, our goal has been to make modeling tools more intelligent. Weve analyzed how common model elements are used together. Based on that analysis, weve built tooling to guide the practitioner to work with collaborations of elements rather than always building up from single, isolated pieces. Intelligent automation is critical to getting value from tools. We also understand that there is immense value in defect prevention. The use of constraints is a quick and simple method to check that models are following known rules. While Service Litmus Tests guide architects to question service design before we even get to implementation. And of course, we need tools that support sharing information with our team. The key word here is information, not just data. The Model Accelerator provides informative reports that go beyond simple inventories and general-purpose summaries. With information we get insight, we can take action, we gain understanding. With data, we just get overwhelmed. By using the SOAD Model Accelerator, software architects are more effective in creating SOA solutions that are based on the needs of the business, are better designed, delivered more quickly and with greater predictability. This is achieved by:
the group
Page 35 of 261
1. Reducing errors by automating tedious, errorprone tasks. 2. Improving efciency and overall productivity by eliminating repetitive, mechanical steps. 3. Bringing Agile SOA to life via automation. Starting with an empty model\diagram can be intimidating. Designing and problem solving using patterns encourages practitioners to think in terms of larger constructs. 4. Enabling a wide-range of practitioners to use Rational Software Architect for WebSphere to model SOA solutions by reducing the learning curve while also ensuring that they align with organizational best practices. 5. Supporting governance through simplied and streamlined adoption of practices, improved communication and using traceability and reporting to generate data and metrics. 6. Increasing the impact of skilled practitioners. Skilled SOA architects are always in short supply - increasing their productivity and inuence gives them opportunities to participate in and impact more projects. The SOAD Model Accelerator amplies Rational Software Architect through intelligent automation. This automation guides, analyzes and communicates solution architecture and design in enterprise settings. For example, three critical efforts that architects, designers and analysts participant in are: Design Reviews Business-IT Alignment Consistent application of practices and alignment to standards In traditional settings, organizations will use a combination of presentations, documents and pictures to feed into these efforts. However, the time to prepare, analyze and the grasp the information shared is measured in days! However, by using the Model Accelerator, we are able to dramatically shrink these timelines. We can prepare reports for Design Reviews in a matter of seconds. The Model Accelerator itself provides practices and standards enforcement. We use reports and patterns to guide and report on Business-IT alignment.
the
group
Page 36 of 261
Part II. SOA Modeling
the
group
Page 37 of 261
Introduction Here in Part II, we discuss SOA modeling. That is, how can we effectively model Service-Oriented Architectures? What approaches do we take? What modeling To provide continuity and context, notation? How do we use that notation the Pattern Reference section of effectively? this book uses this same case study. Dealer Network examples Well introduce a case study that well use are used to illustrate the throughout the book, look at the basic elements application of the patterns of the Service oriented architecture Modeling discussed. Language (SoaML), and take a look at approaches to using SoaML. Why Model SOA solutions? Weve17 all seen the statistics1819 20 , and likely experienced rst-hand, the reality of project failure. The majority of software projects continue to be classied as failures. In thinking about this situation we can see that there are a few different ways in which a project can fail (clearly this is not an exhaustive list!): - Technical: - the solution does not meet the project requirements (scalability, performance, reliability, cost, etc) - due to technical challenges we continue to push out deadlines (and in turn, cost) until we reach the point that project sponsors lose faith in the project and cancel funding - Functional - the team does not understand the requirements that have been provided - the requirements provided are not the correct requirements If we try to distill this to a high level view, we can see that we have difculty in understanding the problem and moving to a solution.
17
Content for this section originally appeared in an InfoQ article: Agile Modeling: Enhancing Communication and Understanding, Nov 2011
18
http://www.infoq.com/news/2011/10/risky-it-projects - provides an example of a recent look at IT project risk and some startling gures on failures.
19
James Kwak, Software Runs the World: How Scared Should We Be That So Much of It Is So Bad?, http:// www.theatlantic.com/business/archive/2012/08/software-runs-the-world-how-scared-should-we-be-that-so-much-isbad/260846/
20
Nathaniel Popper, Knight Capital Says Trading Glitch Cost It $440 Million, http://dealbook.nytimes.com/ 2012/08/02/knight-capital-says-trading-mishap-cost-it-440-million/
the group
Page 38 of 261
How can we successfully transition from the problem to the right solution?
However, such a view is too simplistic. We shouldnt think that the movement from problem to solution is a one-way ow of information - and we denitely shouldnt see it happening as a one-time, waterfall progression. Weve seen that before, and it doesnt go well. So lets update our view a bit and recognize that there is a ow of information between problem and solution domains and that this is an iterative effort.
More accurate to recognize that there is an iterative effort to move from a problem to a solution.
Our view of the situation is getting better, but its still too simplistic. Lets go another layer deeper. We also need to recognize that development is a team sport. Were going to have multiple stakeholders and multiple people responsible for design, development, deployment and operations.
Getting closer to reality now by also recognizing that there are many people involved in these efforts.
the
group
Page 39 of 261
Weve taken another step forward in getting a more realistic view. However, theres one more step thats worth taking. Although we strive to have our team co-located, the reality is that we work in a distributed, networked world.
And todays teams are often dispersed to locations worldwide.
So to summarize this progression, project success is limited by our ability to: 1. Understand a. Do we understand the problem domain? b. Do we understand the solution domain? c. Do we understand how to transition between the two domains? 2. Communicate a. Are stakeholders able to communicate the requirements to those building the solution? b. Are those building the solution able to communicate the solution details amongst themselves? c. Are the solution builders able to communicate challenges and alternatives to the stakeholders? And adding to the difcultly is the recognition that we need to deal with proximity and temporal challenges (i.e. locations and timezones). A key technique to address these challenges that is often overlooked, undervalued or misunderstood is the use of modeling - especially as we move to an agile approach. In ghting back against heavy-weight processes and tool-centered development modeling was guilty by association. So lets take a few minutes to set the record straight...
the group
Page 40 of 261
A good place to start is to agree on a denition for modeling. Simply put, modeling is the simplication of reality. Thats it, thats all. It does not imply the use of a specic notation, tool or process. Were just trying to look at something that is complex, and make some portion of it easier to understand. As they say, sometimes you cant see the forest for the trees. Unnecessary details make it more difcult to understand the situation. Better to hide those unnecessary details and focus on the important aspects of the situation. If we can agree on this denition of modeling, we can take things a step further and consider the idea of Agile Modeling21. With Agile Modeling we follow an agile approach to using models to help us to understand and communicate. Apologies for the circular denition - but this gives us a good starting point to pose the question How do we take an agile approach when using models? Much like Agile development in general we use a set of values, principles and practices to guide us in being as agile as possible. Some of the highlights of the Agile Modeling approach include: a. Agile Modeling adheres to the Agile Manifesto and supporting principles. As such, it becomes another practice that you can add to your agile toolkit. b. Models support communication and understanding. c. We strive to create simple models using simple tools. Embrace simplicity. d. We know that requirements are going to change and we therefore embrace change as we create models. e. Our focus is on delivering software not models. We use models when and where they add value. If they do not provide value and move us closer to delivering software - then we dont create a model. f. We keep models for as long as they are needed. If a model has served its purpose and is no longer needed - we throw it away. This allows us to travel light and not get bogged down with busy work. g. We use multiple models. We use models for different perspectives, different levels of abstraction and for different audiences. For each model we create we understand the audience(s) and goal(s). We do not create models if we dont have this understanding. h. We use a combination of informal and formal models as dictated by situation, audience and goals. For example, a model could be comprised of simple shapes (sketches) helping to explain a system metaphor OR diagram that uses the UML (or SoaML, BPMN, etc).
21
http://www.agilemodeling.com
the group
Page 41 of 261
Modeling supports us in communicating and understanding when we create software solutions. As communication and understanding are two of the most critical aspects of delivering software solutions - modeling is a valuable tool that should not be overlooked. To summarize, in general we model for 3 reasons: a. Analysis and Problem solving. We use models to gain an understanding of the problem domain, solve problems and create solutions. b. Communication. Software development is a team sport. Whether our teammates are down the hall or across the world, models help us to communicate the design with others. c. Solution generation. Models specied with formal languages can be interpreted by automations and used to generate portions of the solution. More specic to SOA, we use models to: a. Identify candidate services: What services could be created or consumed within the organization? b. Capture investment decisions: For those services that are identied, which should actually be created? Which should we try to consume? c. Capture decisions about which services to expose: What services do we want to make available? Who should be able to consume them? d. Specify the contract between service providers and consumers: What are the details for the contract? How do we make this contract clear to both parties in the relationship? e. Map services to the components required to realize those services: How do we work with development to create the underlying implementation? Case Study Background In this section we introduce the Dealer Network case study. The Dealer Network example is commonly used to illustrate the use of SoaML and shows up in the SoaML specication and many related artifacts. After we have introduced the case study, well take a look at how we model SOA solutions including the use of SoaML, common service interactions and approaches to modeling services. The Dealer Network is introduced in the SoaML Spec as follows: Our example business scenario is a community of independent dealers, manufacturers, and shippers who want to be able to work together cohesively and not re-design business processes or systems when working with other parties in the community. On the other hand they want to be able to have their own business processes, rules, and information. The community has decided to dene a service oriented architecture for the community to enable this open and agile business environment. Well be using a slight modied example described as follows:
the
group
Page 42 of 261
The Dealer Network Architecture consists of four participants (dealer, manufacturer, agent and shipper) interacting and fullling their roles dened in the three service contracts: Secure Purchase (specifying the roles buyer, seller and broker), Shipping Request (specifying the roles sender and shipper) and Shipping Status (specifying the roles receiver and shipper). In the services architecture the participants are bounded to the roles dened in the service contracts through the collaboration uses purchase (instance of Secure Purchase), ship (instance of Shipping Request) and status (instance of the Ship Status).22 The following diagram provides a high-level overview of the four participants and their interactions. The diagram is just a simple sketch - highlighting the fact that we can and should use sketching in our modeling efforts. The diagram is quick and simple to make, invites discussion and can be easily updated (and hides unnecessary details!). This is a great way to get the ball rolling.
High-level view of the Dealer Network.
22
Specifying Services using the Service Oriented Architecture Modeling Language (SOAML): A baseline for Specication of Cloud-based Services, Brian Elvester, Arne-Jrgen Berre, and Andrey Sadovykh
the group
Page 43 of 261
Service Oriented Architecture Modeling Language (SoaML) One of the modeling languages well use is the Service oriented architecture Modeling Language (SoaML). SoaML is an industry standard domain specic modeling language (DSL)23 for specifying SOA based solutions. The specication for the language is from the Object Management Group and is supported by companies large and small. Why do we want to use a DSL rather than just plain ol UML? A DSL uses concepts and terminology from a business or technical domain. In the case of SoaML, the language is based on the technical domain of SOA. We could just use plain UML, however, we would then be stuck with the limitations of using a generic language. It works equally well (poor?) across all situations. The generic elements are ambiguous and we will have to nd some way to relate the generic to the specics of the situation. For example, we could try use UML interfaces or components in our model. However, we end up having to distinguish between when the interface is dening a service contract or when its just a normal interface. Reducing the ambiguity means that DSL models are simpler to create, are easier to understand and serve as better input for transformation.
A model marked up with SoaML can be used as input to vendor supplied or custom transformations.
SoaML is supported in Rational Software Architect for WebSphere as an extension to UML 24. This provides us with a palette of modeling objects, context menus and
23
A Domain Specic Language (DSL) is a language that we can use to describe a solution that allows us to use terminology from the domain in which we are working. We may work within a business domain, industry domain, or a technology domain. By using the terminology from that domain, it is easier to understand, discuss and articulate solutions. In addition, by using formal approaches to dening the DSL, we can use automation to interpret models that use the DSL and generate related artifacts. We use DSLs to simplify our development - communication is easier, designs map more closely to the domain, and automations are able to better interpret and work with elements specic to the domain. Denition is from Ackerman and Gonzalez, Patterns-Based Engineering. http://patternsbasedengineering.net
24
To get the most from SoaML, you will need a solid understanding of some UML2 constructs. The most important of which include structured classiers and collaborations.
the group
Page 44 of 261
associated features to support the creation of models and diagrams for SO solutions. The language is also understood by a collection of UML transformations that can generate code artifacts based on SoaML models. The following table introduces some of the key elements from SoaML 25 and provides a brief description for each.
Overview of SoaML
Element
Capability
Stereotype/Icon
Capability
Description (SoaML Specication)

A Capability identies or species a cohesive set of functions or capabilities that a service provided by one or more participants might offer. Capabilities are used to identify needed services, and to organize them into catalogues in order to communicate the needs and capabilities of a service area, whether that be business or technology focused, prior to allocating those services to particular Participants. Often these are thought of as candidate services. Provides a means of classifying and organizing elements by categories for any purpose. A classication or division used to characterize the elements of a catalog and to categorize model elements. Consumer models the type of a service consumer. A consumer is then used as the type of a role in a service contract and the type of a port on a participant. An Expose dependency is use to indicate a Capability exposed through a ServiceInterface. The source of the Expose is the ServiceInterface, the target is the exposed Capability. A Participant represents some (possibly concrete) party or component that provides and/or consumes services participants may represent people, organizations or systems that provide and/or use services. A Participant is a service provider if it offers a service. A Participant is a service consumer if it uses a service a participant may provide or consume any number of services. Service consumer and provider are roles Participants play: the role of providers in some services and consumers in others, depending on the capabilities they provide and the needs they have to carry out their capabilities. Since most consumers and providers have both services and requests, Participant is used to model both.
Catalog Category Consumer
Catalog Category Consumer
Expose
Expose
Participant
Participant
25
http://www.omg.org/spec/SoaML/
the group
Page 45 of 261
Element
Provider
Stereotype/Icon
Provider

Provider models the type of a service provider in a consumer/provider relationship. A provider is then used as the type of a role in a service contract and the type of a port on a participant.. A Request represents a feature of a Participant that is the consumption of a service by one participant provided by others using well-dened terms, conditions and interfaces. A Request designates ports that dene the connection point through which a Participant meets its needs through the consumption of services provided by others. A ServiceContract is the specication of the agreement between providers and consumers of a service as to what information, products, assets, value and obligations will ow between the providers and consumers of that service it species the service without regard for realization, capabilities or implementation. A ServiceContract does not require the specication of who, how or why any party will fulll their obligations under that ServiceContract, thus providing for the loose coupling of the SOA paradigm. In most cases a ServiceContract will specify two roles (provider and consumer) but other service roles may be specied as well. The ServiceContract may also own a behavior that species the sequencing of the exchanges between the parties as well as the resulting state and delivery of the capability. The owned behavior is the choreography of the service and may use any of the standard UML behaviors such as an interaction, timing, state or activity diagram. A ServiceInterface denes the interface and responsibilities of a participant to provide or consume a service. It is used as the type of a Service or Request Port. A ServiceInterface is the means for specifying how a participant is to interact to provide or consume a Service. A ServiceInterface may include specic protocols, commands and information exchange by which actions are initiated and the result of the real world effects are made available as specied through the functionality portion of a service. A ServiceInterface may address the concepts associated with ownership, ownership domains, actions communicated between legal peers, trust, business transactions, authority, delegation, etc.
Request
Request
Service Contract
ServiceContract
Service Interface
ServiceInterface
the
group
Page 46 of 261
Element
Service
Stereotype/Icon
Service

A Service represents a feature of a Participant that is the offer of a service by one participant to others using well dened terms, conditions and interfaces. A Service designates a Port that denes the connection point through which a Participant offers its capabilities and provides a service to clients. The high-level view of a Service Oriented Architecture that denes how a set of participants works together, forming a community, for some purpose by providing and using services. We can specify a Services Architecture for a B2B scenario, an internal solution, a portion thereof, or even for a participant.
Services Architecture
ServicesArchitecture
More Information For more details on the complete set of elements within SoaML, consult the SoaML Specication: http://www.omg.org/spec/SoaML/. You can also consult the UML specication for details on the underlying metamodel. Also take a look at an Annotated SoaML Example. SoaML Modeling Approaches SoaML provides a exible language that can be used to support a number of SOA modeling approaches and SOAD methodologies. We already touched upon SOAD methodologies by looking at SOMA and SiSaS. So lets look at what is meant by different modeling approaches. Why Use SoaML? In reviewing the SoaML overview, 1. Industry standard DSL supported by many you may have noticed the vendors. similarity of the descriptions for 2. As a formal specication it supports elements such as automation ServiceInterface and 3. Industry standard leads to a large pool of ServiceContract and wondered practitioners that understand and work with why this is the case. You may the language. have also wondered what the 4. The language was crafted and vetted by a difference is between a UML large pool of experts. The resulting language Interface and a Service Interface. reects their experience, inputs and best practices. SoaML supports three 5. As a DSL, there is less ambiguity in trying to approaches to service modeling map model elements to the solution. including simple interface, 6. SoaML scales from very simple scenarios to contract and service interface. complex, multi-party, sophisticated The following table summarizes interactions. these approaches.
the
group
Page 47 of 261
SoaML support for alternative modeling approaches
Approach Simple Interface
Description The focus of the solution is on simple one-way interaction. This approach makes no assumptions about the caller or choreography of the service. This approach allows for more sophisticated, bi-directional services. That is, there is a protocol that denes two-way communication between the Service Provider and Consumer roles. We use a class-based approach to dene the contract for the services. Service Contracts provide an alternative approach to modeling sophisticated, bi-directional interactions. This approach is based on a collaboration based denition of the service contract between parties and having the participants agree to their part in that contract, or adapt to it.
ServiceInterface
Service Contract
A positive aspect of adopting and use SoaML is that it scales from very simple scenarios to complex, multi-party, sophisticated interactions. In these descriptions we saw reference to the interaction model between the participants in the service contract. Understanding the service interaction models and then identifying them in our projects help us to decide how we model the solution. Is there a simple request-response? Is the interaction bi-directional? How many parties are involved in the interaction?
Simple request-response service interaction.26
26
This series of images is produced using icons based on the book This is Service Design Thinking: http://thisisservicedesignthinking.com. Stencil used is available at: http://grafetopia.com/stencils/896
the group
Page 48 of 261
More sophisticated bi-directional service interaction.
Multi-party, multi-directional service interaction.
So which is the right approach? Should these approaches be used in combination? Does the selection of one approach preclude the use of another? The interaction model is one criteria that we can use in deciding on a modeling approach. The use of simple UML interfaces is not a good choice if we are dealing with a multi-party, multi-directional service interaction. And conversely, simple UML interfaces are an acceptable choice if were dealing with a simple request-response interaction. To answer these questions more fully, lets take a look some examples of diagrams using these approaches.
the
group
Page 49 of 261
Exploring SoaML Modeling Approaches In exploring SoaML Modeling approaches, well also highlight a number of SOAD Model Accelerator UML Patterns. Full details on each of the patterns is provided in Part III Pattern Reference. Lets start with the high-level sketch used previously to introduce the Dealer Network Pattern Impact example and dene it more formally using Highlights roles that participate in SoaML. To do so, we use the Simple Services a ServicesArchitecture Architecture pattern. By using this pattern we Creates parts within the are quickly able to create a Services ServicesArchitecture Architecture, add Service Contracts and a set Documents and supports of Participants. Theres still work left to be done traceability in creating the role bindings between the elements, but we are able to skip much of the point and click steps. We still have work in front of us for detailing the specics of the Service Contracts and Participants, but we have a good feel for the big picture.
High-level view of the Dealer Network via a ServicesArchitecture.
the
group
Page 50 of 261
We have a very direct mapping between this ServicesArchitecture and the sketch from earlier. This is intentional. The sketch served a purpose; it helped us to understand the big picture. And, the sketch was quick and easy to create, update and discuss. As we gain condence in our understanding of the solution we can formalize our depiction. The ServicesArchitecture builds on the output of this effort and now serves as the basis for formal modeling.
Simple Request-Response Service Interaction To model a simple request-response service interaction, we could just use the Simple UML Interface-based approach. Recall that this approach makes no assumptions about the caller or choreography of the service. However, from an architectural point of view, weve failed to take advantage of what SoaML can do for us as a DSL. In addition, if we have other service interactions to model, we end up with an inconsistent approach to our modeling.
Simple request-response service interaction.
Instead, we recommend taking things step further and use either the ServiceProvider or ServiceInterface stereotypes on your interfaces. Lets walk through an example of modeling a simple request-response scenario.
the
group
Page 51 of 261
Well focus on the Ship Status service contract Going a step deeper than the ServicesArchitecture, lets look at whats happening inside of the Ship Status ServiceContract. In this case, weve dened a Provider stereotyped interface and a generic receiver that consumes the service. In this case, as there is no callback to the consumer, theres no need to dene an interface - it would just be empty anyways!
View of the internals of the ServiceContract We add an operation to the ShippingStatus interface - providing support for others to nd out the status of their shipment.
the
group
Page 52 of 261
Detailing the ShippingStatus Provider interface We use a document style approach to the messaging - sending a document with the request and receiving a document as a reply. Heres a look at the two MessageType elements.
Dening the MessageTypes used by the service We then create ports on the Participants - the Dealer and the Shipper. If youre unfamiliar with this aspect of UML2, what you need to know is that each port is dedicated to a specic interaction and presents the interface appropriate to that purpose. By using ports, we: a. Distinguish between different collaborations based on the port used. Useful in modeling complex architectural components, which are often involved in multiple interactions. b. Incorporate encapsulation. The instance is a blackbox hiding the implementation details behind the interface that is provided\required. For SOA, this means that we can have a provider participating in a number of different service interactions. For each interaction, they have a unique port. In this way we are clear about what interfaces are provided and required in each interaction. A change in one interaction does not ripple across the solution. Weve isolated changes; supporting a SOA best practice of separation of concerns. In addition, through the use of encapsulation weve improved the design of the solution. As shown in the following diagram, the Shipper is offering this service and the Dealer is going to call the service.
the
group
Page 53 of 261
The two participants and their typed ports And to wrap things up, we create a component, a structured classier, that allows us to show how instances of these participants interact. We use a service channel to show the connection between the provided interface and the required interface.
The interaction of these participants via a ServiceChannel
In wrapping up this rst example, note that we followed the workow of diagram creation as discussed in SiSaS. We started by gaining a high-level Patterns Used understanding of the participants and In creating the diagrams in this example, the service contracts. We then rened the following patterns were used: model, adding in more details about 1. Simple Services Architecture the service contract. The details 2. Simple Request Participant included specifying the operations for 3. Simple Service Participant the Provider interface. Along with dening the Provider, we also detailed the MessageType elements used in the service. Getting further detailed, we rened the participants. For each participant we dened the ports used in the interaction and detailed what interfaces are provided\required. And to wrap things up, we used a
the group
Page 54 of 261
structured classier and a ServiceChannel to show the interaction. Well follow a very similar approach as we work through more sophisticated service interactions in the following sections. In these upcoming examples, well show how we can use a similar Service Contract renement approach, or an approach that focuses on ServiceInterface elements. Service Contract Based Approach The modeling effort gets more interesting as we introduce scenarios where there is a two-way interaction between service providers and service consumers. Although there are some more elements modeled, we follow the same approach as we saw in the previous section when examining the very simple request-response scenario. In this case, consider the situation where we need to support the placing of an order. In this scenario, the interaction sees the Dealer requesting a quote from the Manufacturer, and once theres a satisfactory quote, be able to place an order and receive a conrmation. Note: This a simplied version of the Secured Pattern Impact Purchase ServiceContract. Well Automates creation of parts within the introduce the secure aspect a little ServiceContract later. Automates the creation of an associated interaction with lifelines based on the parts We dene a ServiceContract that Documents and supports traceability contains parts for the OrderPlacer (Consumer) and the OrderTaker (Provider). Notice that we are using both a Provider and a Consumer this time. The reason is that there is a bi-directional interaction. The Consumer is required to provide some services that the Provider can call in this interaction.
Dening the ServiceContract for Place Order.
At this point we know the contract and the roles participating, but we need to further understand the interaction and how these services will be offered. We can use a sequence diagram to dene the protocol.
the group
Page 55 of 261
Sequence diagram for dening the protocol between the OrderPlacer and OrderTaker. With the understanding of the protocol in place, we can dene an interface that we Pattern Impact will assign to the participants. Well use Automates creation of the relationships this interface (we use the term interface between the interface and the Consumer here generically, the underlying and Provider implementation is actually a class, Documents and supports traceability necessary for typing the port on the participants) to clearly dene the responsibilities of the roles. For the consumer to participate in the dialog there are certain interfaces that it will require and provide.
the
group
Page 56 of 261
High-level view of the Dealer Network via a ServicesArchitecture.
With the interface dened, the next step is to properly assign the interface Pattern Impact to the Dealer and Manufacturer Guides practitioner to use componentparticipants. We want to have a port based participants on each participant, identify which Automates creation of a port with the participant is providing the Service proper markup and which is making Requests. Recall Documents and supports traceability that the Dealer also had a service interaction with the Shipper. We use ports to clearly delineate these different interactions. So well create (and type) a new port for this order placing interaction. The next step is to properly indicate which interfaces are provided and which are required. Note that in this case with the Dealer making the Request, we want to conjugate the port. Conjugate is a fancy way of saying that we are going to reverse the required and provided aspects of the type used by the port. In this way it will accurately reect the way that these interfaces are used by the service provider and service consumer. As a result we provide the OrderPlacer interface and use the OrderTaker interface.
the
group
Page 57 of 261
We can use the Simple Request Participant pattern for creating and typing the port.
Next, we create the port on the Manufacturer participant. In this case, the port is marked up as a Service.
the
group
Page 58 of 261
We can use the Simple Service Participant pattern for creating and typing the port.
Service Contracts: Beyond Two Participants In this next example, things get more interesting as we introduce a 3rd party into the mix. In this example we extend the place order scenario we just discussed and look at the Secure Purchase service contract. To support secure transactions, we use an Escrow Agent to ensure that both the Dealer and Manufacturer interests are protected when selling\purchasing merchandise. We model the service contract and the service providers and consumer.
the
group
Page 59 of 261
Service Contract for Escrow Purchase.
We use the associated interaction to dene how the roles interact to realize this secure transaction.
the
group
Page 60 of 261
Interaction between the participants for secure purchase.
Just like we saw with the previous two-way interaction example, we want to dene the interface that is attached to each participant in the interaction. However, with a third party in the mix, we have a little more work to do. Although each participant is going to draw upon the same set of consumer and provider elements, the way in which these interfaces are presented will differ based on their role in the interaction. We want to dene how these interfaces are provided or required across the set of participants, to do so we need to dene a set of collaborating interfaces. The following three gures dene the SecureSale, SecurePurchase and EscrowPurchase interfaces.
the group
Page 61 of 261
Use the Collaborating Interface pattern to dene SecureSale
Dene collaborating interface for SecurePurchase
Dene collaborating interface for EscrowPurchase

the group
Page 62 of 261
Pattern Impact With the collaborating interfaces Automates creation of the participant port dened, we now need to set up the Ensures that the port has the correct type participants, their ports and the and markup interfaces associated with the ports. Enables us to map multiple interfaces to For the Dealer, we use the the single Request port SecurePurchase collaborating Documents and supports traceability interface and also the EscrowAgent interface. We assign the interfaces to a port and dene this as a Request (recall that a Request conjugates the interfaces).
Dening the Dealer participant
We perform similar steps to set up the Manufacturer participant. In this case, we want to dene the port as a Service. We use the same interfaces as we did with Dealer, but need to dene them so that they connect the entities and also support the interaction with the EscrowAgent.
the
group
Page 63 of 261
Interpreting the Specication When working with Service Contracts, the SoaML specication states that use of conjugation with a Request port is optional. The SOAD Model Accelerator consistently uses conjugation on all Request ports.
Dening the Manufacturer participant
And we set up the nal participant, the EscrowAgent. In this case, we just need to connect a collaborating interface to the port. Similar to the Manufacturer, the EscrowAgents port is typed as a service.
Pattern Impact Automates creation of the participant port Ensures that the port has the correct type and markup Creates one port for each interface Documents and supports traceability
the
group
Page 64 of 261
Dening the EscrowAgent participant The following gure shows the completed set of participants. And much like we saw with the earlier example, we would proceed to wrap things up by adding these participants to a structured classier that allows us to show how instances of these participants interact. We use a service channel to show the connection between the provided and required interfaces.
the
group
Page 65 of 261
The completed set of participants
Service Interface Based Approach Using Service Interfaces is very similar to the Service Contract approach that we just looked at. In both cases, the focus is on supporting multiparty, bi-directional service interactions. The biggest different between the approaches is that Service Interfaces focus on the use UML components and interconnections through ports (whereas, as weve just seen, Service Contracts use UML collaborations). Lets take a look at some example diagrams using Service Interfaces. Earlier on, we looked at PlaceOrder through the use of a Service Contract. Lets revisit the same example and this time well model it through the use of Service Interfaces.
the
group
Page 66 of 261
Dening the collaborating interface, this time using a Service Interface
To dene the protocol associated with the interfaces and how they collaborate we can use an interaction and associate it with the PlaceOrderInterface service interface. The following gure shows the participants with their ports dened. We were able to use the Simple Service Participant and Simple Request Participant patterns exactly like we did previously with the Service Contract approach.
View of the participants after creating the ports
Once we have our participants and associated ports dened, we can add them to a composite structure diagram. Recall that with the composite structure diagram we are detailing how instances of these elements collaborate (in contrast a class diagram is about structural relationships). As shown the following diagram, we connect the participants via a service channel. In this case, since they each support the same interface (in essence, the ports are mirror images of one another, the service channel simplies the diagram and connects the ports rather than showing the ball and socket notation for each interface).
the
group
Page 67 of 261
Participants connected via a Service Channel
Picking the Right Approach Weve now taken a closer look at the three approaches to modeling with SoaML and can now try to answer the question: which is the right approach? Not too surprisingly, there is no one right answer. However, there are some guidelines that we can use to help us formulate an answer. We can start with some general ideas about making choices when modeling. As discussed in Why Model SOA Solutions? and Models, Diagrams and Views - we need to consider why we are modeling. Our purpose, audience and problem all inuence our decisions and typically result in the use of a number of techniques. For example, consider whether the models you produce will serve as input to a model transformation. What elements does the transformation understand and expect in input models? If you are creating a custom transformation, focusing on a streamlined set of input elements can simplify the transformation design and implementation. Also, what role will sketching play in our modeling efforts? Will we bypass some of the formal diagrams that use SoaML and instead try a more lightweight approach with sketching? We also need to recognize that these approaches can (and should be used in combination). The use of one approach does not preclude the use of another approach. The key here is that we do not want to unnecessarily duplicate information
the group
Page 68 of 261
and effort. We want to use the right approach for the situation at hand, and ideally keep our modeling as simple as possible (...and no simpler). For instance, if we have a situation where we do not have a bi-directional interaction, a choice for modeling the scenario is to use just a simple interface. However, recall that having a bi-directional interaction between participants rules out the use of simple interfaces and leads us toward ServiceInterfaces or ServiceContracts. So we recommend that for consistency sake, a ServiceInterface or ServiceContract is used. These elements scale from simple to more sophisticated use. ServiceInterfaces and ServiceContracts are equally valid approaches to dening these bi-directional service interactions. We could choose to just use one approach or the other. There are resources available that discuss examples from service interface 27 and service contract28 approaches. However, we can also use these two approaches in combination. Published recommendations29 point to two main ways of aligning these modeling approaches: a. Renements: Service contracts, represented as UML collaborations, are used for high-level architecture rather than detailed design. Service interfaces, via components and composite structure diagrams, are used to rene the service contracts. The result is that service contracts are used to model business-level architectures and service interfaces are used to model system-level architectures. b. Views: Consider both approaches as alternate views, both existing at the same level of abstraction. You can pick and choose the representation that makes most sense for the situation. The one exception is that you have to use service contracts to when showing services in a services architecture. Typically an organization will make a choice to focus on one approach. For most organizations, the best choice is to go with the Renements approach. Need REST? SoaML and the examples that we have seen are well suited to traditional service development (using elements such as WSDL, XSDs and SOAP). However, another popular option to consider is the use of RESTful30 web services (where REST is short for REpresentational State Transfer). Some organizations adopt a traditional approach
27 28 29
Amsden Series Casanova whitepaper\presentation
Specifying Services using the Service Oriented Architecture Modeling Language (SoaML): A baseline for Specication of Cloud-based Services, Brian Elvester, Arne-Jrgen Berre, and Andrey Sadovykh
30
Theres a short, concise introductory article discussing REST at InfoQ: http://www.infoq.com/articles/ rest-introduction. Google is your friend for further content on this topic (tutorials, books, articles and presentations).
the group
Page 69 of 261
to services, others have decided that a REST-based approach is their preference, and some organizations nd that they use a mix of approaches31. Both approaches have their strengths and weaknesses, and this typically leads to the situation where an organization uses both types of services. At this point, some questions that pop to mind include: 1) How and when is a decision made on the type of service to create? 2) How should RESTful services be modeled? 3) How should a solution that includes traditional and RESTful services be modeled? Lets start with a quick discussion regarding the rst question. There are many resource available that go into the technical factors and decision points that can help you choose between the approaches. Regardless of the technical factors, we still expect that the decision to create services is in support of realizing business goals. As we look at the different sources for identifying services, we need to consider whether the service is best implemented via traditional approaches or a RESTful approach. Now, lets consider how we model RESTful services. There isnt a standard for modeling RESTful serviecs. SoaML is not the answer. Default UML falls short - again, the curse of being a general purpose language. Luckily, as weve seen with SoaML, UML is highly extensible and Rational Software Architect32 provides a prole for modeling RESTful services. In addition, there are automations that can interpret models that use this prole and generate JAX-RS code for realizing the services. Recall that models that are created using the SoaML prole can serve as input to automations that generate SCA, WSDL and XSD artifacts. Typically, an automation is set up to interpret certain elements with certain markup applied. If the automation doesnt nd the element, or doesnt see the correct markup, then it ignores the element. So having a model that has both SoaML elements and RESTful elements should not cause problems with downstream transformations. However, as a rule of thumb, try to minimize unnecessary overlap.
31
Take a look at this short article from InfoQ that discusses when to which approach. REST and SOAP: When Should I Use Each (or Both)?, http://www.infoq.com/articles/rest-soap-when-to-use-each
32
An introduction to modeling RESTful web services with Rational Software Architect is described in the article: Design and implement RESTful web services with Rational Software Architect: http:// www.ibm.com/developerworks/rational/library/design-implement-restful-web-services/index.html
the group
Page 70 of 261
Sample Bookmark RESTful web service33.
Beyond this rule of thumb, there are some ways in which these modeling approaches come together. Regardless of how the services will be realized, we need to understand the entities that collaborate. A ServicesArchitecture is a useful view to gain that understanding. Dening and documenting the participants and service contracts applies to both web service approaches. With the traditional approach to web services we saw that there were three different service interactions. However, when creating RESTful services, we typically just see one type of service interaction; a simple request-response interaction.
RESTful services follow a simple request-response service interaction. As we saw previously, a Service Contract is a collaboration that shows a number of parts representing service providers and service consumers. Regardless of how we implement the services these roles remain valid. Now instead of dening service provider based on other interfaces or classes, we can create a part based on our RESTful service to play this role.
33
Image is sourced from: Design and implement RESTful web services with Rational Software Architect: http://www.ibm.com/developerworks/rational/library/design-implement-restful-web-services/ index.html
the group
Page 71 of 261
From this point forward we then use the REST prole and model that service. From an architectural point of view we understand who is the provider, who is the consumer, what service is being offered, the resources accessed and the type of access. The following gure, as discussed in the Participant Services Architecture pattern, shows the participants and service contracts from the view of the Manufacturer. Lets focus on the Invoice Customer service contract. What if we had a need to leverage some RESTful services to support this service contract?
RESTful services follow a simple request-response service interaction. As part of the scenario we want to make it possible to provide an ability to work with information related to customers and their orders. To do so, we model the RESTful service as shown in the following diagram.
the
group
Page 72 of 261
A RESTful web service for Customer Orders. And to connect the dots, we create a relationship between the RESTful service and the service consumer within this service contract.
Specify the RESTful service as the provider and show the relationship to the consumer.
Related Domain Specic Languages Weve already looked at SoaML, a DSL for modeling SOA. However, SOA involves the use of some additional DSLs. As we saw in the introduction, a software architect has an important role in collaborating and guiding other roles - such as those found in the business realm. In these interactions, it is helpful for the software architect to be able to speak in the same language as the business. Two business focused DSLs that we will work with include BPMN and the Business Modeling UML Prole. Business Process Model and Notation (BPMN) Business Process Model and Notation (BPMN) is the Object Management Group (OMG) driven standard for Business Process Modeling. Some important terms that are useful for understanding BPMN: A process is a specic ordering of activities with clearly identied inputs and outputs that provide value.
the group
Page 73 of 261
The Business Process (BP) takes an input and creates a business related output that is of value to the organization, its stake holders, or its customers. Business Process Modeling consistently and thoroughly captures information so that those involved in the process can understand the requirements, the output, and their position in providing that output. BPMN represents business models through the use of 4 kinds of diagrams: 1. Process Diagrams: Represents regular ow between tasks, events and decision points to complete a process in the company. 2. Collaboration Diagrams: Represents message ows or communication routes between process or entities like customers or partners. 3. Conversation Diagrams: Represent groups of messages called communications and its relation between process and participants. 4. Choreography Diagrams: Represent participant interaction between task and users or resources and the messages result of this interaction. Rational Software Architect supports three types of BPMN diagrams: Process, Collaboration and Choreography diagrams. RSA and BPMN When using BPMN you can import BPMN diagrams from WebSphere Business Modeler or IBM BlueworksLive. You can also create BPMN models within RSA, or use a combination of approaches. RSA also provides a transformation to convert BPMN elements into SoaML elements. By using a formal DSL, we are able to convert between elements in one language to elements in another language. For SOA, we want to transform elements as captured using BPMN into SoaML elements. The approaches taken to transforming these elements vary. In this section well look at a couple of different approaches. First lets take a look at how the Rational Software Architect provided transformation34 interprets BPMN model elements and generates SoaML model elements: 1. Process to Participant. The participant that is generated is customized based on the properties of the process (interface references in other BPMN models, supportedInterfaces property, etc). 2. Interface to Interface. For each interface in the BPMN model, an interface is created in UML. For any operations dening on the BPMN interface, similar operations are dened on the UML interface. 3. ServiceTask::Operation to Port. A port is generated in the participant of the associated interface.
34
Derived from the RSA help topic: Interpretation of business process model elements by BPMN-to-Service-Model transformations.
the group
Page 74 of 261
4. Operation Messages to Parameter Types: Based on the data type used in messages a parameter type is specied in the UML operation. Note: It is recommended that practitioners use the interactive modeling features of Software Architect for WebSphere as they migrate from BPMN to SoaML-based Service Models rather than the provided BPMN to SoaML transformation. An alternative set of rules35 is summarized as follows: 1. Process to ServicesArchitecture. Participants and service contracts are derived from pools or lanes. Public community-level services architectures occur when there are public and collaborative interactions between different organizations. Private participant-level services architectures occur when there are private business processes under your ownership control. 2. Task to Action. A task most closely aligns to an action element in UML. 3. Sub-process to ServicesArchitecture. Sub-process is more complex than a task, typically translates to a participant-level services architecture. 4. Pool to Participant. As a pool can contain one or more lanes it typically maps to a role in a community-level services architecture. 5. Lane to Participant. A lane maps to a role in a participant-level services architecture. 6. Message begin to Service. The starting point of the data channel between two participants maps to a service port. 7. Message end to Request. The ending point of the data channel between two participants maps to a request port. 8. Process fragment (pattern) to Service Contract. Analyze the business process looking for fragments\patterns that can be mapped to a service contract. Regardless of the approach taken (one of the above, or your own custom approach), successfully dening an SOA solution based on a set of BPMN models requires followon analysis and design.
35
Based on content provided in: Guideline: BPMN to SoaML mapping rules http://epf.thingml.org/wikis/sisas/practice.architecture.service_modelling.base-sintef/guidances/guidelines/ bpmn_to_soaml_mapping_rules_3F5FB601.html?nodeId=bd4f24ba
the group
Page 75 of 261
Business Modeling UML Prole Another DSL that is useful for interacting with business stakeholders and for understanding the business domain is the Business Modeling UML Prole 36. We Using the Business Modeling typically consult a number of different UML Prole sources when we identify services. BPMN Refer to Applying Proles for details modeled business processes provides us on how to add a prole reference to with one source. We can also use the a model in Rational Software Business Modeling UML prole to create Architect. business goals or business use cases. Using multiple approaches in conjunction allows us to more accurately and completely understand the needs of the business and create the right set of services. The following table introduces some of the key elements from the Business Modeling UML Prole. The SOAD Model Accelerator provides patterns to help transform elements from the Business Modeling UML Prole into SoaML model elements.
Overview of Business Modeling UML Prole
Element Business Actor
Stereotype
Business Actor
Icon
Description (Business Modeling Prole

Whitepaper)
Someone or something outside the business that interacts with the business A requirement that the business must satisfy. Invalid to have business goals that are not supported by use cases. Describes a business process from an external, value-added point of view. Typically cut across organizational boundaries and are comprised of a number of workows. A signicant and persistent piece of information that is manipulated by business actors and business workers.
Business Goal
Business Goal
Business Use Case
Business Use Case
Business Entity
Business Entity
36
You can access the Whitepaper that describes the prole via Rational SOMA. An overview of the prole is available at: http://www.ibm.com/developerworks/rational/library/5167.html
the group
Page 76 of 261
Element Business Use Case Realization Business Worker
Stereotype
Business Use Case Realization
Icon
Description (Business Modeling Prole

Whitepaper)
Describes how business workers and entities collaborate to perform a business use case. An abstraction of a human or software system that represents a role participating in business use case realizations.
Business Worker
the
group
Page 77 of 261
Part III. Pattern Reference
the
group
Page 78 of 261
Introduction The SOAD Model Accelerator provides a set of UML Patterns. They guide you to use best practices, are self-documenting, automate the creation of model elements, Applying UML Patterns support traceability and via the use of This reference section focuses on constraints and reports feed into governance the patterns themselves and shows efforts, design reviews and a better examples of them being used. For a understanding of the design. quick summary of applying patterns in Rational Software Architect, The following gure provides a listing of the consult the section Applying UML patterns provided by the Model Accelerator. Patterns. The patterns are applied via drag and drop, with easy mapping (and generation) of model elements. The patterns are available via the Pattern Explorer view and are categorized to simplify access and selection.
Patterns provided by the SOAD Model Accelerator
As an organization and individual, you will need to determine which patterns to use. There is no one-size-ts-all approach to pattern consumption. The needs of the situation, that is, your current context, will determine the patterns to use. Following SOMA or SiSaS will lead you to situations where the possible patterns to select from is
the group
Page 79 of 261
reduced (possibly down to one or two choices). Weve categorized the patterns in the Pattern Explorer to map directly to the main phases discussed in SOMA (Business Modeling, Service Identication and Service Specication). SiSaS activities have an alignment with SoaML element types (and diagrams). In naming the patterns weve highlighted the SoaML elements that participate in the pattern. In this way, you can map the patterns to the activities from SiSaS. If you have a custom process, or wish to reorganize the how the patterns are presented you can create and modify the categorization within the Pattern Explorer. We can also use some of the guidelines from Patterns-Based Engineering to help us succeed with patterns. Some guidelines to consider include: Pattern Selection Driven byRequirements: How do we determine what patterns should be selected and used on a project? Use a combination of functional and nonfunctional requirements as a guide in selecting the patterns to use. Refactor with Patterns: How do we improve an existing solution to align with best practices? Refactor the existing solution using patterns as the means and endpoint for the updated solution. Communicate Design withPatterns: Use patterns to describe and communicate key design aspects of a solution. Use Pattern Denitions to Understand ExistingSolutions: How do we quickly understand an existing solution? Is it well built? Has it stayed true to the design? Using a set of known pattern denitions, search the solution for occurrences of the patterns. Business Modeling The raison dtre for SOA is to provide business agility and exibility. Driving service creation efforts from our business domain is a critical requirement for successful SOA solution delivery. There are a number of ways in which we can capture details about the business and in turn start to identify services. Regardless of the approach taken, our focus in business modeling is to: 1. Understand the current business 2. Understand areas for improvement 3. Identify what should be improved 4. Assess the impact of organizational change 5. Ensure a common understanding of the business 6. Maintain business rules From an SOA perspective, the key is that we are able use business modeling efforts to support successful Service Identication. Candidate services can be identied from: Business Processes (as discussed in BPMN) Business Models Business Goals
the group
Page 80 of 261
Business Rules Business Use Case Models Domain Models Business Functional Models Existing Assets The SOAD Model Accelerator complements the out-of-the-box experience, providing support for the Business Modeling UML Prole (Business Goals, Business Use Cases, Business Workers) and Domain Models. The following table provides an overview of the Business Modeling patterns.
Overview of Business Modeling patterns.
Pattern Name Business Entity Promotion Business Goal Decomposition
Description Starting with Business Entities the pattern generates Candidate Services, potential Participants, message types and information types. Sometimes our business goals are too broad in scope to be acted upon. To simplify understanding, analysis and implementation - we subdivide or decompose the high-level goal into a number of subgoals. Guides the practitioner to consider the key elements that comprise a business scenario (Business Goal, Use Case, Scenario, Actors and Workers). With this set of elements dened, the pattern then generates a Use Case Realization. Migrate to Service Identication by using the responsibilities as identied within Use Case Realization Interactions as the basis for a Candidate Services.
Structured Business Driven Scenario
Use Case Realization Promotion
the
group
Page 81 of 261
Business Entity Promotion
View of the pattern instance
During business modeling efforts, we identify and model a number of business entities. Those key concepts from the business domain - concepts that the system must process, including in messages and persistence. The Business Entity Promotion pattern assists us in leveraging this analysis work and generates related constructs in our Service Identication model. Problem Weve reached a point in our Business Modeling efforts where we have identied a number of Business Entities and we want to use these elements as a basis for a transition into Service Identication. How do we take a set of Business Entities and leverage the investment to accelerate our transition to Service Identication? More specically, how can we use the Business Entities to identify Candidate Services, potential Participants, message types and types that need to be persisted? Solution Basic Candidate services can be identied from domain business elements. These elements are the key ideas\nouns that we persist - as found in a domain, logical data model, or a business model. At a minimum, we want to provide access to these entities to other services and provide basic CRUD operations. In addition, we can generate a set of Parameter and Info types to assist in crafting messages and objects related to persisting information about our key entities. Heres an initial look at the Pattern Instance - note that we have four parameters.
the
group
Page 82 of 261
The pattern has four parameters
1. Business Model Package: The base package that contains the Business Elements. This is a required parameter. Elements within the package must either have the BusinessEntity stereotype applied or else the domainType keyword. 2. Service Identication Package: The target package that will be used to contain the generated Service Identication elements. This is a required parameter. 3. Create Parameter Types: We can generate a set of parameter types based on the Business Entities. Each business entity leads to the generation of a corresponding parameter type. These types are typically used when dening the service messages. By default, no action is taken. Set the parameter to true to generate the Parameter Types. 4. Create Info Types: We can generate a set of Info types based on the Business Entities. Each business entity leads to the generation of a corresponding Info Type. These types are used as we interact with the persistence layer. By default, no action is taken (i.e. default value is false). Set the parameter to true to generate the Info Types. Example Heres a look at some business entities that we have identied. Relationships have also been captured and added to the diagram.
the
group
Page 83 of 261
A set of related Business Entity (with domainType keyword applied) elements.
All of these elements are currently placed within the BusinessEntities package of our Business Model. Note that in this example weve applied the domainType keyword. As an alternative, we could have used the BusinessEntity stereotype.
All of the business entities are within a package
We want to take the next step and use these entities as a starting point for candidate service specications - also known as Capabilities. The next gure shows the Project Explorer and that we have our domainType elements in the BusinessEntities package and that the BEP-Target package is currently empty.
the
group
Page 84 of 261
View within the Project Explorer before applying the pattern
The following image shows the pattern instance, the package that contains the Business Entities, the package where we want to put the Capabilities and also one of the domainType elements.
Pattern instance and some of the elements to be bound
We start to apply the pattern by binding the rst two parameters to the pattern.
the
group
Page 85 of 261
View when rst two mandatory parameters are bound
At this point, if we did not need parameter or info types, our work would be done. We have successfully used the pattern to take a set of Business Entities and create a corresponding set of Capability elements. The following gure shows the updated elements shown in the Project Explorer.
Updated view of elements in the Project Explorer Figure 44 View of the Project Explorer and the Capability elements that were generated.
the group
Page 86 of 261
However, if we require InfoTypes or ParameterTypes, we can continue working with the pattern and add values for the remaining two parameters. Two new packages are added to the model: Info Types and Parameter Types. These new packages contain the infoType and parameterType elements. These new elements are derived from the domainType (or BusinessEntity). The attributes and relationships that exist in the business entities are recreated for these new elements.
View of relationships and each of the three types of elements that are generated.
The next gure takes another look at the Project Explorer view and we can see the new elements that have been generated.
the
group
Page 87 of 261
Updated view of elements in the Project Explorer
The next diagram looks at the infoType elements that were created. We can see that the appropriate attributes and relationships have been created. The following diagram provides a similar look at the parameterType elements.
the
group
Page 88 of 261
Relationships and attributes of the generated infoType elements
Relationships and attributes of the generated parameterType elements
the
group
Page 89 of 261
Moving forward we would perform further analysis on the generated elements. This includes renement of the elements, Service Litmus Tests, and consolidation/ decomposition as needed. Related Accelerator Components Capability Consolidation: If this pattern leads to too many ne-grained Capabilities we can use Capability Consolidation to lead us toward more coarse-grained Capabilities. Business Goal Decomposition
Instance of the Business Goal Decomposition pattern
Sometimes our business goals are too broad in scope to be acted upon. To simplify understanding, analysis and implementation - we subdivide or decompose the highlevel goal into a number of subgoals. This effort to subdivide into more manageable goals can be carried out to multiple levels. In performing this effort, we must ensure that we maintain traceability between a Business Goals and each of its subgoals. Without having a proper set of business goals, that are well dened, understood along with an understanding of KPIs and metrics for measuring success - our SOA solutions cannot be business aligned, nor successful. Problem How can we quickly and easily set up a hierarchy of business goals - creating relationships between parent goals and subgoals? Solution We use the Business Goal Decomposition pattern to guide us in creating relationships between Business Goals and their subgoals. These relationships help us to work toward a level of goals that are actionable and measurable.
Pattern has two parameters

the group
Page 90 of 261
This pattern has 2 parameters: 1. Business Goal: This is the parent or main Business Goal. The parameter must be based on the Business Modeling prole Business Goal element. This is a mandatory parameter. 2. Subgoal: This is a sub or nested goal. It also uses the Business Goal element from the Business Modeling prole. Each parent business goal will have one or more subgoals when working with this pattern. This is a mandatory parameter. Example We have a meet with one of our Business Analysts to gain an understanding of the business goals. We want to make sure that coming out of this meeting we have identied an actionable set of goals. To help us capture this information, we use the Business Goal Decomposition pattern. To get started we add the pattern instance to a diagram.
Start by creating an instance of the pattern.
The discussion starts quite high-level, noting that our main goal is to reduce costs. We hover the mouse pointer over the Business Goal parameter and select the text entry option. This allows us to quickly create and bind a new Business Goal to the pattern.
We can use the pattern to help create model elements.
We then type in the name of this rst main goal: Cost Reduction.
the
group
Page 91 of 261
Typing in the name leads to the creation of a new Business Goal.
And a new Business Goal is added to the model (youll see it in the Project Explorer view). We can add the new Business Goal to the diagram.
Initial high-level business goal
We update the view and show the properties associated with the BusinessGoal stereotype.
Performance and measurement details for the goal

the group
Page 92 of 261
Although we have detailed the goal in terms of performance and measurement information, this goal is still too high-level to be actionable. We continue the discussion with our Business Analyst. Asking probing questions, we determine that there are related subgoals. We add these two our model, following the same steps used when adding the rst goal. The only difference is that this time we hover the mouse pointer over the Subgoal parameter. We add two subgoals: Reduce Order Costs and Reduce Shipping Costs.
Initial set of subgoals
Typically, we want to have three to seven levels of goals, to reach a point where the goals are actionable. So we continuing the discussion with the Business Analyst. In reviewing the Reduce Order Costs goal, we discover that this can be further decomposed. We create another instance of the Business Goal Decomposition pattern, this time we use Reduce Order Costs as the Business Goal and specify two subgoals: Eliminate Order Retyping and Reduce Fraudulent Orders.
the
group
Page 93 of 261
Next level of subgoals
We create a new diagram and clean up the layout to improve the readability of the diagram. We review the resulting set of goals and the hierarchical relationship with the Business Analyst.
Hierarchy of business goals
Related Accelerator Components Related components include the Goal Service Model Report, the Structured Business Driven Scenario pattern and the Business Goal Constraint - Performance and Measurement.
the group
Page 94 of 261
Structured Business Driven Scenario
Some of the main constructs in Business Modeling include Business Goals, Business Use Cases, Business Actors and Business Workers. But how do we use these elements to help us analyze and understand how to realize business goals? Typically, we create Use Case Realizations, including the analysis of a number of scenarios within the boundaries of the use case. Problem We want to move forward in understanding how business elements work together to realize business goals. In analyzing a scenario related to achieving a business goal via the realization of a business use case, what model elements need to be created? How are they related? How do we best position ourselves for follow on work? How do we ensure the proper relationships are created? Solution To successfully analyze business needs via a business model, a number of model elements need to be dened. Once dened, interactions, details and relationships are added to the elements. Starting from scratch can be daunting - while written documentation and manually implemented solutions can be tedious and error prone. The Structured Business Driven Scenario pattern guides the practitioner to consider the key elements that comprise a business scenario - including a Business Goal, Use Case, Scenario, and a collection of Actors and Workers. With this set of elements dened, the pattern then generates a Use Case Realization where the practitioner can then focus on dening he messages that are passed between the scenario participants. The pattern also generates the appropriate relationships between the specied elements - highlighting the connections and ensuring that business goals are driving our analysis. This serves us well in later efforts as we can evaluate the services that have been identied\specied and are able to trace these elements back to the driving business goal. This is a key aspect of Goal-Service modeling.
the group
Page 95 of 261
Pattern has ve parameters
There are ve parameters associated with this pattern: 1. Business Goal: Represents the goal that the business needs to achieve. This is a mandatory parameter. 2. Business Use Case: Typically one or more use cases are used to realize a business goal. This pattern focuses on an individual use case and is a required parameter. 3. Scenario Name: A Use Case will use one or more scenarios to handle the different paths through the use case (normal, exceptional, error, etc). The pattern requires 1 scenario name to be provided. 4. Business Actor: Actors are the external to the system and are a role lled by people or another system. This is a mandatory parameter. 5. Business Worker: The people or systems that participate in realizing the scenario. This is a mandatory parameter. Example We start out with a set of Business Goals for the Manufacturer. Weve updated the set of goals a little beyond what we saw when discussing Business Goal Decomposition weve added a new goal Improve customer response time.
Initial business goals

the group
Page 96 of 261
Were going to focus on Improve customer response time
The Manufacturer, provides nancing to its customers and an important Business Use Case is Apply for a loan. This use case can help us to achieve the business goal of improving customer response time.
Use case that well use to help drive analysis
The main business Business Actor is the Customer.
An actor that participates in the use case
And we have a handful of Business Worker elements that help us to realize the Business Use Case.
Set of business workers that help us to realize the use case
We add the pattern instance to our diagram.
the
group
Page 97 of 261
Pattern instance that well use
And then bind parameters to the pattern instance.
View of the pattern instance and the bound parameters
After binding the parameters, we can update our diagram and view the relationships between the pattern instance and its parameters.
the
group
Page 98 of 261
Relationships between the pattern and its parameters
Next, we examine the Project Explorer and notice that a number of new elements have been added to the model, including a Business Use Case Realization, an Interaction (which uses the name of the scenario (Scenario1) and a number of lifelines based on the Business Actor and Business Worker elements.
the
group
Page 99 of 261
Updated Project Explorer view
We update the diagram to include relationships related to the Business Use Case and we also add the Interaction that is associated with the Business Goal. At this point, we can focus on the messages that are needed to realize the behavior (which in turn will be used to drive the creation of capabilities (that is, candidate services). If desired we can use the Interaction as the basis for a new Sequence diagram, or we can edit the Interaction directly on the diagram.
Generated Relationships, Use Case Realization and Scenario
the
group
Page 100 of 261
And taking a closer look at the Interaction we can see that it has been pre-populated with the appropriate lifelines.
The pre-populated interaction
Typically a Business Use Case will support multiple scenarios that will be examined in our realization efforts. To add another scenario, add another instance of the pattern to the diagram, bind the parameters (using the same Business Goal, same Business Use Case and likely the same Business Actor), varying the Business Worker as necessary and also provide a new and unique Scenario Name. As a result a new Interaction will be created under the Business Use Case Realization using the new Scenario name. Related Accelerator Components This pattern serves as input to the Use Case Realization Promotion pattern. This pattern also helps to set the stage for Goal-Service Model reporting. Use Case Realization Promotion
Weve already spent time creating a set of Use Case Realizations. In doing so we have gured out how our Business Actors and Business Workers support the Business Use Cases, and in turn, support our Business Goals. We use these Use Case Realizations to seed an initial set of candidate services (SoaML::Capability)
the
group
Page 101 of 261
Problem How do we leverage the investment weve made in business modeling and create initial versions of our candidate services (SoaML::Capability)? Solution When analyzing the Use Case Realizations we discover the interactions between key business elements (Business Actors and Business Workers). In doing so, we see the responsibilities that these elements take on. To migrate to Service Identication we will use the responsibilities as identied within the Interactions for each Use Case Realization as the basis for a Candidate Service. This is a rather mechanical transition, but an important step. The importance stems from a change in mind set (i.e. we have an understanding of the business) as well as taking a step closer to creating our services. After applying the pattern, we can now focus our efforts on making sure that we have the right set of candidate services (SoaML::Capability) and that they have the right responsibilities.
The pattern has two parameters
This pattern has two parameters: 1. Use Case Realization: Provide a use case realization that contains 1 or more scenarios as captured via Interactions. This is a mandatory parameter. 2. Candidate Service Package: This package will be used as the target for new elements that are created. This is a mandatory parameter. Example Recall that when we nished with the Structured Business Driven Scenario pattern, we had brought together a Business Use Case to realize a Business Goal. In doing so, we connected the Business Goal, Business Use Case, and then created a Use Case Realization with a Scenario and Lifelines that used the associated Business Actor and Business Case Workers.
the
group
Page 102 of 261
Recall the elements and relationships already created
Typically the next step in the workow is to dene the messages between the participants in the interaction.
Further analysis completed has led to messages being modeled
Based on this interaction, some of our Business Workers are updated.
Updated Business Workers
Once we have detailed the messages - we are well positioned for identifying some of the capabilities that the system will need to support. A simple step for moving forward is to create a capability for each message. Lets use the Use Case Realization Promotion pattern to help us.
the
group
Page 103 of 261
Add the pattern instance to the model
The elements we will use as pattern parameters are shown in the following gure (and should be familiar)
The pattern instance and the elements to be bound
The next gure shows that we have bound the parameters to the pattern instance. Notice that the name of the TargetPackage was updated to align with the name of the Use Case Realization (and the Catalog stereotype was applied).
the
group
Page 104 of 261
View after parameters have been bound
We can examine the relationships between the pattern and its bound parameters.
Updated relationships and model elements
The pattern also generates a sub-catalog for each scenario that has been dened under the Use Case Realization. In this case we only have one Scenario. For that scenario, there were three messages - so three Capability elements are created. Moving forward, we would review the generated Capabilities and adjust the names as appropriate to reect that they should be starting to sound like service names, rather than message names.
the
group
Page 105 of 261
Generated Capability elements within the Catalog
In using this pattern along with the Structured Business Driven Scenario we ensure that our Business Goals are supported by one or more services - a key aspect of GoalService Modeling.
Traceability from the Business Goal through to the Capability
Related Accelerator Components Capability Consolidation: If we nd that this pattern leads to too many ne-grained capabilities we can use Capability Consolidation to create more coarse-grained capabilities. Also, take a look at Service Decomposition37 . Service Decomposition is used to handle the situation where our service has too many responsibilities and needs to be decomposed.
37
http://www.soapatterns.org/service_decomposition.php
the group
Page 106 of 261
Service Identication The goal with Service Identication is to create an initial set of candidate services and their initial responsibilities. In doing so, we ensure that our efforts are business aligned and that the resulting services satisfy the needs of the business. If you are familiar with traditional Object-Oriented Analysis and Design (OOAD), a useful analogy is to think of the candidate services identied in this phase as analysis classes, and the work done in Service Specication leading to design classes. Typically we would use the Business Entity Promotion and Use Case Realization Promotion patterns to seed our service model as we start on Service Identication. As we perform our Service Identication analysis we will augment, streamline, merge and remove Capabilities (candidate services). The following table provides an overview of the Service Identication patterns.
Overview of Service Identication patterns.
Pattern Name Capability Consolidation
Description Take the responsibilities of one or more negrained Capabilities and move them to a more coarse grained Capability. Takes a model with a set of conrmed Capabilities and generates a set of ServiceInterfaces. Creates a Usage dependency between an originating and set of target Capabilities. Service Catalog is used to put together a Catalog along with a means to classify solution elements within that catalog. This is useful for understanding the role and purpose of services within the solution. Elements within the SOA solution should be categorized. This pattern simplies the creation of relationships between a Category and one or more model elements.
Capability Promotion
Capability Usage Service Catalog
Service Category
the
group
Page 107 of 261
Capability Consolidation
Recall that according to the SoaML specication: A Capability identies or species a cohesive set of functions or capabilities that a service provided by one or more participants might offer. Capabilities are used to identify needed services, and to organize them into catalogues in order to communicate the needs and capabilities of a service area, whether that be business or technology focused, prior to allocating those services to particular Participants. In simpler terms, we can consider a Capability to be a candidate service. And as we move into Service Identication, we start to prepare our Capabilities for the transition to Services. A nice analogy for this effort is the transition from Analysis to Design found in ObjectOriented Analysis and Design (OOAD). Capabilities (candidate services) are much like the analysis classes of OOAD. As we move from Analysis to Design, some of the classes merge, some are enhanced, some carry forward as-is, and some disappear. One issue that we may nd as we review our Capabilities and consider how they transition to services is that some may have too few (or too many) responsibilities. In the case where we nd Capabilities that have too few responsibilities, it might make sense to merge them together into a more coarse grained representation. Problem In addition to having Litmus tests to determine which Capabilities warrant further investment, we may also nd that the Capabilities have too few responsibilities. How do we handle the case where we want to reduce the number of Capabilities while ensuring that the responsibilities move forward? The challenge is to nd the right level of granularity for each service. Capabilities that have too many responsibilities are less reusable. Having too many Capabilities with too few responsibilities leads to additional development, testing and governance work.
the group
Page 108 of 261
Our goal is to specify a set of Capabilities where each Capability has the right number of responsibilities. Each Capability has a set of responsibilities that is cohesive and makes the service meaningful, maintainable, and reusable. Solution Take the responsibilities of one or more related, ne-grained Capabilities and move them to a more coarse grained (and still cohesive) Capability. To support traceability, a trace relationship is created from the coarse grained Capability to the Capabilities from which it gained responsibilities. The Capabilities that no longer have responsibilities are moved from the catalog to another package that is not going to be migrated to service specication.
The pattern has two parameters
This pattern has two parameters: 1. Target Capability: This is the Capability that is the target for the responsibilities that are being transitioned from the ne-grained Capabilities. This is a mandatory parameter. 2. Fine-Grained Capability: One or more ne-grained Capabilities need to be specied. The responsibilities from these Capabilities will be transitioned to the Target Capability. This is a mandatory parameter. Example We have already recognized a number of related Capabilities as shown in the following diagram.
the
group
Page 109 of 261
The capabilities within the Support Catalog
In reviewing the Capabilities, we see that there are too many ne-grained capabilities. That is, they have too few responsibilities. To simplify the path forward we want to eliminate the ne-grained Capabilities and push their responsibilities onto a more coarse-grained Capability that will move on to Service Specication activities. We bind the parameters to the pattern.
Parameters bound to the pattern.
And here is the updated diagram showing the movement of responsibilities between the capabilities. We see that the parameters bound to Fine-Grained Capabilities (in this case Refunds and Exchanges) are no longer considered Capabilities (and the stereotype has been removed from those elements). They have also been moved to a new package called Consolidated (not a Catalog) that will not be moving forward to Service Specication. And last, but not least, a derive relationship has been added to highlight that CustomerService now derives the functionality that was originally mapped to the Exchange and Refunds Capabilities - ensuring that traceability is maintained.
the
group
Page 110 of 261
View of updated model elements and relationships.
Related Accelerator Components Capability Promotion - once we are satised with the granularity of a set of Capabilities within a catalog, we can use the Capability Promotion pattern to move to Service Specication. Also, take a look at Service Decomposition38 . Service Decomposition is used to handle the situation where our service has too many responsibilities and needs to be decomposed.
38
http://www.soapatterns.org/service_decomposition.php
the group
Page 111 of 261
Capability Promotion
The pattern instance
The Capability Promotion pattern is used at the completion of Service Identication (also seen as the beginning of the Service Specication) activity. At this point in our development efforts, we have identied a number of potential services - which we have called Capabilities. With a set of Capabilities identied we perform a Litmus test - to determine which Capabilities warrant investment. With a conrmed set of capabilities in hand, we want to move forward and start to specify the services. The Litmus test is quite simple at this point - but will be revisited in Service Specication, at which time we will use more indepth criteria and formal approaches. To accelerate the effort and reduce the manual steps, the Capability Promotion pattern takes a model with a set of conrmed Capabilities and generates a set of ServiceInterfaces. In doing so, it preserves the naming and operations that have been identied. This saves the designer from having to recreate all of the Candidates as ServiceInterfaces. In addition, traceability links are added to the model - ensuring that we understand the origins of our ServiceInterfaces. Problem With a set of Capabilities identied, analyzed and vetted - we need to move to Service Specication. How do we make the transition to Service Specication while minimizing mechanical steps and ensuring traceability? Solution The Capability Promotion pattern accepts a package that contains a set of Capabilities (which could contain a set of nested packages). For each Capability found, the pattern will create a new ServiceInterface in the target package - typically found in the Service Specication portion of the model. When creating the new elements, the pattern preserves the package structure and also adds Expose relationships between the ServiceInterface and the Capability. This highlights the connection between the elements and also supports us in being able to trace from a ServiceInterface to the Capability from which it originated.
the group
Page 112 of 261
The pattern has two parameters.
This pattern has two parameters: 1. Service Specication Package: A package that contains a set of Capability elements (and possibly nested packages). This is a mandatory parameter. 2. Service Specication Package: This is the target package where generated ServiceInterface elements will be placed. This is a mandatory parameter. Example We start by looking at the model elements already created and shown in the Project Explorer. We see that a number of packages have been created - containing many Capability elements. These Capability elements are our candidate services. We performed a number of evaluations (Litmus tests) to determine which warrant investment and further analysis as service specications.
View of the Catalogs and Capabilities
Heres a closer look at some of the Capabilities - highlighting their relationships and some of the responsibilities that have been identied.
the
group
Page 113 of 261
Closer look at some of the capabilities
We take a rst step in applying the pattern by adding an instance of the pattern to a diagram. Weve also added the two items that we are going to use as parameters.
Preparing for applying the pattern.
We bind the parameters to the pattern instance.
Parameters are bound to the pattern.
We now have an updated set of model elements in the Project Explorer view.
the
group
Page 114 of 261
Project Explorer view after applying the pattern.
Taking a closer look at a few elements, we see that Invoicing was promoted and an Expose relationship has been created between the Capability and the ServiceInterface. Also, the relationships between the pattern and its parameters added.
View of structure, new element, Expose relationship and traceability

the group
Page 115 of 261
Related Accelerator Components At a minimum, consider the use of the Capability Consolidation pattern before using the Capability Promotion pattern. The use of model validation including Capability Catalog Constraint and Capability Responsibility Constraint should be used before using the Capability Promotion pattern. Capability Usage
The pattern instance
The Capability Usage pattern is used during Service Identication as we work with and rene our identied potential services (Capabilities). Capabilities can, and should, have usage relationships dened to indicate how the capabilities are related. Problem With a set of Capabilities identied, how do we specify relationships between related Capabilities? Solution The Capability Usage pattern accepts a set of Capability elements. The rst parameter, the Originating Capability, is used to specify the Capability that is related to one or more other Target Capability elements. The pattern creates Use dependencies from the Originating Capability to each of the Target Capability elements.
This pattern has two parameters: 1. Originating Capability: A Capability that we want to use as the origination point for a set of Use dependencies. This is a mandatory parameter.
the group
Page 116 of 261
2. Target Capability: These are the target Capability elements that the Originating Capability uses. This is a mandatory parameter. Example We start by looking at the model elements already created and shown in the Project Explorer. We start by looking at a set of Capability elements that have already been created in our model (either manually created or generated via use of one of the other patterns).
View of the Capabilities
Having identied the set of capabilities is a good start - but what if we also want to show that there is relationships between some of the Capabilities? More specically, lets add Use dependencies between these Capabilities showing the relationships between them.We start by adding the Capability Usage pattern instance to our diagram.
Closer look at some of the capabilities
In this case, we want to show that Order Processing uses the other Capabilities. So we bind Order Processing to the Originating Capability parameter of the pattern instance. We then take each of the remaining capabilities and bind them one at a time to this same pattern instance.
the
group
Page 117 of 261
Preparing for applying the pattern.
After we have completed binding the pattern parameters, we end up with a set of use dependencies created from the Originating Capability to each of the Target Capability elements.
Parameters are bound to the pattern.
And completing the view of what was generated, we can update the diagram to show the traceability links that are created from the pattern instance to each of the pattern parameters.
the
group
Page 118 of 261
Project Explorer after applying the pattern.
Related Accelerator Components Related patterns, at a minimum include Capability Consolidation and Capability Promotion. We should also consider use of Capability Usage pattern after having used the Business Entity Promotion and Use Case Realization Promotion patterns. The use of model validations including Capability Catalog Constraint and Capability Responsibility Constraint should also be considered. Service Catalog
The pattern instance.
A Service Portfolio is a best practice that organizations use to understand service classication and availability. Having a portfolio leads to better reuse, less waste and a
the group
Page 119 of 261
more thoughtful approach to service creation. Typically, organizations will have at least two Service Portfolios, one for Candidate Services and another for those services that have already been created. The Service Portfolio then becomes a key part of the design-time and run-time governance efforts. SoaML helps us dene Service Portfolios with the Service Catalog, Category and Categorization elements. Once we have created a Service Catalog, we then specify a set of categories for classifying elements. Some options for classication categories include Entity, Task and Utility 39 Business Service, Enterprise Service, Application Service, Infrastructure Service 40 Bus Services (Infrastructure) (which can be further classied as Communication Services or Utility Services), Application Services (which can be further classied as one of Entity Services, Capability Services, Activity Services or Process Services)41. User Interaction Services, Application-Specic Services, Process Integration Services, Information Integration Services, Business Services, Infrastructure Services42.
Service Portfolio classication categories as recommended by Rational SOMA.
Problem How can we quickly and easily create a Service Portfolio with a set of categories?
39 40 41 42
Thomas Erl, SOA Design Patterns, Prentice Hall, January 2009 Creating an Effective SOA Service Taxonomy Ontology and Taxonomy of Services in a Service-Oriented Architecture Rational SOMA
the group
Page 120 of 261
Solution The Service Catalog pattern streamlines the service portfolio conguration. The pattern supports the creation of a set of custom categories, the default SOMA categories or a combination thereof.
The pattern has four parameters.
This pattern has four parameters: 1. Catalog: The main package representing the catalog. This is a mandatory parameter. 2. Custom Category: Specication of one or more categories based on corporate or other industry best practices. This is an optional parameter. 3. Default Categories: Indicate whether you would like the default, SOMA-suggested, categories created within the Catalog. Mandatory parameter, default value provided is False. 4. Subcatalog: One or more packages to use as subcatalogs. This is an optional parameter. Example Typically, we set up a Candidate Service portfolio and a Service portfolio. In each case, we want to set up the same classication categories. Lets take a look at an example for setting up the Service portfolio. In this example well show the simple scenario of using the Rational SOMA suggested categories. We create an instance of the pattern and bind values to the pattern parameters. For this example well just need to use two of the parameters: Catalog and Default Categories. As shown in the following image, we create a Catalog called Service Portfolio and specify True as the value for the Default Categories.
the
group
Page 121 of 261
In this case we specify a name for the Catalog and indicate that we want the SOMA suggested Categories.
As a result of applying the pattern, our model is updated. The Catalog called Service Portfolio is created and within that catalog we nd a set of categories. The next step is to use those categories to categorize the elements in our model.
Diagram shows the Catalog and Category elements that were created.
Related Accelerator Components Related components include the Service Category pattern and a number of constraints including: Catalogs should have categories Capabilities should have multiple responsibilities Catalogs contents are limited to organizational elements Capabilities should be categorized Categories should be placed within Catalogs Categories should be used to categorize model elements
the
group
Page 122 of 261
Service Category
So weve dened a Service Portfolio via a Catalog and a set of Categories. The next step is to make sure that we are using these categories to categorize the Services in our model. Problem How can we quickly and easily categorize our services through the proper use of Category elements? Solution The Service Category pattern is typically used after we have already created our service portfolio infrastructure via the use of the Service Catalog pattern. Now that we have the infrastructure in place, we use the Service Category pattern to create categorization relationships between a Category and a set of elements.
This pattern has two parameters: 1. Category: The Category that is to be used for categorizing a set of elements. This is a mandatory parameter. 2. Element: The elements that are to be categorized. Typically this is a service (via one of the SoaML representations). However, you can use this pattern with a range
the group
Page 123 of 261
of elements. It all comes down to what you want to categorize within your catalogs. This is a mandatory parameter. Example In this example, well pick up where we left off with the Service Catalog pattern. That is, weve already created a Service Portfolio that uses the categories as suggested by Rational SOMA. The following image shows the catalog and categories that have been created.
A look at a catalog and the available Categories.
Elsewhere in our model, weve dened a set of Service Interfaces as shown in the following image.
The ServiceInterface elements that we want to categorize.
We need to make sure that we are properly categorizing these services. To get started we create an instance of the pattern and bind the category that we want to use.
the
group
Page 124 of 261
So far, we only specied the Category.
Next we bind the service interface elements to the pattern instance.
The pattern with model elements bound to its parameters.
The pattern creates categorization relationships between the category and the elements. This relationship is key for setting up the service portfolio. We do not place the services themselves into the Catalog package. The categorization relationship allows us to have our services organized in our model according to technical or business needs, while still having structure via the categories and catalog.
the
group
Page 125 of 261
Complete set of elements with relationships.
Related Accelerator Components Related components include the Service Category pattern and a number of constraints including: Catalogs should have categories Capabilities should have multiple responsibilities Catalogs contents are limited to organizational elements Capabilities should be categorized Categories should be placed within Catalogs Categories should be used to categorize model elements Service Specication In previous phases, weve had a very strong focus on understanding the business and potential services. Weve been primarily concerned with understanding the problem domain and setting up a foundation for organizing services.
the
group
Page 126 of 261
In service specication, we adjust our focus and now look primarily at the solution space. In doing so, we dene our services with an architectural mindset which includes: Detailing the specications for the services that are being created. Specifying how those services interact from both a providing and consuming point of view. Detailing the messages associated with the services. Rening the model to the level of detail necessary to support communication with other architects, developers and to serve as input for transformations. Ensuring that we are building the right services the right way. In this phase, we also start to use much more of the SoaML language. And as mentioned earlier well be using UML2 features such as structured classiers and collaborations. The SOAD Model Accelerator assists the practitioner in using SoaML and these UML2 language features - simplifying the modeling effort. In total there are seventeen patterns to support service specication. To make it easier to nd the right pattern weve created a set of sub-categories (message design, participant design, service contract design, and services architecture design). The following table provides an overview of the general Service Specication patterns. Follow-on sections will detail each of the Service Specication sub-categories.
Overview of Service Specication patterns.
Pattern Name Collaborating Interface
Description To support bi-directional service interactions, we need to be able to specify provided and required interfaces and detail a protocol for the interaction. Quickly and easily update the package names within our model to support solution creation and deployment. Evaluate the constraints such as time, costs, business t, available resources, and technical concerns to determine candidate services that will end up being created.
Domain Prex
Service Litmus Test
Collaborating Interface
the
group
Page 127 of 261
With the Collaborating Interface pattern we can dene a class that requires and provides certain interfaces. We can use this approach when working with either a ServiceInterface or a ServiceContract based approach to service modeling. An example showing the use of this pattern with ServiceContract elements was shown earlier in the section Service Contract Based Approach. When specifying a service, we may nd that we are dealing with a simple requestresponse interaction.
A simple request-response service interaction.
In such a case, there is no additional required interfaces, no need to dene protocols. And we can use the simple elements from the Services and Class drawers of the palette within Software Architect for WebSphere.
A simple service interface.
the
group
Page 128 of 261
However, we often nd a situation where a more sophisticated approach is needed for specifying our service interface. In such cases, there is a need to support a bidirectional service interaction.
More sophisticated, bi-directional service interaction.
In such situations we need to be able to specify provided and required interfaces and detail a protocol for the interaction. This presents challenges not only in properly designing the Service Interface\Service Contract - but also in remembering how all of the elements come together within the modeling environment. At the end of the effort, we want to detail the interfaces provided, those used, and the associated protocol. The following image provides an example of doing so for a ServiceInterface.
the
group
Page 129 of 261
Model elements to support a more sophisticated bi-directional service interaction.
Problem How can we dene a Service Interface\Service Contract that supports a bi-directional service interaction? And how can we detail that denition so that the behavior of the Service Interface\Service Contract is clear? Solution The Collaborating Interface pattern guides us in dening a Service Interface\Service Contract that supports a bi-directional service interaction. As part of this denition it creates relationships supporting provided and required interfaces. In addition, the pattern generates an associated Activity with partitions and activities so that the protocol for this bi-directional behavior can be specied.
the
group
Page 130 of 261
The pattern has three parameters.
This pattern has three parameters: 1. Collaboration Coordinator: A class-based element (typically a Service Interface or a Service Contract) that provides and requires interfaces. This is a mandatory parameter. 2. Provided Interface: One or more interfaces that are provided. This is a mandatory parameter. 3. Required Interface: One or more interfaces that are required. This is a mandatory parameter. Example We saw this pattern being used in the section Service Contracts: Beyond Two Participants. In this section well take a closer look at applying the pattern and the results of doing so. We start by recognizing that we are dealing with a bi-directional service interaction. We have a set of model elements that we want to use together to support this service interaction. So far, this set of model elements includes a class and a set of interfaces. We want to clearly model the interface that denes the service provided and also the interface that the service requester is required to support on their end of the interaction.
The class that will play the Collaboration Coordinator role.
the
group
Page 131 of 261
One of the interfaces that will participate in this collaboration.
The other interface that will participate in the collaboration.
Having identied the elements that are going to collaborate, lets create an instance of the pattern and bind these elements to the parameters.
Elements bound to the pattern parameters.
After applying the pattern, we see that the SecureSale class now implements the Seller interface and requires (uses) the Purchaser interface.
the
group
Page 132 of 261
Highlighting the provided and required interfaces for the SecureSale class.
The pattern also creates an activity diagram for us with a partition for each of the interfaces. The partitions are populated with activities that map to the operations dened on the interfaces. At this point, it is up to us to dene the ow for the protocol.
The pattern also seeds an activity diagram for us so that we can dene the protocol.
With the pattern reducing the busy work, we focus on ensuring that we have dened the correct set of operations on the provided and required interfaces, that the Service Interface\Service Contract is working with the correct set of interfaces and that we have a well-thought out protocol. Related Accelerator Components Coordinating Participant: A coordinating participant may use a coordinating service interface to provide and consume services. Participant Subsystem: A coordinating participant may end up being encapsulated by a participant subsystem.
the
group
Page 133 of 261
Domain Prex
As we prepare for solution generation (Service Realization and Service Implementation) we continue to rene the model. A simple aspect that can be overlooked is the name of the packages used for organizing the model elements. To this point, our focus has been on names meaningful in the business domain. However, in deploying the solution, we need to use names supporting the technical domain. The Domain Prex pattern enables us to quickly update the names of the packages in our model. Problem How can we quickly and easily update the package names within our model to support solution creation and deployment? Solution The Domain Prex pattern focuses on updating package names to include a user specied domain prex. The pattern accepts a base package as the starting point for package name updates. The pattern then navigates through the package structure under the base package - updating the package names to include a user supplied prex. In doing so, packages such as Customer can now be represented as com.myorganization.customer.

the group
Page 134 of 261
This pattern has two parameters: 1. Base Package: The package (that may contain nested packages) that we want to update with a domain prex. This is a mandatory parameter. 2. Prex: The domain prex that we want to afx to our package names. This is a mandatory parameter. Example We start with an initial package structure.
The initial package structure.
We add the pattern to our diagram.
the
group
Page 135 of 261
Adding the pattern instance to the diagram.
We bind the parameters to the pattern and show the relationship between the pattern instance and its parameter. The pattern has updated the package structure - applying the domain prex to the Base Package and each of the nested packages.
After binding the package structure is updated.

the group
Page 136 of 261
As a result of using the pattern, we were able to quickly update the names of our packages. Service Litmus Test
During Service Identication we typically create a large number of candidate services.However, constraints such as time, costs, business t, available resources, and technical concerns limit the number of candidate services that will end up being created. Applying a Litmus test helps us to determine which of the Services are worthy of investment. Problem How do we determine which of our Candidate Services warrant investment? Solution The Service Litmus Test should be considered, used and revisited a number of times during our modeling efforts. Typically we start to use this pattern during the early efforts of Service Identication and revisit it multiple times. The Litmus Test contains a minimum set of requirements that should be considered for each service before moving forward to realization and implementation.
the
group
Page 137 of 261
The pattern has six parameters.
This pattern has six parameters: 1. Candidate Service: The candidate service that we are evaluating. We then have ve questions to answer - these questions are the key to the Litmus Test. Each question is answered with True\False to indicate whether the Candidate Service has passed the specic test. All of the tests must be set to True for the Candidate Service to be considered having successfully passed the Litmus Test. 2. Service is Business Aligned: Does the service provide business functionality? And, does it trace back to a business process or goal? We also need to consider service lifecycle funding, whether and how the service will be used (internally? externally?) - and the implications of such use. 3. Service has External Description: Does the service have a WSDL le (or some other comparable representation) that is used to describe the solution? And is this description external and separate from the implementation? 4. Service is Reusable: Can the service be reused in all of the processes where it is required? 5. Service is Technically Feasible: Taking into account all functional and nonfunctional requirements, is it possible to create the service? 6. Service is Composable: Does the service have the right level of granularity? Does the service meet QoS requirements? Is the service stateless? Is the service technically aligned? Example We start with the pattern instance.
the
group
Page 138 of 261
Start the example by creating an instance of the pattern.
We add a Candidate Service (SoaML::Capability) to our diagram. Note: Litmus tests will be applied multiple times during our efforts. As we evolve and further our design a ServiceInterface will surface in our models. The ServiceInterface should be traceable to the Capability and in turn connected to the Service Litmus Test.
Identify the Service Interface to be evaluated.
We bind the parameter to our pattern instance. For each of the additional pattern parameters, we consider whether the candidate service meets the requirements as stated. That is - is the candidate service: Business Aligned? Described Externally? Reusable? Technically Feasible? Composable? At this point, youre probably thinking that theres more to Service Litmus Testing than just capturing the nal result of the testing. And youre right!
the
group
Page 139 of 261
As the architect, it is imperative that were on board with defect prevention, and the Service Litmus Test plays a key role in these efforts. So how do we go further in capturing information about these testing efforts? The pattern implementation helps us capture information about our testing. When the Candidate Service is bound to the pattern instance, the documentation associated with the pattern instance is enhanced with a set of pre-congured tables for each test aspect. Each table provides a set of detailed questions and provides space for recording answers to these questions. Each table also includes a row for capturing details for additional concerns and notes.
Updated to reect a successfully completed test.
As we capture details about this testing effort, we update the documentation and the summary values captured by the pattern parameters. In this case, weve indicated that this specic Candidate Service has passed all of our tests, except for one. We still need to create an external description.
the
group
Page 140 of 261
Not all of the tests have been successful...yet.
After creating the external description, we return to the pattern instance and update the last parameter - setting it to true. The Candidate Service is automatically updated by the pattern - a new keyword is applied indicating that this Candidate Service has passed the litmus test.
Updated to reect a successfully completed test.
Related Accelerator Components We use the Service Litmus Test Summary and Service Litmus Test Details reports to detail the Candidate Services that have had a Litmus test applied and to see the status of that testing. We also use model validation and the Service Litmus Test constraint to identify services that have not yet had a Litmus test applied. Service Specication: Message Design The set of patterns in this category assist in dening the messages that Messaging Approach will be exchanged between service SoaML provides support for both documentproviders and consumers. The based and RPC-based approaches to patterns highlight the different types messaging. However, we recommend of approaches to messages, adopting a document-based approach. automates the creation of Following a document-based approach relationships and documents the provides exibility in dening your services use of the approach. while also reducing coupling.
the group
Page 141 of 261
The following image shows a simple example of dening a message using SoaML. Notice that the attribute associated with the message has public visibility (another best practice).
A simple message using the MessageType stereotype.
The next image, takes things a step further and shows that we can also dene attachments for a message.
We can also dene attachments.
In this section we look at a small set of patterns to help build out messages. The table below provides an overview of the patterns and is followed by detailed sections for each pattern.
Overview of Service Specication: Message Design patterns.
Pattern Name Command Message
Description Denes a message that contains a command. The Command is used to invoke behavior on another system.
Document Message A Document Message only passes data and lets the receiving party decide how to act upon that data. Event Message Multipart Message When there is an event to share, wrap the event in a message to send it to interested parties. A multipart message brings together a combination of elements which could include data or attachments.
Page 142 of 261
the
group
Command Message In some cases, we want to send a command to another system to invoke a behavior.
Problem How do we specify the use of a command message in a model? Solution The Command Message pattern simplies the denition of a message that contains a command.
This pattern has two parameters: 1. Message: The message that we are detailing. This is a mandatory parameter. 2. Command: The command to be included in the message. This is a mandatory parameter. Example The scenario for this example is quite simple. We want to create a message that contains a command. The command will be used to indicate to a fraud system that we want to suspend an account.
the
group
Page 143 of 261
After creating the pattern instance, we type in the name of a new message, FraudAlert. Then we type in the name of the command to send, SuspendAccount. In this case, weve used the pattern instance to create the associated model elements. To see the results of the pattern, we drag and drop the elements from the Pattern Explorer view and add them to our diagram. The resulting set of elements and relationships is shown in the following gure.
Resulting set of elements and relationships.
Related Accelerator Components The Command Message 43 pattern (and many other patterns) is further described in Enterprise Integration Patterns44 by Hohpe and Wolfe. Also, take a look at SOA Design Patterns45 by Erl. In this book, the other related components include the other messaging patterns (Document Message, Event Message, and Multipart Message). And, also take a look at the set of constraints related to messaging, including: MessageType elements should have public attributes MessageType elements should not have operations Document Message
43 44 45
http://www.eaipatterns.com/CommandMessage.html Enterprise Integration Patterns, Gregor Hohpe and Bobby Woolf, ISBN 0321200683, Addison-Wesley SOA Design Patterns, Thomas Erl, ISBN: 0136135161, Prentice Hall/PearsonPTR
the group
Page 144 of 261
A Document Message only passes data and lets the receiving party decide how to act upon that data. Problem How do we specify the use of a document message in a model? Solution The Document Message pattern simplies the denition of a message that contains a document.
This pattern has two parameters: 1. Message: The message that we are detailing. This is a mandatory parameter. 2. Data: The data (document) to be included in the message. This is a mandatory parameter. Example The scenario for this example is quite simple. We want to create a message that contains a document. The document will be the invoice related to a purchase. Well need to pass that invoice to other systems, however, were not worried about how the data will be used. After creating the pattern instance, we type in the name of a new message, InvoiceMessage. Then we type in the name of the document to send, Invoice.
the group
Page 145 of 261
To see the results of the pattern, we drag and drop the elements from the Pattern Explorer view and add them to our diagram. The resulting set of elements and relationships is shown in the following gure.
The resulting set of elements and relationships.
Related Accelerator Components The Document Message46 pattern is further described in Enterprise Integration Patterns47 by Hohpe and Wolfe. Also, take a look at SOA Design Patterns 48 by Erl. In this book, the other related components include the other messaging patterns (Command Message, Event Message, and Multipart Message). And, also take a look at the set of constraints related to messaging, including: MessageType elements should have public attributes
46 47 48
http://www.eaipatterns.com/DocumentMessage.html Enterprise Integration Patterns, Gregor Hohpe and Bobby Woolf, ISBN 0321200683, Addison-Wesley SOA Design Patterns, Thomas Erl, ISBN: 0136135161, Prentice Hall/PearsonPTR
the group
Page 146 of 261
MessageType elements should not have operations Event Message
When there is an event to share, wrap the event in a message to send it to interested parties. Problem How do we specify the use of an event message in a model? Solution The Event Message pattern simplies the denition of a message that contains an event.
This pattern has two parameters: 1. Message: The message that we are detailing. This is a mandatory parameter. 2. Command: The event to be included in the message. This is a mandatory parameter. Example The scenario for this example is quite simple. We want to create a message that contains an event. In this case, the event is based on inventory being depleted. Well need to pass that event to other systems, however, were not worried about how the event will be used.
the group
Page 147 of 261
After creating the pattern instance, we type in the name of a new message, Inventory. Then we type in the name of the event to send, OutofStock. To see the results of the pattern, we drag and drop the elements from the pattern explorer view and add them to our diagram. The resulting set of elements and relationships is shown in the following gure.
The resulting set of elements and relationships.
Related Accelerator Components The Event Message49 pattern is further described in Enterprise Integration Patterns50 by Hohpe and Wolfe. Also, take a look at SOA Design Patterns51 by Erl. In this book, the other related components include the other messaging patterns (Command Message, Event Message, and Multipart Message). And, also take a look at the set of constraints related to messaging, including: MessageType elements should have public attributes MessageType elements should not have operations
49 50
http://www.eaipatterns.com/EventMessage.html
Enterprise Integration Patterns, Gregor Hohpe and Bobby Woolf, ISBN 0321200683, Addison-Wesley. In particular, take a look at: http://www.soapatterns.org/event_driven_messaging.php
51
SOA Design Patterns, Thomas Erl, ISBN: 0136135161, Prentice Hall/PearsonPTR

the group
Page 148 of 261
Multipart Message
A multipart message brings together a combination of elements which could include data or attachments. Problem How do we specify the use of a multipart message in a model? Solution The Multipart Message pattern simplies the denition of a message that contains a combination of data and attachments.
This pattern has three parameters: 1. Message: The message that we are detailing. This is a mandatory parameter. 2. Data: The set of data elements to be included in the message. This is an optional parameter. 3. Attachment: The set of attachments to be included in the message. This is an optional parameter.
the group
Page 149 of 261
Example After creating an instance of the Multipart Message pattern, we type in the name of the new message element to create. In this case we call the new message POMessage.
Start by specifying the name of the message.
We also see that within the model, we already have two classes dened; Customer and PurchaseOrder. Wed like both of these elements to be part of the data portion of this message.
Classes well use for specifying the data aspects of the message.
We drag and drop these classes onto the pattern instance to bind them as parameters.
Instance of the pattern with the data elements bound.
Next, we update our diagram to show the elements and their relationships. We see that the POMessage element will now contain Customer and PurchaseOrder data.
the group
Page 150 of 261
Resulting diagram showing the message and the data.
The last step is to also specify an attachment. In this case, we type in form as the name of the attachment. The diagram updates automatically and we see that attachment specied on the message.
the
group
Page 151 of 261
The attachment shows up on the message with the stereotype applied.
The last step is to look at the properties for the Attachment stereotype. The properties allow us to specify the encoding and mimeType.
the
group
Page 152 of 261
The Stereotypes properties tab allows us to set the encoding and mimeType.
Related Accelerator Components In this book, the other related components include the other messaging patterns (Command Message, Document Message, and Event Message). And, also take a look at the set of constraints related to messaging, including: MessageType elements should have public attributes MessageType elements should not have operations Service Specication: Participant Design In this category of patterns we focus on designing participants. Recall from the SoaML specication that: Design Review Tip A Participant In a Design Review, use the Pattern Instances report represents some to understand where patterns supporting simple (possibly concrete) scenarios versus complex scenarios are being used. party or component Does the pattern usage correctly reect the that provides and/or sophistication of the projects service scenarios? To consumes services prevent defects look for situations where there is a participants may mismatch between service scenario complexity and represent people, pattern selection. organizations or systems that provide and/or use services. A Participant is a service provider if it offers a service. A Participant is a service consumer if it uses a service a participant may provide or consume any number of services. Service consumer and provider are roles Participants play:
the group
Page 153 of 261
the role of providers in some services and consumers in others, depending on the capabilities they provide and the needs they have to carry out their capabilities. Since most consumers and providers have both services and requests, Participant is used to model both. Participants play an important role in our SOA modeling. We use them to gain a high level understanding (with ServicesArchitectures) and we continue to use them as we detail the system view of the solution. When combined with the recognition that a service can vary from quite simple to more sophisticated bi-directional use - we see that a Participant and how it is modeled becomes an important part of our Service Model.
Overview of Service Specication: Participant Design patterns.
Pattern Name Coordinating Participant
Description Specify a more sophisticated Participant that offers Services and makes Requests in a way that allows us to minimize mechanical steps while focusing on problem solving. Create subsystems comprised of other Participants while dening the externally available interfaces for Services offered and Requests that will be made. Specify a Participant that is a consumer of a simple set of services. Specify a Participant that is a provider of a simple set of services. Create a participant with a single request port and type that port with a number of interfaces. Create a participant with a single service port and type that port with a number of interfaces.
Participant Subsystem
Simple Request Participant Simple Service Participant Single Request Port Participant Single Service Port Participant
In modeling participants we want to keep things as simple as possible. Critical to this effort is to recognize the sophistication of the service interaction. How many participants are in the interaction? Is this a bi-directional interaction? Or just simple request/response? For simpler scenarios, focus on using the Simple Request Participant, Simple Service Participant and Participant Subsystem patterns. As warranted by the sophistication and complexity of the scenario, consider using the other participant patterns in combination.
the group
Page 154 of 261
Coordinating Participant
Problem How do we specify a more sophisticated Participant that offers Services and makes Requests? And how do we do so in a way that allows us to minimize mechanical steps while focusing on problem solving? Solution The Coordinating Participant pattern assists the practitioner in creating more sophisticated Participants - participants that support bi-directional interactions. With this pattern we need to specify the participant that will serve as the coordinator for this usage model. With a participant selected, we then focus on specifying the interfaces that will be used for Services and Requests.
This pattern has three parameters: 1. Coordinator: The participant that will be used for Services and Requests. This is a mandatory parameter. 2. Service: Interfaces describing the services being offered. This is a mandatory parameter. 3. Request: Interfaces that describe the requests that will be made. This is a mandatory parameter.
the
group
Page 155 of 261
Example We start with a set of model elements that we want to use together in dening a Coordinating Service Interface. First an InvoicingService:
A complex service interface with a protocol.
And also a ShippingService:
A second interface with a protocol.
We want to show how a participant can work with these service interfaces - more specically, we have to provide the ShippingService (i.e. we are a service provider) and request the InvoicingService (i.e. we are a service consumer). We add the Coordinating Participant pattern to our model.
the
group
Page 156 of 261
Pattern instance with elements that will be the parameters.
We bind the parameters to the pattern. And to help convey the services provided and consumed by the participant, lets switch to the external view of the component. Weve also added in the relationships between the pattern instance and the parameters.
Updated diagram after binding the parameters.
Notice in this case that we end up with separate service and request ports. Typically, such ports would participate in different scenarios. If you require that multiple interfaces are support via a single port for a more sophisticated interaction, consider the Single Request Port Participant or the Single Service Port Participant patterns.
the group
Page 157 of 261
Now we can look at detailing how this Participant interacts with the other participants in our service-oriented solution. Related Accelerator Components Collaborating Interface: Can be used in conjunction to dene a service interface that serves as a parameter to this pattern. Simple Service Participant: An alternative to consider is whether a simpler service participant is all that is needed. Simple Request Participant: An alternative to consider is whether a simpler request participant is all that is needed. Participant Subsystem
As with any solution, we encapsulate elements in subsystems - raising the level of abstraction within the overall solution. Elements within the subsystem are only accessible via published and exposed interfaces. We take a similar approach to participants. As a result, we decrease the coupling between elements in our solution, while increasing the cohesion within the subsystem itself, and better support reuse. In taking this approach we also support the SOA goal of supporting a separation of concerns. Problem How can we create a Participant subsystem? In such an effort, how do we encapsulate other participants and manage access to those encapsulated elements? Solution The Participant Subsystem pattern helps us to quickly create subsystems comprised of other participants. In addition, we dene the externally available interfaces for Services offered and Requests that will be made. This pattern reduces mechanical busywork and also guides the practitioner to think in terms of more coarse-grained and reusable elements within their solution.
the
group
Page 158 of 261
This pattern has four parameters: 1. Subsystem: This is a participant that will be used to encapsulate other participant elements. This is a mandatory parameter. 2. Service: A list of services that the subsystem will provide. This is an optional parameter. 3. Request: A list of requests that the subsystem will make. This is an optional parameter. 4. Encapsulated Participant: Participants that will be encapsulated within the subsystem. This is a mandatory parameter. Example Lets rst take a look at the participants that have already been dened - and that are going to be encapsulated in the subsystem we are creating. We see a Simple Participant named Customer that we have already dened by using the Simple Participant pattern.
the
group
Page 159 of 261
Using another pattern to build elements to use as parameters.
Next, we have another participant to be encapsulated. However, this participant OrderProcessor - is more complex. First lets look at a couple of ServiceInterface elements that have been dened.
View of a Collaborating Service Interface.
the
group
Page 160 of 261
And another Collaborating Service Interface.
Next, we use the Coordinating Participant pattern to dene a participant that uses these Service Interfaces.
Continuing to build larger constructs via patterns.
We also have identied a couple of ServiceInterfaces that we will use to expose functionality from the subsystem. With this prep work complete, we can now focus on our Participant Subsystem. Lets take a look at the pattern instance and the related elements before we bind any parameters.
the
group
Page 161 of 261
We now have all of our parameters and a pattern instance.
We bind parameters to the pattern instance.
Bind the parameters to the pattern instance.
We show the relationships and the structure compartment.
the
group
Page 162 of 261
New parts are created within the Structure of the subsystem, ports as well.
And a little more detail, adding in the relationships between the pattern and its parameters.
Adding in the traceability relationships.

the group
Page 163 of 261
At this point, we can focus on ensuring that we have the right participants encapsulated, that their interfaces are correctly dened, interactions noted and if necessary, we can add to the interface(s) provided by the subsystem itself. The remaining step is to wire up the component. Wiring up the component requires that we have compatible interfaces between those exposed by the Subsystem and those encapsulated within the subsystem. In this example, we still have some work to do before we take this next step. Related Accelerator Components Simple Service Participant and Simple Request Participant are good patterns to start with for simpler service interactions. Simple Request Participant
The Simple Request Participant pattern is the mirror image of the Simple Service Participant pattern. Whereas the Simple Service Participant pattern is used to model a situation where a participant is a provider of a simple set of services - the Simple Request Participant is used to model a participant that is a consumer\requestor of a simple set of services. Problem How can we quickly model a simple participant and the requests that it will make? Solution The Simple Request Participant pattern allows us to specify a Participant element along with a collection of Service Interfaces. For each Service Interface that is specied, a port and the service being requested is added to the participant. The request port is conjugated, which enables us to create service connections between this participant and other participants that offer services that adhere to the same interface.
the
group
Page 164 of 261
This pattern has two parameters: 1. Participant: The model element that will request\consume one or more services. This is a mandatory parameter. 2. Request Interface: One or more service interfaces that describe the services that will be requested\consumed. This is a mandatory parameter. Example We start with an instance of the Simple Request Participant pattern.
Add an instance of the pattern.
And a set of elements that well use with the pattern - a participant and an interface that will be the basis of a service request.
Identify the elements well use with the pattern.
We add these elements to the same diagram as the pattern instance.

the group
Page 165 of 261
Pattern and parameters on the same diagram.
We bind the elements to the pattern instance. The diagram is updated - as the Participant is given a port based on the interface, the port is stereotyped as a Request and it is conjugated (~). By conjugating the port we are now able to create service connections between this request port and other service ports that have been typed with the same interface.
Binding the parameters leads to a Service port added to the Participant.
We update the diagram to include the traceability links between the pattern instance and the pattern parameters.
the
group
Page 166 of 261
Update diagram to also highlight traceability.
Related Accelerator Components Simple Service Participant: The mirror image of this pattern, used to create simple service participants. Participant Subsystem: The resulting participant may be encapsulated in a participant subsystem. Simple Service Participant
The Simple Service Participant pattern is used to model a situation where a participant is a provider of a simple set of services. We use the pattern to detail the services that the participant provides and also to denote the behaviors that are provided by the participant. Problem How can we quickly model a simple service participant? In doing so, how can we detail the services that the participant offers and the behaviors provided? Solution The Simple Service Participant pattern allows us to specify a Participant element along with a collection of ServiceInterfaces. For each ServiceInterface that is specied, a port and the service being offered is added to the participant. In addition, to highlight
the
group
Page 167 of 261
the behavior supported by the interface, an opaque behavior is created for each behavior provided by the interface.
This pattern has two parameters: 1. Participant: The model element that will offer one or more services. This is a mandatory parameter. 2. Service Interface: One or more service interfaces that describe the services that will be offered. This is a mandatory parameter. Example We start by creating a Participant and an Interface (which represents a simple service).
The elements we want to use with the pattern.
We add an instance of the Simple Service Participant pattern to our diagram.
Adding the pattern instance to the model.

the group
Page 168 of 261
We bind the Participant and the Interface to the pattern parameters. Once the parameters are bound the model is updated. To get a rst glimpse at some of the changes to the model, change the representation of the Participant to its external view.
After binding, Participant has a port added for the Service.
Next, we update the diagram by adding the owned behaviors related to the participant.
Corresponding behaviors are generated.
And the nal step is to add in the relationships between the pattern instance and the bound parameters.
the
group
Page 169 of 261
Complete view of all elements and relationships.
As a result of using the pattern, we effectively use SoaML to describe a service provider and the services that it provides. Related Accelerator Components Simple Request Participant: The mirror image of this pattern, used to create simple request participants. Participant Subsystem: The resulting participant may be encapsulated in a participant subsystem. Single Request Port Participant
Problem When working in a multi-party, multi-directional service interaction, how can we dene a single request port on a participant that correctly implements the necessary set of interfaces?
the
group
Page 170 of 261
Solution The Single Request Port Participant pattern assists the modeler in building out a request port on a participant that is involved in a multi-party, multi-directional service interaction.
This pattern has four parameters: 1. Participant: The participant that is primarily a requestor of services for the scenario that we are modeling. This is a mandatory parameter. 2. Port Type: The type (class) that will be used for the request port for the scenario being modeled. This is a mandatory parameter. 3. Required Interface: Additional interface that is required in this scenario. This is an optional parameter. 4. Provided Interface: Additional interface that is provided in this scenario. This is an optional parameter. Example The section Service Contracts: Beyond Two Participants walks through a scenario where this pattern is used. Rather than repeating the entire scenario, well dig a little deeper into the pattern and what it does for us in the scenario. Recall that in the service interaction between the Dealer, Manufacturer and the EscrowAgent we have three interfaces that we need to support: 1. SecurePurchase 2. SecureSale 3. EscrowAgent Noting that SecurePurchase and SecureSale both use the Seller and Purchaser interfaces. At the end of the modeling, we want to end up with our participants modeled as shown in the following gure. Looking at the ports we can see the different ways in which the Seller, Purchaser and EscrowAgent interfaces are being provided or required. As we are modeling a single interaction, we want to have all of these interfaces connected to a single port.
the
group
Page 171 of 261
The complete set of participants for this scenario.
In the case of the Dealer, they are primarily a service requestor in this scenario. So we want to create a port that is stereotyped as a request. Recall that by doing so, it will conjugate the interfaces, so in the case of the EscrowAgent interface, we bind it to the ProvidedInterface parameter (which shows the interface as being required).
the
group
Page 172 of 261
A view of the elements that come together in dening the Dealer Participant.
Related Accelerator Components Single Service Port Participant, Collaborating Interface, Simple Service Participant, Simple Request Participant. Single Service Port Participant
the
group
Page 173 of 261
Problem When working in a multi-party, multi-directional service interaction, how can we dene a single service port on a participant that correctly implements the necessary set of interfaces? Solution The Single Service Port Participant pattern assists the modeler in building out a service port on a participant that is involved in a multi-party, multi-directional service interaction.
This pattern has four parameters: 1. Participant: The participant that is primarily a provider of services for the scenario that we are modeling. This is a mandatory parameter. 2. Port Type: The type (class) that will be used for the service port for the scenario being modeled. This is a mandatory parameter. 3. Required Interface: Additional interface that is required in this scenario. This is an optional parameter. 4. Provided Interface: Additional interface that is provided in this scenario. This is an optional parameter. Example The section Service Contracts: Beyond Two Participants walks through a scenario where this pattern is used. Rather than repeating the entire scenario, well dig a little deeper into the pattern and what it does for us in the scenario. Recall that in the service interaction between the Dealer, Manufacturer and the EscrowAgent we have three interfaces that we need to support: 1. SecurePurchase 2. SecureSale 3. EscrowAgent Noting that SecurePurchase and SecureSale both use the Seller and Purchaser interfaces.
the group
Page 174 of 261
At the end of the modeling, we want to end up with our participants modeled as shown in the following gure. Looking at the ports we can see the different ways in which the Seller, Purchaser and EscrowAgent interfaces are being provided or required. As we are modeling a single interaction, we want to have all of these interfaces connected to a single port.
The complete set of participants for this scenario.
In the case of the Manufacturer, they are primarily a service provider in this scenario. So we want to create a port that is stereotyped as a service. In this case, we specify that EscrowAgent is a required interface for the interaction with the EscrowAgent participant.
the
group
Page 175 of 261
A view of the elements that come together in dening the Manufacturer Participant.
Related Accelerator Components Single Request Port Participant, Collaborating Interface, Simple Service Participant, Simple Request Participant. Service Specication: Service Contract Design In this section we focus on how to simplify the specication of Service Contracts. Recall that according to the SoaML specication: A ServiceContract is the specication of the agreement between providers and consumers of a service as to what information, products, assets, value and obligations will ow between the providers and consumers of that service it species the service without regard for realization, capabilities or implementation. A ServiceContract does not require the specication of who, how or why any party will fulll their obligations under that ServiceContract, thus providing for the loose coupling of the SOA paradigm. In most cases a ServiceContract will specify two roles (provider and consumer) but other service roles may be specied as well. The ServiceContract may also own a behavior that species the sequencing of the exchanges between the parties as well as the resulting state and delivery of the capability. The owned behavior is the choreography of the service and may use any of the standard UML behaviors such as an interaction, timing, state or activity diagram.
the group
Page 176 of 261
Overview of Service Specication: Service Contract Design patterns.
Pattern Name Compound Service Contract
Description Guides the practitioner to think in terms of creating more coarse-grained service contracts via the composition of a number of more negrained service contracts. A Service Contract species the agreement between providers and consumers of services as to what information, products, assets, value and obligations will ow between two parties.
Simple Service Contract
Compound Service Contract
Going beyond the denition, the SoaML specication also goes on to explain Compound Service Contracts: Enterprise services are frequently complex and nested (e.g., placing an order within the context of a long-term contract). A ServiceContract may use other nested ServiceContracts representing nested services as a CollaborationUse. Such a nested service is performed and completed within the context of the larger grained service that uses it. A ServiceContract using nested ServiceContracts is called a compound service contract. Problem Recognizing that enterprise services can be complex and nested, how can we support a practitioner in dening and modeling compound service contracts? That is, how can they establish the relationship between ner-grained service contracts and the more coarse-grained service contracts which encapsulate them? In addition, how can they specify the consumer and provider elements that participant in the compound service contract?
the group
Page 177 of 261
Solution The Compound Service Contract pattern guides the practitioner to think in terms of creating more coarse-grained service contracts via the composition of a number of more ne-grained service contracts. The user can quickly and easily dene the Compound element and the set of elements which it encapsulates. In addition, the pattern supports the identication and encapsulating of Consumer and Provider elements that interact and support the service contract.
This pattern has four parameters: 1. Service Contract: The service contract that we are detailing. This is a mandatory parameter. 2. Consumer: Consumers that participate in the service contract. This is an optional parameter. 3. Provider: Providers that participate in the service contract. This is an optional parameter. 4. Encapsulated Service Contract: One or more service contracts that are encapsulated within the Compound Service Contract. This is an optional parameter. Example We start by looking at the elements we have at hand to help us dene a Compound Service Contract. This includes Consumer, Provider, and other ServiceContract elements.
the
group
Page 178 of 261
The elements that well use with the pattern.
Having recognized that we have a need for a Compound Service Contract, we add the pattern instance to the diagram and bind our model elements to the pattern parameters.
Parameters bound to the pattern instance.
The pattern updates the Service Contract, encapsulating two service contracts as well as the Buyer and Seller elements.
the
group
Page 179 of 261
Updated Service Contract with encapsulated elements.
The pattern also generates an associated interaction and adds in lifelines for the Consumer and Provider elements. We can use this to articulate the associated protocol (as needed).
Complete view with traceability.
the
group
Page 180 of 261
Our next step is to create the relationships between the encapsulated elements. Beyond that, we could look to use this Service Contract as a participant in a Compound Service Contract that is even more coarse-grained. Related Accelerator Components Related patterns include Simple Service Contract, Participant Services Architecture and Simple Services Architecture. Simple Service Contract
Problem How can we quickly and easily dene a Service Contract that highlights the interaction of Consumers and Providers? Solution The Simple Service Contract pattern assists the practitioner in creating simple service contracts that are comprised of a set of Consumer and Provider elements.
This pattern has three parameters: 1. Service Contract: The package (that may contain nested packages) that we want to update with a domain prex. This is a mandatory parameter. 2. Consumer: At least one Consumer needs to be specied. 3. Provider: At least one Provider needs to be specied.
the group
Page 181 of 261
Example We saw use of this pattern during the discussion about the Service Contract Based Approach to working with SoaML. By using the pattern, we can quickly dene the contract and the set of participating providers and consumers. After applying the pattern we are left with having to create a connection between the parts within the ServiceContract element.
The pattern as applied in creating the Place Order Service Contract.
The pattern also generates an associated Activity diagram. The pattern creates a partition for each provider and consumer. Within each partition an activity is created for each operation supported by the interface. We then need to add a denition of the ow between these activities.
After the Activity Diagram is generated we follow up by dening the ow between the activities.
the group
Page 182 of 261
Related Accelerator Components Related patterns include Compound Service Contract, Participant Services Architecture and Simple Services Architecture. Service Specication: Services Architecture Design Recall that according to the SoaML Specication: A ServicesArchitecture (a SOA) describes how participants work together for a purpose by providing and using services expressed as service contracts. By expressing the use of services, the ServicesArchitecture implies some degree of knowledge of the dependencies between the participants in some context. Each use of a service in a ServicesArchitecture is represented by the use of a ServiceContract bound to the roles of participants in that architecture. Note that use of a ServicesArchitecture is optional but is recommended to show a high level view of how a set of Participants work together for some purpose. Where as simple services may not have any dependencies or links to a business process, enterprise services can often only be understood in context. The services architecture provides that context, and may also contain a behavior, which is the business process. The participants roles in a services architecture correspond to the swim lanes or pools in a business process. We can specify a Services Architecture for a B2B scenario, an internal solution, a portion thereof, or even for a participant. This category of patterns helps to accelerate the specication of ServicesArchitectures.
Overview of Service Specication: Services Architecture Design patterns.
Pattern Name Participant Services Architecture
Description A ServicesArchitecture can be dened at a Participant level. Giving us insight into the encapsulated Service Contracts and Participants that collaborate to provide value. The purpose of the ServicesArchitecture is to specify the SOA of an organization, community, component or process to provide mutual value. The participants specied in the ServicesArchitecture provide and consume services to achieve that value.
Simple ServicesArchitecture
Participant Services Architecture

the group
Page 183 of 261
Recall that the scope of a ServicesArchitecture can vary. We can specify a Services Architecture for a B2B scenario, an internal solution, a portion thereof, or even for a participant. Problem How can we correctly, quickly and easily specify a ServicesArchitecture for a Participant? Solution The Participant Services Architecture pattern allows us to quickly create a ServicesArchitecture for a Participant. The pattern is an interesting variation of the Simple Services Architecture pattern in that it details the relationship between a Participant and the Services Architecture. In addition, by focusing on a Participant we also are now able to highlight the interaction with both internal and external Participants.
The pattern has ve parameters.
This pattern has ve parameters: 1. Realized Participant: This participant provides the scope for the ServicesArchitecture that we want to model. This is a mandatory parameter.
the group
Page 184 of 261
2. Services Architecture: The ServicesArchitecture for the participant. This is a mandatory parameter. 3. Service Contract: The Service Contract elements that are provided or consumed by this participant. This is a mandatory parameter. 4. Internal Participant: Participants internal to the scope that provide or consume services.This is a mandatory parameter. 5. External Participant: Participants that are external to the scope that provide or consume services within the scope. This is an optional parameter. Example Recall from our earlier look at the Dealer Network case study the view of the overall B2B interaction that was depicted with a ServicesArchitecture.
This ServicesArchitecture provides us with an overview of the entire scenario.
This perspective helps us understand the overall big picture. But what if we want a more detailed view, a view from the perspective of one of the participants? Recall that we can create ServicesArchitectures from different perspectives and at different levels. In this case, we can use the Participant Services Architecture pattern. We create an instance of the pattern and bind our model elements to the pattern parameters. Of
the group
Page 185 of 261
particular interest with this type of ServicesArchitecture is that we want to note which participants are internal or external. That is, from the viewpoint of the participant that we are modeling, we recognize the participants that exist within the scope of that entity and those that are external. In the case of the Manufacture, we have a number of participants that do not surface until we get to this more detailed look. These participants are internal to the participant and include Fulllment, Accounts Receivable and Production. The fact that this is a B2B scenario, we know that the Manufacture interacts with external parties. As such we add the Dealer and Shipper to pattern as External Participants.
The pattern has ve parameters.
After binding the pattern parameters we clean up the diagram and create relationships between the participants (represented as parts) and the service contracts (collaboration uses). A important detail to notice is that the internal and external participants have slight differences in how they appear in the diagram. The internal participants show up as parts with a solid outline, whereas, the external participants show up as parts with a dotted outline.
the
group
Page 186 of 261
The completed Participant Services Architecture. The diagram has been cleaned up to improve readability and role binding relationships have been aded.
And to help dene the interaction, the pattern also creates an Activity diagram that enables us to focus on dening the business process.
The generated Activity diagram with a partition for each of the participants.
Related Accelerator Components Related patterns include Simple Services Architecture, Simple Service Contract and Compound Service Contract.
the group
Page 187 of 261
Simple Services Architecture
Problem How can we quickly and easily create a ServicesArchitecture and specify the Service Contracts and Participants? Solution The Simple Services Architecture pattern is useful for creating a simple Services Architecture. So what makes this simple? In this case, we are not differentiating between internal and external participants and we are not specifying a Services Architecture for a specic participant. The focus is only on dening the set of participants and the service contracts that are used.
This pattern has three parameters: 1. Services Architecture: Recall that this is a high-level view of a Service Oriented Architecture. It denes how a set of participants works together, forming a community. We can specify a Services Architecture for a B2B scenario, an internal solution, or a portion thereof. This is a mandatory parameter. 2. Service Contract: ServiceContracts that participate in this ServicesArchitecture. This is a mandatory parameter. 3. Participant: The participants that provide and consumer services via the Service Contracts. This is a mandatory parameter.
the group
Page 188 of 261
Example We saw an example of the use of this pattern when we introduced the Dealer Network example in the section titled Exploring SoaML Modeling Approaches. We started the example with a simple sketch that provided an overview of the example. The Simple Services Architecture pattern was then used to help us create a Services Architecture that provided an overview of the participants and service contracts that operate in this community. By using the pattern, we can either bind existing elements to the parameters. Or, if we are just getting started, we can use the pattern instance to help us create the model elements. Recall that we can hover over the parameter and then type in the name of the model element to generate.
The resulting ServicesArchitecture cleaned up for readability and with role binding relationships added.
The pattern also generates an associated Activity diagram with a partition for each of the Participants. We can then dene the activities associated with their interaction. Providing insight into the behavior associated with this services architecture.
the group
Page 189 of 261
Activity diagram that has been generated. We now focus on detailing the business process.
Related Accelerator Components Related patterns include Participant Services Architecture, Simple Service Contract and Compound Service Contract.
the
group
Page 190 of 261
Part IV. SOA Governance
the
group
Page 191 of 261
Overview Governance 52 plays a critical role in the success of our SOA projects. However, the fog and friction of development hinders the effectiveness of enforcing governance policies. Adopting a process and a toolset, consulting documentation and participating in skill building events are the typical rst steps taken by organizations as they combat the fog and friction of development. However, having to learn, internalize and effectively execute a process and set of tools can be an exercise in frustration. Here we will discuss how to use automation to apply patterns, validate designs and summarize details to amplify the efforts and skills of teams in SOAD. By using these approaches, we are better able to align Business and IT, ensure proper investments, and track and enforce adherence to best practices, all of which combine to bring process and governance to life. SOA Governance empowers and enables the people within the organization to successfully perform SOAD and deliver SOA solutions. We empower people by establishing chains of responsibility, authority and communication. We enable people to carry out their roles and responsibilities by establishing measurement, policy and control mechanisms. We want to get the team to work using the same best practices, improve communication, and support measurement and traceability. The focus of such efforts is to ensure Business-IT alignment, reduce risk, ensure proper investments, support reuse, and deliver quality solutions in a timely manner. You might start out successfully with your SOA initiative, but without SOA Governance from the beginning, you will start to see a greater usage of resources to maintain your existing services, and start to lose the value of moving to SOA in the rst place. Realizing the potential and promise of SOA is best achieved through the successful application of SOAD along with SOA Governance. Even better is to adopt an Agile SOA approach that includes Agile practices such as SAFe. However, our efforts need to overcome the fog and friction [REF1] associated with any signicant undertaking. That is, are we able to gather reliable information and reduce the fog surrounding our efforts? And with information in hand, can we execute in an effective and timely manner by reducing the friction? What obstacles need to be overcome, what delays and unnecessary (and unexpected) steps must we deal with in order to complete the project? The following gures touch upon some of the questions related to fog and friction that we must overcome.
52
Content in this section originally appeared in the article: Top 3 Tips for Using Automation to Bring Governance to Service-Oriented Analysis and Design, Published: March 23, 2012 Service Technology Magazine Issue LX
the group
Page 192 of 261
Fog What are our business goals? Why have we created these services? What is the impact of changing a goal? What is the business impact of not delivering this service? What best practices have been followed? Where has this best practice been followed? Which services should we invest in? Has this been designed correctly?
Questions that highlight the fog associated with SOAD
Friction Why does this tool require so many clicks? What are the steps in the process? What is the best practice? How are these elements supposed to collaborate in realizing a solution? How do I start in solving this problem? Why does it take so much effort to support traceability? How can I reduce the time it takes to prepare for design reviews? How can I streamline the effort of sharing information with EA and Governance?
Questions that highlight the friction associated with SOAD
The above lists arent exhaustive, although it certainly is exhausting to think of the work that is needed to tackle these issues! Sadly, we often fail to overcome these challenges, and in coming up short the negative outcomes tend to snowball and put our projects in jeopardy. To address these challenges we need to harness proven approaches and tooling. By doing so, we are able to reduce the fog and friction and in turn improve our governance efforts and deliver better solutions. Adopting a process and a toolset, consulting documentation and participating in skill building events are the typical rst steps. However, having to learn, internalize and effectively execute a process and set of tools can be difcult, frustrating, and errorprone. Use of the SOAD Model Accelerator aligns with and supports an organizations SOA Governance effort. Recall that a focus of governance efforts is to empower and enable the people within the organization. In these efforts we want to get the team to work using the same best practices, improve communication, and support measurement and traceability.
the group
Page 193 of 261
At this point it should be clear that the SOAD Model Accelerator focuses on the methods and processes that support service identication and design - while ensuring alignment with the business. We should also recognize that the models (and the elements within) that we have created through the use of the Accelerator provide a rich source of data for our governance efforts. The set of reports and model constraints, as described in this section, take advantage of the rich set of data that is created to produce key input to our metrics, measurement, and risk mitigation efforts associated with SOA governance. Reports Consider some of the many scenarios where it is essential to be able to share information about SOA solution design: Personal review and understanding of our own model Sharing with others to help them understand the solution Participating in design reviews Providing input in EA efforts for project coordination Supporting SOA Governance efforts with solution metrics, best practice application and adherence insights, and details about business-IT alignment. The key word here is information. We cant just throw a model or diagram at someone and expect comprehension to follow. We need to review, interpret and analyze the data we have and put it into meaningful representations. This requires a blending of summary graphics as well as supporting details. The challenge is to take our everyday work efforts and minimize the amount of effort and time it takes to transform these work products into meaningful, shareable representations. Using manually created diagrams, pictures, spreadsheets and documents is a path that we already know does not work. It takes too long to create these artifacts, never mind the fact that they are out of date almost from the moment of inception. Creating and recreating such diagrams is seen as busy work. As a result, we dont bother with the effort. Its just documentation and as everyone knows, our job is to deliver software. This brings us back to the importance of having a model (containing meaningful representations of domain elements, relationships, pattern instances, traceability, and so on). This is a rich source of information waiting to be leveraged for the benet of the organization. Automating the generation of reports that harvest information from our models is a signicant win for the organization. We need reports that can be generated in seconds, which provide meaningful insights, and which can be regenerated at any time, taking into account the current state of our model(s).
the
group
Page 194 of 261
Lets take a look at reports that the SOAD Model Accelerator has automated and which provide great value and support for our governance efforts: 1. BPMN Complexity 2. Goals-Service Model 3. Service Litmus Test Summary 4. Service Litmus Test Details 5. Pattern Instances
Select one of the SOAD Reports when creating a report conguration.
In summary, with automated report generation, execution occurs in seconds and is based on the current state of the model. We can support information requests on demand and always meet the request with up to date and accurate insights into design status. Yes, great value can arise from creating and reviewing these reports in isolation. However, dont overlook the fact that having the set of reports and consulting them in combination can help to broaden our understanding of the solution and the impact of our design (technical and business impact!). The following sections provide further details on each of the reports. Details on how to congure and run reports is found in Generating Reports. BPMN Complexity Business Process Models serve as a basis for communication between stakeholders. They provide a key understanding of the needs of the business and what the solution should do.
the group
Page 195 of 261
These models need to be easy to understand and maintain. A model that is too complex is difcult to understand, is difcult to develop and test, and leads to the wrong solution taking too long to be built53. This report is applicable to multiple project roles and phases. Some example scenarios where this report adds value: 1. Business Analyst runs the report to understand the complexity of specied business processes. Uses this information along with anticipated ROI to prioritize the business processes to be implemented. 2. Business Analyst uses the report to identify business processes that require a review and refactoring. 3. Architect uses the report as a milestone\gating mechanism as business process are transitioned from business to IT. Business processes may be sent back to the business analyst for refactoring. 4. Architect uses the report to assist with planning the iteration in which the process is addressed. Higher risk processes are slotted into early iterations. 5. Quality Assurance uses the report to assist with planning the testing effort. Recognizing the more complex processes will require additional testing effort. This report provides an overview of the factors that affect the complexity of business models. The higher the score, the greater the effort required to comprehend the model. How is the score calculated? The formula we use for calculating the score is: BPC = (n(Ei)x CWi) which is read as Business Process Complexity is equal to the summation of the number of each BPMN element type times the cognitive weight for that type.
53
For more information describing approaches to calculating Business Process Complexity, consult the following papers: 1. Volker Gruhn and Ralf Laue, Complexity Metrics for Business Process Models 2. Volker Gruhn and Ralf Laue, Adopting the Cognitive Complexity Measure for Business Process Models
the group
Page 196 of 261
Output from the BPMN Complexity report
Goal-Service Modeling The Goal-Service Model report is used to ensure direct relationships between the business goals and the services as identied and specied in our SOAD efforts. This report details the traceability between business strategy and IT capabilities. Use of this report enables us to inspect and adapt during development - ensuring that IT stays aligned with the business. Constraints and Patterns discussed previously guide the user to create model elements that are referenced by this report. Some of the patterns that directly lead to meaningful information for the report include Structured Business Driven Scenario, Use Case Realization Promotion, and Capability Consolidation. By using these patterns in combination we have direct traceability from our Services to the Business Goals. The report uses the traceability links to list out all of the business goals and the list of services that map to each goal. But thats just the beginning, the report also identies: Business Goals that do not have any services Business Goals that have too many services
the group
Page 197 of 261
Services that do not map to any Business Goals Services that map to too many Business Goals The Goal-Service Model report is used to ensure direct relationships between the business goals and the services as identied and specied in our SOAD efforts. This report details the traceability between business strategy and IT capabilities. Use of this report enables us to inspect and adapt during development - ensuring that IT stays aligned with the business. The following gure provides the rst high-level summary in the report a simple inventory of goals, Capabilities (candidate services) and service interfaces that exist in the model.
Goal-Service Inventory lists the goals, capabilities and service interfaces in the model
The next gure provides another summary view, providing a business goal realization summary. In this representation we are shown how many of the goals have some form of realization (that is, they are connected to one or more candidate services or service interfaces). We are also alerted to the fact that the model contains candidate services and service interfaces that do not map to any business goals orphaned elements, not owned by any business driver.
the
group
Page 198 of 261
Summary of how goals are realized in the design
Along with these summary views, the report examines each business goal, showing: Performance and metrics Capabilities that realize the business goal (either directly or via use case realization) Service Interfaces that realize the business goal (either via a Capability or direct relationship)
Details for each goal including key performance indicators and how it is realized
There are four patterns that guide the user to generate content that would surface in this report: 1. Structured Business Driven Scenario 2. Use Case Realization Promotion 3. Capability Consolidation 4. Capability Promotion By using these patterns in combination we will have direct traceability from our Services to the Business Goals. The report uses the traceability links to list all of the business goals and the list of services that map to each goal.
the group
Page 199 of 261
When we review the report, we look for: 1. Business Goals that do not have any services 2. Business Goals that have too many services 3. Services that do not map to any Business Goals 4. Services that map to too many Business Goals This report should be generated multiple times during a project. Pattern Instances The Pattern Instances report details each of the patterns that are used within a model. The report lists each pattern instance along with the parameters that have been bound to the pattern instance. In doing so, we can gain insights into which patterns are used, how often they are used, and where in the solution they are being used. This data provides insight into solution quality, as well as team adherence to best practices. This report is applicable across all of the phases covered by the SOAD Model Accelerator. With SOA Governance we want to establish the best practices that the team should follow. Automation makes the application and adherence of best practices actionable and signicantly increases the likelihood of such occurrences. However, we still need to know where and how best practices are being used. The Pattern Instances report helps us meet this need by detailing each of the patterns that are used within a model. The following gure shows a subset of the summary view from the report, where we can see how many instances of each pattern are applied in the model from some of the pattern categories.
the
group
Page 200 of 261
Summary of pattern instances found in a model
The details section of the report lists each pattern instance along with the parameters that have been bound to the pattern instance. This provides insights into which patterns are used, how often they are used, and where in the solution they are used. This data provides insight into solution quality, as well as team adherence to best practices. On the ip side, we can use these insights combined with our understanding of the solution to investigate solution quality (further assistance for defect prevention). Some questions that we should consider when using this report include: What patterns are being used? For each pattern instance, does the use of the pattern align with the needs of the situation? Are some patterns used too frequently? Are some patterns used too infrequently? Does pattern use align with current project status? For example, do we have some services already in Service Specication, yet the only patterns used are related to Business Modeling? Does pattern use align with service interaction scenarios? Do we have simple and limited pattern use, yet complex and involved service interaction scenarios? Or conversely, do we have simple service interaction scenarios, yet prevalent use of sophisticated patterns?
the group
Page 201 of 261
With the report in hand, have we run model validation for clues on where additional patterns should be used? Service Litmus Test Summary Further supporting the goal of Business-IT alignment and successful SOA solution delivery, we perform litmus tests on our services. Litmus tests are conducted on all of the services, following an iterative and incremental approach. The following gure shows a Service Litmus Test summary view. In this summary we can see how many services have been tested, how many have successfully completed testing, how many have not yet been tested, and even cases where we have gotten ahead of ourselves and have a test with no service yet specied.
Overview of service litmus testing coverage
Service Litmus Tests are a critical part of our Governance effort. We need to make sure that we are investing in the right services. Reective of this importance, there is support for Service Litmus Tests across all three approaches to automation. The pattern supports the application of the test, capturing results of the test. The constraints provide a quick and simple method to nd services that have not been tested. The report summarizes and details testing efforts. When performing a Service Litmus test, a minimum set of questions that should be answered include: Is the Service Business Aligned? Does the service provide business functionality? And, does it trace back to a business process or goal? We also need to consider service lifecycle funding, whether and how the service will be used (internally? externally?) - and the implications of such use.
the group
Page 202 of 261
Does the Service have an External Description? Does the service have a WSDL le (or some other comparable representation) that is used to describe the solution? Is this description external and separate from the implementation? Is the Service Reusable? Can the service be reused in all of the processes where it is required? Is the Service Technically Feasible? Taking into account all functional and nonfunctional requirements, is it possible to create the service? Is the Service Composable? Does the service have the right level of granularity? Does the service meet QoS requirements? Is the service stateless? Is the service technically aligned? Along with the summary view, the report details: Service Interfaces that have passed the litmus test Testing results for each question for each service that has not yet passed the litmus test Service Interfaces that have not been tested Tests that exist in the model that do no map to any service interface
Overview of results for each testing aspect
This report is used to detail all of the instances of the Service Litmus Test pattern. Based on the pattern instances and pattern parameters, we can detail the Candidate Service that the test was applied to and the results of the Litmus tests. The report also summarizes the number of Candidate Services, the number that passed the test and the number that failed. Service Litmus Test Details The Service Litmus Test Details report is a companion to the summary report just discussed. In performing Service Litmus Tests we go beyond just recording the true| false results for each test aspect. Recall that within the documentation for each Service Litmus Test pattern instance, we record many details about the testing effort. The SLT Details report accesses this detailed information and makes it available for sharing/reviewing. These two Service Litmus Test reports are an important input for defect prevention efforts. The sooner we can identify and correct defects, the higher the likelihood that the project succeeds.
the
group
Page 203 of 261
Model Constraints Model constraints automate the model validation. To initiate a model validation, all we have to do is select a model (or an element within a model), right-click and select Model Validation. Each enabled constraint is applied to the model elements within the scope specied (i.e. to the model itself or a subset of elements within). If an element in the model violates the rules associated with a constraint, a warning will be displayed in the Problems view and a warning symbol will annotate the model element(s) in the Project Explorer view and in diagrams.
Guide. Highlight. Reinforce. UML patterns, model reports and model constraints complement and reinforce one another. Pattern use leads to better models. Model constraints identify areas that require attention and guide you to a improved models. Reports recognize where patterns have been used and also highlight areas where more work is needed.
The SOAD Model Accelerator provides a set of model constraints spanning Business Modeling, Service Identication and Service Specication. The following gure provides an overview of the collection of constraints provided, organized by category. By default, all of the constraints are enabled. As desired, you can disable constraints either individually or at the category level.
Software Architect provides many constraints; which are enhanced for SOAD by the Model Accelerator.
The business modeling constraints.

the group
Page 204 of 261
The service identication constraints.
The service specication constraints.
The following set of tables provides an overview of the collection constraints.

Overview of the Business Modeling Constraints
Constraint Name Business Goal species Change Value Business Goal species target Date
Description Business Goals should state a scalar value for Change Value. Business Goals should state a date by which the goal will be attained. Valid date formats include: "yyyy-MMdd", "yyyy-M-dd", "yyyy-M-d", "yyyy-MM-d", "MM-ddyy", "yy-MM", "yyyyMMdd", "MMM-yyyy", "MMM yyyy", "MMM dd, yyyy"
the
group
Page 205 of 261
Constraint Name Business Goal species Performance and Measurement values Business goals should have subgoals
Description Business Goals should have performance and measurement values specied. Business Goals should be decomposed into a set of subgoals. Consider using the Business Goal Decomposition pattern.
Overview of the Service Specication Constraints
Constraint Name Catalogs should have categories Capabilities should have multiple responsibilities Catalogs contents are limited to organizational elements Capabilities should be categorized Categories should be placed within Catalogs Categories should be used to categorize model elements
Description A Catalog should have categories. A Capability should have more than one responsibility. Consider using the Capability Consolidation pattern. A Catalog should only have Category, CategoryValue or Catalog elements (or Patterns). A Capability should be categorized. Consider using the Service Category Pattern. A Category should be placed within a catalog. A Category should be used to categorize elements within the solution.
the
group
Page 206 of 261
Overview of the Service Specication Constraints
Constraint Name Additional details for SLT should be captured via Documentation A Participant should not use or realize interfaces A Participant should provide or consume services via ports Candidate Services should be evaluated via Service Litmus Tests MessageType elements should have public attributes MessageType elements should not have operations Service Contract should have Consumers and Providers Service Interface should be categorized Service Interface should use Document Style Parameters Services Architecture should have roles participating
Description When detailing SLT results, use the documentation eld to capture additional details. During design a Participant should not use or realize interfaces. Service and Request ports should be used. A Participant should have at least one Service or Request port. A Service Litmus Test should be performed for each Service. Consider using the Service Litmus Test pattern. A MessageType should have only public Attributes.
A MessageType should not have Operations.
A Service Contract should have Consumers and Providers. A Service Interface should be categorized.
A Service Interface should use Document Style Parameters through the use of MessageType elements. A Services Architecture should have Participants or Capabilities that participate.
In the following sections, well walk through some short examples of working with the model constraints. Example: Business Goal KPIs
the group
Page 207 of 261
Picking up from where we left off in the Business Goal Decomposition pattern, we see that we dened a set of Business Goals and the relationships between them.
Business Goal hierarchy
Having the structure is great, but are these well described Business Goals? Are we able to use these as they are currently dened to guide our efforts and measure success? Lets validate the model and see if the business modeling constraints identify any issues.
the
group
Page 208 of 261
Requesting model validation
After validating the model, we see that a number of the Business Goals have not been sufciently specied. The Business Goal species Performance and Measurement values constraint has generated a number of warnings.
the
group
Page 209 of 261
Warnings generated by the validation
Going back to our overview diagram, we also see that the elements on the diagram have been updated to highlight those that need attention.
Diagram is updated to show markers on elements with issues
We switch the view to show the properties associated with the BusinessGoal stereotype. In doing so, we can clearly see that only our Cost Reduction goal has Performance and Measurement information detailed.
the
group
Page 210 of 261
View updated to show stereotype properties
We update the model and revalidate.
the
group
Page 211 of 261
Business Goal properties updated and validated again.
We still have one Business Goal that still needs attention. In this case, we need to gure out how to measure this goal. Once weve determined and recorded the value, we can revalidate and have the warning removed. Example: Capability Responsibility Constraint We start with a set of Capabilities, candidate services, that have been identied.
The Capabilities before validation.
We run the model validation and nd that all three of them have warnings. Each of these Capabilities has only one responsibility.
the group
Page 212 of 261
The validation nds that all three of the Capabilities need attention.
We decide that an approach to solve this issue is to the use Capability Consolidation pattern. In this case we decide to promote responsibilities to the Customer Service Capability. The other two capabilities have the stereotype removed, but a relationship is created to maintain traceability. We run the validation again and see that all of the warnings have been addressed.
After using the pattern, weve xed all of the issues.
Example: Service Litmus Test Constraint We start with a couple of Capabilities within our model.
the
group
Page 213 of 261
The set of Service Interfaces.
We run the model validation and see that warnings are created.
The Capabilities have warnings.
We consult the model and conrm that the Capabilities are not yet participating in Service Litmus Tests. We add an instance of the Service Litmus Test pattern to the model and bind the Scheduling capability as a parameter.
We can see that Scheduling now participates in a Litmus Test.

the group
Page 214 of 261
One more warning to address by applying another Service Litmus Test.
Running the validation again, we see that the warning is removed from the Scheduling capability and the list in the Problems view shows only one issue. Cheat Sheets Patterns, Constraints, Reports and now Cheat Sheets provide a compelling approach to designing and governing SOA solutions. The Cheat Sheets provide: SOAD and SOA Governance check lists Pointers to reference materials Streamlined access to Rational SOMA content Short videos showing how to perform tasks The following screen capture shows the Cheat Sheets provided by the Model Accelerator. In total, the Model Accelerator provides eleven cheat sheets.
View of the Cheat Sheets provided by the Model Accelerator.
the
group
Page 215 of 261
Once you select a Cheat Sheet, the Cheat Sheets view is added to the Modeling perspective. In this way, you can access the guidance while you are actively working on your model. If you're not familiar with Cheat Sheets, the following image provides a glimpse into one of the Cheat Sheets ("Applying Service Litmus Tests"):
The Applying Service Litmus Tests Cheat Sheet.
Identifying Project Risk With any project, we always try to identify areas of risk and attack them. A simple step for attacking risks is following an iterative approach; addressing the highest risk items in early iterations. No one likes to get to the end of a project to nd that the riskiest items are yet to be addressed. Leaving the riskiest items to the end of the project leads to a loss of predictability and the ability to deliver. All of which begs the question How do you identify risk? What good is a strategy for addressing risk management through project planning if we are not nding the right risks? A few tips for identifying risks when creating SOA solutions: 1. Understand and evaluate the complexity of the business processes you are implementing. Evaluate your business processes and rank them according to their level of complexity. At a minimum, the most complex processes are analyzed and
the group
Page 216 of 261
2.
3.
4.
5.
drive design in early project iterations. Ideally, we refactor such processes to make them less complex. Use models to understand the problem domain and to work through the solution. Dont rush to code the solution. Domain Specic languages are especially helpful as they reduce the need for mapping between generic terms and domain specic terms. Such mappings increase risk by allowing for details to be overlooked or misunderstood. Service Litmus Tests should be conducted to ensure that before an investment is made in a service. We need to understand whether the service is business aligned, is technically feasible, is reusable and can be composed into processes. Results should be recorded, shared, and reviewed. Sometimes risk sneaks into the project due to poor adherence to best practices and standards. An approach where we provide the team with best practices is insufcient. a. We need to understand where best practices have been used and that they have been applied correctly. b. Design reviews are proven to be as effective as QA efforts in nding defects. Use these reviews to identify and address hidden risks. Risk identication is a task that is revisited throughout a project. It is not a one-time effort that only occurs at the beginning of the project. Use tools and techniques that allow you to evaluate and share status quickly and easily.
the
group
Page 217 of 261
Part V. Installation, Conguration & Assistance
the
group
Page 218 of 261
Installation Requirements 1. The SOAD Model Accelerator requires either: IBM Rational Software Architect for WebSphere Software v8.0.3 or later. IBM Rational Software Architect v8.0.3 or later with the Rational Software Architect Extension for SOA and WebSphere. 2. Supported Operating Systems: Software Architect for WebSphere supported platforms (Windows and Linux) 3. Software Architect for WebSphere Conguration Requirements. Conrm that, at a minimum, you have the following packages installed via the IBM Installation Manager: Solution Architecture and Model-Driven Development Extensibility and patterns-based engineering Life cycle and tool integrations, at a minimum: Process Advisor and Process Browser Architecture Reporting, at a minimum: Business Intelligence and Reporting Tools (BIRT) Architecture reporting (UML) with BIRT Integrated architecture frameworks, at a minimum: Service modeling SOA and WebSphere Installing the SOAD Model Accelerator 1. Conrm that you meet the installation requirements. 2. Unzip the Update Site that was provided (SOAD-Update-Site.zip) The remaining steps should be performed in Software Architect for WebSphere. 3. Click Help > Install New Software.... 4. Click Add... button that is located beside the Work with eld.
the
group
Page 219 of 261
Starting the installation process
5. Click Local... beside the Name eld.
Need to specify the location of the update site
6. Select the location where you unzipped the archived update site.
the
group
Page 220 of 261
Specifying the folder for the SOAD Model Accelerator Update Site
7. Review the Location and then click OK.
Review the location and optionally provide a name
8. Expand the category labelled Service-Oriented Analysis and Design and select the SOAD Model Accelerator. Then click Next.
the
group
Page 221 of 261
Select the component to install
9. Optional: Review the install details by clicking on More.... 10.Click on Next.
Initial component details.
11.Review the License Agreement. If you agree with the terms, select I accept the terms of the license agreement and then click Finish.
the
group
Page 222 of 261
To install and use the Accelerator, read and accept the License Agreement
12. Click OK to acknowledge the security warning.
Click OK to acknowledge the warning
13. At the completion of the installation process you will need to restart Software Architect for WebSphere. Click Restart Now.
Restart for the new capabilities to be available
14. Conrm the installation. a. Click Help > About.

the group
Page 223 of 261
b. You should see The Emphasys Group logo in the About dialog window.
The Emphasys Group logo in the About dialog
c. Click Installation Details to open a dialog showing pages that provide more detail about your installation. d. Click the Installed Software tab to see a list of the software items that you have installed into your system. e. Scroll through the list until you locate the SOAD Model Accelerator
The Model Accelerator in the list of installed software
Uninstalling the SOAD Model Accelerator To uninstall the SOAD Model Accelerator, from within Software Architect for WebSphere: 1. Click Help > About and then click Installation Details to open a dialog showing pages that provide more detail about your installation.
the group
Page 224 of 261
Installation Details is entry point to the removal process
2. Click the Installed Software tab to see a list of the software items that you have installed into your system. 3. Scroll through the list until you locate the SOAD Model Accelerator.
Locate the Model Accelerator in the list of installed software
4. Click Uninstall.... 5. The Uninstall Details page will show you a list of the items that will be uninstalled.
the
group
Page 225 of 261
Review the Uninstall Details
6. Click Finish to start the uninstall. 7. Once all of the software is uninstalled successfully, you will be prompted to restart for the Workbench. Click Restart Now when asked to exit and restart the Workbench for the changes to take effect.
Restart to complete the process
8. After Software Architect for WebSphere restarts, you may still nd a listing for the SOAD Patterns in the Pattern Explorer. If so, you can delete the entry.
the
group
Page 226 of 261
Removing the empty category in the Pattern Explorer view.
Accessing SOAD Model Accelerator Help 1. Click Help > Help Contents.
Accessing the main help content.
2. Locate the SOAD Model Accelerator topic.
the
group
Page 227 of 261
The SOAD Model Accelerator topic
3. Expand the SOAD Model Accelerator topic to see the sub-topics.
Overview of the help topics.
the
group
Page 228 of 261
Part VI. Rational Software Architect for WebSphere Tips
the
group
Page 229 of 261
Overview Rational Software Architect for WebSphere Software From a technical implementation point of view, the SOAD Model Accelerator leverages and enhances (Amplies!) Rational Software Architect for WebSphere Software. Lets take a closer look at the underlying platform and the capabilities provided.
Complementing the Software Architect for WebSphere experience
Software Architect for WebSphere ships with a number of transformations that assist with creating Service-Oriented solutions. However, there is still a burden placed on the user to craft the model that serves as input to transformations that generate WSDL, SCA components and XSDs (or as input to custom transformation to generate other related collateral). Software Architect for WebSphere has many features and is highly congurable. If you nd yourself in a situation where a feature is not visible check that you have the associated Capability enabled. Another option to consider is to use Installation Manager to modify your conguration (in the case where a component was not installed). Service Realization and Implementation The SOAD Model Accelerator with its focus on Business Modeling, Service Identication, Service Specication and SOA Governance - positions us well for further work focused on Service Realization and Service Implementation. The artifacts we produce by using the Accelerator provide a solid foundation for these follow-on efforts.
the
group
Page 230 of 261
The section Further Resources highlights content that will help you with taking the next steps in nalizing and then implementing your design. Service Realization In Service Realization, we continue to work in Software Architect for WebSphere further enhancing and embellishing our models. This work is focused on deciding how to realize the service components of our solution. We add details about the components that realize the services that weve specied. The result is that we ensure that the overall solution architecture satises our functional and non-functional requirements. As discussed in Rational SOMA, you would perform tasks such as: Make Service Component Realization Decisions and Detail Service Component Layers. Service Implementation In Service Implementation we transition from modeling into solution creation. We add any further details needed within our model to support implementation. If we are using a transformation such as the UML to WSDL, UML to SCA, UML to XSD or a custom transformation - we add any further markup needed to the model to support the transformation. For an example, consult the Article: Design and develop a more effective SOA, Part 5 as it provides guidance on using SoaML models as input to the UML to SCA transformation. We also use the development and testing capabilities of Rational Application Developer for WebSphere Software and/or IBM Integration Developer. Models, Diagrams and Views The essence of modeling is that it is a simplication of reality. Using a model allows us to hide details that unnecessarily complicate and hinder our understanding. Ideally, we can take things a step further - leveraging simplication, we use models to understand, communicate and hopefully generate parts of our solution. To support us in these efforts, we use diagrams. A model will contain many diagrams providing us with different views on model elements. In that way we can focus on specic areas or tailor the message as we communicate with others. And within diagrams - not only can we adjust which elements we show - but we can also change the appearance of the elements on the diagram - again with a focus on hiding unnecessary details. A few things to keep in mind as you work with diagrams in Software Architect for WebSphere: 1. Use lters. Right click on an element in a diagram and select Filters > ... and then choose from being able to show relationships, related elements, show\hide compartments, stereotype visibility and style, parent style and attribute style.
the
group
Page 231 of 261
Filters enable to you to highlight and focus
2. Minimize the number of elements on the diagram. Diagrams with too many elements are difcult to comprehend. 3. Give your diagrams meaningful names. When you create a new package, a main diagram is created. Get in the habit of updating these diagram names to be more descriptive. Such a habit makes it easier to work with a number of diagrams at once, as you can quickly and easily switch between tabs in the diagram editor. 4. Always consider consumability. In addition to the previous tips - always consider how you can make your diagrams more consumable. Some additional approaches to consider would be using a logical layout for the elements, minimizing the cross of relationship lines, and incorporating the use of color54 . Applying UML Patterns To apply a UML Pattern, perform the following steps: 1. If you have not already done so, add the Pattern Explorer View to your Modeling Perspective.
54
Take a look at the Model in Color plug-in for RSA. Get automated, consistent color in your UML models by using the UML Coloring plug-inm Steve Arnold, IBM DeveloperWorks, http://www.ibm.com/ developerworks/rational/library/10/getconsistentcolorusingumlplugin/index.html
the group
Page 232 of 261
Accessing additional Views
Select the Pattern Explorer view.
2. Create a diagram (typically a Class diagram or a Freeform diagram) in the model where you would like to apply the pattern.
the group
Page 233 of 261
3. Locate the pattern of interest in the Pattern Explorer
The SOAD Patterns in the Pattern Explorer view
4. Drag and drop the pattern from the Pattern Explorer view to your diagram. This will create an instance of the pattern. Note: The Pattern Explorer view lists the pattern denitions. You can create many instances of a Pattern. Each instance is based on the pattern denition. Each instance operates and exists independently. Note: You can customize the categories used to organize the patterns in the Pattern Explorer. Weve provided a default approach to organization. However, dont feel you need to stick with the defaults. 5. Bind model elements to the pattern parameters. Typically this is done either by dragging and dropping existing model elements onto the pattern instance OR by
the group
Page 234 of 261
clicking on the pattern instance to create new model elements of the type required by the parameter.
Binding a parameter via drag and drop
Creating and binding a new model element via the Pattern Instance
6. As parameters are bound to the pattern, the existing model elements may be updated, new elements may be generated, or a combination of both activities may occur. 7. Update the diagram to highlight pattern related model elements - show relationships between elements, show newly generated elements, or the relationships between the pattern and the bound parameters. Reapplying UML Patterns Typically, model elements will continue to evolve over the course of the project. This means that the model elements that you have used as parameters to a pattern will likely change sometime after they have been bound to the pattern. To reapply the pattern, perform the following steps:
the group
Page 235 of 261
1. Locate the pattern instance in the Project Explorer or on a diagram. 2. Right-click on the pattern instance and select Patterns > Reapply. Unapply UML Patterns Unapply is a manual process. Applying UML patterns as part of the SOAD Model Accelerator leads to additive changes being made to a model. However, when unapplying a pattern, the expectation is that model elements would be deleted. However, in reviewing the use of the Accelerator with customers, a consensus was reached that the patterns should not delete model elements. The reasoning is that after pattern application - additional enhancements can be made to the generated model elements. If the pattern deleted the underlying element - work would be lost. To support you in unapplying the patterns - we have taken steps to detail the behavior of each pattern so that it is possible to retrace the impact of the pattern and take steps to delete the elements as desired. The process to be taken includes: 1. Review the Pattern Documentation 2. Locate the Pattern Instance in your model 3. Note the parameters that are bound to the pattern. 4. Locate the elements that have been updated\generated as a result of the pattern 5. Delete the desired elements from the model 6. Delete the model instance. Working with Proles As discussed in the section Domain Specic Languages - in working with the SOAD Model Accelerator, we use the Business Modeling and SoaML proles. To add a prole to a model, perform the following steps: 1. Create a Modeling project. In this case, weve added a Blank model package to the project.
Staring with a Blank Package
2. Select the Blank Package model element and then direct your attention to the Properties view.
the
group
Page 236 of 261
The General tab of the Properties view
3. Select the Proles tab within the Properties view. This tab shows all of the Proles that have been applied to the model. Click on the Add Prole... button to add a prole.
The Proles currently applied to the model.
4. Select the Prole of interest using the drop-down found on the Select Prole dialog.
the
group
Page 237 of 261
Selecting the Business Modeling prole.
5. Once youve selected the prole, click OK.
Conrm the selection and click OK.
6. The selected prole is now listed on the Proles tab in the Properties view.
the
group
Page 238 of 261
Updated list of applied proles.
Applying Stereotypes Assuming that you have already applied one or more proles to you model, you can now use Stereotypes from the proles. 1. Add an element to the model. In this case, weve added a Class to the model. However, we want this element to represent a Business Goal.
Starting with a simple class element.
2. Switch to the Stereotypes tab of the Properties view. Here we see that no Stereotypes have been applied to the model element.
the
group
Page 239 of 261
The Stereotypes tab within the Properties view.
3. Click on Apply Stereotypes.... Select BusinessGoal and then click OK.
The list of stereotypes that are available and applicable to the current model element
4. Review the Stereotypes tab of the Properties view and conrm that the Stereotype was applied. Also note that a Stereotype may have additional properties that you can use to add more information about the element (in this case, more information about a Business Goal).
the group
Page 240 of 261
Stereotype properties
5. If our diagram, we see that the class has been updated to include the stereotype and also has an icon specic to that stereotype.
View of the model element with the stereotype applied
6. To view the stereotype properties on a diagram element, right-click on the element and select Filters > Stereotype and Visibility Style > Show Stereotype Attribute Compartment When Not Empty.
the
group
Page 241 of 261
Making Stereotype properties visible for a diagram element.
7. You can also set this as a preference to apply across all of your diagrams. 7.1. Select Window > Preferences. 7.2. In the Preferences dialog, navigate to Modeling > Appearance > Shapes. 7.3. Select Show stereotype attribute compartment when not empty.
Making Stereotype properties visible for all diagram elements.
7.4.
Click Apply, then click OK.
Model Validation and Constraints To enable viewing of preferences for Model Validation, perform the following steps: 1. Select Window > Preferences.... 2. Select General > Capabilities
the group
Page 242 of 261
Eclipse Capabilities...not to be confused with SoaML::Capability!
3. Click Advanced to enter the Advanced Capability conguration editing dialog.
Advanced Capability conguration is available from bottom-right of the dialog.
4. Select Development. 5. Enable Eclipse Modeling Framework.
EMF needs to be enabled to access Model Validation conguration.
6. Click OK. 7. Click OK. 8. Conrm that Model Validation is an available and congurable Preference. Select Window > Preferences... 9. Select Model Validation.
the
group
Page 243 of 261
Model Validation conguration is now available in Preferences.
10.Expand the Model Validation node and select Constraints. 11.Review and congure SOAD Model Accelerator Constraints as desired.
SOAD Model Accelerator Constraints.
Model Validation and UML Patterns Note - Validation has an issue with the template binding approach for patterns. To work with UML patterns and not see unnecessary error message, you need to turn off that validation, otherwise will get errors on pattern use!
the group
Page 244 of 261
To avoid errors on UML Pattern instance disable the Template constraint
Generating Reports To generate a Report, perform the following steps: 1. First, create a Report Conguration. Select Run > Report > Report Congurations...
Gaining access to the Report Congurations.
2. Select BIRT Report and then click on the New Launch Conguration icon in the toolbar.
the group
Page 245 of 261
Create a new Report Conguration
3. Youll then be presented with a Report Congurations dialog. This needs to be customized - including details on the source model, report location and output format.
Conguration supports report, data source and format selection.
4. Select a built-in report. Navigate to SOAD Model Accelerator Reports and then, for example, select Service Litmus Test Report. Then click OK.
the
group
Page 246 of 261
SOAD Model Accelerator Reports.
5. In the Report Data section, select UML Model in the Data Sources pane, then click on the Add button beside the Instance Models pane. Click Browse Workspace... to select a Model from within your workspace.
Specify the UML Model that will serve as a Data Source.
6. Select the .emx le for the model(s) that will serve as the Data Source. Then click OK.
the
group
Page 247 of 261
Select the .emx le for the model.
7. In the Report Output section, specify a Location (including name) for the report. In addition, select the publishing format.
Options for publishing formats.
8. Review the conguration that youve created. If you are satised with the settings, click Apply to save the conguration. You can then click on Report to run the report.
the
group
Page 248 of 261
A fully populated Report Conguration.
9. If youd like to run the same conguration again later on, you can access recent congurations via Run > Report.
Reuse the conguration to quickly rerun the report.
the
group
Page 249 of 261
Model Transformations
Set of SOA Transformations provided by Software Architect for WebSphere Overview of Out-of-the-Box Transformations 55
Transformation Name BPMN-toService-Model BusinessProcess-toService Model
Description The BPMN-to-Service-Model transformation transforms business process models into UML service models. The Business-Process-to-Service-Model transformation enables you to transform a business analysis model, which you might import from IBM WebSphere Business Modeler, into an architected solution UML model, which is also called a service model. The service model fullls a traceable contract between business analysis and high-level design.
55
Descriptions of the transformations is sourced from the Rational Software Architect for WebSphere help content. You can access the InfoCenter for v8.5 at: http://pic.dhe.ibm.com/infocenter/rsahelp/v8r5/ index.jsp
the group
Page 250 of 261
Transformation Name UML-to-SOA
Description You can use the UML-to-SOA transformation and its extensions to create software services artifacts for serviceoriented architecture (SOA) solutions. The UML-to-SOA transformation invokes several other transformations to generate different types of output, such as SCDL, WSDL, XSD, and BPEL. You can create UML representations of web services and run the UML-to-WSDL transformation to generate Web Services Description Language (WSDL) documents. WSDL documents are les that have .wsdl as a le name extension. You can use the UML-to-SCA transformation to transform UML models, including service models, with or without the Software Services prole or Services Modeling (SoaML) prole applied, into Service Component Architecture (SCA) projects and artifacts for service-oriented architecture (SOA) solutions. You can use UML to create a visual representation of an XML schema, and then you can run the UML-to-XSD transformation to generate an XSD le. A model can contain elements that represent XSD elements, as well as elements that are not related to XSD. You can transform a UML model that has the Representational State Transfer (REST) prole, and optionally the Java API for RESTful Web Services (JAXRS) prole, applied to it into Java implementations of REST service elements in a JAX-RS web project.
UML-to-WSDL
UML-to-SCA
UML-to-XSD
UML-to-REST
Service Model Template Software Architect for WebSphere provides a Service Model template. The model template provides guidance on perspectives to use and some common combinations of model elements. In addition, there are many notes and tips throughout the template guiding you on the use of the template and modeling SOA solutions.
the
group
Page 251 of 261
Template with set of perspectives and building blocks
Note: In working with perspective packages, we typically do not put semantic elements within the package structure. We use these packages for providing \addressing different views of the model. That is, these packages contain a set of related diagrams - tailored to a specic audience. Rational SOMA Integration You can access Rational SOMA content via the Process Browser. To do so, click on Help and then select Process Browser.
the
group
Page 252 of 261
Access Rational SOMA via the Process Browser
When working with the Process Browser and Rational SOMA, you are presented with four views into the process content: 1. Designing Service Solutions using Rational Software Architect 2. Team 3. Rational SOMA 2.9 Workow 4. SOA Architectural Patterns
the
group
Page 253 of 261
View of the Process Browser and Rational SOMA
Cheat Sheets and SOMA Using the SOAD Model Accelerator Cheat Sheets will provide you with streamlined access to relevant content within SOMA. There are hundreds of content pages published within SOMA. The Cheat Sheets direct you to a relevant subset and help you to nd answers more quickly.
the
group
Page 254 of 261
Part VII. Resources & References
the
group
Page 255 of 261
Resources IBM RedBook: Building SOA Solutions Using the Rational SDP Rational SOMA v 2.9: http://www-01.ibm.com/support/docview.wss?uid=swg24024567 SoaML Specication: http://www.omg.org/spec/SoaML/ IBM Rational Method Composer plug-in for SOA Governance: http://www.ibm.com/ developerworks/rational/downloads/06/plugins/rmc_soa_gov/overview.html SOA Design Patterns: http://www.soapatterns.org/ IBM Whitepaper: Rational UML Prole for Business Modeling, March 2004 Using models to design business processes and services: Assembling components with modeling tools Jim Amsden Series: Modeling with SoaML, the Service-Oriented Architecture Modeling Language Part 1: Service Identication Part 2: Service Specication Part 3: Service Realization Part 4: Service Composition Part 5: Service Implementation Portier & Hodgkinson: Model Service-Oriented Architectures with Rational Software Architect Part 1: Case Study, Tools, and the Business View Part 2: Modeling the business domain Part 3: External system modeling Part 4: Use Case Models Part 5: Service Identication Dunnavant & Johnston Series: Design and develop a more effective SOA Part 1: Introducing IBM's integrated capabilities for designing and building a better SOA Part 2: Condently dene and design your service-oriented solutions using Rational SOMA 2.9 Part 3: Describe business processes using Rational Software Architect and Business Process Modeling notation Part 4: Build and manage your service-oriented solution designs using Rational Software Architect and SoaML Part 5: Build service-oriented solutions faster and more accurately with Rational Software Architect 8.0.2
the
group
Page 256 of 261
SOA and Agile http://scaledagileframework.com What does SOA bring to Agile? Or Agile to SOA?http://www.zdnet.com/blog/serviceoriented/what-does-soa-bring-to-agile-or-agile-to-soa/8041 Agile and SOA, Hand in Glove? Agile Modeling: Enhancing Communication and Understanding AgileModeling.com: The Agile Modeling home page, an excellent and detailed resource created and maintained by Scott Ambler. Essentials of Agile Modeling - Workshop focused on providing foundational skills for Agile Modeling. Top 3 Tips for Using Automation to Bring Governance to Service-Oriented Analysis and Design : http://servicetechmag.com/I60/0312-1 Frequently Asked Questions Here are some Frequently Asked Questions (FAQs) related to getting started with the SOAD Model Accelerator: 1. Do I have to use all of the automations? Which automations you use is up to you and the situation at hand. You can choose to use just one of the automations or all of the automations. We think that there is great value is using the automations in combination and using each automation multiple times. 2. How do I know which pattern to use? As with patterns in general, we select patterns based on the problem we are trying to solve. Each pattern description provides an overview of the pattern and a description of the problem that is being addressed. In addition, the patterns are classied according to the phase in which they are used. Last, but not least, the pattern description includes a section discussing related patterns to consider. 3. Which pattern do I start with? Building on the answer from the previous question, additional guidance on when, where and what you should be trying to create (and in turn which patterns to use) comes from Rational SOMA and SoaML. Weve given each of the patterns a meaningful name and classied them according to the phase of the SOAD effort to help align the use of the patterns with Rational SOMA. 4. What if I want to use BPMN instead of Business Modeling? Using BPMN as a starting point is a great way to understand the needs of the business. Software Architect for WebSphere supports BPMN out of the box. If you prefer to use BPMN rather than the Business Modeling prole thats a technically valid and reasonable approach to understanding the business. You can then pick up with using the SOAD Model Accelerator once you have your candidate services identied. The Accelerator can then assist you with Service Identication and Service Specication and overall SOA Governance.
the
group
Page 257 of 261
5. Some of the patterns seem quite simple in what they do - whats the value in using them versus interactive modeling? Even the most simple patterns add value to your models and lead to better solutions. At a minimum, the patterns enhance the documentation within the model, guide users to solve recurring problems, and support model reporting - highlighting where within the solution best practices are being used. 6. The SOAD Model Accelerator is great - but I wish that they did XYZ instead. Can you help? Give us a call, wed be happy to hear about your needs. We offer consulting services to help with customizing the Accelerator. In addition, we have new products under development that might meet your needs. 7. Asides from this document, are there other ways to learn how to work with the SOAD Model Accelerator? Yes - we offer training, coaching and consulting services. Give us a call or drop us a note to discuss - info@emphasysgrp.com. Annotated SoaML Example Weve included another view of some of the diagrams from the Dealer Network example. In this representation weve added some annotations to the diagrams to further highlight the SoaML elements that are used.
Sketch of the elements that participate in this example
the
group
Page 258 of 261
A ServicesArchitecture is used to show the participants and service contracts
"
A look inside one of the service contracts
the
group
Page 259 of 261
A simple approach to dening the MessageType elements.
Dening a provider (and using the MessageType elements we just dened)
Ports are added to the participants and then typed
the
group
Page 260 of 261
Show how the participants communicate via a service channel
the
group
Page 261 of 261
This book details and provides guidance on realizing an Agile SOA approach through the combined application of OSIMM, Service-Oriented Analysis and Design (Rational SOMA and SiSaS), Scaled Agile Framework, SOA Governance and of course the SOAD Model Accelerator.
Through these efforts we create models to help us understand, define, communicate and generate SOA-based software solutions. These models use languages including UML, BPMN, SoaML and the UML Profile for Business Modeling. We also look at how we can use Patterns, Constraints, Cheat Sheets and Reports to streamline and increase the effectiveness of our SOA efforts.
At The Emphasys Group we help our customers build better software, more quickly. We bring years of outstanding experience and expertise to help customers acquire new skills, use tools more effectively and increase their Velocity through our unique and holistic application of Automation, Reuse and Agile best practices. Through this book we strive to contribute to the community and improve how we all deliver solutions.
Web: http://www.theemphasysgroup.com/contact-us/ Email: info@emphasysgrp.com Phone: 1.888.784.7759 Twitter: @EmphasysGroup

Designing Solutions Using The SOAD Model Accelerator-V1.3

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Designing Solutions Using The SOAD Model Accelerator-V1.3

Caricato da

Copyright:

Designing Solutions using the SERVICE-ORIENTED ANALYSIS AND DESIGN MODEL ACCELERATOR

Lee Ackerman Randy Lexvold Craig Rudman

SOA with Emphasys

Lee Ackerman Randy Lexvold Craig Rudman

Part I. Introduction to the SOAD Model Accelerator!

Part II. SOA Modeling!

Part III. Pattern Reference !

Part IV. SOA Governance !

204 207 212 213 215 216

Part V. Installation, Conguration & Assistance!

Part VI. Rational Software Architect for WebSphere Tips!

245 250 251 252

Part VII. Resources & References!

Publications written by our team.

Part I. Introduction to the SOAD Model Accelerator

Architectures critical role in succeeding with SOA

The Open Group Service Integration Maturity Model, http://www.opengroup.org/soa/source-book/osimmv2/ index.htm

The Open Group Service Integration Maturity Model3

The Open Group Service Integration Maturity Model, http://www.opengroup.org/soa/source-book/osimmv2/ index.htm

Benets of achieving higher levels of maturity4.

The Open Group Service Integration Maturity Model, http://www.opengroup.org/soa/source-book/osimmv2/ index.htm

The Open Group Service Integration Maturity Model, http://www.opengroup.org/soa/source-book/osimmv2/ index.htm

IBMs Actionable Business Architecture6

The SOA Manifesto.

The Agile Manifesto.

The principles underlying the SOA Manifesto.

The principles underlying the Agile Manifesto.

Interested in learning more about the Scaled Agile Framework? http://scaledagileframework.com

The disciplines that are involved in creating SOA solutions.

SOAD covers these disciplines and adds in SOA specic aspects.

SOMA inuences, practices and work products.

Image from Rational SOMA, copyright IBM.

Image from Rational SOMA, copyright IBM.

Overview13 of artifacts, relationships and mapping to MDA levels of abstraction

Workow following in creating the Business Architecture Model

Workow following in creating the System Architecture Model

Highlighting the alignment between the two approaches.

Forrester/Dr. Dobbs Global Developer Technographics Survey, Q3 2010

Scaled Agile Framework! Big Picture

Scaled Agile Framework big picture that brings it all together16

SOAD Model Accelerator automations.

Overview of SOAD Model Accelerator impact areas

Part II. SOA Modeling

And todays teams are often dispersed to locations worldwide.

High-level view of the Dealer Network.

Description (SoaML Specication)

Catalog Category Consumer

Catalog Category Consumer

Description (SoaML Specication)

Description (SoaML Specication)

SoaML support for alternative modeling approaches

Approach Simple Interface

Simple request-response service interaction.26

More sophisticated bi-directional service interaction.

Multi-party, multi-directional service interaction.

High-level view of the Dealer Network via a ServicesArchitecture.

Simple request-response service interaction.

The interaction of these participants via a ServiceChannel

Dening the ServiceContract for Place Order.

High-level view of the Dealer Network via a ServicesArchitecture.

Service Contract for Escrow Purchase.

Interaction between the participants for secure purchase.

Use the Collaborating Interface pattern to dene SecureSale

Dene collaborating interface for SecurePurchase

Dene collaborating interface for EscrowPurchase

Dening the Dealer participant