Page 1 of 43

WebSphere Integration Developer Version 6.0.2

Lecture 1,2 and 3

Lecture 1 - Get a driver's view of the WebSphere Integration Developer

landscape

Introduction

This article series gives you a guided tour of developing applications with WebSphere Integration Developer. This first article gives you a broad overview of WebSphere Integration Developer and its main concepts. Subsequent articles will dive into each concept and the related construction tools. We'll look at each area of the product, why it matters, what you can do with it, and lastly give you the driver's seat to build the next piece of an overall application. Some topics that we'll cover in future articles include:

• SOA development

• Building and assembling a simple application

• Business processes, state machines, and rules

• Human tasks

• EIS connectivity support

• Mediation and selectors

Although these articles build on each other as a series, each stands on its own if you want to delve into a particular

area of interest.

What is WebSphere Integration Developer?

You are probably wondering what WebSphere Integration Developer is, and why you should care. Companies today face increasing pressure to integrate parts of their enterprise, automate their systems and provide new channels

for their customers. Companies need products and solutions that are flexible and based on standards. Some of the problems typically encountered in the integration arena include:

• Synchronizing data among two or more heterogeneous enterprise information systems (EIS).

• Intelligently brokering product requests from consumers to multiple producers.

• Publishing product data to a global repository, thus enabling consumers to access and use the information. Publishing can range from making catalogs of products available, to participating in a global online marketplace.

• Orchestrating multiple existing business processes using an overarching process.

• Managing order processing from order receipt to both inventory management and supply chain management.

• Assigning, approving, and escalating tasks to effectively deal with customer requests.

• Dynamically responding to changing business conditions by altering the rules and decisions governing the business.

WebSphere Integration Developer tackles these and other types of application integration problems. From the ground up, WebSphere Integration Developer is based on industry standards (notably WSDL, XSD, BPEL, Java™,

Page 2 of 43

and UML) and is on the leading edge of evolving standards (the Tuscany Service Component Architecture is a good example). To build applications on these standards you use a set of visual construction tools and higher level concepts, which lets you focus on the business problem, and not have to write masses of J2EE code or be a WSDL rocket scientist. You get the standards without having to eat, sleep, and breathe them. From a WebSphere Integration Developer perspective, a service-oriented architecture means you can focus on the key components of your system, build them visually, connect them together visually and then be off and running

using WebSphere Process Server. Afterwards, you can also visually unit test and debug your entire application or individual parts of it. WebSphere Integration Developer supports top-down, bottom-up, and meet-in-the-middle construction. You can start at the top--the design level, lay out your overall vision and then gradually drill down and implement the components (services). Alternatively, you can work bottom up, implement the services, and then compose them together into a larger application. More likely, you will find yourself using a meet-in-the-middle approach, perhaps laying out the initial high-level vision, then use the Enterprise Metadata Discovery utility to explore an enterprise information system, and define services that connect to it. You might also want to pull in and reuse an external Web service that one of your business partners has provided.

Who uses WebSphere Integration Developer? Perhaps the real question we should be asking is, what roles do users of WebSphere Integration Developer fulfill,

and when, during the overall development process, do they use the tools? WebSphere Integration Developer targets integration specialists. These users are not Java, WSDL, or XSD experts. They focus on integrating applications and addressing the types of problems discussed above -- and of course they want to do it as easily as possible. Figure 1 illustrates the relationship between the skill set of the integration specialist and other user roles.

Figure 1. WebSphere Integration Developer users

The process of application development involves many user roles at different stages of development. Note that by role, we refer to a capacity in which an individual works; any given person could actually fulfill multiple roles in a company. Figure 2 illustrates the portions of the software development process in which the integration specialist is typically involved. The integration specialist takes over where the business analyst leaves off, developing the integration application, testing and debugging it, and then ultimately, when all the t's are crossed and the i's dotted, deploying it to a production server.

Page 3 of 43

Figure 2. Integration specialist development involvement

A tour

It's time to warm up the car and take a tour of WebSphere Integration Developer's key concepts and tools. In

subsequent articles, we will focus on the importance and value of each element and show you how to use the concept or tool as part of building a sample application. For now we'll just do a quick cruise by each item.

Pick your route -- service implementation types Services are the main building blocks of a service-oriented architecture. WebSphere Integration Developer includes

a diverse set of service-building tools that cover the spectrum of problems you might encounter. For the most part, you can build the service implementation types mentioned above using visual construction tools, which is why you don't need to be an expert programmer to develop applications with WebSphere Integration Developer. Most services are built using visual construction tools, with the one exception being a Java or EJB service. You can use these Java and EJB services to leverage existing Java applications, or, if your organization has some Java heads, to build Java services using IBM Rational® Application Developer. You can implement your services using a variety of programming paradigms, from process-flow style BPEL processes, to state machine-style event management, to declarative business rules style. The style of implementation you select will be determined both by your comfort level with a given paradigm as well as the nature of the problem. For example, some problems lend themselves to more succinct expression as a state machine than as a set of declarative rules. Let's have a look at these different service types and discuss when you might want to use one versus the other.

Business processes A business process provides the primary means for coordinating enterprise services and describing your business logic. A business process consists of a series of activities or steps that are executed in a specific order, sequentially or in parallel. The business process editor is a visual construction tool that allows you to quickly author a business process based on the BPEL standard. A business process itself is a service. You can use it to coordinate reusable subprocesses or other services, which may have any other implementation type. An important aspect of business processes is their longevity and interaction with people. A process can be very short lived; this is common in highly automated systems. Alternatively, the process could be extremely long running, perhaps days or even months, and may wait on a

human user to complete a specific work item associated with an activity before the process can continue. For example, the business process could be patiently waiting for a manager to approve a travel request. Figure 3 shows how to construct a simple travel booking business process with the business process editor.

Page 4 of 43

Figure 3: The business process editor

