SOA?

[Former Member]

What is SOA in XI / PI?

Normally what can be the requiremnts in XI w.r.t SAO?

Thanks

Kiran

[Former Member · Accepted solution]

ESOA BASICS

SAP Architecture u2013Enterprise SOA Basics

/people/kareemullahshah.quadri/blog/2007/02/19/sap-architecture-150enterprise-soa-basics

Quick Guides for setting up an eSOA prototyping environment with CE, ESR, and NWDS

/people/kevin.liu/blog/2008/04/28/quick-guides-for-setting-up-an-esoa-prototyping-environment-with-ce-esr-and-nwds

ESA = SOA + ES ?

/people/kevin.liu/blog/2005/10/17/esa-soa-es

REGARDS

chandra

[Former Member]

HI

SOA is a design for linking computational resources (principally, applications and data) on demand to achieve the desired results for service consumers (which can be end users or other services).

SOA is more generic. Any system that provides web services (which are self-contained and self-describing) can be termed as SOA enabled. The provider registers the service over UDDI in the form of WSDL.

SOA emphasizes the implementation of components as modular services that can be discovered and used by clients.

Promotes re-use of existing functionality

Supports a distributed model of computing

Enable scalability and reuse of components of across a wider development community

Provides a uniform way of handling the functionality especially true in a large business environment.

SOA is already implemented mostly as Web services. Web services standards have catalyzed the adoption of standards-based SOA. Early Web services standards - SOAP and HTTP - provide ubiquitous protocols suitable for SOA.

SOA is more technical, ESOA (former ESA - Enterprise Service Architecture) created by SAP is more business focus.

Enterprise Service oriented Architecture is the adoption of SOA at an enterprise level. It breaks the traditional Client server application oriented architecture. What Enterprise oriented architecture has done is to break down each of the core business functionality into services.

SOA is an idea of creating composite applications based on reusable building blocks using open standards like Web Services, WSDL, SOAP, UDDI.

To summarize ESA = SOA + Enterprise content or in other words ESA is an instantiation of SOA at ERP level.

SAP name for service oriented architecture is Enterprise SOA which enabled by open Net weaver Platform. Enterprise services allow applications to expose as web services (based on WSDL). In order to efficiently use web services across various applications and customers, it is essential that companies need to store these services centrally in one repository.

cheers

reward points if found useful

[former_member537867]

Hi Kiran,

pls see the below link

https://www.sdn.sap.com/irj/sdn/advancedsearch?query=toolstoimplementSOAprojects&cat=sdn_all

The goal of a service-oriented business architecture (SOA) is the loose coupling of business services. In order to enable such a service-oriented business architecture users require a SOA runtime platform. As of today, enterprise users face a number of challenges in operating these SOA runtime platforms, e.g.

SOA Platforms consist of a set of internal technical services (e.g. registry, messaging, and security). Today, those technical services are strongly coupled within most of these platforms. A loose coupling of those services would allow a best of breed approach and would give the user the option to leverage existing software assets

The interoperability between different SOA runtime platforms is often limited to the basic technical services (e.g. messaging). High level interoperability (e.g. business process orchestration) across SOA domains operated on different platforms is often not possible.

The enablement of embedded systems collaborating in a SOA runtime environment.

The SOA platforms available today fall short to these expectations and limit the value of SOA on the user side. This project intends to address these three challenges:

Lack of common interfaces between the technical components of a SOA runtime platform

Lack of interoperability between SOA environments

Lack of SOA runtime deployment on embedded systems, e.g., on medical devices in the healthcare industry

Lack of common interfaces: The different SOA runtime platforms consist of very similar technical components (e.g. service registry, messaging). The lack of common APIs between these technical components means that these components cannot be exchanged. This project intends to develop a common framework/API which treats these components as exchangeable plug-ins.

Lack of interoperability: Although there are ongoing standardization efforts, the interoperability of heterogeneous SOA environments is very limited today. As an example, a BPEL code can usually not be executed across different SOA environments. Rather than introducing yet another new SOA platform, the SOA Runtime Framework introduces a new abstraction layer and allows developers to create adapters to existing SOA platforms.

