Loyalty program's success

CHAPTER 2 - LITERATURE REVIEW

2.1. Loyalty Program

Loyalty program's success is predicated on determining what it can realistically accomplish and then seeing appropriate goals. Goals and objectives provide actionable steps for operating the program and measurable benchmarks for gauging if it is achieving its strategic purpose.

Loyalty program rewards can be classified into two main categories: hard benefits and soft benefits. Hard benefits appeal to the rational component of customer loyalty with "tangible" rewards such as free travel. Hard benefits compel customers to immediately take advantage of an extraordinary opportunity that may not last long. Conversely, soft benefits appeal to the emotional component of customer loyalty and are slower to reward. Discounts are considered soft benefits, as they require the member to spend in order to receive and do not differentiate merchants from the competition. Focusing the member's attention on price and not on the issue of a compelling reward, soft benefits are equally important to merchants' most valuable customers, whose loyalty demands legitimate evidence of their special status? Special status means special treatment, special deals, special access and special events - whatever it takes to reinforce the sense of importance of a merchant's top-tier, high-value customers. Defining soft benefits sets apart your relationship with your best customers, offering unique experiences to your product or service and unavailable to non-members.

Real-time points programs are a powerful tool for merchants to reward loyal customers for making purchases. Point are accumulated as a percentage of the dollar amount spend and a reward for frequenting your location. Points can be adjusted to align with merchants' seasonal business cycles (double points, bonus points, etc.). All points are accrued and or redeemed at the POS in real-time. Points in effect instantly become an electronic currency that can be redeemed at all merchants participating

2.2. Distributed Computing

In computer science, a distributed system is an application that consists of components running on different computer concurrently. These components must be able to communicate and be designed to operate separately. As stated by Andrew S. Tannenbaum (Tannenbaum. 2002), "Distributed systems need radically different software than centralized systems do". The software he was discussing must be implemented in some form of distributed programming language. The types of hardware, programming languages, operating systems and other resource may vary drastically. It is similar to computer clustering with the main difference being a wide geographic dispersion of the resource.

Various hardware and software architecture exist that are usually used for distributed computing. At a lower level, it is necessary to interconnect multiple CPUs with some sort of network, regardless of that network being printed onto circuit board or made up of several loosely-coupled device and cables. At a higher level, it is necessary to interconnect process running on those CPUs with some sort of communication system (Allamaraju, S. et al., 2000).

  1. Clien-server - smart client code contacts the server for data, then formats and displays it to the user. Input at the client is committed back to the server when it represents a permanent change.
  2. 3-tier architecture - 3-tier systems move the client intelligence to a middle tier so that stateless clients can be used. This simplifies application deployment. Most web application are 3-tier.
  3. N-tier architecture - N-tier refers typically to web applications which further forward their request their request to other enterprise services. This type of application is the one most responsible for the success of application servers.
  4. Tightly coupled (clustered) - refers typically to a set of highly integrated machines that run the same process in parallel, subdividing the task in parts that are individually by each one, and then put back together to make the final result.
  5. Peer-to-peer - an architecture where there is no special machine or machines that provide a service or manage the network resources. Instead all responsibilities are uniformly divided among all machines, known as peer.

Architecture that is used in the designed is the N-Tier architecture, which is defined in Figure 1 (Allamaraju et al., 2000).

A concept of distributed computing can be implemented using an architecture providing interoperability between various systems among different platform.

According to Russ Basiura et al. (Russ Basiura et al., 2001) there is many reasons for distributing application logic:

  1. Distributed computing makes it possible to link different organizations and organizational units.
  2. Often the data accessed by the application is on a different machine. The application logic should be close to the data.
  3. Distributed application logic may be reused in several applications. Pieces of distributed application may be upgraded without upgrading the whole application.
  4. By distributing the application logic, the load is spread out to different machines, giving potentially better performance.
  5. As new need arise, application logic may be distributed or reconnected.
  6. It is easier to scale one layer than a whole application. If for example the data layer isn't fast enough, more resources can be added to this layer without affecting the entire application.