Business state machines A business state machine is an event-driven business transaction that defines a set of states for a given part of the application. The state machine moves from one valid state to the next based on external events it receives. For a given event, you use conditions to determine the new valid state. A simple illustration is a vending machine; when it receives enough money, it transitions into a state where the selection buttons become active. When you make a

selection, it changes to a state where it can dispense the merchandise (let's say a quadruple chocolate candy bar). You construct business state machines using the state machine editor, which, like the business process editor, is a visual editing tool that requires little or no Java programming experience. You can use both business state machines and business processes to coordinate parts of your application. There are some subtle differences between them, which makes one more appropriate for certain types of problems than others. State machines are well suited to cyclical patterns or cases where you "naturally" think in a set of valid states. This is important because in a state machine you actually are not doing anything in a state, you are simply waiting to be told to pick up your gear and go to the next state. While the state machine is racing to get into the next state, it can do some work, such as handing the customer their chocolate bar in the vending machine example. Business processes, in contrast, do their work in the activities. They are well suited to sequential and parallel tasks. Just as with business processes, business state machines can invoke other service implementation types and can themselves be invoked as a service. Figure 4 shows a business state machine that we constructed

using the business state machine editor.

Page 5 of 43

Figure 4: The business state machine editor

For those who are familiar with UML, a business state machine is a subset of a UML state machine and is more appropriate for business users.

Business rules

A business rule captures and implements business policies and practices. A rule can enforce business policy, make a decision, or infer new data from existing data. It can be specified using two different formats: a rule set, or a

decision table. That explanation sounded too much like a collection of buzzwords, so an example is in order. A business rule is something like, if a customer is a gold customer and has been with us for ten years then give them a 10% discount. This business rule is a simple if-then rule. If the rule evaluates to true, it performs an action, which in this case, is giving the customer a discount. Business rule sets consist of groups of rules that allow great flexibility in the implementation of complex business logic. A decision table is designed to handle basic business rule logic. It does not have the same flexibility as a rule set; however, it offers great simplicity for capturing simple rule logic in a table format. A classic example of a decision table is one that frequent travelers are familiar with. Suppose you want to escape the cold and use up your frequent flyer points to go Hawaii. You look at a table and locate the row and column that correspond to your home city and Hawaii respectively; where they meet shows how many points are required for that trip. This is just one

kind of business rule logic that can be easily captured in a decision table. This brings us to a key aspect of a business rule: how dynamic it is, or, its ability to respond to a changing business environment. You can use business rules to modify key business parameters on a production server dynamically and have them take effect immediately. For example, suppose it is an unusually warm winter and there is little demand for tropical destinations. You decide to reduce the frequent flyer points needed for Hawaii. It is trivial to do this at runtime by viewing the table and changing the value. Later in this article, we will briefly visit WebSphere Business Monitor; you can use this product to monitor your business in real time so that you can react to key observations and conditions by adjusting your business rule policies. In general, you should use business rules to make a decision when any of the following conditions apply:

• You want to change the results at runtime, on a running server

• The decision itself naturally takes on the form of a table

• The decision itself naturally takes on the form of a series of simple choices--easily thought of as if-then statements

Figure 5 shows how we would create a decision table using the decision table editor.

Page 6 of 43

Figure 5: The decision table editor

Selectors

Selectors are an easy way to respond to a service request and route it to another service that is designed to handle it. The routing can vary over time. You use a selector to invoke different service implementations based on a date.

For example, let's say you want your online Christmas card business to use the regular sales service until December 25th, and then use the mega-discount service afterwards. You can use the visual selector editor to build a selector that will intercept sales service requests and select the regular service up until Christmas, and afterwards, select the discount service. Figure 6 shows how we would create such a selector. As with business rules, you can change selectors dynamically on a production server. You can modify the service destinations and the date selections to suit your evolving business needs.

Figure 6: The selector editor

Interface maps Sometimes you might have two services that just will not to speak to each other because they do not understand the same set of operations. While you might be inclined to get grumpy at this dilemma, a simple solution is to use an interface map. An interface map describes how an operation of one service translates into another. When mapping two interfaces, first map their operations and then map the input and output messages. If the input and output messages do not have the same type, you would use a data map (explained in the next section) to map between the two types. Figure 7 shows how we would construct an interface map using the interface mapping editor.

Page 7 of 43

Figure 7: The interface mapping editor

Business object maps Business object maps, also known as data maps, are used for translating business data from one type to another. It is often necessary to map one business object into another when coordinating heterogeneous systems, or even as part of normal business logic. Using the business object map editor, you can graphically create a map that transforms a business object and its fields to another business object as Figure 8 shows. As a simple example, consider a name from an employee

information service that needs to be passed to your travel booking service. Suppose the service is hosted by an old clunky system that returns a comma delimited string, yet the travel booking service requires three separate fields (first/last/middle name). The mapping process in this case means taking the full name and separating it into the required pieces. The editor provides quick convenience mechanisms for all the common maps you will need (concatenation, for instance), and provides a way for you to define your own custom conversions using either Java or a visual snippet (more on those later). Business object maps support 1-to-n, m-to-1 and m-to-n mappings among business objects.

Page 8 of 43

Figure 8: Business object map editor

Human tasks

A human task is, quite simply, a unit of work done by a human. Quite often, this type of task involves interactions with other services, and thus becomes a task within a larger business goal. You can use WebSphere Integration Developer and WebSphere Process Server to escalate or delegate human tasks in the event they are not handled in a timely fashion. Tasks can be assigned to individuals or groups of individuals (any manager, for example) based upon your organization structure as defined in a system such as LDAP. You can create human tasks using the visual human task editor as shown in Figure 9.

Page 9 of 43

Figure 9: The human task editor

Web services The services we have mentioned are first-class services, but so far are only accessible to other WebSphere applications. However, you can easily expose any of the service types listed above as Web services. We will explain this in the Assembly diagrams section. You can even go one step further and create standard Web services using the capabilities inherited in WebSphere Integration Developer from Rational Application Developer.

Enterprise information system (EIS) services Since your company likely depends on at least one EIS, you can easily turn its applications into services. You do this using the Enterprise Service Discovery wizard, which uses standard J2C resource adapters to connect to and

query back-end systems such as CICS® or PeopleSoft. There are two resource adapters that ship with WebSphere Integration Developer, one for CICS ECI and one for IMS™. Figure 10 shows how you would create an operation for a purchase-order service, based on the data it found on the PeopleSoft server. When you complete the steps for the wizard, you have a service that lets you access your EIS the same way you access any other service.

Page 10 of 43

Figure 10: The Enterprise Service Discovery wizard

Java and EJB services As we mentioned, if your company has some seasoned Java developers, you can still create or reuse plain old Java objects or EJBs as your service implementations. Calling other services from your Java code is as easy as calling

them using the visual editors. If you were to use Jave code to make the same service call to the Travel Agency partner as in the Business process section (recall Figure 3 shows the book trip activity making this call), the code would look something like this: result = locateService_TravelAgencyPartner().placeTripOrder(travelRequest); The service call is made simple by helper code that is generated for each reference (you create the references in an assembly diagram, as we will explain shortly).

Key landmarks -- business objects Back in the section called Business object maps, we showed how to map variations of a business object so that one service can understand another. In this section we'll give you an idea of what business objects are. A business object is the primary currency of your business application. Examples of business objects include a customer order, a customer, and items in your inventory. A business object consists of a set of fields and their values. A field may in turn be another business object. For example, an Order business object may have a customer field which in turn is a Customer business object.

Business objects are created using the business object editor, which provides a graphical view of your business objects. You can also use the editor to work with the object in a tabular format, if you prefer to use the keyboard for quickly filling in forms.

Figure 11: The business object editor

Page 11 of 43

Relationships

A relationship correlates at least two semantically equivalent business objects that are represented in different physical formats. Suppose EIS1 had employees whose name was represented as a full name, and EIS2 also had employees, but with the name stored as a first name and a last name. If these are really the same employees, then you would use a relationship to indicate this. Now, if the information is updated for an employee in one EIS, it

can easily be updated for that employee in the other. By establishing a relationship between them, you are saying it is in fact the exact same employee. Relationships are created using the visual relationship editor, as shown in Figure 12.

Figure 12: The relationship editor

Visual snippets There are times in your business processes, state machines, or other services where you might find yourself needing to write some nitty-gritty logic. You can use WebSphere Integration Developer to do custom code in a number of places, and although you are free to throw in some Java, a popular alternative is to use the visual

snippet editor. This editor lets you describe a more detailed level of logic without having to drop down to textual Java. Figure 13 shows a simple way to determine which branch should execute in the choice following the human task shown previously in Figure 9.

Figure 13: Visual snippet editor

Page 12 of 43

Mediation services A mediation service intercepts and modifies messages that are passed between existing services and their clients. Mediation services are implemented using mediation modules that contain mediation flows. For example, suppose you had two types of customers using your stock quotation service: regular (non-paying) and gold. Your service delegates to two external services to fetch the stock prices: one provides delayed quotes, and one provides real-

time quotes. You could use a mediation flow to route gold member requests from your service to the real-time quotation service, and the rest to the delayed service. Figure 14 shows how you would use the meditation flow editor to create such a mediation.

Figure 14: The mediation flow editor

Putting it together Now that you are familiar with the various ways to implement a service, we will show you how those fit together in a deployable integration application.

Modules and components Any service that you create becomes a component that you can drop into an assembly diagram (see the next section). The components are grouped together into a module, which can be deployed to WebSphere Process Server (more on that in a moment). An important aspect of components is their interfaces. An interface lets others know how to talk to your service, and are defined using WSDL or Java. So, a component requires an interface and the implementation must adhere to that interface. You can wire any reference of one component to any other component, provided the component's interface matches the interface required by th reference. As we mentioned, you might not define the implementations for your services if they already exist, such as a Web service (which has WSDL interfaces) or an EIS application (the Service Discovery wizard creates an appropriate

interface). In this case, you use an import, which you can reference in the same manner as any other component. The fact that it is implemented externally is transparent; you just use the reference. Similarly, when you expose your services outside WebSphere or to other applications within WebSphere you just add an export with the appropriate interface and wire it to the component you want to expose. You assign bindings to imports and exports whose properties determine how the service is accessed. For example, if your import has a Web service binding, you will specify an endpoint and a port.

