SOA OSB BPEL BPM Presentation

Editor's Notes

• #7: Service-Oriented Architecture is a way of organizing applications and processes in terms of services. Functionality available through automated means is exposed in services that can easily be used and reused. However, services do not need to be automated: Actions performed by a human actor can be included in a service, too. In fact, one of the key aspects of working with a service is that we do not know how it is implemented or whether it is automated at all.An important objective and benefit of working with services is decoupling — the ability to have services interact while minimizing their interdependencies. The latter allows us to make local changes with minimal impact on the whole environment, such as modifying the implementation of a service, changing its physical location, or even replacing one service with another. In addition, complex services and processes can easily be composed offering rich, dedicated functionality by assembling results based on multiple less complex services.The cornerstone of SOA obviously is the concept of a service. And what exactly is a service? For our purposes, we can define a service as a collection of capabilities (sometimes referred to as operations) that are defined in a standardized interface contract and can be invoked by external consumers. The implementation of the service is encapsulated, hidden from the consumers. Web Services have the additional quality of interoperability through the use of industry standards, both for specifying the service contract and for the protocol used for making calls to and receiving responses from the service.Services comprise unassociated, loosely coupled units of functionality that have no calls to each other embedded in them.Rather than services embedding calls to each other in their source code, they use defined protocols that describe how services pass and parse messages using description metadata.
• #8: Continue reading at http://www.accentway.com/web/soa
• #9: Flexibility, or business agility, is an important goal for modern organizations in order to compete in fast-changing markets, keep up with ever-evolving regulations, and satisfy demanding customers.Architecture strives for alignment between business and IT. SOA aims at providing the agility to quickly respond to changing requirements by re-wiring existing and assembling new functionality through the reuse of existing building blocks (services) and providing capabilities in an interoperable, cross-platform, and cross-domain manner;The functionality is exposed through services with well-defined interfaces and encapsulated (hidden) implementations.Associated with SOA are various other architecture topics . One such topic is Business Process Management (BPM)—a continuous process improvement endeavor that’s focused on designing, executing, and monitoring business processes and looking for ways to optimize them; business processes in BPM consist of human tasks and automated operations—the latter implemented through calls to Web Services. BPM promises better control and higher quality, lower costs, and an intrinsic capability to rapidly change the process flow. BPM integrates with and can build on SOA.EDA (Event-Driven Architecture) is another topic that borders on SOA and that can be seen as an extension or specialization of SOA — a pattern that promotes a high degree of decoupling between systems and components through event-based, asynchronous communication via a generic mediator from producers to consumers; EDA allows business processes to initiate service execution in response to events without creating direct dependencies that would hamper the ability to change the components. SOA, BPM, and EDA are related, as shown in the figure. The business processes in BPM raise events when certain business conditions occur and call services to perform automated tasks. The services may invoke other services as well as trigger additional events. The event mediator handles the events produced by processes and services, and propagates them to any registered consumer—possibly a service to be initiated or a process to be triggered or updated.
• #10: Types of services:Business services Services that offer quite dedicated, often complex functionality defined in business terms and supporting tasks in business processes (called business services or task services); these services are typically exposed to consumers throughout the business domain, the enterprise, or even to a wider audience.Continue at www.accentway.com
• #11: Application Service Components LayerThe application (service) components layer consists of the service implementations. For example, if we have an appointment service, the application component that creates the appointment in our clinical information service is the service implementationServices and Events The services and events describe the contracts and the interfaces of the service. The contract of our appointment service could state that it is available during office hours and can be used by authorized personnel only. The interface can be defined through operations, inputs, and outputs, as well as the events consumed by the service and published by it. The appointment service in a hospital, for example, has the following operations: create appointment, cancel appointment, and reschedule appointment. The input parameters for the create appointment operation are patient, date, and doctor; the output parameters are the appointment details. The service publishes the “appointment was cancelled” event and consumes the events with regard to the death of a patient.Within the services layer, we usually apply a taxonomy—a classification scheme to organize the potentially large number of services. This is useful, because it helps keep track of what services exist in the organization. This is an important precondition for reuse: You can only reuse something if you know that it exists and are able to quickly find it. Even more important: Services with specific classifications have different rules applied with regard to granularity, behaviour, security, and more.As an example, say Mary creates the taxonomy by defining the following service types for a hospital (St. Matthews): business services, elementary services, technical services (e-mail, notification service), and enterprise services (the latter are business services exposed outside their business domain).A service inventory (or service repository) is a collection of services under some form of governance that assists the organization in finding services, defining and maintaining taxonomies, and recording metadata about the services published in an enterprise. Various tools exist that provide an implementation of a service inventory.The service layers represent different levels of abstraction. Elementary services are specific to a domain. When we use business domains (sometimes called information domains) to organize our applications, we can assign the elementary services to these business domains. Elementary services often offer CRUD-type operations on an entity (CRUD stands for create, update, delete). An example can be an elementary patient service that offers the operation “addPatient.” Business services are usually composed of one or more elementary services and perform an atomic operation or task defined in the business domain. An example of a business service is a medication service that has the operation “prescribemedication.” This service can use the patient service to look up address information about the patient, and a “MedicalRecord” service can be used to get the prescription needed.Enterprise services are business services that the organization as a whole offers to consumers throughout the enterprise—across business domains—and sometimes even outside of it, to customers and business partners. A special type of enterprise services in the context of St. Matthews hospital includes services offered to the hospital by its external partners, such as insurance companies, other hospitals, government agencies, and third parties in the cloud. St. Matthews keeps a list of these as well. It is important for the hospital to keep track of all the dependencies on services, including these external services.Business events are published by services and business processes to a generic event-handling framework. These events carry a (usually small) payload with specifics about the events. Interested consumers—services, business processes, or application components—register their interest in events of specific types with the framework through subscriptions. When an event occurs that they have subscribed to, the framework sends it to them. Thus, events establish a decoupled link between producers and consumers of events. Note that events, too, exist at various levels: business, elementary, and technical. Complex event processing can be used to deal with the finer-grained and more frequently occurring elementary events.Business Processes LayerThis layer contains the business processes. Simply put: A business process consists by and large of calls to services for automated operations and human tasks for manual actions—with some flow logic in between. Business Process Management (BPM) is concerned with the management of business processes in an organization. The cycle of Business Process Management consists of the following stages: business process analysis, business process execution, and business process monitoring. There are different types of processes. One category is formed by human-centric processes, where most of the work is done by humans and the most important challenge is to assign workloads evenly and to monitor the progress of tasks. This is what is traditionally known as workflow.Another category includes document-centric processes. These are processes that evolve around documents, such as contracts or a press release for a website. Typically, you will see this in document management and content management systems. There will be processes for scanning, editing, approving, and publishing the documents. The third category of processes is system-centric processes. This is what is traditionally called orchestration. One of the biggest improvements in system-centric processes in recent years has been the shift from batch processing to straight-through processing of one item. The last category of processes is called rule-centric processes. A rule-centric process is one that has many alternative paths, depending on existing business rules.GUI LayerThis layer contains the interface that interacts with end users. Components in this layer, such as back-office applications or customer-facing portlets and mash-ups, use the business processes and services layer to retrieve data and perform actions.ESB An ESB sits between service consumers and the services they invoke (see the ESB figure on NEXT PAGE). It typically has a number of features that facilitate the interaction and help decouple consumers from providers:Endpoint Virtualization When service consumers call a service through the ESB instead of calling the provider directly, location transparency is achieved in the architecture. A service provider can be replaced by another service provider, without the need to change every service consumer to reflect the new address. Only the ESB knows which service provider is invoked exactly; all the consumers leave it to the ESB. This is called virtualization of services.Routing of services Sometimes the routing is more specific: Based on the content of the request message from the consumer, the service is selected to forward the request to; this is called content-based routing.Transformation Providers and consumers don’t always speak the same language: They frequently do not use the same protocols or message formats. The enterprise service bus can transform a request to the format and/or protocol supported by the service and does the inverse to the response before handing it back to the consumer. Messages inside the ESB are based on the canonical data model (CDM); messages are transformed to the CDM upon entering the ESB and may need to transform to application-specific formats when traveling out of the ESB.A special element in transformation can be message enrichment: The result of the transformation is not just the same data in a different message structure but an enriched message with additional information that has been looked up (for example, an appointment request that has been enriched with the recent medical history for the patient).Validation The ESB can validate requests before they are delivered to the service provider as well as the responses coming out of the provider.Auditing The ESB can log requests and responses for auditing purposes and send out alerts when special conditions apply.Messaging Instead of calling a service, an application can send messages and communicate asynchronously with other applications. The ESB can provide guaranteed delivery and persistence of the message. Synchronous/asynchronous adaptation An enterprise service bus can expose services with either a synchronous or an asynchronous interface—regardless of the nature of the actual service provider(s) it needs to invoke; It can adapt from synchronous to asynchronous, and vice versa. This—together with support for queuing and store-and-forward for services that are temporarily unavailable—provides another very important type of decoupling: The provider does not need to be available at the same time as the consumer, and the consumer does not need to wait for the response from the service it invokes. This has the same impact on service invocations as the answering machine and voicemail had on communication via telephone. Composition An ESB may be used to aggregate the results from several services in a single response to a service invocation, effectively publishing a new, composite service; enrichment can also be seen as a special case of composition. An ESB may also be able to mediate between different security protocols: for example, allowing (or requiring) the consumer to send a request with a SAML authentication token while the service provider is authenticated through basic HTTP authentication.Many of the functions listed are instances of mediation.The ESB clearly is good at bringing two parties together across various types of divides: communication protocol, location, technology, message format, synchronous/asynchronous, availability, and security protocol. Other functions an ESB may offer include technical and administrative aspects, such as performance improvements through result caching, high availability through clustering, reliability and transaction management, enforcement of authorization rules, throttling of message load, and SLA monitoring.
• #12: ESB An ESB sits between service consumers and the services they invoke (see the ESB figure). It typically has a number of features that facilitate the interaction and help decouple consumers from providers:Endpoint Virtualization When service consumers call a service through the ESB instead of calling the provider directly, location transparency is achieved in the architecture. A service provider can be replaced by another service provider, without the need to change every service consumer to reflect the new address. Only the ESB knows which service provider is invoked exactly; all the consumers leave it to the ESB. This is called virtualization of services.Routing of services Sometimes the routing is more specific: Based on the content of the request message from the consumer, the service is selected to forward the request to; this is called content-based routing.Transformation Providers and consumers don’t always speak the same language: They frequently do not use the same protocols or message formats. The enterprise service bus can transform a request to the format and/or protocol supported by the service and does the inverse to the response before handing it back to the consumer. Messages inside the ESB are based on the canonical data model (CDM); messages are transformed to the CDM upon entering the ESB and may need to transform to application-specific formats when traveling out of the ESB.A special element in transformation can be message enrichment: The result of the transformation is not just the same data in a different message structure but an enriched message with additional information that has been looked up (for example, an appointment request that has been enriched with the recent medical history for the patient).Validation The ESB can validate requests before they are delivered to the service provider as well as the responses coming out of the provider.Auditing The ESB can log requests and responses for auditing purposes and send out alerts when special conditions apply.Messaging Instead of calling a service, an application can send messages and communicate asynchronously with other applications. The ESB can provide guaranteed delivery and persistence of the message. Synchronous/asynchronous adaptation An enterprise service bus can expose services with either a synchronous or an asynchronous interface—regardless of the nature of the actual service provider(s) it needs to invoke; It can adapt from synchronous to asynchronous, and vice versa. This—together with support for queuing and store-and-forward for services that are temporarily unavailable—provides another very important type of decoupling: The provider does not need to be available at the same time as the consumer, and the consumer does not need to wait for the response from the service it invokes. This has the same impact on service invocations as the answering machine and voicemail had on communication via telephone. Composition An ESB may be used to aggregate the results from several services in a single response to a service invocation, effectively publishing a new, composite service; enrichment can also be seen as a special case of composition. An ESB may also be able to mediate between different security protocols: for example, allowing (or requiring) the consumer to send a request with a SAML authentication token while the service provider is authenticated through basic HTTP authentication.Many of the functions listed are instances of mediation.The ESB clearly is good at bringing two parties together across various types of divides: communication protocol, location, technology, message format, synchronous/asynchronous, availability, and security protocol. Other functions an ESB may offer include technical and administrative aspects, such as performance improvements through result caching, high availability through clustering, reliability and transaction management, enforcement of authorization rules, throttling of message load, and SLA monitoring.
• #13: SOA should help us to adapt our business processes and the underlying IT systems much faster, cheaper, and more reliably than we could in the past. Reuse of proven building blocks in new composite services and reworked business processes should allow both for quicker time to market (reuse instead of building from scratch) and higher quality (reuse of services that have been tried and tested). The decoupled design helps to minimize the impact of changes—in terms of effort and risk. There is, of course, a cost benefit in all this as well.Another trigger for SOA from a business perspective is competitive pressure, demands from a key customer or state regulations. An organization may simply need to have the capability to interact through (Web) Services because important business partners or the government stipulate that.
• #15: Magic Quadrant for Application Infrastructure for Systematic Application Integration ProjectsApplication integration is getting applications that were designed independently to work together. Most everyone in IT understands the challenges created by stand-alone, stovepiped applications. Consequently, virtually every software project that deploys a new application involves application integration tasks.The part of the application infrastructure market focused on integration products for application-to-application (A2A), B2B and cloud-based application integration will undergo consolidation, because multiple product features are used across each of the project types. Many users are looking to support their integration projects with an integrated suite provided by one vendor, thus eliminating the burden to act as a system integrator for application infrastructure. To address this, even market-leading vendors have more work to do to complete modernization and consolidation of the technologies to support these types of integration projects, and to secure long-term retention and the long-term retention of their market shares in an economic environment that is driving organizations to implement extensive cost-cutting measures.This Magic Quadrant focuses on support for systematic integration projects that span internal, B2B and cloud applications, data and interfaces, particularly for projects that include long-term consideration and project planning in the process of design and technology selection for interfaces. The IT projects addressed by solutions and vendors evaluated in this Magic Quadrant target integration interfaces that are intended for an extended period of use, carry advanced service-level requirements and typically have an impact on the overall information context of the business organization. These are distinct from opportunistic projects that are undertaken in response to urgent demands and target interfaces of limited life, responsibility and complexity. Opportunistic projects value time to market and cost optimization above the long-term use and flexibility of the interface. Here, we focus only on the systematic project types, in part because opportunistic projects rarely focus on selection of the integration infrastructure, but focus instead on using the approach and technology that yield the least-expensive interface in the shortest time.In this Magic Quadrant, we examine a market where buyers (IT projects) are looking for application infrastructure technology to fulfill the end-to-end requirements of a systematic application integration project. For each competing vendor, we evaluate how well that vendor's portfolio of application infrastructure offerings fulfills the requirements of such projects. The evaluation of a particular vendor is based on the premise that the vendor is the sole provider of the complete, end-to-end set of requirements for this project type.Gartner offers analysis of application infrastructure for two additional project types. One analysis is for systematic, service-oriented-architecture (SOA)-style application projects. This is the type of project where the effort centers on the modeling and design of an SOA-style application topology, and the development of service implementations and user-facing logic (which is often multichannel). The orchestration of new and pre-existing like and unlike services is a key requirement (including some degree of SOA-style integration and governance). If your project, while implementing the strategic SOA backplane and governance for your organization/domain, is also intended to make decisions or provide recommendations about the tooling for supporting the implementation of SOA applications, see "Magic Quadrant for Application Infrastructure for New Systematic SOA Application Projects" for more details.Additionally, Gartner offers analysis of technology vendors for systematic SOA interoperability infrastructure projects. Those projects are usually driven by the organization's SOA center of excellence (COE), and typically consists of the architecture, design, implementation and deployment of two macrocomponents — the SOA backplane and SOA governance — that can be implemented at different times for convenience, though they are designed as an integrated, enterprisewide (or domainwide) SOA. SOA-enabling infrastructures are meant to be shared by virtually any SOA application project in the enterprise (or domain).
• #16: Oracle is a Leader in the recently published Gartner Magic Quadrants for Application Infrastructure (including SOA and SOA Governance ).Most new software projects target a service-oriented software model. Service-oriented applications separate the front-end business logic of the application from its back-end business logic. They are modular, and the modules (services and clients) are loosely coupled, shareable and distributable. They are also encapsulated behind documented programmatic interfaces. Most such applications are composites — that is, they partly use services that are newly designed for this application, and partly use services that already exist as part of other applications. Support of such architecture requires a multifunctional, underlying application infrastructure technology (middleware), often assembled by users from offerings of potentially different vendors. Some IT projects prefer this best-of-breed approach to assembling their enabling application infrastructure environments, although it requires IT organizations to act as system integrators (SIs) in assembling the disparate pieces into a cohesive platform for the project.Many users are looking to support their projects with an integrated application infrastructure suite provided by one vendor, thus eliminating the burden to act as an SI for the application infrastructure. Most vendors recognize this buying pattern by offering technology suites targeting some popular and/or important project styles.The application infrastructure suite of a vendor can be applied to different types of projects. Here, we examine vendors' application infrastructure worthiness for systematic service-oriented architecture (SOA)-style application projects. At the same time, two other Magic Quadrants have been published examining vendors' application infrastructure suites against the requirements of application integration and SOA interoperability and governance projects.Systematic projects include long-term consideration and project planning in the process of design and technology selection for the application. They target applications that are intended for extended periods of use, carry advanced service-level requirements and typically have an impact on the overall information context of the business organization. These are distinct from opportunistic projects that are undertaken in response to urgent demands and target applications of limited lifetime, responsibility and complexity. These projects value time to market and cost optimization above the long-term use and flexibility of the application. This Magic Quadrant focuses only on the systematic project types, in part because the opportunistic projects rarely focus on selection of the application infrastructure, rather focusing on finding the best-fit development environment that encapsulates everything else.In this Magic Quadrant, we examine a market where buyers (IT projects) are looking for application infrastructure technology to fulfill the end-to-end requirements of a systematic, SOA-style application project. For each competing vendor, we evaluate how well that vendor's portfolio of application infrastructure offerings fulfills the requirements of such projects. The evaluation of a particular vendor is based on the premise that the vendor is the sole provider of the complete end-to-end set of requirements for this project type.
• #17: Market OverviewIn recent years, Gartner has identified a trend in enterprise IT projects away from the best-of-breed selection of application infrastructure components and toward selecting a sole (or at least a primary) provider of enabling technology for the planned project type. Thus, we have noted the emergence of a new type of market, which is defined by the requirements of a particular type of IT project, rather than by the taxonomy of vendor offerings (the traditional approach to defining technology markets).Although Gartner continues to analyze markets for specialized products — for example, enterprise application servers, horizontal portals, BPM suites and business intelligence tools — we also provide analysis of the vendors capable of offering most of these products in support for some specific usage scenarios. Buyers in such markets are not looking to invest in a grand, all-encompassing application infrastructure technology stack; instead, they're looking for a vendor that understands and supports the kind of project requirements they face.A large-scale, enterprisewide SOA initiative requires the implementation of a complex application infrastructure, which includes four major functional macrocomponents: SOA Backplane — Incorporates the functionality needed to enable any-to-any, secure, reliable, scalable, manageable and high-performance interoperability across service consumers, service providers, composite applications and processes, SaaS/cloud applications and external domains (including business partners, suppliers and clients) in a technologically heterogeneous environment. SOA Governance — Provides the functionality required to support the governance processes associated with a specific SOA initiative, including a registry/repository, SOA life cycle management tool, and policy management and enforcement tools. SOA Containers — Application infrastructure components that can host various forms of application logic: user interaction/presentation logic, composite front ends, business processes, business rules, transactional back-end services and event-processing services. SOA-Related Capabilities — Functionality needed to support advanced requirements, such as business activity monitoring (BAM), master data management (MDM) and advanced management of trading-partner communities (for example, to support multienterprise B2B integration).Gartner defines a "shared SOA interoperability infrastructure project" as "the set of activities needed to implement the combination of SOA backplane and SOA governance macrocomponents of the whole SOA application infrastructure." Therefore, in this research, we use the phrases "shared SOA interoperability infrastructure projects" and "SOA backplane and SOA governance projects" interchangeably.Deployment of these macrocomponents is increasingly perceived by users as the foundation infrastructure for their SOA initiatives. Therefore, it is planned for, designed, implemented and deployed through a specific and dedicated project (that is, not as part of an individual, SOA-style application development project), typically under the responsibility of the organization's SOA COE.This Magic Quadrant focuses on vendors that offer a set of capabilities for SOA backplane and governance and can play the role of a single supplier or primary provider of these capabilities to end-user organizations. In reality, projects will often supplement the technology of the single supplier with additional products from other vendors. However, the stronger the vendor is rated in this Magic Quadrant, the less it is required for the project to take on the burdens of incorporating third-party vendors' technologies.If a shared SOA interoperability infrastructure project is also intended to take decisions or provide recommendations about the tooling for supporting the implementation of SOA applications. Gartner recommends that users examine the "Magic Quadrant for Application Infrastructure for Systematic SOA-Style Application Projects," along with this research to refine their decision processes.If the project must provide capabilities to substantially interact with non-SOA external resources (such as pre-SOA legacy or packaged applications or B2B partners processes not exposing SOA interfaces), Gartner recommends that users review the "Magic Quadrant for Application Infrastructure for Systematic Application Integration Projects," along with this research to refine their decision processes.Market Definition/DescriptionWhen organizations develop their SOA application infrastructure, the choice of SOA containers and other SOA capabilities is in some cases made upfront in the life cycle of an SOA initiative, especially when it comes to selecting a comprehensive set of components to address multiple and related systematically oriented SOA applications. However, this selection is often done in the context of specific projects, driven by a variety of technical and local convenience considerations.Increasingly, the choice of technologies and products aimed at supporting SOA backplane and governance is done "once and for all," because the resulting SOA interoperability infrastructure is, almost by definition, shared among all the SOA application projects in the enterprise (or in a specific SOA domain). Therefore, the definition of the SOA backplane and governance architecture, product selection and technology integration, implementation and deployment is a key enabling project in most large-scale SOA initiatives.Such a project may be kicked off after the organization has successfully implemented multiple stand-alone SOA application projects, as long as it realizes that a common infrastructure, shared across established and future SOA applications, would be most cost-effective and more manageable. However, SOA interoperability and governance technology deployment projects increasingly precede every SOA-style application project, because it is intended to provide an interoperability infrastructure that all the SOA application projects framed in that particular initiative will share.In the early days of SOA adoption (circa the mid-1990s), the SOA backplane and governance infrastructure was implemented by leading-edge organizations by aggregating products from multiple vendors, often complemented by significant custom developments — for example, many early SOA adopters custom developed their own SOA registry/repository. The advent of Web services in the early 2000s created a standard foundation for SOA, which fostered industry excitement. Therefore, many vendors — both established and startups — developed specific products for SOA backplane and governance, and a growing number can now provide the full set of capabilities, either as integrated suites or collections of related products. As more and more mainstream organizations, which were traditionally reluctant to deal with too many vendors, move to SOA, a growing number of users are looking at single sourcing their SOA backplane and governance technology from one single strategic vendor.Properly deploying an SOA backplane and governance infrastructure requires a holistic, top-down architectural and systematic approach. However, most organizations don't usually implement the full set of SOA backplane and governance functionality (nor do they put the relevant products together) at one time. Often, in the early stages of SOA adoption, technical and business requirements are not fully understood, and, if they are, there might not be enough investment capabilities available to implement the full set of features. The benefits and necessity of some components (for example, orchestration, service registry, and policy management and enforcement) might not be that evident, when the number of deployed services and applications consuming them is relatively small. Therefore, most organizations implement their SOA backplane and governance infrastructures by incrementally adding components, as necessary, and as relevant investments can be justified in the context of specific projects.Typically, shared SOA interoperability infrastructure projects are conducted under the responsibility of the enterprise or the domain-level SOA COE, which is in charge of:Defining the architecture of the SOA backplane and governance infrastructureSelecting the appropriate technical componentsIntegrating and putting them into productionAdministering, managing and monitoring the resulting platformSupporting application teams that share the SOA backplane and governance infrastructureTo address the SOA backplane and governance opportunity, several vendors offer integrated suites of products (typically referred to as "SOA suites" or "SOA platforms") packaging ESB products, orchestration tools, Web services management tools, registry/repository products, policy management and enforcement, activity monitoring and other components.Although many organizations will never need to deploy the full set of SOA backplane and governance features, the current good crystallization of user's requirements is driving vendors to specifically package their SOA-enabling technologies in a way that supports incremental implementation. Therefore, deployments can be more modular and standardized, less risky and less expensive.This Magic Quadrant considers vendors providing all the components required to implement an integrated SOA backplane and governance infrastructure. Availability from the vendor of other SOA application infrastructure components — such as portals, application servers, business rules or other container technologies aimed at running service consumer or service provider applications — is welcomed, but it is not essential. Organizations typically aim at a vendor-neutral shared SOA interoperability infrastructure that is able to integrate and govern service consumer and provider applications running on containers from multiple vendors, of heterogeneous technology nature, and located inside or outside the four walls of the organization. Therefore, shared SOA interoperability infrastructure projects are typically not interested in selecting container technologies. Such a selection is usually carried out separately or in the context of specific SOA-style application projects.Due to their strategic nature, shared SOA interoperability infrastructure projects greatly value the technical merits of the enabling application infrastructure technology and a sound medium-term vision in terms of technology evolution.Return to TopInclusion and Exclusion CriteriaVendors included in this Magic Quadrant have sufficient technology and expertise in their total application infrastructure product portfolios to support — as the sole application infrastructure provider — the implementation of a mainstream, shared SOA interoperability infrastructure, consisting of an SOA backplane and SOA governance macrocomponents. The key characteristic required to implement these macrocomponents are the following:Return to TopSOA Backplane CapabilitiesThese capabilities include (see Note 1 for a more-detailed description):ESB core functionalities, including technology that:Implements communication middleware that reliably moves messages between endpoints (service provider and service consumer applications)Supports the fundamental Web and Web services standardsImplements the binding necessary to create associations between consumer and provider endpointsHas an architecture that enables it to apply optional intermediary functions (e.g., transformation and splitting) to messages in flightSupports typed messages — that is, messages for which contents are explicitly defined and documentedProvides adapters for applications, databases, A2A and B2B protocols, cloud application programming interfaces (APIs), etc.Service orchestration — a development tool and associated process execution engine for designing and implementing heterogeneous (that is, involving application components and/or services of different technical nature possibly running on different systems) micro-flows, service composition and multistep process integration. Support for human-centric workflow is not required. Service orchestration can be offered as a separate product (or products) or as part of an ESB suite.Return to TopSOA Governance CapabilitiesThese include (see Note 2 for a more-detailed description):SOA policy management and enforcementRegistry/repository and metadata managementStatistical and key performance indicator (KPI) data collectionMonitoring and managementLife cycle management for applications and servicesInteroperability with other SOA governance technologiesThese technologies must be able to deal with on-premises services, as well as cloud/SaaS services. This requirement poses specific challenges in terms of the synchronization of life cycle management between on-premises and in-the-cloud services and applications. SOA governance capabilities can be provided as a single integrated suite or as a set of related products.Vendors must provide all the governance capabilities listed above to be included in this Magic Quadrant; however, at this stage of the industry, they may be still in a rudimentary form or may be provided through various forms of partnerships. Therefore, they may not be fully integrated into the vendors' offering.The strategic nature of the SOA backplane and governance projects implies anticipation of major future requirements and a capacity for long-term management and extensibility for infrastructure, as well as dependable quality of service (QoS), functionality and extensibility of the vendor technology.Vendors' entire offering portfolios are considered, without regard to product packaging. All the SOA backplane and governance capabilities must be delivered and supported by the vendor being assessed. Some of the technology in the total evaluated portfolio might be an OEM product from a third party. This is acceptable, as long as the user's primary support experience is with only the vendor being assessed, which requires that the OEM product be seamlessly integrated with the main vendor's offering. Delegating Level 3 support to the OEM partner is also acceptable.There must be evidence of production success (present or imminent) by this vendor as a sole provider of technology for this project type.Vendors with combined license and maintenance revenue from application infrastructure deployments of less than $10 million may not be included.Vendors for which Gartner has experienced significant client interest via inquiries or other interactions have been included as exceptions, even if they don't meet all the criteria. However, all the vendors rated in this Magic Quadrant provide and support the SOA backplane and SOA governance capabilities listed above. All the vendors considered offer the required technology as products. Some vendors also offer some elements of their product set as a service or as a prepackaged virtual machine in a public cloud. However, Gartner is not aware of any vendor that provides the full set of capabilities exclusively via a public-cloud model.
• #18: Forrester evaluated 15 leading comprehensive integration solution (CIS) vendors against 137 criteriathat reflect the requirements of application development and delivery professionals. We found that Oracle, IBM, TIBCO Software, and Software AG lead the pack with the best overall combination ofarchitecture, integration server, application development, business process management (BPM), andbusiness-to-business (B2B) support features. Progress Software, Vitria, SAP, Axway, Microsoft, and SEEBURGER are also Leaders based on the overall strength of their integration solutions. Additionally, Sterling Commerce (IBM), iWay Software, Active Endpoints, inubit, and Microgen all scored as StrongPerformers based on their unique strengths in the integration arena.CIS tools are the most Comprehensive Integration Products on the Market(Comprehensive Integration Solutions)CISes offer the broadest array of capabilities for solving complex integration challenges.1 Theyprovide enterprise application integration (EAI), business process management (BPM), B2Bintegration for both electronic data interchange (EDI) and Extensible Markup Language (XML)transactions, model-driven application development (MDD), embedded service-orientedarchitecture (SOA) capability, and managed file transfer (MFT) features in a preintegratedtechnology stack from a single vendor. These solutions should be at the top of the shortlist of toolsenterprises should consider to support the most complicated integration challenges they face.2Forrester has defined the CIS reference architecture model to outline the broad range of capabilitiesincluded within this type of solution
• #19: VendorActive EndpointsAxwayIBMinubitiWay SoftwareMicrogenMicrosoftOracleProgress SoftwareSAPSEEBURGERSoftware AGSterling CommerceTIBCO SoftwareVitriaProduct(s) evaluatedActiveVOS v7.1.2Axway Synchrony Platform v4.3IBM WebSphere Dynamic ProcessEdition (WDPE) v7inubit BPM-Suite v5.3iWay Service Manager rel 5.5 SP1iWay Trading Partner ManageriWay CEP EnableMicrogen Aptitude v3.0BizTalk Server 2010 & ESB ToolkitOracle SOA Suite 11g R1Oracle BPM Suite 11g R1Progress Integration SuiteSAP NetWeaver v7.1Business Integration Server v6.3.4Business Integration Server B2BGateway v6.3.4webMethods v8ARIS product suite v7.1Sterling Integrator (SI) v5.0ActiveMatrixBusinessWorks v5.8ActiveMatrix BPM v3.0Vitria M3O Suite v3Vendor selection criteriaThe product meets Forrester’s definition of a CIS and as such provides capabilities for supportingenterprise application integration (EAI), B2B integration (B2Bi), business process management (BPM),model-driven application development (MDD), and service-oriented architecture (SOA).The vendor has been determined to be one of the leading providers of CIS technology and has significantmarket share in this space or has gained significant mindshare via the capabilities of its products.The product version has been released and was available in the marketplace (with reference customers)prior to July 1, 2010.
• #20: http://www.ft.com/cms/s/0/97701346-c273-11df-956e-00144feab49a.html#axzz1Pr7IpvEEJacques Bughin, Michael Chui, and James Manyika - identified 10 trends. For the first six, they argue that it is important to assign the responsibility for identifying the specific implications of each issue to functional groups and business units. “The impact of these six trends — distributed cocreation, networks as organisations, deeper collaboration, the Internet of Things, experimentation with big data, and wiring for a sustainable world — often will vary considerably in different parts of the organisation and should be managed accordingly,” they say.Three of the trends — anything-as-a-service, multisided business models, and innovation from the bottom of the pyramid — augur far-reaching changes in the business environment that the authors believe could require radical shifts in strategy.“CEOs and their immediate senior teams need to grapple with these issues; otherwise it will be too difficult to generate the interdisciplinary, enterprise-wide insights needed to exploit these trends fully. Once opportunities start emerging, senior executives also need to turn their organisations into laboratories capable of quickly testing and learning on a small scale and then expand successes quickly.”The final trend identified in the report, using technology to improve communities and generate societal benefits by linking citizens, requires action by not just senior business executives but also leaders in government, nongovernmental organisations, and citizens.7. Imagining anything as a service Technology now enables companies to monitor, measure, customise, and bill for asset use at a much more fine-grained level than ever before. Asset owners can therefore create services around what have traditionally been sold as products. Business-to-business (B2B) customers like these service offerings because they allow companies to purchase units of a service and to account for them as a variable cost rather than undertake large capital investments. Consumers also like this “paying only for what you use” model, which helps them avoid large expenditures, as well as the hassles of buying and maintaining a product.In the IT industry, the growth of “cloud computing” (accessing computer resources provided through networks rather than running software or storing data on a local computer) exemplifies this shift. Consumer acceptance of Web-based cloud services for everything from e-mail to video is of course becoming universal, and companies are following suit. Software as a service (SaaS), which enables organisations to access services such as customer relationship management, is growing at a 17 per cent annual rate. The biotechnology company Genentech, for example, uses Google Apps for e-mail and to create documents and spreadsheets, bypassing capital investments in servers and software licenses. This development has created a wave of computing capabilities delivered as a service, including infrastructure, platform, applications, and content. And vendors are competing, with innovation and new business models, to match the needs of different customers. Beyond the IT industry, many urban consumers are drawn to the idea of buying transportation services by the hour rather than purchasing autos. City CarShare and SipCar were first movers in this market, but established car rental companies, spurred by annual growth rates of 25 per cent, are also entering it. Similarly, jet engine manufacturers have made physical assets a platform for delivering units of thrust billed as a service.A number of companies are employing technology to market scalable services from business capabilities they first developed for their own purposes. That’s a trend we previously described as “unbundled production.” More deals are unfolding as companies move to disaggregate and make money from corporate value chains. British Airways and GE, for instance, have spun off their successful business-process-outsourcing businesses, based in India, as separate corporations.Business leaders should be alert to opportunities for transforming product offerings into services, because their competitors will undoubtedly be exploring these avenues. In this disruptive view of assets, physical and intellectual capital combine to create platforms for a new array of service offerings. But innovating in services, where the end user is an integral part of the system, requires a mind-set fundamentally different from the one involved in designing products.
• #21: 2. SOA is notWeb Services. But, Web Services is one of the means to achieve a SOA3. Claus T Jensen - IBM Chief Architect for SOA-BPM-EA technical strategyClaus T Jensen: They should understand that SOA is not about technology, and that adopting SOA cannot be done in a project it has to be done organizationally (or at least at a program level). Steve Mills, Senior VP and Group Executive IBM Software Group, stated back in 2007 that “ Service orientation does not begin with technology; it begins with the mind-set of thinking about your business and the world around you in terms of functional components.”http://www.infoq.com/articles/soa-2011-panel
• #22: Many of the standards around the Web, Web Services, SOA, and interoperability are created and maintained by standards bodies such as the W3C, OASIS, and JCP (java community process), in close collaboration with many of the major industry players.XML (eXtensibleMarkup Language, inspired by HTML and its predecessor SGML) was the first (and foremost) standard in this area, sponsored by Microsoft and published by the W3C in 1998. XML is today the lingua franca as well as the main lubricant of SOA, Web Services, and other interoperability initiatives, as well as the foundation for many more specialized standards. The XML standard describes a set of rules for creating documents with structured data. XML itself is very generic—something like ASCII or comma-separated files with more structure. Its real value starts to shine in conjunction with standards and tools that describe and perform validation of the structure and content of the documents (XSD), retrieve pieces of information from the documents using structured queries (XPath), and transform documents into different structures (XSL-T).The first definition of SOAP (the Simple Object Access Protocol) saw the light of day as early as 1998. SOAP describes a simple envelope-style mechanism for combining payload and metadata in structured packages. In 2000, the Web Service Definition Language (WSDL) introduced the now-omnipresent standard for describing the contract for a Web Service—where the definition of a Web Service by now has been stretched to encompass almost any service and operation that deals with structured information. The Universal Description, Discovery, and Integration (UDDI) standard, also dating from 2000. UDDI is intended to underpin directories of Web Services that tools can browse through in order to discover useful services. UDDI has helped to promote the concept of service registries with listings of useful services that potential consumers such as developers can browse through. UDDI, SOAP, and WSDL can be seen as the first generation of the XML-based standards concerning Web Services. In 2004, the WS-I Basic Profile was published to complement this threesome—a set of guidelines on how exactly to apply these core Web Service standards, to ensure full operability (the original standards allowed for multiple interpretations in certain areas that led to differences between vendors’ implementations).The second wave of standards in the area of Web Services is concerned with more advanced concepts around message exchanges, such as the policies that apply to the message, the security of the messages, sending them in a reliable way to guarantee the reception (in the proper sequence and without duplication) of messages, correlation of multiple messages sent over a longer period, and the specification of return addresses and other concerns. Together these standards are referred to as WS-*: Their names all start with WS, and collectively they constitute a framework for service-oriented message exchanges that make it useful to have a common denominator. Important members of the WS-* family are WS-Addressing, WS-Reliable Messages, WS-Security, and WS-Policy.The automation of business processes has always been an important objective for the IT industry. The complexity of many processes and the involvement of multiple IT systems and applications, as well as the required participation of humans, have stood in the way of process automation for a long time.With the rise of Web Services to overcome the interoperability challenges, fresh opportunities started to open up for business process automation. New ways to describe business processes in a structured way started to appear in 2004. The most prominent examples are Business Process Modeling Notation (BPMN) and Business Process Execution Language (BPEL). Process definitions include the process routing and decision logic, calls to Web Services, and tasks to be performed by people. As the standards evolved, engines to execute such process definitions were developed by various vendors. BPEL4People and WS-Human Task (2007) have added human task-oriented extensions to BPEL that, by itself, is a rather technical Web Service–oriented language. Standards in SOAOne of the important principles of SOA is standardization. It is very hard to communicate with other applications if the protocols and message formats that these other applications use are all different. The same is true for protocols. IT systems in an organization typically use various protocols and programming languages. This makes combining them into new applications difficult, if not impossible. To solve this, services should use standard protocols and message formats. Web ServicesOne of the most important sets of standards is the one concerning Web Services. The World Wide Web Consortium (W3C) describes Web Services as follows (www.w3.org/2002/ws/Activity):“Web Services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. Web Services are characterized by their great interoperability and extensibility, as well as their machine-processable descriptions thanks to the use of XML. They can be combined in a loosely coupled way in order to achieve complex operations. Programs providing simple services can interact with each other in order to deliver sophisticated added-value services.”There are two ways of creating a Web Service: using a formal protocol defining the operations and message format in advance, and using a loose protocol where a hint of the next available set of operations can be derived from the last service response.SOAP Web Services are an example of working according to formal specifications defined in advance, whereas RESTful services are an example of the latter approach.SOAP and WSDLSOAP Web Services dictate a formal method of communication between applications. Through SOAP and WSDL, an organization can specify the available operations in services and the data that can be exchanged with the services. The specification of these services in such a formal way has several advantages:The interaction is strongly typed: the consumer knows what type of data to expect.Because SOAP is more formal, there is more tool support to create SOAP-based Web Services.Multiple protocols are supported (SOAP over HTTP and SOAP over JMS, for example).Additional features, such as WS-Addressing, WS-Security, and Basic Profile, are used.However, this formal, contract-based, and XML-riddled approach is sometimes perceived as very heavy-handed. The overhead in terms of the infrastructure required for handling SOAP Web Service interaction and the sheer size of the SOAP messages compared to the actual information content of those messages can cause people to shy away from SOAP.RESTful ServicesA more lightweight Web Service alternative is available in the form of RESTful services. REST, by the way, is an acronym for Representational State Transfer. Originally introduced by Roy Fielding as a rather formal resource-oriented method of programmatic interaction over the HTTP protocol using the four basic HTTP operations—PUT, POST, GET and DELETE—for CRUD operations, RESTful services have evolved into a plethora of lightweight HTTP-based APIs. RESTful services accept simple HTTP requests and send equally simple responses.There are no generally accepted standards for RESTful services (for example, the use of contracts of some form of description of the services). Initially, it was almost blasphemy to suggest the need or even the usefulness for such descriptions, whereas in later stages large groups experimented with WADL (Web Application Definition Language), a simpler counterpart to WSDL. REST-style services can return responses in XML, although other formats such as CSV and JSON are popular too.There is a lot of support for REST on the client side (consuming RESTful services in many programming languages) and some on the server for publishing REST-style services. Some enterprise service bus implementations have some support for REST—although mainly in situations where the payload is XML described by some predefined contract, however lightweight.REST seems primarily useful for data integration between web clients and servers, not so much for enterprise SOA.RSS FeedsAnother lightweight approach to programmatic (one-way) exchange of information is through RSS feeds. A simple HTTP GET request (REST-like) suffices to retrieve the information; the format is a predefined XML structure. RSS only supports a very simple interaction pattern, but in some situations may very suitable.PoliciesReiterating, a service consists of an interface that can be described in a WSDL, an implementation that can be in virtually any language and contract. The contract describes the quality of aspects of the service. Examples include the number of concurrent calls it can handle, the maximum number of records it returns, its maximum response time, the authorization required for this service, the availability of the service, and the way the service will evolve. Some aspects of the contract can be defined using the WS-Policy standard. For other aspects of what is sometimes laid down in a service-level agreement (SLA), a standard format is currently lacking.UDDI Directory, Service Registry, and Service RepositoryBecause we want to reuse our assets and build new applications using existing components by exposing them as Web Services, we need some type of registry to store and publish information about the services in our organization—which services are available and where can they be found. To make it possible for different tools to look up services, a standard has been defined to discover (web) services: UDDI (Universal Description, Discovery, and Integration). UDDI defines a standard method for publishing and discovering network-based software components in SOA. The comparison is frequently made with the Yellow Pages—a directory that you browse through when you are looking for a specific service. It contains an API for publishing and searching for services, and to subscribe to changes to the service metadata.UDDI was one of the earliest standards in the Web Service arena, along with WSDL and SOAP.Many UDDI implementations or service registries today seem primarily used for run-time lookup of the physical location of services, a form of service (endpoint) virtualization.The originally intended role of the UDDI-based registries has been taken over by a more elaborate service repository—or asset manager—that serves as a service inventory—a listing of the services available in the organization along with extensive metadata that helps search operations and also provides real insight into the purpose, status, and fit-for-use of the services.Note that the service repository contains many more SOA artifacts than just services (WSDL and XSD); virtually any artifact that can provide insight and facilitate reuse and collaboration, from service-level agreements to canonical data model descriptions, can be recorded. An important role of the service repository is to provide insight into the dependencies between the artifacts, primarily to assess the impact of changes.Service registries tap into or collaborate with the service repository, using maybe 10 percent of their information for service discovery.Service Component Architecture (SCA)A relatively new standard is Service Component Architecture (SCA). It is a set of specifications that describes a model for building applications and systems using a Service-Oriented Architecture. It is a widely supported standard, backed by most large vendors of SOA software and tooling.With on the one hand the obvious success of BPEL for creating service composites and on the other the ongoing challenges, many vendors working on Service-Oriented Architecture have joined forces to come up with a new standard for creating service-oriented applications.The objective of this standard was to allow the development of a service-oriented application that could implement every piece of its functionality in the language and run-time engine best suited for it (for the piece) and still have all the pieces integrated in a simple, standardized way, based on the established standards for services.It is assumed—though not required—that the application will invoke several external services. It is also expected that the application will expose a service interface itself. Reuse is an important theme in SOA and is also a key objective for this new standard: Applications developed according to the standard are reusable components that can be included in other applications.This standard called Service Component Architecture (SCA) was first published in 2007. It is expected to become the dominant guiding principle, according to which vendors build their SOA containers, and thus the framework for development of SOA applications.The promise of SCA is that developers can use various languages running on different run-time engines to implement various parts of the application—for example, BPEL, Java, another SCA composite application, a rule engine, a workflow engine, and technology adapters to work with databases, queues, and file systems. Each such part of the application is called a service component. Each service component publishes a contract that describes its interface through a WSDL document. The developers specify the functional link between these different parts of the application, and it is up to the SCA container or run-time engine to facilitate communication between the components in the most efficient way, usually through a native, binary communication protocol.The coupling between service components is very loose; they can work together without any knowledge about each other’s implementation. This way of creating composite applications is very flexible: It allows replacement of one service component with another that, as long as it fulfills the same contract, could be implemented in an entirely different language running on another service engine.SCA is not just for easier and more productive development of SOA applications. It also specifies how the behavior of the application can be made configurable to allow administrators to apply changes in the behavior without redeployment of the application. Changes in the location of services called from the application can be changed at run time without impact on the availability of the application. Quality of Service aspects, including security policies and reliability requirements, can be (re)configured during or even after deployment.SCA helps to simplify the assembly and deployment of composite applications. An SCA composite application can be assembled from a collection of SCA composites and then turned into deployable units.Industry Specific StandardsMany standards have been developed for structuring messages and services in specific industries and business domains. An example is HL7 in the healthcare domain. HL7 is a framework (and related standards) for the exchange, integration, sharing, and retrieval of electronic health information. Another example is XBRL—a standard for financial reporting.
• #23: The two key roles in SOA:Service consumer The application, business process, or (other) service implementation that uses the serviceService provider The component or application that provides or implements the service(Figure: Service roles and their relationships)The third role in this figure (service registry) will be discussed later on: It is the intermediary that brings consumers and providers together.
• #24: http://ca.sports.yahoo.com/nascar/blog/from_the_marbles/post/Video-Two-cycles-dance-in-the-funniest-wreck-of%3Furn=nascar-wp2122Loosely coupled ?Reusable ?Agile ?
• #25: The composite applications running on the SOA Suite can make use of the following service languages and engines for executing its components:Mediator For filtering, transforming, adapting, and routing messages.BPEL Process Manager Orchestrates (potentially) long-running service composites with many interactions with external services, both outgoing and incoming.Decision Service or Business Rules engine Executes decision logic that can be (re)defined at run time.Human Workflow Service For engaging humans in making decisions or providing information.Spring-based Java Beans (as of 11g R1 PS 2) Custom business logic implemented in Java acting on the messages.BPEL Process Manager Human Workflow Adapters Business Rules Business Activity Monitoring (Oracle BAM) Complex Event Processing (CEP) Oracle Service Bus (OSB) B2B Oracle Web Services Manager (OWSM)
• #26: Oracle SOA Suite is a component of Oracle’s Fusion Middleware stack of applications.A typical Oracle Fusion Middleware environment contains the following components:One Oracle WebLogic Server domain, which contains one Administration Server and one or more Managed Servers.If system components are installed, they are configured in an Oracle Instance.A metadata repository, if the installed components require one. Oracle SOA Suite requires a metadata repository.A Middleware home, which contains product binary files.Oracle Fusion Middleware Java components such as Oracle SOA Suite, as well as customer-developed applications, are deployed to Managed Servers in the domain. Managed servers are Java Virtual Machine (JVM) processes.
• #27: The composite applications running on the SOA Suite can make use of the following service languages and engines for executing its components:Mediator For filtering, transforming, adapting, and routing messages.BPEL Process Manager Orchestrates (potentially) long-running service composites with many interactions with external services, both outgoing and incoming.Decision Service or Business Rules engine Executes decision logic that can be (re)defined at run time.Human Workflow Service For engaging humans in making decisions or providing information.Spring-based Java Beans (as of 11g R1 PS 2) Custom business logic implemented in Java acting on the messages.BPEL Process Manager Human Workflow Adapters Business Rules Business Activity Monitoring (Oracle BAM) Complex Event Processing (CEP) Oracle Service Bus (OSB) B2B Oracle Web Services Manager (OWSM)
• #28: A SOA composite application is the basic unit of deployment to the SOA runtime. Service components (BPEL process, business rule, human task, and mediator routing rule) are the building blocks of a SOA composite. Components are targeted to Service Engines (BPEL PM, Mediator, Workflow, Rules) during deployment while Services and References are enabled using the Binding Components (JCA Adapters, B2B). The composite applications running on the SOA Suite can make use of the following service languages and engines for executing its components:Mediator For filtering, transforming, adapting, and routing messages.BPEL Process Manager Orchestrates (potentially) long-running service composites with many interactions with external services, both outgoing and incoming.Decision Service or Business Rules engine Executes decision logic that can be (re)defined at run time.Human Workflow Service For engaging humans in making decisions or providing information.Spring-based Java Beans (as of 11g R1 PS 2) Custom business logic implemented in Java acting on the messages.BPEL Process Manager Human Workflow Adapters Business Rules Business Activity Monitoring (Oracle BAM) Complex Event Processing (CEP) Oracle Service Bus (OSB) B2B Oracle Web Services Manager (OWSM)
• #29: Analogous to a load balancer routing HTTP traffic, the Oracle Mediator routes data from service providers to external partners. In addition, it can subscribe to and publish business events. Using Oracle Mediator, you create routing services and rules for them. A routing service is the key component for moving a message from its entry point to its exit point. The rules determine how a message instance processed by the routing service gets to its next destination. Using the rules, Oracle Mediator can perform the following actions: Route: Determines the service component (BPEL process, business rule, human task, and mediator) to which to send the messages.Validate: Provides support for validating the incoming message payload by using a schematron or an XSD file. Filter: If specified in the rules, applies a filter expression that specifies the contents (payload) of a message be analyzed before any service is invoked.Transformation: If specified in the rules, transforms document data from one XML schema to another, thus enabling data interchange among applications using different schemas.
• #30: BPEL is the standard for assembling a set of discrete services into an end-to-end process flow, radically reducing the cost and complexity of process integration initiatives. Oracle BPEL Process Manager offers a comprehensive and easy-to-use infrastructure for creating, deploying and managing BPEL business processes. 
• #35: PreRequisites1 Database Oracle Database is the recommended database for SOA Suite deployments. Note that Oracle Express Edition (XE) 10.2.0.1 does not meet the minimum version requirement for supported use, but will generally work in a personal development environment.If you want to use Oracle XE as your database, you have to set the RCU_JDBC_TRIM_BLOCKS environment variable to TRUE *prior* to running RCU. As a reminder as to support level, when running RCU against XE you will receive a warning stating that the database version is not supported by Oracle.Download2 Oracle WebLogic Server + Coherence - Package Installer 10.3.5 Size: 706 MB, Check Sum: 413041778 Note that this WLS package is for a 32-bit JVM. If you want to run with the 64-bit JVM choose the "Generic" option in the platform selection drop-down menu.Download3 Repository Creation Utility 11.1.1.5.0 Size: 309 MB, Check Sum: 2130853384 RCU is used to create and populate the database schemas required by the SOA Suite.If you want to use Oracle XE as your database, you need to set the RCU_JDBC_TRIM_BLOCKS environment variable to TRUE *prior* to running RCU.DownloadContinue at www.accentway.com
• #36: Oracle Service Bus transforms complex and brittle architectures into agile integration networks by connecting, mediating, and managing interactions between services and applications. Oracle Service Bus delivers low-cost, standards-based integration for mission critical SOA environments where extreme performance and scalability are requirements.
• #38: The diagram shows an OSB Messaging node connected to elements above and below it. Above are custom applications, routing and transformation, and service orchestration. Below are a distributed query engine with data sources, adapters with enterprise applications, web services, Java (JMS) applications, and a MQ gateway.
• #39: The diagram shows an OSB Messaging node connected to elements above and below it. Above are custom applications, routing and transformation, and service orchestration. Below are a distributed query engine with data sources, adapters with enterprise applications, web services, Java (JMS) applications, and a MQ gateway.
• #40: Functions Performed by the Oracle Service BusBefore the OSB can do anything, it first needs to properly receive a request message from a service consumer—either synchronously via a call or asynchronously through, for example, fire-and-forget or message polling. It is capable of receiving messages from a variety of transport protocols such as HTTP(S), e-mail, JMS, RMI (for EJB), FTP, and File System. OSB can, of course, return response messages via the same set of protocols, and it can itself invoke services along those protocols. The contents of the messages are typically presented inside the OSB message flow as if they are XML messages, with header body and optionally MIME attachments. Non-SOAP messages are mapped to this paradigm—including e-mail bodies, messages in binary format, JMS messages, and REST-style requests with JSON or plain text. The processing in the message flow has easy access to header variables that provide metadata about the message.Once messages are safely delivered to the bus, an ESB is expected to be able to perform several standard operations. Most definitions of the term enterprise service bus include the so-called “VET(R)O pattern” that an ESB should implement. This acronym stands for Validate, Enrich, Transform, (Route), and Operate. The OSB has support for this integration pattern besides various other patterns, such as fan-in and fan-out, fire-and-forget, and so on. As a side note, the SOA Suite Mediator component, while in a sense comparable with OSB, it is significantly more limited when it comes to enrichment and has less functionality than OSB in the other three departments. This is partially due to the fact that OSB can store data in intermediate variables, whereas Mediator is mostly stateless when it comes to data—it does not have the concept of temporary variables.
• #41: OSB exposes proxy services that connect through a message flow to business servicesThe message flow may include routing and transformation logic.A proxy service can route messages to multiple business services; we can choose to configure a proxy service with an interface that is independent of the business services with which the proxy service communicates. In such cases we can configure a proxy service message flow definition to route a message to the appropriate business service and map the message data into the format required by the business service interface.
• #43: Dev, QA installed in a Dev Setup.Production installed in Production Setup.
• #45: http://cmwd018:7001/sbconsole/
• #46: http://cmwd018:7001/console/
• #47: http://cmwd018:7001/em/
• #50: In OSB, a Proxy Service published to UDDI and, once approved, the service becomes available for discovery (browse and import).