The internet has increased the importance and applicability of distributed computing. The simplicity and ubiquity of internet makes it a logical choice as the backbone for distributed applications.

2.3. Business Process Integration

Business process integration focuses on integration on and support of processes that contains business logics and information needs. Business Process Integration uses visual, business process driven models to provide real time visibility and control of strategic business processes that across applications, data, people and companies. Business process integration usually provides functionalities of connectivity, process automation, visibility and decision support.

Connectivity refers to establishing communication both within an enterprise and with external business partners such as suppliers and customers. It is a prerequisite for all integration in a distributed environment. Business process automation can be defined as the management and automatic transfer of information by software. Here human intervention is completely eliminated or reduced to the process steps where such intervention is a business requirement. Visibility is about access to aggregated and consolidated real time information within and across enterprise boundaries. Decision support involves the aggregation, synthesis and presentation of information to enhance human decision processes.

2.3.1. Business Process Management

Business process management plays an important role in business process integration. Business Process Management (BPM) refers to the closed loop, iterative management of business processes over their entire lifecycle. It includes designing, optimizing, documenting, communicating, deploying, evaluating, updating, and retiring processes. Business Process Management Systems (BPMS) are a new family of software systems that automate and simplify the task of managing business processes over the entire lifecycle. With a BPMS, the process management system specializes in orchestrating every business process, and will call on other applications for services.

The main components are the Process Development Environment, the Process Engine, Business Activity Monitoring (BAM), and System Administration. Business analysts and business users employ the development environment to define business processes and business rules to be executed on the BPMS. This component also enables processes to be simulated before they are deployed, so that potential bottlenecks are identified and removed. The process engine is responsible for managing project instances. This includes creating process instances, prioritizing them, ensuring process integrity and performance, managing the interfaces with services and users, executing business rules, and generally ensuring that the business process meet the expectations of the business.

Business Activity Monitoring (BAM) provides the business with data and reports on the performance of various business processes. This enables the process owner to identify bottlenecks and to drill down into the data to obtain even more detailed views of process capability.

System administration refers to the features of the BPM product that enable system administrators to configure users and their rights, administer the servers, monitor performance, etc. The BPMS uses the Enterprise Services Infrastructure to access the underlying applications and databases. These applications and Databases themselves expose their functionality in the form of services, which are managed by the Service bus, and combined in various ways to create composite services.

2.4. Enterprise Java Bean (EJB)

2.5. Component Object Model (COM)

The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM is the foundation technology for Microsoft's OLE (compound documents), ActiveX (Internet-enabled components), as well as others.

To understand COM (and therefore all COM-based technologies), it is crucial to understand that it is not an object-oriented language but a standard. Nor does COM specify how an application should be structured; language, structure, and implementation details are left to the application developer. Rather, COM specifies an object model and programming requirements that enable COM objects (also called COM components, or sometimes simplyobjects) to interact with other objects. These objects can be within a single process, in other processes, and can even be on remote computers. They can be written in different languages, and they may be structurally quite dissimilar, which is why COM is referred to as abinary standard; a standard that applies after a program has been translated to binary machine code.

The only language requirement for COM is that code is generated in a language that can create structures of pointers and, either explicitly or implicitly, call functions through pointers. Object-oriented languages such as C++ and Smalltalk provide programming mechanisms that simplify the implementation of COM objects, but languages such as C, Java, and VBScript can be used create and use COM objects.

COM defines the essential nature of a COM object. In general, a software object is made up of a set of data and the functions that manipulate the data. A COM object is one in which access to an object's data is achieved exclusively through one or more sets of related functions. These function sets are calledinterfaces, and the functions of an interface are calledmethods. Further, COM requires that the only way to gain access to the methods of an interface is through a pointer to the interface.