Assembly diagrams You use an assembly diagram to wire your service components together within a module. Figure 15 shows the

assembly diagram using EmployeeToPersonnelSystemMap. Here you have a CheckEmployee process that expects to use the Employee EIS. Using the map, you can keep that reference (and, more importantly, the business logic that uses it) and wire it to the PersonnelSystem using the mediation. The EmployeeSystemPartner reference displayed on the CheckEmployee component corresponds to the same reference within the process.

Page 13 of 43

Figure 15: The assembly diagram editor

Want to learn more about related products? WebSphere Integration Developer complements several other IBM WebSphere business integration products to assist in the development of service-oriented applications. The most important of these are WebSphere Business Modeler, WebSphere Process Server, and WebSphere Business Monitor. Let's have a brief look at each of these products and how WebSphere Integration Developer fits in with them.

WebSphere Business Modeler Although you can begin building your service-oriented applications using WebSphere Integration Developer directly, it may be more useful to first model your business processes using WebSphere Business Modeler. Modeling your business processes with WebSphere Business Modeler helps you gain a better understanding of your business, validate enhancements and transformations, and discover potential areas for process improvement, or latent value in existing processes, before implementing technical solutions. Aside from helping to provide a starting point for implementing solutions, WebSphere Business Modeler also provides other benefits, such as giving you the necessary information for process compliance, documentation and

