Architecture requirements for Service-Oriented Business Applications
A Model-Driven Engineering methodology has to organize its transformation process in such a way that the resulting artefacts conform to a chosen architecture. While the transformation from models to working artefacts is fully automated it is guaranteed that every resulting artefact conforms to the defined architecture. So, an important aspect for defining an MDE methodology is the definition of that architecture. In this article I research the architecture requirements for an MDE methodology for Service-Oriented Business Applications (SOBA’s).
In addition I also describe the problem domain. Before starting to develop a Domain-Specific Language (DSL), which is the main part of an MDE methodology, a good understanding of the application domain is needed as well as a considerable code base for systems in the domain (Visser, 2008). So, besides just listing the architecture requirements for SOBA’s, I also explain the motivation behind SOBA’s in this article as well as the properties of service-oriented development to gain a better understanding of the problem domain.
I’ll do this by first describing the origin of the term Service-Oriented Business Application (part 1), where after I explain the technical gap between application integration and service-oriented development (part 2). I explain the ideas behind a service-oriented programming model in detail in part 3. This article is concluded with an overview of the architecture requirements for SOBA’s (part 4).
1. Application infrastructure
In the past, the categorization of software products was easy. A clear distinction could be made between operating systems, applications and the middleware between operation systems and applications. According to Gartner (Hayward & Natis, 2006) these distinct software products has been evolved into suites with overlapping capabilities in these separate product categories. Besides this, the distinction between development tools and runtime middleware has also blurred. Therefore Gartner has defined a new category of software called "Application Infrastructure". They define this category as: "Application infrastructure includes the majority of runtime middleware, as well as application development and management tools that support the new generation of applications, based on service-oriented architecture (SOA), event-driven architecture (EDA) and business process management (BPM)" (Hayward & Natis, 2006). Or in short: "as platforms for delivery of business applications, including development and runtime enablers".
Although a company should, for the long term, have all the functionalities defined by the application infrastructure software category, this can’t be established in a short time frame. Therefore Gartner identified three different styles of projects which can be executed (Hayward & Natis, 2006):
- New Service-Oriented Business Applications (SOBA’s): the primary objective of these projects is the design, creation and execution of new and complete SOBA’s. The resulting applications can be either user-facing or back-end application components. Integration of new and old business logic is a minor consideration in these projects.
- Composite applications and business process support: the primary objective of these projects is the assembly and deployment of composite applications and processes. Orchestration of services in support of an application process is important. The focus of these projects is on combining existing functionality rather than creating new business functionality.
- Back-end application integration: the primary objective of these projects is the integration of the back-end data and business logic of applications. Direct user access to integrated application views is a minor consideration in these projects.
Figure 1 visualizes the different project styles for a possible IT landscape. This figure is just an example to make the distinction between the different project styles clear. The way all the different components are organized differs in practise and depends on the products used and the vision of the responsible architect. For example, service layer 1 and 2 can be implemented in one middleware product.
Figure 1 – The focus areas of the different application infrastructure projects
Both the composite applications and back-end application projects have a strong focus on integrating existing functionality. An integration architecture is usually build in several layers to break the problem into several smaller problems. Four important layers can be distinguished (Juric, Loganathan, Sarang, & Jennings, 2007): data-level integration, application / API integration, business process integration and presentation integration.
Data-level integration focuses on sharing the same data among different applications. A data integration layer should support the exchange of data among applications despite differences in data formats, structures and intended meaning of business terms (Papazoglou & Ribbers, 2006). Two different types of solutions can be distinguished in the field of data integration: data warehouses and Enterprise Information Integration (IIS) solutions. While data warehousing loads data from other data sources into one warehouse for aggregation, analysis and historical information, IIS solutions aim at virtualizing data sources for crossing warehouse boundaries and up-to-the-minute operational facts (Halevy, et al., 2005). Enterprise Information Integration is mostly integrated in Enterprise Application Integration (EAI) solutions.
Application integration focuses on sharing functionality (business logic). Application integration is usually achieved through the use of application programming interfaces (API’s). As many modern applications are constructed with distributed component technology externalizing interfaces as a point of access, the application integration layer is also known as the message or component integration layer (Papazoglou & Ribbers, 2006). Solutions for Enterprise Application Integration (EAI) are mostly indicated as an Enterprise Service Bus (ESB).
Business Process Integration (BPI) can be described as the ability to define a commonly acceptable business process model that specifies the sequence, hierarchy, events, execution logic and information movement between systems residing in the same enterprise and systems residing in multiple interconnected enterprises (Papazoglou & Ribbers, 2006). An important element of BPI is human interaction. The extension of PBI with management aspects (analysis and monitoring, measurement, optimization) is commonly referred to as Business Process Management (BPM). BPM suites are solutions in this area, however, most ESB vendors are extending the functionality of their middleware with BPM capabilities.
Presentation integration aims at showing an unified presentation layer to users, through which they can access the functionality of the underlying systems (Juric, Loganathan, Sarang, & Jennings, 2007). Solutions for this integration layer are often referred to as portals.
Figure 2 – Open Group Service Integration Maturity Model (The Open Group, 2007)
Organisations building such a layered integration architecture can be in several maturity stages. As shown in Figure 2 seven levels can be identified, the number of levels depend of course on the used maturity model. In the first two levels data integration and application (API) integration are important. Process integration becomes important in level five and six. Presentation integration can be used in each stage to give the end-user a consolidated view on their applications, components or services.
Based on the integration types and the integration maturity model we see a clear gap between application integration (level two) and process integration (level five and six). This gap comes from the fact that ‘old-style’ applications are never designed to work together, they are islands of information and automation. So Enterprise Application Integration (EAI) and Enterprise Information Integration (EII) projects attempting to bring together both data and processing from the applications are very expensive, complex and labour intensive (Lublinsky, 2007). The solution for bridging this gap is a Service-Oriented Architecture (SOA). "SOA can be defined as an architectural style promoting the concept of business-aligned enterprise service as the fundamental unit of designing, building, and composing enterprise business solutions. Multiple patterns, defining design, implementations, and deployment of the SOA solutions, complete this style" (Lublinsky, 2007). I don’t ignore the fact that a lot more definitions of SOA are going around (almost everyone seems to have his own definition), but from an architectural viewpoint this one is appropriate to explain the concepts. Only one addition have to be made: services themselves shouldn’t be ‘business-aligned’ by definition. The composite enterprise business solution, build from services should be business aligned. A big part of the services needed in (or for) a composite enterprise business solution can’t be designed from just a business perspective (see the next part of this article). The main focus of service design should be on reuse (Dubray, Composite Software Construction, 2007).
Table 1 shows the difference between the application-centric architecture and SOA. It shows that for supporting higher integration maturity levels we have to make a paradigm shift, not only at the integration level, but also in the way we build software assets.
|Design and implementation|
Table 1 – Application-centric architecture compared with SOA (Lublinsky, 2007).
Concluding we can say that for moving from integration maturity level two to a higher level, software assets have to move from applications to processes and services. Or in other words, looking at the application infrastructure projects Gartner defines, the focus of projects has to move from back-end application integration to creating new service-oriented business applications (SOBA’s).
3. Service-oriented development
As presented in Figure 1 Gartner makes a distinction between composite application projects and projects for creating new SOBA’s. Although there is a clear distinction from a project-oriented view (reuse instead of creating new functionality) the underlying programming model for both application types should be the same. What we need is a service-oriented, process-centric, composite programming model (Dubray, Composite Software Construction, 2007).
A lot of people see SOA as a direct evolution of Object-Oriented Programming (OOP), considering services just as big objects. This is as far from reality as it can get. The similarities do not extend beyond system decomposition for definition and encapsulation for implementation (Lublinsky, 2007).
The base of the differences is that OOP is based on the theory of sequential algorithmic processes (λ-calculus) while concurrent communicating systems need π-calculus, developed by Robin Milner in the late 1980s (Dubray, Automata, State, Actions, and Interactions). The programming concepts missing in OOP are messages, orchestrations and assemblies (Dubray, Composite Software Construction, 2007).
OOP is very good in producing infrastructure software assets resulting in a focus on code composition instead of asset composition. So, the focus is on developer improvement instead of improving or simplifying the way we build information systems from requirements to deployment (Dubray, Composite Software Construction, 2007).
I do not say that OOP shouldn’t be used, it is definitely the choice for creating infrastructure elements and implementations ‘under-the-hood’. However, for a Model-Driven Engineering methodology we should use a model which isn’t only based on the object orientation paradigm, it should be service-oriented, process-centric and focused on creating composite applications.
Why service-orientation? As stated before and shown in Figure 2, just integrating existing applications isn’t enough to bring enterprise the flexibility they need. For reaching a higher integration maturity level a Service-Oriented Architecture is needed in opposite of an application-centric architecture. If I talk about applications in a SOA I mean business solutions composed of services. Services aren’t the same as ‘legacy’ applications, to fulfil the needs of a SOA, services should adhere to the following principles (Erl, 2007):
- Standardized Service Contracts: services within the same service inventory are in compliance with the same contract design standards.
- Service Discoverability: services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
- Service Abstraction: service contracts only contain essential information and information about services is limited to what is published in service contracts.
- Service Reusability: services contain and express agnostic logic and can be positioned as reusable enterprise resources.
- Service Loose Coupling: service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment.
- Service Autonomy: services exercise a high level of control over their underlying runtime execution environment.
- Service Composability: services are effective composition participants, regardless of the size and complexity of the composition.
- Service Statelessness: services minimize resource consumption by deferring the management of state information when necessary.
Standardized service contracts, discoverability and abstraction are all about the definition of the interface (or contract) of a service. These principles are needed to enable the principles of reusability and loose coupling. Loose coupling calls for a messaging system supporting the communication between services. Service composability asks for the concept of assemblies to be introduced as a programming concept. The principle about service statelessness is good to strive for, but not always possible. Therefore the notion of state alignment is crucial to loosely coupled solutions (Dubray, Composite Software Construction, 2007).
From a technical perspective the presented principles can only be adhered to if a good infrastructure is available. So a distinction can be made between two main types of services (Cohen, 2007): those that are infrastructural in nature and provide common facilities that would not be considered part of the application, and those that are part of the application and provide the application’s building blocks.
So, infrastructure services are common facilities that do not add any explicit business value, but rather are part of the required infrastructure for the implementation of any business process in a SOA. Infrastructure services can be further divided into (Cohen, 2007):
- Communication services, which are mainly used for message transportation, and
- Utility services, which deliver generic (non-application-specific) infrastructural functionality. Examples of utility services are (Dubray, Composite Software Construction, 2007):
- Analytics services, analyzing the exchanged messages between services for, by example, Complex Event Processing (CEP);
- Technical services, supporting the operations of other services by offering, by example, logging and transaction capabilities; and
- Security services, delivering single sign on capabilities and identity propagation that enable services to operate on the behalf of the user.
Application services, on the other hand, are services that take part in the implementation of a business process providing explicit business value. Cohen (Cohen, 2007) divides these services into entity, capability, activity and process services. Dubray (Dubray, Composite Software Construction, 2007) adds two important types of services: delivery and decision services. This results into the following kinds of application services:
- Entity services, exposing and managing business entities;
- Activity services, implementing a specific application-level business capability;
- Capability services, implementing a generic value-add business capability;
- Process services, implementing a business process by orchestrating other services;
- Decision services, supporting the externalization and reuse of complex en critical decision points within a task, process or business object; and
- Delivery services, enabling user interactions with the system, which are always performed within a task.
The main difference between Capability services and Activity services is the scope in which they are used. While Capability services are an organizational resources, Activity services are used in a much smaller scope, such as a single composite application (Cohen, 2007).
Why a process-centric programming model? Processes are at the core of business models and the starting point of any innovation, adaption or optimization (Dubray, Composite Software Construction, 2007). In a SOA different kinds of processes exist used for the implementation of different service types.
First, a distinction can be made between business processes and service orchestrations, or in terms of standards, a clear distinction exists between BPMN and BPEL (Dubray, The Seven Fallacies of Business Process Execution, 2007) (Baeyens, 2008) (Ouyang, Aalst, Dumas, & Hofstede, 2006) (Ouyang, Dumas, Aalst, & Hofstede, 2006). Business processes, mostly defined in BPMN, are modelled from a user point of view. These process models instructs the user what to do, they never model the responses of the systems to the user input (Dubray, The Seven Fallacies of Business Process Execution, 2007). Service orchestrations, mostly defined in BPEL, are modelled from a system’s point of view. These models are used to implement new composite services (assemblies) based on (or as a function of) other services. In most cases, you should expect having a developer translating process definitions (BPMN) into user tasks, service invocations and service interactions (Dubray, The Seven Fallacies of Business Process Execution, 2007).
Second, a distinction can be made between business processes and resource lifecycles. Most work in the field of business process automation is focused on centralized process engines. Jean-Jacques Dubray states: "With this kind of thinking we are simply ignoring the very nature of business processes: enabling an organization to add value by transforming resources. Processes such as Source-to-make, Quote-to-cash… all move "things" along a work flow of activities that ultimately (and hopefully) add value to the resources being transformed and consumed. The information systems are simply here to advance, capture and report the state of these resources and activities" (Dubray, The Seven Fallacies of Business Process Execution, 2007). Resource lifecycles are a common means for explicitly modelling allowed state transitions of an object/resource during its existence (Küster, Ryndina, & Gall, 2007). The explicit modelling of lifecycles ensures that a business process manipulates object states as defined in these lifecycles. Lifecycles aren’t used a lot in current practice, most lifecycles are "built-in" the process models. It is easy to see that it takes a lot of management (in fact it is error-prone) to keep consistent lifecycles if they aren’t specified at all and if multiple processes are interacting with the same resource. With lifecycles explicitly defined it is possible to check the compliance of business processes with these lifecycles (Küster, Ryndina, & Gall, 2007) with appropriate tooling (Ryndina, Küster, & Gall, 2007).
The third, and last distinction which can be made is the one between macroflow and microflow. According to Zdun, Hentrich and Van der Aalst (Zdun, Hentrich, & Aalst, 2006) the distinction between macroflow and microflow is just conceptual, in order to be able to design process steps at the right level of granularity. They define macroflow as long running business processes and microflow as the short-running more technical processes. I’d like to refine that definitions to fit them among the other concepts. Macroflows are the same as what I called business processes before. Microflows, however, have just a partial overlap with service orchestrations. I’d like to place service orchestrations between the business processes, describing the high level user-centric processes, and microflows as a model-driven definition of internal service implementations.
As mentioned in the previous part each kind of service asks for a different implementation approach. Although not every service can be implemented with some kind of a process definition, it is important to implement most of them with processes which can be made executable, thereby enabling model-driven engineering.
I’ve presented a service taxonomy, clarifying the different service types needed for implementing a SOBA. I’ll now describe the implementation possibilities for each of these service types.
Entity services can be implemented using resource lifecycles which describe the state diagram with the possible state transitions and the triggers for a state change, events or incoming messages. State changes themselves will fire an event which can be a trigger for other services. The implementation of entity services can be done using the well-established standards BPEL (OASIS, 2007) and the Web Service Description Language (WSDL) (W3C, 2001). Although the idea of resource lifecycles is clear and can be implemented using mature standards, some challenges exist for implementing entity services (Dubray, Composite Software Construction, 2007). The first one is the management of relationships between the business objects, data is relational in nature. How to deal with that in combination with autonomous services? The second challenge is that the elements that make up a business object data structure (identity, content, state, location(s), replication, privacy) are not always available from legacy systems (in which content of a business object is persisted) because they don’t have all the elements or they don’t expose them.
Activity and capability services can be composite or atomic. In the first case they can be implemented using BPEL, in the latter one they can be implemented using microflows. For microflows no formal standard exist, they can be seen as a process-oriented Domain Specific Language (DSL). This DSL can be custom defined, but should adhere as much as possible to existing standards like BPEL, WSDL and the Service Component Architecture (SCA) (OSOA, 2007). See "Combining general purpose languages and domain specific languages for Model Driven Engineering" for an example of defining DSL’s using General Purpose Language standards.
A process service, implementing a business process, is implemented by an assembly of services interacting with each other (not centrally orchestrated) (Dubray, The Seven Fallacies of Business Process Execution, 2007). The interactions of the entity, activity, capability, decision and delivery services with each other through message exchanges and events advance the business process. It should be clear that creating such an assembly, as stated before, can hardly be done fully automatic (you don’t even want it) due to the gap between the user-centric viewpoint of business processes and the system viewpoint of assemblies.
Decisions services are implemented using rule engines. The Semantics of Business Vocabulary and Business Rules (SBVR) (OMG, 2008) standard can be used as a starting point for defining the business rules. This standard, however, isn’t very mature and supporting engines and tools aren’t widely available.
In Table 2 an overview is given of the service types and their implementation possibilities.
| Service type||Implementation||Available standards|
|Entity services||Resource lifecycles, including a state diagram defining the possible state transitions and event and/or message definitions defining the triggers for each state change.||BPEL, WSDL|
|Activity and capability services||Service orchestrations and Microflows using entity and decision services as well as pervasive services available in the model driven runtime environment.||SCA, BPEL, WSDL|
|Process services||Assemblies consisting of several other (entity, activity, capability, decision and delivery) services.||SCA, BPEL, WSDL|
|Decision services||Rule engines.||SBVR|
|Delivery services||Task engines and presentation frameworks.||BPEL4People, WS-HumanTask, AJAX, XHTML|
Now the types of services are clear along with the way to implement them the question is how to deploy and execute these services. Does every service necessarily have to be a self-containing runtime component? A component is defined as a "unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties" (Szyperski, 2002). Can one component implement multiple services?
Activity and capability services are good candidates to implement in the same component depending on the needed granularity. In order to do this a formal approach, the three dimensional method for business components identification (BCI-3D) (Albani & Dietz, The Benefit of Enterprise Ontology in Identifying Business Components, 2006), can be used for determining an (near) optimal composition of process activities and information objects in components based on the heuristic, "choose the elements so that they are as independent as possible; that is, elements with low external complexity (low coupling) and high internal complexity (high cohesion)", in which ‘elements’ can be replaced by components.
BCI-3D aims at grouping business tasks and their corresponding information objects into business components. So, based on the process architecture and information architecture services and data can be grouped into components. The base of this method is the construction of a weighted graph containing all services from the process architecture and all data objects from the information architecture as nodes. The edges consist of service-service connections, service-data connections and data-data connections. The graph is constructed based on a process and information architecture defined in DEMO (Design & Engineering Methodology for Organisations). Details can be found in (Albani, Dietz, & Zaha, Identifying Business Components on the Basis of an Enterprise Ontology, 2005), (Albani & Dietz, The Benefit of Enterprise Ontology in Identifying Business Components, 2006) and (Dietz J. L., 2006). Each edge can be weighted based on the strength of the relationship between two nodes. For example, the relation between a service which creates (or owns) a certain object is much stronger than between a service which just uses a certain object. So the edge corresponding with the first relation has a much bigger weight than the edge corresponding with the second relation.
Once the graph is fully constructed a starting solution (decomposition of the graph) is generated using a greedy graph partitioning algorithm (Jungnickel, 2005). The Kernighan and Lin graph-partitioning algorithm (Kernighan & Lin, 1970) improves this starting solution to an optimal solution. The result is an optimal decomposition of the given graph into sub graphs with high intern costs and low extern costs: the components we are searching for.
BCI-3D can also be used to determine a composition of high level process activities into multiple composite solutions (SOBA’s) supporting this high-level process. The results aren’t single components in this case, but composite solutions (assemblies, SOBA’s) consisting of several interacting services.
4. Service-Oriented Business Applications
In the previous part 3 I’ve shown the needed programming model for SOBA’s. If we, however, only look at the programming model, the consequence will be that new SOBA’s, build with an MDE methodology complying to the presented requirements, only can be used if an organization is at a high integration maturity level. A maturity level in which an infrastructure exists supporting all kinds of services, including delivery services for user interaction. Examples of needed infrastructure products are: a task engine, a BPEL engine, an Enterprise Service Bus (ESB) or mediation services, a portal server, etc.
In an ideal situation the Service-Oriented Business Applications build with a Model-Driven Engineering methodology:
- can be used by organisations at each OSIMM maturity level,
- without creating new legacy applications which should be replaced when transforming the IT landscape into a higher maturity level, and
- without the need for certain middleware products to be available.
So, a SOBA should be usable both as stand-alone application and as a component/assembly exposing services. If a SOBA is used as application it should support Enterprise Application Integration (EAI) without much effort. For integration with middleware products it should support web service standards involving transport, XML, (reliable) messaging, security, transaction and metadata (Leroux Bustamante, 2007) (Tsalgatidou & Pilioura, 2002). For a quick overview of a lot of these so-called WS* standards see (Web Service Standards, 2005). User interaction calls for several other capabilities to be supported, like web-based access with use of rich clients and servlets (Murray, 2006) or portlets. Portlets are used for presentation integration with use a portal server. Most used portlet standards are JSR-168 (Abdelnur, Chien, & Hepper, 2003) and WSRP (Web Services for Remote Portlets) (OASIS, 2003). If a SOBA is used as a component or assembly the underlying programming model should be service-oriented and process centric.
To conclude, an architecture for SOBA’s should:
- be based on a service-oriented, process centric programming model,
- consist of all elements needed to be used stand-alone,
- interoperable with messaging products like ESB’s, using the WS* standards stack,
- interoperable with portal products, using the JSR-168 or WSRP standards.
Abdelnur, A., Chien, E., & Hepper, S. (2003). JSR-000168 Portlet Specification. Retrieved May 17, 2008, from Java Community Process: http://jcp.org/aboutJava/communityprocess/final/jsr168/index.html
Active Endpoints, Adobe, BEA, IBM, Oracle, SAP AG. (2007, June). Web Services Human Task (WS-HumanTask), Version 1.0. Retrieved May 14, 2008, from IBM Developer Works: http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel4people/WS-HumanTask_v1.pdf
Active Endpoints, Adobe, BEA, IBM, Oracle, SAP AG. (2007, June). WS-BPEL Extension for People (BPEL4People), Version 1.0. Retrieved May 14, 2008, from IBM Developer Works: http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel4people/BPEL4People_v1.pdf
Albani, A., & Dietz, J. L. (2006). The Benefit of Enterprise Ontology in Identifying Business Components. In D. Avison, S. Elliot, J. Krogstie, & J. Pries-Heje, TFTP International Federation for Information Processing, Volume 214, The Past and Future of Tnfonnation Systems: 1976-2006 and Beyond (pp. 243-254). Boston: Springer.
Albani, A., Dietz, J. L., & Zaha, J. M. (2005). Identifying Business Components on the Basis of an Enterprise Ontology. Interop-Esa 2005 – First International Conference on Interoperability of Enterprise Software and Application. Geneva, Switzerland: Springer-Verlag.
Baeyens, T. (2008, Februrary 4). Process Component Models: The Next Generation In Workflow? Retrieved April 3, 2008, from InfoQ: http://www.infoq.com/articles/process-component-models
Cohen, S. (2007). Ontology and Taxonomy of Services in a Service-Oriented Architecture. Microsoft Architect Journal (Journal 11).
Dietz, J. L. (2006). Enterprise Ontology – theory and methodology. Heidelberg, Berlin, New York: Springer-Verlag.
Dubray, J.-J. (n.d.). Automata, State, Actions, and Interactions. Retrieved April 25, 2008, from eBPML: http://www.ebpml.org/pi-calculus.htm
Dubray, J.-J. (2007). Composite Software Construction. InfoQ.com: C4Media.
Dubray, J.-J. (2007, December 04). The Seven Fallacies of Business Process Execution. Retrieved April 24, 2008, from InfoQ: http://www.infoq.com/articles/seven-fallacies-of-bpm
Erl, T. (2007). SOA Principles. Retrieved June 18, 2007, from SOA Principles, an introduction to the Service-Orientation paradigm: http://www.soaprinciples.com/
Halevy, A. Y., Ashish, N., Bitton, D., Carey, M., Draper, D., Pollock, J., et al. (2005). Enterprise Information Integration: Successes, Challenges and Controversies. SIGACM-¬SIGMOD. Baltimore, Maryland, USA.
Hayward, S., & Natis, Y. V. (2006). ‘Application Infrastructure’ Reflects New Dynamics in the Software Market. Gartner.
Jungnickel, D. (2005). The Greedy Algorithm. In D. Jungnickel, Graphs, Networks and Algorithms (pp. 123-146). Berlin: Springer.
Juric, M. B., Loganathan, R., Sarang, P., & Jennings, F. (2007). SOA Approach to Integration. Birmingham: PACKT Publishing. See SOA approach to integration
Kernighan, B. W., & Lin, S. (1970). An efficient heurisitc procedure for partitioning graphs. Bell Systems Technical Journal , 291-307.
Küster, J. M., Ryndina, K., & Gall, H. (2007). Generation of Business Process Models for Object Life Cycle Compliance. In G. Alonso, P. Dadam, & M. Rosemann (Ed.), BPM 2007, LNCS 4714 (pp. 165-181). Berlin Heidelberg: Springer-Verlag.
Leroux Bustamante, M. (2007, May 16). Making Sense of all these Crazy Web Service Standards. Retrieved May 17, 2008, from InfoQ: http://www.infoq.com/articles/ws-standards-wcf-bustamante
Lublinsky, B. (2007, January 9). Defining SOA as an architectural style. Retrieved May 7, 2008, from developerWorks. IBM’s resource for developers: http://www-128.ibm.com/developerworks/architecture/library/ar-soastyle/
Murray, G. (2006). JSR-000154 Java Servlet 2.5 Specification. Retrieved May 17, 2008, from Java Community Process: http://jcp.org/aboutJava/communityprocess/mrel/jsr154/index.html
OASIS. (2007). Web Services Business Process Execution Language Version 2.0.
OASIS. (2003). Web Services for Remote Portlets Specification version 1.0. OASIS, wsrp-specification-1.0.
OMG. (2008). Semantics of Business Vocabulary and Business Rules (SBVR), v1.0. OMG Document Number: formal/2008-01-02.
OSOA. (2007, March 21). Service Component Architecture Specifications. Retrieved May 14, 2008, from Open SOA Collaboration: http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
Ouyang, C., Aalst, W. M., Dumas, M., & Hofstede, A. H. (2006). Translating BPMN to BPEL. Technical Report, BPM Center Report BPM-06-02.
Ouyang, C., Dumas, M., Aalst, W. M., & Hofstede, A. H. (2006). From Business Process Models to Process-oriented Software Systems: The BPMN to BPEL Way. BPMcenter.org: Technical Report BPM-06-27.
Papazoglou, M. P., & Ribbers, P. (2006). e-Business: organizational and technical foundations. West Sussex: John Wiley & Sons Ltd.
Ryndina, K., Küster, J. M., & Gall, H. (2007). A Tool for Integrating Object Life Cycle and Business Process Modeling. proceedings of the BPM Demonstration Program at the 5th International Conference on Business Process Management (BPM). CEUR-WS.
Szyperski, C. (2002). Component Software – beyond Object-Oriented Programming. Addison Wesley.
The Open Group. (2007, February 13). Launch Presentation and WG Updates. Retrieved May 07, 2008, from Open Group Service Integration Maturity Model (OSIMM): http://www.opengroup.org/projects/osimm/
Tsalgatidou, A., & Pilioura, T. (2002). An Overview of Standards and Related Technology in Web Services. Distributed and Parallel Databases (12), 135-162.
Visser, E. (2008). WebDSL: A Case Study in Domain-Specific Language Engineering. In R. Lammel, J. Saraiva, & J. Visser (Ed.), Generative and Transformational Techniques in Software Engineering (GTTSE 2007). Springer.
W3C. (2001, March 15). Web Services Description Language (WSDL) 1.1. Retrieved May 14, 2008, from W3C, World Wide Web Consortium: http://www.w3.org/TR/wsdl
Web Service Standards. (2005, September). Retrieved May 17, 2008, from International Virtual Observatory Alliance: http://www.ivoa.net/forum/grid/att-0344/Web_Services_Standards_09_2005.pdf
Zdun, U., Hentrich, C., & Aalst, W. M. (2006). A survey of patterns for Service-Oriented Architecture. Int. J. Internet Protocol Technology , Vol. 1 (No. 3).