Besides specifying the basic binary object standard, COM defines certain basic interfaces that provide functions common to all COM-based technologies, and it provides a small number of functions that all components require. COM also defines how objects work together over a distributed environment and has added security features to help provide system and component integrity.

2.5.1. COM+

COM+ is an evolution of Microsoft Component Object Model (COM) and Microsoft Transaction Server (MTS). COM+ builds on and extends applications written using COM, MTS, and other COM-based technologies. COM+ handles many of the resource management tasks that you previously had to program yourself, such as thread allocation and security. COM+ also makes your applications more scalable by providing thread pooling, object pooling, and just-in-time object activation. COM+ also helps protect the integrity of your data by providing transaction support, even if a transaction spans multiple databases over a network.

2.6. Web Service

Web Service according to World Wide Web Consortium (W3C) organization, which establishes the standards for Web services is "software system identified by a URI whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML-based messages conveyed by Internet protocols." A simpler definition, and perhaps more useful, might be: "a Web service is a software application, accessible on the Web (or an enterprise's intranet) through a URL, that is accessed by clients using XML-based protocols, such as Simple Object Access Protocol (SOAP) sent over accepted Internet protocols, such as HTTP. Clients access a Web service application through its interfaces and bindings, which are defined using XML artifacts, such as a Web Services Definition Language (WSDL) file.

Web services are a result of the natural evolution of the Web. Initially, the Web consisted of sites that were plain HTML pages. Later, Web applications dynamically generated these same HTML pages. For example, a map Web site initially provided only static links to maps of various cities and locales. Later, this same map Web site became a map Web application that provided driving directions, customized maps, and so forth. Despite their expanded capabilities, Web applications are still limited to the restricted GUI capabilities of their HTML pages--a Web application is usable only through the limited GUI bound to the HTML pages. Web services go beyond this limitation, since they separate the Web site or application (the service) from its HTML GUI. Instead, the service is represented in XML and available via the Web as XML. As a result, the same map Web site can extend its functionality to provide a Web service that other enterprises can use to provide directions to their own office locations, integrate with global position systems, and so forth.

Web services, or simply services, build on knowledge gained from more mature distributed computing environments (such as CORBA and Java Remote Method Invocation) to enable application-to-application communication and interoperability. Web services provide a standardized way for applications to expose their functionality over the Web or communicate with other applications over a network, regardless of the application's implementation, programming language, or computer platform.

Web services can provide a means for an enterprise to expand its business offerings, increase the efficiency of its business processing, and to improve its customer experience. By including with its own services the offerings of multiple partners, both the enterprise and the partners expand their capabilities and their business base. Not only can Web services help automate business processing; it can streamline interactions with outside services, such as credit card and shipping services. As a result, customers are offered an enriched experience: more options and greater choices, along with more flexibility. Thus an enterprise consider to implement Web services-based application

Like any application, Web services-based applications can perform a range of functions. Some may handle only simple requests for information, while others may implement complex business processes and interactions. Whereas browser-based applications are concerned with the representation of data to end users, Web services let clients programmatically not only use the Web to obtain information but also to access these service components and their functionality. Furthermore, applications can incorporate Web service functionality for their own use.

2.6.1. Purpose of Web Service Architecture

Web Services provide a standard means of interoperating between different software applications, running on variety of platforms and/or frameworks. The web service architecture is an interoperable architecture: it identifies those global elements of the global web service network that are required in order to ensure interoperability between web services.

2.6.2. Web Service Architecture