training, and allowing you to run simulations to reveal the implications of process modifications (the simulation tools are included with the advanced version of the product). You can define company resources such as existing information systems, equipment, or employees and business items such as invoices and documents with WebSphere Business Modeler and incorporate them in the process models. At a higher level, you can use WebSphere Business Modeler to model the relationships and interactions between the various entities within an enterprise. Just as WebSphere Integration Developer can be used by people with varying skill sets, so can WebSphere Business Modeler. WebSphere Business Modeler allows the people who know the business to do the modeling before beginning implementation. For example, a business analyst who needs to model processes at a higher-level can do so using the basic mode, while the more technically experienced person can use the intermediate or advanced user modes to specify deeper process details or more complex business logic. When you have your business processes modeled, you can pass the models to a development platform for

implementation. You can use WebSphere Integration Developer to import the models, and use them to build and test a complete set of SOA applications.

Rational Application Developer WebSphere Integration Developer is built on Rational Application Developer. Rational Application Developer is a comprehensive development environment designed to meet a variety of development needs, including simple Java applications, sophisticated Web interfaces and portals, and EJB and data access components. It, in turn, is built on Eclipse, which is an open-source platform for development and creating application development tools. So, when you need to develop portal or Web client applications for your services, you can enable additional

features of WebSphere Integration Developer that are found in the underlying Rational Application Developer tool suite. You can also use the Rational Application Developer tools to expose your services as Web services. In fact, you can do additional development for your applications at the J2EE level.

WebSphere Process Server After you complete the implementation phase, you use WebSphere Integration Developer to deploy the applications to WebSphere Process Server. WebSphere Process Server is a service-oriented architecture integration platform based on WebSphere Application Server. It has evolved from proven business integration concepts, application server technologies, and the latest open standards. It plays a key role in helping your business cope

with a changing environment by providing execution-time support for the various types of service components contained within an application developed with WebSphere Integration Developer.

Page 14 of 43

While you can deploy standard Business Process Execution Language (BPEL)-based applications to any BPEL-compliant application server, WebSphere Integration Developer provides the development tools that let you take advantage of WebSphere Process Server's additional capabilities. These capabilities include human tasks to support the manual parts of a business process, business state machines for event-driven processes, business rules to facilitate on-demand changes in a process, and selectors that enable dynamic business processes. WebSphere Process Server is powered by WebSphere Enterprise Service Bus which, in addition to enabling

execution of a true service-oriented architecture, provides J2EE Connector architecture (JCA) and Web services connectivity as well as Java Message Service (JMS) messaging support.

WebSphere Business Monitor When your applications are up and running on WebSphere Process Server, you will need to capture information about them to help you identify problems, discover faults that have occurred, and determine whether any process modifications are necessary. This area is where WebSphere Business Monitor comes in handy. WebSphere Business Monitor collects events emitted by WebSphere Process Server using the Common Event Infrastructure. From them, it calculates Key Performance Indicators (KPIs) and metrics based on a business measures model.

Using the process models you created, you create a business measures model using the business measures editor that comes with WebSphere Business Modeler. These models define measurements and measuring points, event filters and correlations, and the sources of business data that you want to monitor. The monitor server uses these models as it receives and processes events from the server. The dashboard client component of WebSphere Business Monitor enables users to monitor business performance using a customized set of views. The views show different representations of active process instances and their status, reports, KPIs, and KPI scorecards, and alerts based on the business measures model. The adaptive action manager can notify you by way of the dashboard, as well as by e-mail, pager, or cell phone based on criteria that you specify. Finally, WebSphere Business Monitor lets you export monitored values, which you can then import into WebSphere Business Modeler for continuous improvement of the business processes.

Summary

We've taken a quick tour of WebSphere Integration Developer and some of its key concepts. As you can see, the environment is highly visual, with an emphasis on the higher-level concepts of your application. This experience is often described as point, click, and integrate.

In future articles we will get into the details of each concept and build an example around it. Through the series you will see a complete integration application take shape

Page 15 of 43

Lecture 2 - SOA development with WebSphere Integration Developer

Building applications the service-oriented way

Lecture 1 of this series gave you a driver's view of IBM® WebSphere® Integration Developer by telling you what the product is and by showing you the various tools that it offers. In this second article, you will learn the programming model and the context in which the tools are used. To put things into perspective, we will describe a simple application and show you how you would build it using WebSphere Integration Developer.

Unless you are a hermit living in the woods, you have probably heard the phrase service-oriented architecture

(SOA). But what is SOA, and more importantly, why is it of interest to the business integration space? We're glad that you asked. WebSphere Integration Developer applications are implemented using a service-oriented architecture, so let's start by looking at what SOA is and what it means for your application to follow this architectural pattern.

Ideally, you want to be able to reuse your existing IT assets as building blocks or components for new

applications. Each building block is a service, which means you can access each one in a standard way without regard to its implementation or location. In an SOA, the business logic is separated from the infrastructure, or "plumbing," so that developers can focus on the implementation and not worry about how the service will be accessed.

Put in simplest terms, services are black boxes; you don't care what goes on inside as long as they perform as

advertised. Once you have the black boxes, the next key step is to connect them together into an overall integrated application. The boxes can be Java™ technology, Business Process Execution Language (BPEL), connections or adapters to your legacy systems, or connections to Web services provided by your business partners. These black boxes are your service building blocks.

Services generally are stateless, which means you do not have to worry about calling them in a certain order or in a specific context. Furthermore, you might want to incorporate the services of your business partners and access those in the same way that you access your own services. You might also want your partners to be able to access your services. With SOA, you can adapt or respond easily to a changing business environment by

swapping one service for another, or by calling new services as needed. This makes it easy for transactions to occur between businesses.

What is a standard way to access services? Services have published interfaces, which serve as a contract