Lack of SOA deployment on embedded systems: The vast majority of the currently existing SOA environments is exclusively targeted at enterprise environments and demands a considerable amount of memory and processing resources. The SOA Runtime Framework takes a different approach in that all components could potentially be replaced by alternatives with a smaller footprint which renders it equally well suited for both enterprise environments and resource-restricted embedded and mobile devices

Business and IT value chains today have started to merge together in the industry. We now speak of enterprise architecture and Service-Oriented Architecture (SOA) that are independent from IT implementation. With this change, we also need to adapt the way we structure businesses and IT landscape, define and develop architectures like SOA, and run enterprise-focused client engagements.

For all these reasons, governance plays a more important role in today's IT than it ever has before. In this article, I share IBM IT Management Consulting (ITMC) team's best practice governance approach, which we developed and implemented in several client engagements. Starting from proven IT governance structures and practices, I enhanced our governance model to meet SOA requirements.

Motivation and objections

Because of the challenges and issues of the industry, the role of IT in the modern organization has changed radically. Today, IT must react very quickly and flexibly to enable business almost in real time. IT has to design and manage part of a highly integrated and complex enterprise architecture, with increasingly blurred boundaries between business and IT components. This article proposes key governance functions that will help you achieve these goals and implement successful SOA engagements.

Governance provides an overarching structure in order to support the customers' business objectives on strategic, functional, and operational levels. It defines the rules, processes, metrics, and organizational constructs needed for effective planning, decision making, steering, and control of the SOA engagement to achieve customers' business needs and challenging targets. Finally the governance model defines:

What to do.

How to do it.

Who should do it.

How it should be measured.

The model also defines the rules, processes, metrics, and organizational constructs needed for effective planning, decision making, steering, and control of the SOA engagement to meet the customer's business needs and challenging targets.

Based on our experience, we believe that an accepted and formalized governance model is key for successfully achieving business objectives. Therefore, we propose to establish governance functions in SOA engagements. The governance model should also address the fundamental requirement of incremental adaptation, with a focus on using the lessons learned in each step to define and execute the next step. The creation of a governance body for the adaptation and implementation of SOA is a core requirement of the governance model. To achieve fast and high acceptance, we advocate using the client's existing organization and working together to adapt it to the SOA engagement.

The governance model: The right shape for SOA engagements

There are different definitions of IT governance. The one from the IT Governance Institute (see Resources for a link) gives a good overview of IT governance in general:

IT governance is the responsibility of the board of directors and executive management. It is an integral part of enterprise governance and consists of the leadership and organizational structures and processes to ensure that the organization's IT sustains and extends its strategies and objectives.

The purpose of IT governance is to direct IT endeavors to ensure that IT's performance meets the business objectives so that:

IT's alignment with the enterprise results in the promised benefits being realized.

IT enables the enterprise so that opportunities are exploited and benefits are maximized.

IT resources are used responsibly.

IT-related risks are managed appropriately.

Our governance model illustrated in Figure 1 is a combination of organizational structure, joint processes, and relationships based on the strategic direction and accepted ground rules called governance principles. This approach was developed from our experience in large and complex engagements, where we realized that these elements are fundamental for any kind of a project.

Core governance elements

Strategic direction and guiding principles

The definition of a client's strategic direction is the key to success for developing an appropriate SOA and sustaining focus on business needs. A common understanding of the business strategy and objectives is fundamental for both business units and IT.

Governance principles and guidelines are the fundamental basis for any decision. They will shape the solution area and define the way that collaboration takes place. Therefore, they should be well understood and agreed to by executive management. One main guideline is the governance approach. You can diffentiate between two main approaches:

Central governance: Best for the enterprise. The governance council has representation from each service domain (more on this later) and from subject matter experts who can speak to the people who implement key technological components of the solution. The central governance council reviews any additions or deletions to the list of services, along with changes to existing services, before authorizing the implementation of such changes.

Distributed governance: Best for distributed teams. Each business unit has control over how it provides the services within its own organization. This requires a functional service domain approach. A central committee can provide guidelines and standards to different teams.

Each principle should be defined with a rationale that explains that principle's purpose and implications. Guiding principles define the ground rules for development, maintenance, and usage of the SOA. Specific principles -- for architecture design or service definition, say -- are derived from these guiding principles, focusing on specific themes. These principles are the characteristics that provide the intrinsic behavior for the style of design and should cover the following aspects of the project:

Guiding principles:

Reuse, granularity, modularity, composability, and componentization

Compliance to standards (both common and industry-specific)

Services identification and categorization, provisioning and delivery, and monitoring and tracking

Specific architectural principles:

Encapsulation

Separation of business logic from the underlying technology

Single implementation and enterprise-view of components

Leveraging existing assets wherever an opportunity exists

Life cycle management

Efficient use of system resources

Service maturity and performance

By understanding the principles of the SOA style of architecture and design, along with the benefits of those principles to the business and IT communities, you can determine the applicability of SOA when designing a solution. These principles drive certain characteristics that are essential to the design of a service. You can trace back each of the characteristics to one or more SOA principles that provide integrity to the principles and the characteristics.

Governance processes

Governance processes are those processes needed for strategic IT planning and steering, such as:

Strategy development

IT planning

Portfolio management

Sourcing

Innovation management

Architecture management.

Within SOA engagements, you should establish the Architecture Management Process (AMP) at the very beginning of the engagement. The primary objective of the AMP is to ensure the consistent and efficient development and vitality of the defined SOA.

Based on our experience at many engagements, we developed a standard AMP that you can use and adopt within client engagements quickly and easily. The process consists of four subprocesses, illustrated in Figure 2, that are well-defined and available as an asset using IBM LOVEM notation. (LOVEM stands for line of visibility engineering methodology; see Resources for more information).

. Architecture management process

Let's look at some of the elements of the picture in more detail:

Architecture review and approval process:

Defines a structured approach to review and approves changes to the existing SOA; makes decisions in accordance with the SOA roadmap.

Formal design and service evaluation reviews are key control points.

Architecture exceptions and escalation process:

Provides means to appeal architectural decisions.

Allows exceptions to the SOA architecture to meet unique business needs.

Architecture maintenance process:

Ensures that the SOA is maintained and that changes are communicated to stakeholders as new services are incorporated into the architecture.

Variances to the architecture are documented and communicated.

Architecture communication process:

Ensures that the SOA is available to everyone who needs access.

Promotes the understanding of the importance of the SOA.

Organizational structure

To provide architectural governance, some structures have to be established within an organization, defining all required roles and responsibilities as well as appropriate decision-making structures. Experiences in the field have shown that it is very useful to establish an architecture office, especially in large and complex engagements. The architecture office is responsible for keeping the SOA aligned with the business requirements on strategic, tactical, and operational levels. It includes an architecture design authority, who is the owner of the architecture management process. Furthermore, roles and responsibilities are defined on each level.

From our work on client sites, we recognized two effective ways to establish and run such an architecture office:

If the client organization already has an institution with more or less the same functions as an architecture office, then you should interlink with this existing structure. You need to ensure that all functions and responsibilities are on board for making architectural decisions. For the SOA engagement, the board members should be involved with SOA decisions and need to be kept informed on progress.

If there is no governance council at the client's site, we recommend that you establish an architecture office within the context of the SOA engagement and have it make decisions about key project deliverables. Staff the architecture office temporarily with client and project personnel who are involved in the SOA engagement. Members should be decision makers, and should include the CIO as a sponsor. At the end of the engagement, the architecture office can be integrated into the client organization.

Figure 3 represents the architecture office and the roles and responsibilities it fills on each level. On the strategic level there is the architecture board, which is the decision board responsible for submitting standards and principles and prioritizing services aligned with the business and IT strategy. On the tactical level, the architecture group operates as an architecture design authority responsible for defining the architecture management process, along with decision criteria for changing, removing, or adding services and managing domains. On the operational level, the project team develops and implements the services.

Each team needs a role description defining its tasks and responsibilities and the mode of operation.

SOA governance introduces the notion of domain ownership, where domains are managed sets of reusable services sharing some common business cohesiveness. In many cases these are subsets of business services, such as customer information, case information, merchant dispute statistics, and the like, as well as dispute references like merchant risk rating, product analysis, and planning services. Each domain is responsible for maintaining its own business objects and for publishing interfaces to its services to other domains. The domain offers retrieval and maintenance services for the business object, encapsulating business logic, location, and the format associated with its objects and services. When the people in charge of one product or product area want a service from a domain, they makes a request and the two groups determine the relationship, creating a service-level agreement. These relationships and agreements also exist between domains.

