The document discusses key concepts related to business process management (BPM) and service-oriented architecture (SOA). It defines BPM and differentiates it from workflow management. It explains how BPM relates to SOA and how services are parts of business processes. The document also discusses business process modeling and standards like BPEL. It covers approaches to identifying services and contrasts orchestration with choreography.
Fundamental modeling constructs of BPMN 2.0 - Activity, Gateway, Sequence Flow, Pool and Lane. Part of the Business Process Management coursework at Stevens Institute of Technology.
Slides from a webinar that I did recently for TIBCO. Full webinar replay with audio available at http://www.tibco.com/mk/2007/bpm-bpm11-jul-07usarc.jsp
Fundamental modeling constructs of BPMN 2.0 - Activity, Gateway, Sequence Flow, Pool and Lane. Part of the Business Process Management coursework at Stevens Institute of Technology.
Slides from a webinar that I did recently for TIBCO. Full webinar replay with audio available at http://www.tibco.com/mk/2007/bpm-bpm11-jul-07usarc.jsp
Business Process Model and Notation (BPMN)Peter R. Egli
Overview of Business Process Model and Notation (BPMN) language for modeling business processes.
When implementing business processes, there is usually a large gap between the business semantics (process, activity, participant, orchestration, choreography, data items etc.) and the technical implementation languages (REST, WSDL, transport protocol, message bus etc.). BPMN has the goal of bridging this gap by providing a standard notation for describing business processes plus a standard mapping of this notation into an executable description language like WSBPEL. The BPMN 2.0 standard even allows executing BPMN business models directly without the need of a translation.
The core notation elements of BPMN are flow objects to model activities and events, data objects to model pieces of information, connecting objects to model information and control flow, and swimlanes to model process participants. Four different diagram types allow the modeling of processes, process choreographies, collaboration between participants and conversations.
Slides from a webinar that I did recently for TIBCO. Full webinar replay with audio available at http://www.tibco.com/mk/2007/wsemtbpdesign08-aug-07usarc.jsp
This was a 1-hour BPMN Intro/Primer webinar I presented at ASPE. Just to be clear, I design/develop and teach classes for ASPE ("Modeling Processes using BPMN" being one of those classes), so one of goals was to tease audiences into wanting to learn more(and attending my class:-). Beyond that, the main goal was to share useful/interesting information and to ignite questions and curiosity about this important topic. Let me know what you think. Thanks, Razvan:-)
Brief presentation summarizing some new features introduced by BPMN 2.0, focusing on few points (made to answer to particular needs of a research project)
The Role of the Enterprise Architect in Business Process ReengineeringRichard Freggi
Business Process Reengineering is often a challenging undertaking. This paper is a case study, sharing practical experience of how the enterprise architect can help in three ways:
• Provide a common language allowing different organizations, consultants and IT teams to communicate effectively
• Set the right level of abstraction to facilitate analysis and solution of complex questions
• Reconcile user’s wants and needs with the capabilities and constraints of IT systems
Reference is made to the Zachman Framework, especially the columns for “Data”, “Function” and “People”; and how these columns can be used to interact with stakeholders using UML (Unified Modeling Language).
COEPD - Center of Excellence for Professional Development is a primarily a Business Analyst and PMP Training Institute in the IT industry of India head quartered at Hyderabad. COEPD is expert in PMP Training and Business Analyst Training in Hyderabad, Chennai, Pune , Mumbai & Vizag. We offer PMP and Business Analyst Training with affordable prices that fit your needs.
COEPD conducts 4-day workshops throughout the year for all participants in various locations i.e. Hyderabad, Pune. The workshops are also conducted on Saturdays and Sundays for the convenience of working professionals.
For More Details Please Contact us:
Visit at http://www.coepd.com or http://www.facebook.com/BusinessAnalystTraining
Center of Excellence for Professional Development
3rd Floor, Sahithi Arcade, S R Nagar,
Hyderabad 500 038, India.
Ph# +91 9000155700,
helpdesk@coepd.com
TOWARDS AUTOMATION OF SOA-BASED BUSINESS PROCESSESIJCSEA Journal
The adoption of business processes to design business activities is becoming a reality to a significant number of companies. In addition, the Service-Oriented Architecture (SOA) is being used in diverse situations for the execution of business processes using computational resources. In this context, the need of business process automation appears with high relevance. In this work, we present a solution named BPA-SOA, which aims to automate SOA-based business processes, specified in BPMN, into WS-BPEL executable processes. In BPA-SOA, business and service information can be specified at the business level, translated into executable artifacts, deployed in execution-level resources and enforced at runtime. An illustrative scenario is presented to better illustrate and showcase the proposed solution.
Business Process Model and Notation (BPMN)Peter R. Egli
Overview of Business Process Model and Notation (BPMN) language for modeling business processes.
When implementing business processes, there is usually a large gap between the business semantics (process, activity, participant, orchestration, choreography, data items etc.) and the technical implementation languages (REST, WSDL, transport protocol, message bus etc.). BPMN has the goal of bridging this gap by providing a standard notation for describing business processes plus a standard mapping of this notation into an executable description language like WSBPEL. The BPMN 2.0 standard even allows executing BPMN business models directly without the need of a translation.
The core notation elements of BPMN are flow objects to model activities and events, data objects to model pieces of information, connecting objects to model information and control flow, and swimlanes to model process participants. Four different diagram types allow the modeling of processes, process choreographies, collaboration between participants and conversations.
Slides from a webinar that I did recently for TIBCO. Full webinar replay with audio available at http://www.tibco.com/mk/2007/wsemtbpdesign08-aug-07usarc.jsp
This was a 1-hour BPMN Intro/Primer webinar I presented at ASPE. Just to be clear, I design/develop and teach classes for ASPE ("Modeling Processes using BPMN" being one of those classes), so one of goals was to tease audiences into wanting to learn more(and attending my class:-). Beyond that, the main goal was to share useful/interesting information and to ignite questions and curiosity about this important topic. Let me know what you think. Thanks, Razvan:-)
Brief presentation summarizing some new features introduced by BPMN 2.0, focusing on few points (made to answer to particular needs of a research project)
The Role of the Enterprise Architect in Business Process ReengineeringRichard Freggi
Business Process Reengineering is often a challenging undertaking. This paper is a case study, sharing practical experience of how the enterprise architect can help in three ways:
• Provide a common language allowing different organizations, consultants and IT teams to communicate effectively
• Set the right level of abstraction to facilitate analysis and solution of complex questions
• Reconcile user’s wants and needs with the capabilities and constraints of IT systems
Reference is made to the Zachman Framework, especially the columns for “Data”, “Function” and “People”; and how these columns can be used to interact with stakeholders using UML (Unified Modeling Language).
COEPD - Center of Excellence for Professional Development is a primarily a Business Analyst and PMP Training Institute in the IT industry of India head quartered at Hyderabad. COEPD is expert in PMP Training and Business Analyst Training in Hyderabad, Chennai, Pune , Mumbai & Vizag. We offer PMP and Business Analyst Training with affordable prices that fit your needs.
COEPD conducts 4-day workshops throughout the year for all participants in various locations i.e. Hyderabad, Pune. The workshops are also conducted on Saturdays and Sundays for the convenience of working professionals.
For More Details Please Contact us:
Visit at http://www.coepd.com or http://www.facebook.com/BusinessAnalystTraining
Center of Excellence for Professional Development
3rd Floor, Sahithi Arcade, S R Nagar,
Hyderabad 500 038, India.
Ph# +91 9000155700,
helpdesk@coepd.com
TOWARDS AUTOMATION OF SOA-BASED BUSINESS PROCESSESIJCSEA Journal
The adoption of business processes to design business activities is becoming a reality to a significant number of companies. In addition, the Service-Oriented Architecture (SOA) is being used in diverse situations for the execution of business processes using computational resources. In this context, the need of business process automation appears with high relevance. In this work, we present a solution named BPA-SOA, which aims to automate SOA-based business processes, specified in BPMN, into WS-BPEL executable processes. In BPA-SOA, business and service information can be specified at the business level, translated into executable artifacts, deployed in execution-level resources and enforced at runtime. An illustrative scenario is presented to better illustrate and showcase the proposed solution.
This presentation provides a high-level overview of BPM and where it is today.
It also touches on some of the core technologies and standards.
Its focus is on the four specific “Challenges” facing BPM and they are aligned to the four phases of the typical application development life cycle.
1. Discovery
2. Design
3. Development
4. Deployment
BUSINESS RULE MANAGEMENT FRAMEWORK FOR ENTERPRISE WEB SERVICES ijwscjournal
Making a business rule extraction more dynamic is an open issue, and we think it is feasible if we decompose the business process structure in a set of rules, each of them representing a transition of the business process. As a consequence the business process engine can be realized by reusing and integrating an existing Rule Engine. We are proposing a way for extracting the business rules and then to modify it at the runtime. Business rules specifies the constraints that affect the behaviors and also specifies the derivation of conditions that affect the execution flow. The rules can be extracted from use
cases, specifications or system code. But since not many enterprises capture their business rules in a structured, explicit form like documents or implicit software codes, they need to be identified first, before being captured and managed. These rules change more often than the processes themselves, but changing and managing business rules is a complex task beyond the abilities of most business analysts. The capturing process focuses on the identification of the potential business rules sources. As business logic requirements change, business analysts can update the business logic without enlisting the aid of the IT staff. The new logic is immediately available to all client applications. In current trend the rules are modified or changed in the static time phase. But this paper provides to change the rules at the run time. Here the rules are extracted from the services and can be a changed dynamically. The existing
rules are modified and attached to source code without hindering service to the end user which can be achieved with source control systems. When the rules are revised, it provides a path in budding new business logic. This new business logic can be adopted for the efficient software development.
BUSINESS RULE MANAGEMENT FRAMEWORK FOR ENTERPRISE WEB SERVICESijwscjournal
Making a business rule extraction more dynamic is an open issue, and we think it is feasible if we decompose the business process structure in a set of rules, each of them representing a transition of the business process. As a consequence the business process engine can be realized by reusing and integrating an existing Rule Engine. We are proposing a way for extracting the business rules and then to modify it at the runtime. Business rules specifies the constraints that affect the behaviors and also specifies the derivation of conditions that affect the execution flow. The rules can be extracted from use cases, specifications or system code. But since not many enterprises capture their business rules in a structured, explicit form like documents or implicit software codes, they need to be identified first, before being captured and managed. These rules change more often than the processes themselves, but changing and managing business rules is a complex task beyond the abilities of most business analysts. The capturing process focuses on the identification of the potential business rules sources. As business logic requirements change, business analysts can update the business logic without enlisting the aid of the IT staff. The new logic is immediately available to all client applications. In current trend the rules are modified or changed in the static time phase. But this paper provides to change the rules at the run time. Here the rules are extracted from the services and can be a changed dynamically. The existing rules are modified and attached to source code without hindering service to the end user which can be achieved with source control systems. When the rules are revised, it provides a path in budding new business logic. This new business logic can be adopted for the efficient software development.
BUSINESS RULE MANAGEMENT FRAMEWORK FOR ENTERPRISE WEB SERVICESijwscjournal
Making a business rule extraction more dynamic is an open issue, and we think it is feasible if
we decompose the business process structure in a set of rules, each of them representing a transition of
the business process. As a consequence the business process engine can be realized by reusing and
integrating an existing Rule Engine. We are proposing a way for extracting the business rules and then
to modify it at the runtime. Business rules specifies the constraints that affect the behaviors and also
specifies the derivation of conditions that affect the execution flow
BUSINESS RULE MANAGEMENT FRAMEWORK FOR ENTERPRISE WEB SERVICESijwscjournal
Making a business rule extraction more dynamic is an open issue, and we think it is feasible if we decompose the business process structure in a set of rules, each of them representing a transition of the business process. As a consequence the business process engine can be realized by reusing and integrating an existing Rule Engine. We are proposing a way for extracting the business rules and then to modify it at the runtime. Business rules specifies the constraints that affect the behaviors and also specifies the derivation of conditions that affect the execution flow. The rules can be extracted from use cases, specifications or system code. But since not many enterprises capture their business rules in a structured, explicit form like documents or implicit software codes, they need to be identified first, before being captured and managed. These rules change more often than the processes themselves, but changing and managing business rules is a complex task beyond the abilities of most business analysts. The capturing process focuses on the identification of the potential business rules sources. As business logic requirements change, business analysts can update the business logic without enlisting the aid of the IT staff. The new logic is immediately available to all client applications. In current trend the rules are modified or changed in the static time phase. But this paper provides to change the rules at the run time. Here the rules are extracted from the services and can be a changed dynamically. The existing rules are modified and attached to source code without hindering service to the end user which can be achieved with source control systems. When the rules are revised, it provides a path in budding new business logic. This new business logic can be adopted for the efficient software development.
Suggest an intelligent framework for building business process management [ p...ijseajournal
As companies enter into the digital world, information technology is playing a major role in bringing
process improvements to the forefront of business management. In the recent decades, many organizations
have struggled to redesign and improve their business processes to reduce their total cost. The main
contribution of this research study is to propose an intelligent framework that possesses the ability to
employ a database of best practices, business standards, and business activity history in order to permit the
manager to analyze and improve the design of the business processes.
In addition, the other objective of this research is to build a business process or workflow directly from its
process design logic in order to enable rapid process development and deployment. This procedure
requires some technical improvements of the business design, as it is mainly based on building the business
process using Microsoft Office Visio, which communicates the defined business process to the business
process management engine.
Learning spark ch01 - Introduction to Data Analysis with Sparkphanleson
Learning spark ch01 - Introduction to Data Analysis with Spark
References to Spark Course
Course : Introduction to Big Data with Apache Spark : http://ouo.io/Mqc8L5
Course : Spark Fundamentals I : http://ouo.io/eiuoV
Course : Functional Programming Principles in Scala : http://ouo.io/rh4vv
HBase In Action - Chapter 04: HBase table designphanleson
HBase In Action - Chapter 04: HBase table design
Learning HBase, Real-time Access to Your Big Data, Data Manipulation at Scale, Big Data, Text Mining, HBase, Deploying HBase
HBase In Action - Chapter 10 - Operationsphanleson
HBase In Action - Chapter 10: Operations
Learning HBase, Real-time Access to Your Big Data, Data Manipulation at Scale, Big Data, Text Mining, HBase, Deploying HBase
Hbase in action - Chapter 09: Deploying HBasephanleson
Hbase in action - Chapter 09: Deploying HBase
Learning HBase, Real-time Access to Your Big Data, Data Manipulation at Scale, Big Data, Text Mining, HBase, Deploying HBase
Learning spark ch04 - Working with Key/Value Pairsphanleson
Learning spark ch04 - Working with Key/Value Pairs
Course : Introduction to Big Data with Apache Spark : http://ouo.io/Mqc8L5
Course : Spark Fundamentals I : http://ouo.io/eiuoV
Course : Functional Programming Principles in Scala : http://ouo.io/rh4vv
Learning spark ch01 - Introduction to Data Analysis with Sparkphanleson
Learning spark ch01 - Introduction to Data Analysis with Spark
References to Spark Course
Course : Introduction to Big Data with Apache Spark : http://ouo.io/Mqc8L5
Course : Spark Fundamentals I : http://ouo.io/eiuoV
Course : Functional Programming Principles in Scala : http://ouo.io/rh4vv
1. Book Author: Nicolai M. Josuttis
Chapter Seven: Business Process Management
IT-Slideshares http://it-slideshares.blogspot.com/
2. Contents
7.1 BPM Terminology
7.2 BPM and SOA
7.3 Example of BPM with Services
7.4 Business Process Modeling
7.5 Other Approaches to Identifying Services
7.6 Orchestration Versus Choreography
7.7 A Few More Things to Think About
7.8 Summary
3. 7.1 BPM Terminology
The acronym BPM itseft, which can stand for two different things.
Business Process Management , which is general term that refer to all
activities related to management and improving business process.
Business Process Modeling is the modeling of business processes or parts
thereof.
Business process modeling usually is a part of business process
management.
Confusion can be the difference between business process
management and workflow management.
A business process describes what has to be done (including input and
output) .
It might include manual activities and might use any kinds of resources.
A workflow describes how a certain result can be reached.
It looks further into the details of all the steps or activities.
4. 7.1 BPM Terminology (cont)
You can break down a business process into a smaller and more
concrete steps , and that at some level of abstraction those activities or
process steps are part of a workflow layer
Figure 7.1 gives one possible representation of this concept
5. 7.2 BPM and SOA
Services are parts of business processes Business processes to bring
services into play.
Business Process Management deals with aspects such as
Analyzing the business (including needs and opportunities )
Implementing and integrating business strategies
Monitoring and optimizing business processes
Establishing corresponding tools and culture
And align business with IT
Talking about BPM in relation to SOA , it is clear that the lowest-level
activities of a decomposed process are services.
From a business point of view , it doesn’t matter whether these services are basic
or composed services. What count is that the services perform necessary
business functions .
Process services , however , are something different , because they serve to
represent complete business process (or parts thereof).
6. 7.2 BPM and SOA (cont)
Problem and question ?
How do you identify the services that represent or become parts of your business
processes?
In the general fundamental topic of system design How do you break a system of
functionally into smaller parts (called services) so that you can implement it?
How can these services be designed in a more general way so that you can reuse
them in different scenarios?
Two different approaches to dealing with these kinds of problem
Top-down approach
Bottom-up approach
All expert agree that in practice , a pure application of either of these
approaches does not work.
So in Practice , a mixture of both approaches is appropriate (E.g “middle-
out”, “middle-ground”, “met in the middle” …)
Your aim should be to fulfill a real business need.
7. 7.3 Example for BPM with Services
You want to realize a new business process.
You have a new business process on top and the existing back-ends , which might
provide some basic business functionalities represented as services on the
bottom(See Figure 7.2)
You’ll begin with a top-down decomposition to :
Decide which process steps are manual and which ones are IT-Supported
Separate the whole process into smaller chunks according to when they are performed and which
systems are responsible for them
Break down complex aspects into more manageable steps.
8. 7.3 Example for BPM with Services (cont)
The result of this task (which might be called high-level design or solution design) is
a rough idea of how the process should be performed in practice(see Figure 7.3)
One important reason for this design process is to determine which IT systems are
responsible for which parts of the process.
You first need to identify the system involved , so you know which people to discuss the
details with.
9. 7.3 Example for BPM with Services (cont)
An interesting question arises when services come into play : at which level of
abstraction do you design sub-process and/or activities as services?
E.g
Business rules might be extracted and modeled in special rule engines , and you might or
might not consider rules to be services.
You’ll have to develop your own procedure for designing processes and identifying
services(See Figure 7.4)
10. 7.3 Example for BPM with Services (cont)
Tool has a big impact.
In any case , the more you decompose a process, the more you should take existing services
into accounts
If you need customer data, you might look for existing services that fulfill your needs instead of
focusing on specifying a new service that provides all the necessary data.
For example :
You might need a certain attribute relatively late in the process , but if a service you called early in the process has
returned this attribute , you won’t need to call another service for it latter
You‘ll have to design your process in such a way that you can keep the value of this attribute from the service call
where it’s returned to the moment when you really need it.
…
How do you know you’re doing it right? Through learning and experience.
Generally speaking , starting with anything that works and seems to be appropriate is probably
fine.
Iterative development is the only way you can realize complex systems in reasonable amounts
of time.
Start with a small extract of the whole system and realize an appropriate solution.
The you grow, adding new functionality , redesigning existing solutions and refactoring existing
behavior.
Your systems becomes better and better , fulfilling more and more requirements in appropriate
ways.
You will never achieve perfection , and your task will never be done.
11. 7.4 Business Process Modeling
Definition of a (business) model
A model is in the fact just a representation of the process that allows
companies to document , simulate , share ,implement , evaluate
, and continually improve their operations.
With SOA , these models play an important role because
standards evolve to enable process modeling in different
tools .
Some tools even allow you to execute modeled processes with
process engines.
12. 7.4.1 Using Business Process Modeling Tools
Figure 7.5 shows the general role a business process modeling tool or engine can
play.
Such a tool can be used to :
Compose (“orchestrate”) new composed or process services out of existing services.
Have the ability to execute and monitor the resulting composed or process services in a
business process engine, ideally using the abstraction layer of the model
13. 7.4.1 Using Business Process Modeling Tools (cont)
Figure 7.6 shows an example of such a BPM tool (ActiveBPEL, an open source
business process engine).
Shows the current business process (Service) under development.
The lists of existing services and process elements to create the process for.
Can also debug and monitor processes running in the engine.
The vision is to enable users to “plug and play” business processes by dragging and
dropping activities and control structures onto a graphical model.
Allow business experts to design , modify ,monitor , and debug business processes or parts
thereof.
14. 7.4.2 BPEL
The Business Process Execution Language (BPEL) plays a fundamental
role in modeling and running business processes in tools and engines.
BPEL has such momentum in the SOA movement that is rapidly becoming
the standard for designing and running business processes.
Conceptually , BPEL is an XML language for describing business flows
and sequences , which in themselves are services.
Language elements provide the ability to call services, process response , and
deal with process variables , control structures (including timers) and errors
(including compensation).
BPEL was initially designed by IBM, Microsoft, and BEA as a
combination of IBM’s Web Services Flow Language (WSFL and
XLANG, a notation for the automation of business processes based on
Web Services . Nowadays, OASIS is specifying the standard)
15. 7.4.2 BPEL (cont)
A simple BPEL file might looks as follows :
<?xml version =“1.0”?>
<process name="changeAddress" ...>
<variables>
<variable messageType="..." name="...">
</variables>
<flow>
<receive .../> <!– for this request (operation and input) -->
<invoke .../> <!– call other service -->
<assign .../> <!– map data -->
<reply .../> <!– return data -->
</flow>
</process>
Although in principle BPEL is human-readable , reading and writing BPEL files manually is tedious
and error-prone , Usually you should use a BPEL tool to design and execute process.
Naming conventions of BPEL follows Web Services conventions because the “process” it is used to
create are provided as Web Services .
So, to call these processes or services.
Have to be able to call Web Services.
A business process modeling standard is usable not only for Web Services technologies.
There are two parts to the processes and services composed as BPEL XML files :
One describes the structure of the business process
Other defines a binding of this structure to concrete technical operations that are invoked or used.
In practice , you can compose processes and services that use different middleware and even native
technologies such as J2EE calls.
16. 7.4.3 Other Business Process Modeling Standards
BPEL is not only business process modeling standard available. Figure 7.7
provides an overview.
17. 7.4.3 Other Business Process Modeling Standards
You can distinguish between the following main branches of the BPM standards evolution :
The most famous branch is currently BPEL
Another major branch started with the Workflow Management Coalition (WfMC)
Founded in 1993 to specify a standard for workflow management systems
First standard was Workflow Process Definition Language (WPDL)
Current process-definition standard came under the influence of XML and is called XML Process Definition Language
(XPDL)
The third importance standard is the Business Process Modeling Notation (BPMN)
Other standard involved include :
Wf-XML
UML (Unified Modeling Language)
WS-CDL (Choreography Definition Language)
BPSS ( Business Process Specification Schema)
EPC (Event-driven Process Chain)
Only BPEL and XDPL are provided for engines, and BPEL currently has no notation support
Companies work hard to be able to transfer other modeling languages and notations into BPEL
and XPDL
The most importance notations are BPMN , UML and EPC .
A pure XML format to specify business process
These graphical notations are what guarantee that business diagrams look the same
Which standard should you use ?
18. 7.4.4 Busines Process Modeling with BPEL in Practice
BPEL currently seems to have the market momentum
The concept of “Plug and Play” business processes works as naïve assumptions might suggest.
In practice, the following aspects may hinder the realization of that vision:
To compose and/or orchestrate services , you need services.
BPEL can be considered a business process assembler.
The whole concept of composition and orchestration works only from a functional point of view.
Designing and implementing business processes might be done at different layers of abstraction.
Although BPEL has error handling support.
Finally , modeling languages have their limits.
The newness of BPEL is also a source of problems ,as there are still some
functionality and protability issues in the tools and engine.
Using BPEL to design and maintain common business processes can be
appropriate :
Best done by business and IT experts sitting together.
The higher abstraction definitely helps , but has its limits Again , start small and
evolve.
19. 7.5 Other Approaches to Identifying Services
Torsten Winterbeg presented four different ways to discover services :
Process decomposition
By breaking down a process into smaller chunks (step, activities) , you identify the individual
services required.
Domain decomposition
By analyzing the domain , you end up with useful services to provide.
Business event tracing
By analyzing and monitoring what triggers business functionally , you define appropriate services.
Bottom-up
By examining what you have (existing backend interfaces or “natural” technical interface ) you
identify appropriate wrapping services to introduce.
Domain decomposition leads to an approach that is often called “portfolio
management”
20. 7.5.1 Portfolio Management
One more general service design approach is to try to find out how services
should be designed to fit different requirements.
Grady Booch (Father of UML and IBM fellow) recommend this approach.
A better pattern for identifying good services involves defining crisp abstractions. Throw some essential usage
scenarios against your system. Focus on the points of intersection where the success of multiple scenarios all
depend on a narrow set of software. Within striking distance of those intersects, you will find the place to dig for
services, at the granularity suggested by the nature of those scenarios.
The problem here is , again , to find the right depth of analysis.
In large distributed systems, it’s easy to fall the trap of “analysis paralysis”
In the sense that looking at different usage scenarios might help you to find the
right design and granularity for your services.
Note : An approach that starts to perform a complete system analysis for a large
distributed project usually is a receipt for disaster.
Portfolio management has a major risk , which is that you will design and
realize certain element based on assumptions that turn out to be wrong.
There might be very good reasons to realize solutions based on assumptions.
You should know the risk
21. 7.5.2 Don’t Switch Off Your Brain
Taking many elements into account is something that separates the best
designers and implementers from the worst.
The YAGNI principle warns against investing significant effort based on
assumptions.
Too often these assumptions turn out to be wrong.
Usually pay for your mistakes throughout the whole lifetime of your software because
the system gets increasingly complex.
Example : A service that returns the address of a customer , but your customer
only need the town and street the service should also return the zip code if
it’s available in the backend system.
You should do so :
If you can design a service that it will support multiple scenarios without expending a
disproportionate amount of effort.
The point here is not to fall into the trap of trying to achieve perfection.
22. 7.6 Orchestration Versus Choreography
Orchestration approach
Designing higher services and processes by composing them out of existing services.
Characteristics of orchestration approach
One central controller that coordinate all the activities of the process.
Can apply the composite pattern, which means that the whole composition itself can be used as a service.
Choreography approach
This approach involves collaboration between different parties, which are each responsible for
one more steps.
When you analyze processes in practice , you usually end up in a process based on
choreography.
Advantage
This kind of process design avoids centralized control , it might scale better.
Drawback
Finding out the state of the process or the reason for misbehavior can become a nightmare.
Some analogies to illustrate the difference between orchestration and choreography
The name themselves lead to the analogy of an orchestra controlled by a conductor versus a
performed, choreographed dance.
The model of control for the flow of traffic at an intersection
Choreography depends highly on two things : collaboration and the specification of some general
rules so that the collaboration doesn’t lead to chaos.
23. 7.6.1 Choreography and SOA
SOA is more or less understood as an architectural concept where business processes are designed using
orchestration.
BPEL is a pure orchestration language
Composability is often considered to be a fundamental attribute of services
One typical approach , which has the character of choreography , is to implement (business)
process chains (Figure 7.9)
The business starts by calling one service one service that performs some task, which then trigger
another service to perform another task, which in turn triggers yet another service to perform a third
task, and so on.
These services would typically be categorized as basic or composed services, but not process services.
Also , because the service give up control , they usually trigger consecutive services without waiting for
responses.
The concept of services called by one-way messages or events , which in turn leads to the concept of
event-driven architecture (EDA)
24. 7.7 A Few More Things to Think
About
The topic connects with SOA topics presented in other chapters :
Chapter 8 will discuss the consequences of BPM and SOA for the
structure of companies and organizations.
Chapter 9 will discuss the consequences of BPM and SOA for the
overall system design (including the impact to frontends and back-
ends).
Chapter 10 will provide some more details about one-way messages
and events that lead to event-driven architectures (EDA) and
(business) process chains.
Chapter 11 will discuss the service lifecycle , which starts when
services are identified as a part of a high-level or solution design.
Chapter 19 will discuss how to establish SOA, which includes a
careful growing of business processes realized with SOA.
25. 7.8 Summary
Business process management (BPM) and business process modeling provide approaches to identify services
that are parts of distributed business processes.
In practice , process design is a combined top-down and bottom-up approach.
Another typically approach for identifying necessary services is portfolio management.
Have to deal with the risk is of providing services nobody ends up needing.
There are multiple standards for designing and executing business processes , some of which have
standardized notations.
Allow you to use different tools and engines.
The most important notation standards are BPMN, UML, EPC.
The most important process standards engines can execute are BPEL and XPDL
BPEL
BPEL seem to have the market momentum for business process execution.
It can be considered a business process assembler that enables you to define “process” that can serve as composed or
process services using Web Services technologies .
Internally , BPEL processes can use different formats, although a Web Services binding is standardized .
The BPEL format itself is tedious and error-prone , so you need to use appropriate tool and/or model transformations.
Composing new services out of existing services is called “orchestration” . Orchestration results in a model
where there is one central controller that coordinate all activities of a process.
Another form of business process design is choreography . Unlike orchestration, this approach is defined by
collaboration of different parties , each controlling some steps or activities (Services)
Example :
Business chains, where each activity (service) trigger one or more consecutive activities (services).
If the trigger is an event , this leads to event-driven architectures.
Editor's Notes
Definition Business Process Management : usually refers to a technology – enabled means for companies to gain visibility and control over long-lived, multistep processes that span a wide range of systems and people in one or more organizations. Business Process Modeling is a set of practices or tasks that companies can perform to visually depict or describe all the aspects of a business process, including its flow , control and decision points, triggers and conditions for activity execution , the context in which an activity runs , and associated resources.
Bloomberg Schmelzer06 puts it as follows : Your approach to SOA should be both top-down (through process decomposition) and bottom-up (exposing existing functionality as Services and composing them into processes) If you take only a top-down approach , you’re likely to recommend building services that are technically difficult or complex to implement.Take solely the bottom-up approach can yield services you don’t need or , even worse , Service that don’t fullfill the requirements of the business.