PROCESO DE EXPORTACIÓN

A & B _{business rules/constraints,}

medium-level requirements

Analyze trade-offs between adoption of security objectives/patterns & the functional and quality

requirements for interactions Application of security objectives/patterns to

low-level process models

candidate security architecture (including security objectives and patterns)

process designs, low-level requirements, security architecture design, semantics framework

Systems Design Phase

Business process definition at the: (i) low-level & then (ii) service-level (i.e. expressing choreography of interactions using WS standards) process models (low-, service-level) & supporting documentation Harmonization of process & data

semantics across companies metadata repositories

from each company

viable security objectives/patterns process models, low-level functional requirements, a semantics framework

low-level process designs, service-level interaction definitions, security architecture design, semantics framework, standards/technologies to implement interactions, & security and quality requirements Defining quality requirements for

businesses (low-, service-level) process models, low-level requirements, semantics framework

Identifying & agreeing on the standards and technologies to implement interactions, especially security and quality requirements

Consider best practices & vulnerabilities in context of WS and standards/technologies

standards & technologies

Figure 3.10: Workflow model of the Systems Design phase

The Design phase is analogous to a company’s internal systems design process (such as that present in [194]) and therefore targets the definition of a low-level (or logical) systems-related view of exactly how the conceptual model from the Architectural phase will be put in place. Figure 3.10 defines the tasks.

The first activity is for the teams from each business to jointly define the low-level process models. The systems analysts within the teams should be in- volved at this point as they will have a more practical and low-level orientation

towards models. The framework advises businesses to reuse the modelling tech- nique chosen before (in the Architectural phase) but on this iteration, to break down the medium-level models to the lowest level of detail. The goal is to de- compose models such that the individual message flows between companies and the specific tasks which constitute each process activity can be seen.

In defining these low-level interactions, it is critical for company teams to

identify the actual services and define the interactions in terms of these services.

Erl [51] is one commendable reference for companies suggested by the framework, that examines moving from business processes to service models and designs, and also provides thorough guidance. Generally however, businesses should be attempting to identify aspects of functionality within processes that could form distinct logic units. To exemplify this task, Figure 3.11 is used.

Buyer Place order... Receive confirmation Receive bill... Supplier Receive order...

Verify order can be fulfilled... Send order confirmation Process order... Bill customer... Buyer Place order... Receive confirmation Receive bill... Supplier Receive order...

Verify order can be fulfilled... Send order confirmation Process order... Bill customer... Purchase order service Accounts payable service Order receipt service Order processing service Billing service

Medium-level process model Services identified from models

Figure 3.11: An example of moving from processes to services

This diagram shows a simplified medium-level process flow of a typical order processing scenario (on the left) and next to it (on the right) the services that were deduced from it. In identifying services, special attention was paid to subprocesses that could be somewhat independent and could be grouped and encapsulated with related tasks. The purchase order service is a good example of this as it encapsulates the ‘place order’ and ‘receive confirmation’ subprocesses into one unit of functionality that can be referenced.

Depending on how open companies have chosen to be with how their pro- cesses (or systems) will work internally, the low-level process definition task might

3. The BOF4WSS Approach 63

be primarily of the interactions between companies, or the interactions between

and also within the businesses. To use Figure 3.11 to explain this point, the former of these tasks refers mainly to the arrows connecting the Buyer and Sup- plier, whereas the latter refers to those arrows plus the arrows and flows within companies. Even though the ultimate degree of openness maintained by par- ties throughout the framework’s activities is largely left to the individual teams, BOF4WSS stresses that openness and transparency could foster trust. This trust is a key ingredient to successful future business interactions.

Building on the low-level process definitions, Figure 3.10 shows that the following task for system analysts is the application of WS process specification technologies, to state these low-level definitions in terms of WS-level interactions (expressing them in terms of WS wherever appropriate). This transformation task is made much easier once the low-level processes have been stated to resemble

services. WS should be viewed as the Internet-based implementation technology that will implement designed services. At this point, expressing the interactions

from a global perspective (that is, showing interactionsbetween companies rather

than internal process flows) is desired as it allows for the creation of a contract that defines a jointly agreed set of orderings and constraint rules whereby service message exchanges can take place [224].

To facilitate the expression of this global services contract, the framework suggests one of two options, either (i) the use of W3C’s Web Services Choreogra- phy Description Language (WS-CDL)—WS-CDL provides a standard mechanism for defining WS collaborations and choreographies of message exchanges from a global viewpoint [224], or (ii) BPEL4Chor—a recent proposal from the research community built on Business Process Execution Language (BPEL), that aims to address a number of perceived shortcomings of WS-CDL [44, 43]. These ap- proaches were chosen specially because of their suitability for WS and ability to produce formal, Web service-level process specifications that could feed into future framework phases.

the following factors for consideration by businesses. In terms of politics in the standards world, WS-CDL is likely to have more support from industry because it is under the charter of the W3C. A second advantage of WS-CDL is that from the process specification defined, companies have the flexibility to then use their preferred internal technologies to implement the definitions. Furthermore, there is scope for automatically generating workflow templates for these internal technologies that mirror the global perspective [157, 121]. A high-level example is given in [224], where one company may use BPEL engines to drive workflow

whilst another uses a more traditional J2EETM_solution.

Another factor regarding WS-CDL is that if companies had chosen to use the UML Profile for Schedulability, Performance, and Time Specification [148] to model processes in the Architectural phase, research work by Cambronero [21] has investigated a method for translating those models into WS-CDL documents. This might be plugged in and used by companies to automate document creation. Lastly, there is some free (albeit very limited) tool support targeted at providing users with the ability to produce, view, simulate and validate WS- CDL choreographies—namely WS-CDL Eclipse [5], Pi4SOA [163] and LTSA WS- Engineer [63]. Alternatively, software could be purchased, including Oracle SOA

Suite 11g [151] (a complete suite of SOA products for development and execution)

and IBM Rational Software Architect for WebSphere Software [88] (platform focused on development and deployment of SOA solutions).

At its core, the second approach, BPEL4Chor, defines extensions to BPEL to enable the definition of choreographies [44]. In light of this close association, BPEL4Chor can be seen to be specially suited for situations where businesses will desire subsequent BPEL workflow specifications for their internal process flows. The ability to allow for a seamless transition between choreographies (in BPEL4Chor) and orchestrations (in BPEL) is actually one of the main advantages this approach has over WS-CDL (when considering moving from WS-CDL to BPEL workflows) according to its proponents [44].

3. The BOF4WSS Approach 65

processes in previous stages, research by Decker et al. [43] describes how these BPMN models can be reused and largely transformed to BPEL4Chor. A plug-in for an available graphical modelling environment is also proposed to aid in this transformation. Decker et al. [44] could be referenced by companies for more nuances of this approach as compared to WS-CDL. In summary, WS-CDL and BPEL4Chor are both viable solutions for Web service-level process specification. With the information provided above, businesses can choose their technologies of preference.

Along with the low-level process definition shown in Figure 3.10, harmo- nization of process and data semantics across companies is critical. In this re- search however, this activity is not covered as it would necessitate an extensive discussion that digresses considerably from the focus on security. For informa- tion, some of the main aims during this stage would be tackling the semantic interoperability problem at both the data and business process levels. This prob- lem as it relates to the B2B context is discussed in detail by Papazoglou [157]. Addressing these issues would likely include the use of tools such as ontologies, shared vocabularies, metadata repositories and depending on companies’, also technologies such as Semantic Web Services.

process models, low-level functional requirements, a semantics framework

Defining quality requirements for businesses (low-, service-level)

process models, low-level requirements, semantics framework

Figure 3.12: Definition of quality requirements task in Systems Design

Next is the determination of the quality requirements at these lower levels. For ease of reference Figure 3.12 illustrates the task. In earlier stages, quality requirements were produced at a high level and these form the base for the actions here. For this task analysts and systems designers play central roles.

Business teams will need to identify details such as availability of sys- tems/services, acceptable latency levels, performance expectations by parties and

more general aspects including scalability, and even maintainability of envisioned systems. Work by Garcia and Felgar de Toledo [66] has compiled an appropri- ate listing of WS QoS attributes that can be used as a starting point by teams. These requirements and their relation to processes should be well conceived be- cause they constitute prime factors against which the security design will have to be balanced. Businesses can either mainly discuss and agree on these quality re- quirements, or if a more hands-on approach is preferred, use available techniques to specify requirements. UML for example has a profile for modelling quality characteristics (see OMG [147]) that can be used.

Analyze trade-offs between adoption of security objectives/patterns & the functional and quality

requirements for interactions

Application of security objectives/patterns to low-level process models

process designs, low-level requirements, security architecture design, semantics framework

Systems Design Phase

viable security objectives/patterns

businesses (low-, service-level)

process models, low-level requirements, semantics framework

Figure 3.13: Security analysis and application tasks in Systems Design

The next step in BOF4WSS (shown in Figure 3.13) returns the focus to security and aims to finalize the security architecture and build the security de- sign. The first task in fulfilling this aim is analysing the trade-offs between the adoption of security objectives/patterns and the low-level functional and quality requirements from prior tasks. Cost, where possible, should be generally factored in by business teams as it pertains to adopting the security directives, remem- bering that these will translate into security mechanisms and technologies later. Systems designers and security professionals with knowledge of this area can aid significantly in this task.

Sherwood et al. [186] yield a perfect example of the hard task faced by businesses in attempting to balance these often conflicting objectives. Abstracting to the three basic, conflicting aspects, namely security (for example, security requirements), cost (that is, a general limitation) and usability (normally a quality

3. The BOF4WSS Approach 67

requirement), the authors state, “To obtain higher security . . . will cost more. To increase security often impacts upon usability and visa versa” [186] (p.27).

Once the analysis is complete, the viable security objectives/patterns are then applied to the low-level process models to fashion the business process de- signs. Figure 3.13 covers this task. In the Architectural phase, security objectives have already been applied therefore if businesses have utilized this method, the task now is to break down the secured medium-level processes and associate the objectives with lower-level process components (from the low-level models above). For example, as opposed to specifying a confidentiality objective of ‘High’ on all outputs from one activity (or task or system), businesses should consider the individual messages output and whether they all need the ‘High’ confidentiality rating. The messages should be visible from low-level process models, therefore the ideal situation would be to take the low-level models and modify them to show the new, specific levels of security required for all process components.

For the application of viable security patterns, depending on the mod- elling technique chosen, patterns can be easily woven into the low-level process models. Companies will first need to gather the associations made between the medium-level processes and security patterns from the Architectural phase. Then, using the associations, teams can begin to link low-level processes (from which the medium-level processes were defined) to the relevant security patterns. This is fol- lowed by the actual application of patterns to models either conceptually (by way of detailed annotations), or logically (within the formal models). Even though some techniques may prove more efficient at this application task, the conceptual solution that security patterns provide should enable a relatively manageable task for the security professionals on the teams.

Due to its versatility and extensibility, UML again forms one of the better techniques for the modelling task. In Figure 3.6 it was shown that, for simple modelling, sequence or activity diagrams are useful. To facilitate detailed mod- elling, one suggested option is the UML profile for security, quality and fault

tolerance requirements. This profile is defined in OMG [147] and provides a standard mechanism for expressing security.

Another noteworthy option still within the structured confines of UML can be found in Rodr´ıguez et al. [172]. This research work supplies a UML profile specifically for secured business process modelling using activity diagrams. Secu- rity aspects accommodated include auditing, and security requirements such as in- tegrity, attack detection, non-repudiation, access control and privacy. UMLsec [96] and SecureUML [112] are two additional, more detailed security-related exten- sions to UML that might also be of interest to businesses.

process designs, low-level requirements, security architecture design, semantics framework

low-level process designs, service-level interaction definitions, security architecture design, semantics framework, standards/technologies to implement interactions, & security and quality requirements Identifying & agreeing on the standards and technologies to implement interactions, especially security and quality requirements

Consider best practices & vulnerabilities in context of WS and standards/technologies

standards & technologies

Figure 3.14: WS standards agreement and assessment tasks

The penultimate task in the Design phase depicted by Figure 3.14 is iden- tifying and agreeing on the standards that will be used to implement the services, and especially the security and QoS requirements. In general, even though WS is one of the leading interoperability technologies today, basic tasks such as agree- ing on standards (within WS) is still crucial to a successful deployment. Fischer and Werner [61] allude to this fact as they discuss the “What’s missing” in WS. The main interoperability problems they identified stem from the existence of too many standards (innoQ [86] shows over sixty), the tweaking of standards by individual companies and the numerous versions of even the basic WS standards. Fischer and Werner [61] accept that WS-Interoperability (WS-I) [219] profiles can address some of these problems, however they note that this is only possible if companies make their WS compatible with the WS-I profiles. Their work pro- vides just one example of the importance of the agreement on the standards to

3. The BOF4WSS Approach 69

be used by businesses.

In this task, systems analysts and designers knowledgeable in the in- tricacies of WS should take the lead. As analyst help to provide the bridge between the previous works (requirements, low-level processes and so on), de- signers look at service and technology details. Due to the extensive number of technologies available and the frequent updates made, instead of covering the standards within the framework, BOF4WSS documentation directs companies to key information sources which they can reference. Sources range from pub- lished texts [157, 194, 4, 28] for introductory- and intermediate-level material, to the standards Web sites such as W3C [225], OASIS [153], Liberty Alliance Project [110] and WS-I [219], for up-to-date, definitive information. InnoQ [86] is a good reference for a diagrammatic overview of standards placed within their context, including transaction specifications, reliability specifications and so on.

To identify security standards, the work of Steel et al. [194] is particu- larly relevant if companies have used their security pattern catalogue in previous framework phases. The reason for this is that within their catalogue, also sup- plied is a list of standards and technologies that can implement the respective patterns.

Briefly touching the topic of standards and technologies for QoS require- ments, this area is less developed. Companies however can find some information in articles such as [230]. This covers a number of WS QoS aspects, mentions standards which are used to implement them and discusses techniques to im- prove service quality.

A final point companies should be mindful of during the identification and selection of standards is the tool support available to actually use the standards in a production environment. This consideration should help guide the choice of technologies. If there is an absence of tools, regardless of the benefits of standards proposed, these standards cannot be applied.

(see Figure 3.14) advises companies to consider (i) the common vulnerabilities and pitfalls in WS and the mechanisms chosen, and (ii) the best practices in using them and implementing them as securely as possible. Both of these factors may have been analysed in some respects before, but because of their significance and the complexities regarding technologies themselves, it is reiterated here.

As done above with standards and technologies in the previous task, be- cause of the large number of vulnerabilities and range of best practices, BOF4WSS references more complete and detailed sources rather than listing them. For the first factor that is, for common vulnerabilities and pitfalls in WS, two prime sources are documents from organizations such as NIST ([189]) and WS-I ([218]). These give information on common attacks, risks and typical security challenges. The research community is another useful source for up-to-date information, for example, [92]. Examples of vulnerabilities in Jensen et al. [92] range from those linked to XML or networking generally, to more recent ones which target WS cryptography techniques, BPEL processes and internal workflow engines.

For the second task in Figure 3.14, namely the consideration of best prac- tices in using standards and dealing with the various security challenges, the following articles provide designers and developers with some useful techniques.