between the service and the caller. An interface can be described with Web Services Definition Language (WSDL), for example, as in the case of Web services. The interface includes the specification of the data that is to be passed to and from the service. The interface doesn't specify how or with what language the service is implemented. So, you could have a service implemented with Java that makes calls to another service that is implemented with BPEL.

All that is a high level, generic view that sounds nice, but we should get down to how you can realize a service-

oriented architecture with WebSphere Integration Developer. In the last article, we described all of the different ways to implement services, but we didn't say much about how the services work together. This article dives a bit further into the details of service interaction.

The building blocks of an application

The building block metaphor is a useful way to think of a service-oriented architecture. Normally you would

stack or snap the blocks together to build a bigger application, which could become yet another one of the blocks. When you look at services this way, it is easy to grasp the WebSphere Integration Developer programming model of Service Component Architecture (SCA). SCA is a realization of SOA, and WebSphere Integration Developer is a workbench where you have the tools to not only visually assemble the blocks into a complete solution, but also to build the inner workings of each block. There is a standardization effort for SCA that is part of the Apache Tuscany open-source project. The next sections provide a primer in using the Service Component Architecture to lay out the groundwork for any solution that you will build with WebSphere Integration Developer.

Modules

Page 16 of 43

A module is a container for your services and is both a project in the WebSphere Integration Developer

workbench, and the unit of deployment to the WebSphere Process Server. That means that any solution that you build will be deployed to the server as one or more modules. For those who are familiar with J2EE, a module is packaged and deployed as an enterprise archive (EAR) file. One of the advantages of the Service Component Architecture is that you don't have to be concerned with the underlying packaging. A module provides services that can be used by other modules and that can be accessed by external clients used by your

partners or customers. A module is a collection of components and import/export as we explain in the following sections.

You create modules by right-clicking in the Business Integration view and selecting New - Module. A new

assembly diagram is created for each module you create, which you work with using the assembly editor. The Business Integration view shows all of your project's artifacts, which appears to the left of the assembly editor (if you haven't moved the view). Figure 1 shows a newly created module.

Figure 1. A new module

Components

A module is one of the bigger, course-grained building blocks that is composed of smaller, fine-grained blocks