Web services have four models of architectures:

  1. The message oriented model focuses on messages, message structure, and message transport and so on - without particular reference as to the reasons to the messages, nor to the significance. The essence of the message model revolves around a few key concepts illustrated above: the agent send and receive s messages, the structure of the message in terms of message headers and bodies and the mechanisms used to deliver message level model. The abridged diagram shows the key concepts; the detailed diagram expands on this to include and many more concepts and relationships.
  2. The service oriented model focuses on aspects of service, action and so on. While clearly, in any distributed system, service cannot be adequately realized without some means of messaging, the converse is not the case: messages don't need to relate the services. The service oriented model is the most complex of all the models in architecture. A service is realized by an agent and used by another agent. Services are mediated by means of the messages exchanged between requester agents and provider agents. A very important aspect of services in their relationship to the real world: services are mostly deployed to offer functionality in the real world: service is mostly deployed to offer functionality in the real world. Finally, the Service Oriented Model makes use of meta-data, which is a key property of Service Oriented Architecture. This meta-data is used to document many aspects of services: from details of the interface and the transport binding to semantics of the service and what policy restrictions there may be on the service. Providing rich description is a key to successful deployment and use of services across the internet.
  3. The Resource Oriented Model focuses on resources that exist and have owners. The resource model is adopted from the Web Architecture concept of resource that exist and have owners
  4. The Policy Model focuses on constraints on behavior of agents and services. We generalize this to resources since policies can apply equally to documents (such as descriptions of services) as well as active computational resources. Policies are about resources. They are applied to agents that may attempt to access those resources, and are put in place, or established, by people who have responsibility for the resource. Policies may be enacted to represent security concerns, quality of service concerns, management concerns and application concerns.

And the architecture model will use service-oriented model which is related to the integration, development, and maintenance of complex enterprise information systems

2.6.3. Benefits

Web services are gaining in popularity because of the benefits they provide. Listed here are some of the key benefits:

1. Interoperability in a heterogeneous environment

Probably the key benefit of the Web service model is that it permits different distributed services to run on a variety of software platforms and architectures, and allows them to be written in different programming languages. As enterprises develop over time, they add systems and solutions that often require different platforms and frequently don't communicate with each other. Later, perhaps due to a consolidation or the addition of another application, it becomes necessary to tie together this disparate functionality. The greatest strength of Web services is their ability to enable interoperability in a heterogeneous environment. As long as the various systems are enabled for Web services, they can use the services to easily interoperate with each other.

2. Business services through the Web

An enterprise can use Web services to leverage the advantages of the World Wide Web for its operations. For example, an enterprise might make its product catalog and inventory available to its vendors through a Web service to achieve better supply chain management.

3. Integration with existing systems

Most enterprises have an enormous amount of data stored in existing enterprise information systems, and the cost to replace these systems is such that discarding these legacy systems may not be an option. Web services let enterprise application developers reuse and even commoditize these existing information assets. Web services provide developers with standard ways to access middle-tier and back-end services, such as database management systems and transaction monitors, and integrate them with other applications. In addition, because these services are provided consistently, developers do not need to learn new programming models or styles as integration needs expand.

4. Freedom of choice

Web service standards have opened a large marketplace for tools, products, and technologies. This gives organizations a wide variety of choices, and they can select configurations that best meet their application requirements. Developers can enhance their productivity because, rather than having to develop their own solutions, they can choose from a ready market of off-the-shelf application components. Tools, furthermore, provide the ability to move quickly and easily from one configuration to another as required. Web services also ensure the standardization of tools, so that development tools can adopt new tools, whether from server vendors or third-party tool developers, as needs arise.

5. Support more client types

Since a main objective of Web services is improving interoperability, exposing existing applications or services as Web services increases their reach to different client types. This occurs regardless of the platform on which the client is based: it doesn't matter if the client is based on the Java or Microsoft platforms or even if it is based on a wireless platform. In short, a Web service can help you extend your applications and services to a rich set of client types.

6. Programming productivity

To be productive in the information economy requires the ability to develop and deploy applications in a timely fashion. Applications must go quickly from prototype to production and must continue to evolve even after they are placed into production. Productivity is enhanced when application development teams have a standard means to access the services required by multitier applications and standard ways to support a variety of clients. Web services help to enhance programming productivity by creating a common programming standard. Prior to the advent of Web services, developers programming in the distributed computing environment have relied on a diverse set of not-always-compatible technologies. Developers have attempted to tie together various diverse back-end systems, such as both custom and standard database management systems and transaction processors, with traditional Web technologies, but have had to deal with a multitude of programming models. Because Web services introduce a common standard across the Web, vendors, in the interest of staying competitive, are more likely to develop better tools and technologies. These tools and technologies will attract developers because they emphasize increased programming productivity.

2.6.4. Web Service standards

2.6.4.1. Extensible Markup Language (XML)

XML is an industry standard, system-independent way of representing data. Like HTML (Hyper Text Markup Language), XML encloses data in tags, but there are significant differences between the two markup languages. First, XML tags relate to the meaning of the enclosed text. In other words: XML is a way of describing data and an XML file can contain the data too, as in the database. It is a simplified subset of Standard Generalized Markup Language (SGML). Its primary purpose to facilitate the sharing of data across the different systems, particularly systems connected via the internet.

Because XML tags indicate the content and the structure of the data they enclose, they make it possible to do things like archiving and searching. A second major difference between XML and HTML is that XML are extensible, allowing programmers to write their own XML tags to describe the content. With HTML, users are limited to use only tags that have been predefined in the HTML specification. With the extensibility that XML provides, users can create the tags needed for particular type of document.

2.6.4.2. Simple Object Access Protocol (SOAP)

2.6.4.3. Web Service Definition Language (WSDL)

WSDL (Web Service Description Language) is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate. WSDL is able to describe the communications in some structured way by defining an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages. WSDL service definitions provide documentation for distributed systems and serve as a recipe for automating the details involved in applications communication.

A WSDL document definesservicesas collections of network endpoints, orports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions:messages, which are abstract descriptions of the data being exchanged, andport typeswhich are abstract collections ofoperations. The concrete protocol and data format specifications for a particular port type constitute a reusablebinding. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Hence, a WSDL document uses the following elements in the definition of network services:

  • Types- a container for data type definitions using some type system (such as XSD).
  • Message- an abstract, typed definition of the data being communicated.
  • Operation- an abstract description of an action supported by the service.
  • Port Type-an abstract set of operations supported by one or more endpoints.
  • Binding- a concrete protocol and data format specification for a particular port type.
  • Port- a single endpoint defined as a combination of a binding and a network address.
  • Service- a collection of related endpoints.

2.7. Service Composition

2.7.1. Orchestration and Choreography

Depending on the requirements, composition of services can address private or public processes, for which two terms are used:

2.7.1.1. Orchestration

In orchestration, a central process (which can be another web service) takes control over the involved web services and coordinates the execution of different operations on the web services involved in the operation. This is done as per the requirements of the orchestration. The involved web services do not know (and do not need to know) that they are involved into a composition and that they are a part of a higher business process. Only the central coordinator of the orchestration knows this, so the orchestration is centralized with explicit definitions of operations and the order of invocation of web services.

2.7.1.2. Choreography

Choreography on the other hand does not rely on a central coordinator. Rather, each web service involved in the choreography knows exactly when to execute its operations and whom to interact with. Choreography is a collaborative effort focused on exchange of messages in public business processes. All participants of the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing of message exchanges. Choreography in web services composition is as shown in the following figure:

From the perspective of composing web services to execute business processes, orchestration has an advantage over choreography. Orchestration is a more flexible paradigm, although the line between orchestration and choreography is vanishing. Orchestration has the following advantages:

  • We know exactly who is responsible for the execution of the whole business process.
  • We can incorporate web services, even those that are not aware that they are a part of a business process.
  • We can also provide alternative scenarios when faults occur.

BPEL provides support for orchestration and choreography through executable and abstract business processes.

2.8. Business Process Execution Language

The recently released Business Execution Language for Web Services (BPEL4WS) specification is positioned to become Web Services standard for composition (IBM, 2002). It allows you to create complex processes by creating and wiring together different activities that can, for example, perform Web Services invocations, manipulate data, throw fault, or terminate a process. These activities maybe nested within structured activities that define how they may be run, such as in sequence, or in parallel, or depending on certain conditions.

Within enterprises, BPEL is used to standardize enterprise application integration and extend the integration to previously isolated systems. Between enterprises, BPEL enables easier and more effective integration with business partners. BPEL stimulates enterprises to further define their business processes, which in turn leads to business process optimization, reengineering, and the selection of the most appropriate processes, thus further optimizing the organization. Definitions of business processes described in BPEL do not influence existing systems. BPEL is the key technology in environments where functionalities already are or will be exposed via web services.

BPEL represents a convergence of two early workflow languages, WSFL (Web Services Flow Language) and XLANG. WSFL was designed by IBM and is based on the concept of directed graphs. XLANG was designed by Microsoft and is a block-structured language. BPEL combines both approaches and provides a rich vocabulary for the description of business processes.

2.8.1. BPELW4S Concepts

BPEL4WS supports two distinct usage scenarios:

  • Implementing executable business processes.
  • Describe non-executable abstract processes.

As an executable process implementation language, the role of BPEL4WS is to define a new Web Service by composing a set of existing services. Thus, BPEL4WS is basically a language to implements such composition. The interface of the composite service is described as a collection if WSDL portTypes, just like any other Web service. The composition, (called the process) indicates how the service interface fits into the overall execution of the composition.

The composition primitives found in BPEL4WS come primarily from many years of experience in workflow and business process integration, hence it's positioning as a business process composition language.

2.8.2. Implementing the Service

Unlike a traditional programming language implementation of WSDL service, each operation of each portType does not map to separate piece of logic in BPEL4WS. Instead, the entire type of the service (that is, the set of portTypes of the service) is implemented by one single BPEL4WS process. Thus, specific "entry-points" corresponding to external users invoking the operations of the interface are indicated within the BPEL4WS description. These entry points either consume WSDL operations incoming messages from input-only and input-output (request-response) operation of WSDL; output-only (notification) and output-input (solicit-response) operations are not required nor supported.

The BPEL4WS process itself is basically a flow-chart like expression of an algorithm. Each an operation on some Web Service (), waiting for a message to operation of the service's interface to be invoked by someone externally (), generating the response of an input/output operation (), waiting for some time (), copying data from one place to another (), indicating that something went wrong (), terminating the entire service instance (), or doing nothing ().

These primitive activities can combined into more complex algorithm using any of the structure activities provided in the language. These are the ability to define an ordered sequence of steps (), the ability to have branching using the new common "case statement" approach (), the ability to executer one of several alternatives path (), and finally ability to indicate that a collection of steps should be executed in parallel (). Within activities executing in parallel, one can indicate execution order constraints by using links. Each BPEL process will also define partner links, using , and declare variables, using .

BPEL4WS allows you to recursively combine the structured activities to express arbitrary complex algorithm that represents the implementation of the service.

2.8.3. Interacting with others: Partners

As a language for composing together a set of services into a new service, BPEL4WS processes mainly consist of making invocations to other services and/or receiving invocations from clients. The prior is done using () activity and the latter using the () and () activities. BPEL4WS calls these other services that interact with a process partner. Thus, a partner is either a service the process invokes (invoked partners) as an integral part of its algorithm, or those that invoke the process (client partners).

The first kind of partner is obvious - the process must clearly invoke other services to things. The activity indicates the partner to invoke and what operation of which of the partner portTypes to invoke on that partner. Notice, however, that invoked partners may end up being clients as well - it may be the case that the process invokes an operation on the partner to request some service. Later on, the partner may invoke an operation on the process to provide the desired data.

The reason for treating clients of the process as partners may not be so obvious. There are actually two reasons for it: the first is that in sometimes the process may need to invoke operations on one of its client partners. This is primarily how asynchronous interaction is supported: the client invokes an operation on the client partner. At that point, there is no distinction between a client partner and an invoked partner.

The second reason is that the service offered by the process may be used by more than one client. In addition, the process may wish to distinguish between these different users of the service. For example, a process representing a loan servicing system offers a single Web service, but only parts of it are accessible to customer applying for the loan, other parts for the customer service representative and finally the entire service to the loan underwriters. Depending on whether an operation is invoked by the customer or by the underwriter, the returned behavior may be quite different. Furthermore, the approach of using partners to model clients allows the process to indicate that certain operations may only be invoked by certain clients.

Thus, partners are one of the following:

  • Services that the process invokes only.
  • Services that invoke the process only.
  • Service that the process invokes and invoke the process (where either may occur first).

The first two straightforward invoked partners and client partners, respectively. Consider the relationship between the process and the service for the third case when the process invokes the service first. That means that the service provides (or publishes) a portType (PT1) and the process invoked an operation of that portType. Also, the process must provide a portType (PT2) that the service invokes an operation out of. Thus, form the point of view of portType PT2 to the service. Looking at the same relationship from the point of view of the service leads to opposite statement. The service offers the portType PT1 to the process and requires the portType PT2 from the process. The situation is the same whether the process invokes the service first or vice-versa.

2.8.4. Service Link types

Modeling the third kind of partners is what gives rise to service link types. Instead of defining the relationship between the service and the process from the point of view of one of these participants, a service link type represents a third party declaration of relationship between two (or more potentially) services. A service link type defines a collection of roles, where each role indicates a list of portTypes. The idea is that when two services interact with each other, the service link type is a declaration of how they interact - essentially what each party offers. BPEL4WS uses service link types to define partners. Basically, a partner is defined by giving it a name and then indicating the name of a service link type and identifying the role that the process will play from that service link type and the role that the partner will play. In the pure invoked partner and pure client partner cases, the service link type will have just one role in it and, hence, only one is indicated at partner definition time. The partner name is then used in , and activities to indicate the desired partner.

2.8.5. Service Reference

The partner must resolve to an actual Web Service in order for it to work at runtime. Thus, a partner is really eventually just a typed service reference, where the typing comes from the service link type and the roles. The BPEL4WS process itself doesn't indicate how partner is bound to a specific service; that is considered a deployment time or runtime binding step that must be supported by the BPEL4WS implementation.

2.8.6. Dealing with problems

Developers need ways to handle and recover from errors in business process. BPEL4WS has exceptions (faults) built into the language via and constructs. The fault concept on BPEL4WS is directly related to fault concept on WSDL and in facts build on it.

In addition, BPEL4WS supports the notion of compensation, which is technique for allowing the process designer to implement compensating actions for certain irreversible actions. Fault handling and compensating is supported recursively in BPEL4WS by introducing the notion of a scope, which is essentially the unit of fault handling and/or compensation.

2.9. Enterprise Service Bus (ESB)

According to the David A. Chappell, an ESB is a standards-based integration platform that combines messaging, web services, data transformation, and intelligent routing to reliably connect and coordinate the interaction of significant numbers of diverse applications across extended enterprises with transactional integrity. An extended enterprise represents an organization and its business partners, which are separated by both business boundaries and physical boundaries. In an extended enterprise, even the applications that are under the control of a single corporation may be separated by geographic dispersion, corporate firewalls, and interdepartmental security policies.

An ESB provides the implementation backbone for an SOA. It provides a loosely coupled, event-driven SOA with a highly distributed universe of named routing destinations across a multiprotocol message bus. Applications (and integration components) in the ESB are abstractly decoupled from each other, and connect together through the bus as logical endpoints that are exposed as event-driven services.

Please be aware that the free essay that you were just reading was not written by us. This essay, and all of the others available to view on the website, were provided to us by students in exchange for services that we offer. This relationship helps our students to get an even better deal while also contributing to the biggest free essay resource in the UK!