With the concept of domain ownership, there are some more new roles and responsibilities that should be provided for the development life cycle in a SOA engagement, as outlined in Table 1 below.

Table 1. Roles and responsibilities in SOA engagement

Role Description

Domain owner Manages the direction of the domain, which comprises a collection of one or more services, as well as the business relationships to help process owners in various business units understand the business perspective. Works with the data and process owners, using business analysts from the lines of business to clarify business goals and requirements. Tracks usage of services for ROI calculations.

Domain service-oriented business analyst Develops use cases that focus on service functionality with no presumption of a user interface. Ensures that well-abstracted and normalized business services are identified and specified. Must adhere to a service definition and development life cycle that is both rigorous and nimble.

Line of business representative Identifies and analyzes business services for the domains.

Domain developer and maintainer Builds and maintains services consistent with the service-oriented development life cycle. Builds and implements a service that is consistent with development rules (for example, service design considerations or Web services implementation guidelines), the SOA, and the reference architecture.

Service tester Certifies that the service conforms to the litmus test agreed to for a service so that the appropriate business value is obtained. Builds test cases for the functional interface and its implementation independence.

The people working within a given service domain are responsible for developing the business and technical integrations to produce business services that are shared across the lines of business to benefit members and regions. This introduces a change in the organizational structure (roles and responsibilities) for application development, as they shift from developing functionality within an application to developing functionality within a service domain.

Launching the governance model

The process you can use to develop a governance model is based on a three-phase approach. This approach was developed based on time-constrained client engagements. The key to success is the establishment of the governance functions from day one of the engagement.

Step 1: Operationalize

Set the core governance functions in place and support the client's business operation.

Learn by doing; deliver quick wins.

Use well-experienced practitioners to act at the top management level.

Step 2: Professionalize

Build up the necessary structures, processes, methods, and tools.

Adapt experiences from Step 1.

Use experienced architects and method practitioners.

Step 3: Stabilize

Teach and train the client personnel to run the operation.

Change from operation mode to coaching mode.

Use consultants and specialists with coaching expertise

Regards,

Vinod

[Former Member]

Hi,

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/408c5726-ef5b-2910-26a9-9d5b5807...

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/50526bda-4e9a-2910-61ba-e9036a79...

Regards

Seshagiri

[Former Member]

HI Kiran,

XI could be the central hub providing all the enterpise webservices which provide most of the master data from SAP R3.

Hence if you were to have a composite application layer above the webserices repository provided by XI, this will be a perfect SOA based architecture. XI will be ideal for managing all the security for accessing data from R3 and will suite the charging model you mentioned.

You definitely can go ahead with SAP XI if you want to implement an SOA model in the enterprise.

SAP XI can expose the interfaces as webservices. all the 3 listed methods of integrations are not based on SOA as they are proprietary adapters and they cannot expose their services to the enternal world, at least in no straight-forward ways

The advantages and disadvantages of SAP XI which I can list are

Advantages:

1. SOA based integration model.

2. The proxy technology in XI gives the advantage of SOA based integration model in SAP integration scenarios. {which is otherwise is difficult (if not impossible) to achieve}

3. Greater extensibility and all the other advantages featured in SOA

4. The integration model of the enterprise will be the SAP recommended way.

Disadvantages:

1. Deployment and maintanence of the SAP XI infrastructure

SOA is not about what technology you are using to connect. Its about whether your business processes have been exposed as services for other applications / processes to access

Experience Enterprise Service in PI with a real healthcare application

/people/jing.chen-schirrmeister/blog/2008/02/07/experience-enterprise-service-in-pi-with-a-real-healthcare-application

Back to the Future with SOA

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/90ada26b-0e6d-2910-d192-82bafcfc...

a similar thread might help...

XI in a SOA landscape

Thanks

Swarup

Edited by: Swarup Sawant on Jun 13, 2008 7:34 AM

Edited by: Swarup Sawant on Jun 13, 2008 7:34 AM

Edited by: Swarup Sawant on Jun 13, 2008 7:36 AM