known as components, A component is the part of a module that is the actual service. On the inside, it is implemented using one of the implementation types described in the first article (we'll recap those shortly). For example, suppose that you have an order-processing module. Within the module, you might have an inventory component that updates the inventory information system and another component that checks customer credit.

You create components in the assembly editor by selecting the component icon on the palette and then

dropping it on the assembly editor canvas. You can also drag an implementation or an interface from the Business Integration view to the canvas to create a new component. This means that you can either create your components/services by using the top-down approach of defining the contracts first and then the implementation, or you can use a bottom-up approach by pulling in an existing surface.

If you are playing along at home and have dropped a new component from the palette, it is displayed in the assembly diagram, as shown in Figure 2. The blue exclamation mark indicates that an implementation hasn't been created yet. When you create a component, you need to give it at least one interface, which we'll talk about in the next section. Remember the interface (contract) is what other services will be able to see and talk to; they will not see or care about how you implement the service/component.

Page 17 of 43

Figure 2. A service component

Interfaces

To users of a service component, all that matters is its interface, which dictates how to use it. An interface is a

specification of a component's operations. An operation is a business function or query that is provided by a service component. As an example, suppose you have an EmployeeData component, which is a service that provides employee information. It might provide just one operation, such as getEmployee, where you give it an employee ID, and it returns the data for that employee. It might have other operations such as getRetiredEmployees or getCurrentEmployees that return a set of employee data. These operations are the queries that the EmployeeData service provides.

An operation contains inputs, outputs, and faults. In the employee example, getEmployee would specify that

its input is a string and its output is employee data. The other two operations might not require any input (although you might pass in data that specifies some restrictions, for example) and return a collection of employee data. The interface can optionally specify any faults that the operation might throw because of an error condition during the service call. For example, getEmployee might be defined to throw an InvalidEmployeeID fault when the internal mechanism cannot locate any records with that ID. In some cases, an operation might not have any inputs, outputs, or faults, such as in the case where an operation is simply used to trigger an action.

You can define interfaces for your components using either WSDL or Java. Note that in Java parlance,

operations are method signatures and faults are exceptions. Creating WSDL interfaces using a text editor can be tedious. WebSphere Integration Developer provides the interface editor to simplify creating interfaces for your components, as Figure 3 shows.

You will at some point want to call external services such as Web services, so you can also import existing WSDL interfaces from your partners into the workspace.

Page 18 of 43

Figure 3. A component interface

References

So, you've declared what interface your service component will support. OK, that's great, but what happens

when you want your component's implementation to call another service. Well, you need two things. First, the other service component has to have declared its own interfaces, and your own component has to say what interfaces it will be calling. This way, when you connect the black boxes together, the system can make sure that what one service wants is what is provided by the service that you are connecting it to. Let's make this a bit drier with some technical details.

A component has one or more references. When you write your implementation for your service component,

you will never directly call another service component; that would be bad because it builds a dependency into your code on the other component. Instead, your implementation will call a reference. A reference has a name and indicates what interfaces the other service should ultimately have. Eventually, when you wire your black boxes together, you will wire that reference to another box. Presto, your implementation only knows about references and doesn't depend on any specific component. As you assemble your modules, you have complete flexibility to assemble reusable parts, provided the references match the interfaces of the destination component.

For example, Figure 4 shows a call from within a business process implementation to the Travel Agency

Partner reference, and Figure 5 shows the definition and wiring of the reference in the SimpleProcess component. This means that when a call is made to Travel Agency Partner, the service at the other end of the wire will be used.

In the assembly editor, you can right-click on a component, and select Add - Reference to add new references. A dialog box opens that lets you select the appropriate interface for the reference.

Figure 4. A service call using a reference

Page 19 of 43

Figure 5. A component reference

Wires

When we used the building block metaphor earlier, we mentioned snapping or stacking blocks together. To be

more precise, with the Service Component Architecture you use wires to connect the blocks. A wire is simply a connection in the assembly diagram that indicates which reference is connected to which component. For example, in Figure 5 the Travel Agency partner reference of the SimpleProcess component is wired to the TravelAgency component. The interface of the reference at the source of the wire must match the interface of the target component. As we will explain in the "Imports and exports" section of this article, the source of a wire can also be an export and the target can also be an import.

Implementations

An implementation of a service component is the internal business logic that carries out the service's function.

Remember, callers of your service don't know how you choose to implement your service. In fact, they don't even know if your pet hamster is secretly in there doing the work. If you are using a top-down approach, that is, if you are creating components and interfaces first, you can create an implementation by right-clicking on a component in the assembly diagram and selecting Generate Implementation. This gives you a sub-menu where you can select the appropriate implementation type, such as a business process. You can also create an implementation first by selecting File - New, and then selecting an implementation type, such as business process or human task. You can then drag the implementation from the Business Integration view to the assembly diagram to create a component automatically.

Table 1. Component implementation types

Implementation type Purpose

Business process Describes a series of activities to accomplish a business task. Coordinates services and subprocesses that are part of the overall task.

Business state machine An event-driven business process that defines a set of states for a given part of the

Page 20 of 43

application. The state machine moves from one valid state to another, based on external events that it receives. It can perform tasks or call services as it moves from one state to another.

Business rule group Captures and implements business policies and practices based on a set of rules or decision tables that can be changed dynamically after deployment.

Human task A unit of work that is done by a person instead of a program.

Java Describes business logic at a lower level than with the visual implementations such as business processes.

Selector Uses the date and time to determine which component to use. It is a slightly different type of component because it doesn't have references to the components that it selects. The components, and the times to use them, are encoded within the selector

Map An interface map translates from one interface to another, and a business object map translates from one business object to another.

Imports and exports

At some point, you will want to delegate some of your module's work to another module or even to a partner's

service. The challenge is that in the assembly editor, you can only wire components to other components that are in the same module. The solution is to use an import. An import is the same as a component, but without an implementation. Instead, an import contains a binding, which is the information on how to connect to the actual service. The import is essentially saying that, at this point, you will be going outside of your module and relying on a service elsewhere to do the work. The binding helps to identify where and what that other service is. The following bindings are available:

• SCA for binding to other WebSphere Integration Developer components

• JMS for binding to Java message services

• Stateless session bean for binding to Enterprise JavaBeans

• Web Service for binding to Web services

The other components in the module use imports in the same manner as they would any other component

(that is, to create references to it). An import must have the same interface as the component to which it is bound. In English, that means that if the import indicates it will be calling a service (wherever it may be) that has interface 1, then ultimately, that service better play nice and actually implement interface 1.

Exports come into play when you want to expose any of your module's components as services externally or to

other modules. Again, since you can't wire into your module from outside, you need to use an export. Like imports, exports must have an interface matching the component to which they are wired. Exports can also contain the same bindings as imports (with the exception of the stateless session bean). With an SCA binding, components from other modules can make service calls to your module's components. The other bindings let other applications call your components as though they were just another Web service or JMS.

As an example, suppose you had a credit history service and you anticipate that your business partners will

need to access it. You would create an export, give it a Web Service binding and wire it to your credit history component, as Figure 6 shows.

Page 21 of 43

Figure 6. Exporting a component as a Web service

Business objects

As we covered in the previous article, a business object is a container for the data that flows within and

between components. Business objects are often referred to as the currency of your application. Business objects are created using the business object editor, and are built on the Service Data Object framework (SDO), which lets you access business data within your implementations in a standard way. When you define the inputs and outputs for the operations of an interface, you can select business objects.

Business graphs are an extension of business objects. They contain additional metadata as well as change summary and event summary information that is required by various enterprise information system resource adapters. Figure 7 shows an EmployeeInfo business graph that we used as the output of the getEmployee

operation back in Figure 3. The verb attribute is for commands such as "Create" or "Delete," which some information systems require. For example, a verb value of "Create," would tell the back-end system to take the employee business object and create an entry in its database for it.

Figure 7. An employee business object and business graph

Using the building blocks

Now let's put the above concepts to use and build an application using a service-oriented architecture with WebSphere Integration Developer. The general steps of building an application are:

• Create the modules to hold all of the application artifacts.

• Create libraries (a library is another kind of WebSphere Integration Developer project) to hold artifacts that will be shared between modules. For example, if you have several modules sharing the same currency (business object) you can put those business objects into a shared library.

• Create the generic business objects that hold the data that will be used in each component, or passed between components.

Page 22 of 43

• Create interfaces to act as contracts between the components.

• Create components and add their interfaces.

• Add references to components that will use the services of other components.

• Add imports for service references that exist outside each module, and add exports to make the services of each module available to other components.

• Wire each reference to a component or import.

• Implement the components using business processes, business rules, mediations, and so on.

These steps are intentionally not numbered; depending on the situation, you can do the steps in a different

order than in the preceding list. For example, there is no reason you couldn't create interfaces that use business object types that you will define later. As we have pointed out, there are two general ways to build an application, a top-down approach and a bottom-up approach. The order in the preceding list is just one example of a top-down approach. Which route you take depends on whether you already have pieces of your application ready, or you are building it from scratch. Most likely, you will do some parts of an application with

a top-down approach and others with a bottom-up approach. Furthermore, you might choose to use shortcuts such as dragging the interface of a component to add a wire between two components and letting the assembly editor create the reference for you.

A simple order processing application

Let's consider how we might construct a simple application that handles order processing. We will conclude this

article with the general outline of how to build the application and, in the next article, we will list all of the steps to build and test it.

For the purpose of illustration, we assume that the order processing system works as follows: when the system

receives an order, it uses a customer check component to determine whether the account is in good standing. If it is, then the system sends a message to the shipping department with information on the order that is to be shipped. Or, if the account is not in good standing, nothing happens. The system waits for a response from the shipping department confirming that the order was sent. This isn't much of an application, but it should suffice to provide a quick tour of the development process.

The application requires three components: OrderProcessing, Shipping, and CustomerCheck, as Figure 8

shows. The components will be contained in the OrderProcessing module. The CustomerCheck component relies on an enterprise information system to obtain customer status. The actual order shipping is a manual process, so there is one additional component to let employees see what must be shipped, and then let them indicate when the order has been shipped. The numbers in Figure 8 show the order of execution after an order is received, assuming the customer is in good standing. A more detailed description of each component and how it works is shown after the next section. The next section shows the business object type required by the components.

Page 23 of 43

Figure 8. A simple order processing application

The Order business object

Figure 9 shows the Order business object. When an instance of this type is passed to the OrderProcessing

module, it will contain all of the data necessary to do a customer check and ship an order. In a real application, you would probably create a separate Customer business object type to hold additional customer information in addition to the customer ID string that we have here.

Figure 9. The Order business object data type

The OrderProcessing component

The OrderProcessing component is the entry point to the system when an order is received from a client

application and is the driver for the OrderProcessing module. This component receives an Order business object, which contains the order information along with the customer account number. The OrderProcessing component uses the account number to determine from the CustomerInformation component whether the account is in good standing. If so, it sends a message to the Shipping component to ship the order. If the account is not in good standing, the process simply terminates.

Page 24 of 43

Figure 10 shows the interface for the ProcessOrder component. A client calls the placeOrder operation to begin

the ordering process. The operation takes an Order business object as input. We want the client to be able to just place the order and continue with other work, so the operation is one-way. Note that an external client cannot call the placeOrder operation directly because only components in the same module can be wired to it. So the external client must use a stand-alone reference that is wired to the OrderProcessing component. The orderShipped operation is called by the ShippingProcess component when it needs to send a message that the order was shipped.

Figure 10. OrderProcessing component interface

Because the OrderProcessing component is event-driven and the allowable operations are determined by the

state of the order being processed, we will implement it using a business state machine, as Figure 11 shows. The events consist of:

• Receipt of an order (a client calls the placeOrder operation)

• Notification that the order was shipped (the shipping system calls the orderShipped operation)

The states are:

• Waiting for an order

• Customer being checked

• Order being shipped

• Order complete

Figure 11. The OrderProcessing business state machine

There are various ways to model this application in a state machine, but we have chosen this approach

because we assume that, when an order is received, it automatically triggers a customer check as it moves to

Page 25 of 43

the CustomerBeingChecked state. The result of the check automatically triggers a transition to either the OrderBeingShipped or the OrderComplete states, depending on the value of the result of a call to the CustomerCheck service while in the CustomerBeingChecked state. When in the OrderBeingShipped state, the shipping component makes a call to the shipOrder operation of the ShippingProcess component. A transition to the OrderComplete state occurs when notification is received from the Shipping component that the order was shipped.

The CustomerInformation component

Figure 12 shows the interface for the CustomerInformation component. This component determines whether the customer with the given customerID is in good standing.

Figure 12. The CustomerInformation interface

We use a simple rule to determine standing: if the customer ID starts with "gold," then the customer is

automatically considered "good." Otherwise, the customer information system is checked and his status is retrieved. This rule can be changed. Additional rules can be added after application deployment, in which case this component would be implemented using a rule group.

We assume that the information is stored in an external enterprise information system, and that another module will contain the components necessary to access that system. Therefore, this module will use an import instead of defining an implementation. An export for a component in that module will contain the same CustomerInformation interface as the import..

The Shipping and ShippingTask components

Figure 13. The Shipping interface

Figure 13 shows the Shipping interface. This component is implemented as a business process because the

activities are executed sequentially. The first activity sends notification to the ShippingTask component, whose interface is shown in Figure 14, that an order is to be shipped. The ShippingTask component is implemented as a human task because someone must physically ship the order. The ShippingTask component forwards the order information to a Web portal where an employee can view the order information, ship the order, possibly change some of the order information such as the quantity, and then indicate that the order was shipped.

You could use IBM Rational® Application Developer to create the Web portal, or, for starters, just use the

Business Process Choreographer Explorer that ships with WebSphere Process Server to stand in for your own portal. When the component receives notification from the portal that the order was shipped, it returns the updated Order business object to the shipping business process.

Page 26 of 43

Figure 14. The ShippingTask interface

When the ShippingTask component completes its work, the next activity in the Shipping process sends a message back to the OrderProcessing component via a call to the orderShipped operation.

The complete OrderProcessing module

Figure 15 shows how the components are wired together in the OrderProcessing module.

Figure 15. The assembled components in the OrderProcessing module

Summary

In this article, we introduced you to the Service Component Architecture programming model for WebSphere

Integration Developer. We put the concepts into use by showing how a simple order processing module could be built. In the next article, we will show you the exact steps in building the module, and provide explanations for each step that will help you fully understand development with WebSphere Integration Developer.

Page 27 of 43

Lecture 3 – BPEL Process

Introduction Now that you have gotten a handle on the main concepts of WebSphere Integration Developer and its suite of tools

from the first three articles, you are ready to dive deeper into business processes. As you may already know, a business process is any system or procedure that an organization uses to achieve a larger business goal. You can automate a business process or you can involve a number of steps that need to be manually completed by one or more users. Business processes can be short running, or take hours, days, weeks or more to complete. Business processes are great for driving your business, but building them within a service-oriented architecture (SOA) puts your application into overdrive. After all, the real power comes from being able to integrate the processes seamlessly with other components and modules to automate getting work done. With WebSphere Integration Developer, you can create a business process using the business process editor. A business process provides the primary means to coordinate enterprise services and describe your business logic. So, what does that mean? Well, a business process is an implementation of a service component that consists of a series of steps or activities that are run in a specific order. The activities can call other services, perform computations, or do just about any kind of programming work. The activities in a process can run sequentially or in

parallel. You can also implement branching or looping in the flow of control between activities. A business process can be part of a larger business process, and it can contain nested business processes. In the sections that follow, you will learn about:

• The parts that make up a business process

• Business process concepts

• The business process editor

• Building your own business process.

Anatomy of a business process If you read the previous article about business state machines, you might be interested to learn that business state machines are a special case of a business process. To let you in on a little secret, under the covers a business process actually implements a state machine. Both business state machines and business processes are important techniques for defining your business logic. You are probably scratching your head and wondering, "If they are both important yet similar, how can I expect to know when to use a business process instead of a state machine?"

Well, if your business logic involves responding to events, and the response depends on the current state of the process, then it may be useful to implement the logic as a business state machine. State machines are also useful when the logic is cyclic in nature; that is, where an object or part of the system goes through a series of states repeatedly. For example, a vending machine awaits coins, then lets you to buy a drink, then returns your change before it once again waits patiently for its next junk food victim. Business processes, on the other hand, are useful for all other cases, especially cases where your business logic is a series of steps that you want to execute sequentially or in parallel. SOA consists of many services connected together that talk to each other to achieve an overall goal. As you know from previous articles, a business process is one way that you can implement a service component. A business process consists of the following elements, which we will explore in the upcoming sections:

• Activities

• Partners

• Variables

• Correlation sets

• Handlers.

Activities A business process component consists of a set of activities, each of which does some work. Together, these activities represent your business logic. The work each activity does is completely up to you. It could involve performing a computation, calling a business partner's service, or perhaps asking a person in the organization to perform some manual work.

Page 28 of 43

You can break each activity down into still more activities. For example, an activity in your process might be to bill a customer for an order. Prior to your company's going cutting-edge, the overall billing activity might have been broken down into looking up the customer's address, printing an invoice, and then mailing it. The first two activities might be service calls, while the latter would probably be a human task. Activities can execute sequentially, or in parallel. For example, an activity in your ordering process might notify your inventory system that an item needs to be re-ordered while the shipping activity is executing in parallel.

For each type of activity, you can enable event monitoring using the Event Monitoring tab in the properties view. This enables your process to emit Common Event Infrastructure events as it runs. Depending on the activity type, different options are available. For example, an invoke activity can emit entry and/or exit events. An invoke activity emits an entry event when a business process is about to execute or enter the invoke activity, whereas it emits an exit event when the business process is about to finish the execution of the invoke activity. You can add activities to a process by selecting them from the palette and dropping them onto the business process editor canvas, or right-clicking on the canvas and selecting Add - [activity type]. Now let's look at the various types of activities that you can use in your processes.

Service activities Service activities enable your business process to communicate with other services and vice versa. Without service activities, your process would live a lonely, quiet life. There are three types of service activities:

• Receive

• Reply

• Invoke.

Receive activity A receive activity is an entry point to a process; it is the point where the process starts or continues. You need one receive activity per operation you define in the process's interface. In the process editor, you can specify which operation corresponds to which receive activity. That means that when a call is made to one of the process's operations, the corresponding receive activity accepts the call, and the process continues running from there. A process requires at least one receive activity to start. A receive activity can also occur in the middle of a business process. In this case, if the process encounters a receive activity while it is running, the process stops and waits for the corresponding operation to be called. An example should make this easier to understand. In the example in Figure 1, SimpleProcess has an interface that

has two operations: start and continue. These operations are receive activities that run in sequential order. Let’s take a look at what will happen when the process runs.

• When another component calls the start operation, it creates a a new process instance.

• Next, the input parameter, which you can see at the bottom of the figure, will have its value assigned to the variable Input1. The input and output variables are created for you when you create the process.

• The CallService activity runs and, when it finishes, the process stops running until it receives a call to the continue operation.

• Once a call is made to the continue operation, the process continues to the PrepareResponse activity.

Page 29 of 43

Figure 1. Service activities

Reply activity When a receive activity belongs to a request-response operation, a reply activity returns the output of the operation. Figure 1 shows a reply activity as the last node in the simple process. As Figure 2 shows, it sends the response for the start operation using Output1 as the output parameter. A reply activity doesn't necessarily need to be at the end of the process. A process could start with a receive activity, and then return a response before proceeding to do other work. You could have more than one reply activity for each receive activity, such as in the case where your process has multiple paths. The idea is that, when another component calls a request-response

operation of a process's interface, it needs to eventually get a response for that operation (it could instead get a fault returned instead of a reply; we'll talk about that shortly).

Page 30 of 43

Figure 2. Reply activity details

Invoke activity

An invoke activity simply calls an operation on another service. The services you can call with an invoke activity depend on your processes' partners, which we will explain shortly. The way you implement an invoke activity is shown in Figure 3, where the CallService invoke activity is defined to invoke the doService operation of the ServicePartner.

Figure 3. Details for an invoke activity

Structured activities A structured activity contains other activities. The structured activities include:

• Sequence

• Choice

• Receive choice

• Parallel

• While loop

• Scope.

Sequence activity The simplest structured activity is a sequence. A sequence activity contains other activities that run sequentially in the order in which they appear within the sequence. The activities it contains may be simple or they may be other structured activities. One thing we should point out: looking back at Figure 1, the complete process consists of a sequence of activities between the initial and final nodes. The editor canvas is actually one big sequence activity where you add more simple or complex activities. The sequence activity is hidden to keep the diagram clean. In fact, all the structured activities that follow, except for parallel, contain a hidden sequence wherever light-grey arrows connect activities. Figure 4 shows a simple sequence activity containing two nodes. The CallFirst activity runs first followed by the CallSecond activity.

Page 31 of 43

Figure 4. A sequence activity

ERROR: undefinedOFFENDING COMMAND: f‘~

STACK: