This book is a design handbook and provides skills to successfully design, implement, and optimize business processes on top of SOA. Starting with business process modeling, it shows design principles to architect sound process architectures. It presents best practices for modeling business processes using BPMN, together with design principles for services and composite applications. It provides detailed coverage of how to prepare business processes for execution. An in-depth explanation of human interactions is given and also principles and best practices for using rules.
Moving on, Adaptive Case Management principles are explained, along with the reach of business processes to mobile devices and ensuring multichannel interactions. Business activity monitoring, event-driven architectures, complex event processing in relation to business processes, and enabling integration with events and IoT devices are explained. The design principles and best practices are demonstrated in a practical way on a rental car use case. For more infomation please visit Packt bookstore here.
Release: OTN & Service Technology Magazine 4.2013
Authors: Jürgen Kress, Berthold Maier, Hajo Normann, Danilo Schmiedel, Guido Schmutz, Bernd Trops, Clemens Utschig-Utschig und Torsten Winterberg
SOA and service-orientation have laid the foundation for a variety of emergent service technology innovations such as cloud computing and Big Data, while the original building blocks of SOA and service-orientation (which include BI, BPM and MDM, among others) continue to evolve by embracing fundamental service technologies, concepts and practices. The models, principles and patterns behind SOA and service-orientation can be applied to formalize any of the environments produced by modern service technologies. For example, SOA can establish interoperability between different data sources to consolidate Big Data solutions via schema-based interfaces, even when canonical data models don't exist between the solutions' underlying data sources. For example, consider a US customer whose address and zip code are stored in a CRM system but has its state information stored in the data warehouse. An ontology established via a centralized service contract and implemented by a standardized service can establish the necessary link to provide the customer with a combined view. Similarly, service-orientation design principles can be applied to SaaS services that are deployed as part of cloud-based solutions. This application can help prevent cloud environments from accumulating disparate systems and services that will require subsequent integration in order to overcome the traditional problems associated with silos.While emphasis usually falls on the various methods of applying SOA and service-orientation to service technology products and platforms, it is advantageous to take a step back and discern the ways in which this evolving landscape can reciprocally help achieve the strategic goals of SOA. Never before has there been so much potential to realize service-orientation on.
SOA Maturity Alongside Contract Standardization
Introduction: In Search of the Holy Grail of SOA In this article, we present and explore the fundamentals of applying the factory approach to modern serviceoriented software development in an attempt to marry SOA industrialization with service contracts. As service developers and designers, how can we successfully fulfill factory requirements and achieve the essential characteristic of industrialized SOA while remaining compliant with standards on the service contract level? Thinking in terms of contracts has been found to be requisite for granular sourcing strategies that virtualize
underlying implementations. Contracts also function as a common language between business units and IT teams, across cloud computing technologies, and for future-proof and agile enterprises in general. Let’s imagine that today’s “pre-industrialized” world has become one in which contracts are been replaced by organizational and technical silos and the best solutions available. In today’s SOA landscape, functional components are created for specific applications, often redundantly and lacking organizationwide standardization at the interface level. These components work well in a “silo” landscape in which the “application SOA” architecture is particularly suitable within the context of single applications. Figure 1 illustrates the simplicity of combining services within applications that results from standardized design and structures being used as the framework for interfaces and exchanged data.
Enterprise Service Bus
Introduction: Everyone seems to need to use an enterprise service bus (ESB) nowadays, but there is much confusion about its actual benefit and the various concepts this term entails. This uncertainty is revealed in statements like, “Help! My boss says we need an ESB,” or “Why do I need an ESB at all? Can’t I achieve the same thing with BPEL or BPMN?” or even “We can do everything ourselves in language X.” This article is an attempt to answer some of the most important questions surrounding this term using concrete examples, so that the areas of application that can be deemed “correct” for ESBs can be clarified:
■ What exactly is the definition of an ESB? Is it a product or an architecture pattern?
■ What are some practical uses for an ESB?
■ Do I need an ESB to build an SOA platform?
■ Which requirements do I need to satisfy?
■ Which criteria can I use to select the ESB that is most suitable for my needs?
Security requirements are usually relatively easy to manage when using local restrictions in conventional closed systems. They become more complex in the distributed system landscape of an SOA. Not limited to only an application or an application domain anymore, security must work across a range of applications and business processes. Numerous security standards have been created in order to realize these comprehensive security requirements. These include WS-SecurityPolicy, WS-Trust, XML Encryption, XKMS, XML Signature, WSFederation, WS-SecureConversation, SAML1, SAML2, and many more. Currently, no product or open source framework can fully support all of these standards. In our experience, incompatibilities arise whenever an SOA product or deployed Web service framework needs to communicate outside of its small ecosystem. Not surprisingly, project managers who are confronted with increasing expenses tend to start looking for viable alternatives. They then usually choose to develop inflexible solutions in-house that can quickly implement risky anti-patterns, such as transferring usernames and passwords within the functional payload. The variety of different standards makes it difficult to formulate a clear understanding of the available security standards and internal product dependencies, in light of the individual restrictions to designing a well-secured system. Our aim is to provide IT experts and SOA architects with tips on how to handle security responsibly, using tried and true best practices as a basis.
Some of the most important SOA design patterns that we have successfully applied in projects will be described in this article. These include the Compensation pattern and the UI mediator pattern, the Common Data Format pattern and the Data Access pattern. All of these patterns are included in Thomas Erl’s book, “SOA Design Patterns” [REF-1], and are presented here in detail, together with our practical experiences. We begin our “best of” SOA pattern collection with the Compensation pattern.
Compensation is required in error situations in an SOA, as multiple atomic service operations cannot generally be linked with classic transactions this would violate the principle of loose coupling. An error situation of this sort will occur, particularly if service operations are combined into processes or new services during orchestration or by applying the Composite pattern, and the transaction bracket has to be expanded as a result. We need mechanisms to undo the effects of individual services (the status changes in the overall system) and to ensure that a consistent system state is maintained at all times, so as to preserve system integrity. For the Compensation pattern, we would like to address the following questions:
■ Why is compensation important in relation to SOA?
■ How is the topic of compensation linked with the topic of transactions?
■ What are the challenges with regard to compensation?