0207service-oriented-architecture-and-web-servicesppt404.ppt

Slide 1Technologies leading to SOA
Data &
Content
Business
Context
Insightful
Relationships
and
more…
abc…
IBM
IBM
Content
Manager
Oracle
xyz…
Industry Data Models
Extracted or Real-time
Processes
People
Tools & Applications
At the bottom of this chart you see repositories typical of the multitude of application silos many companies have:
SAP running on DB2,
or a content management application running on an IBM Content Manager.
Or yet other applications running on other repositories.
And there's various disparate sources from external suppliers and business partners.
It’s all information that needs to be available to any process or person that can benefit from it. As people build new tools and applications – for example, executive dashboards or next generation procurement applications – they do not need to really understand or do not need to depend upon what sources that information is coming from.
In fact, information sources change every day and consumption of sources change every day. Therefore, to make business flexible, and not based on a specific integration project but a flexible information architecture, we need to deliver information as a service. This virtualizes access to the information. By separating information from the processes and applications it is easier and faster to change either.
Information as a service is about providing a new level of services that helps add value to the information. [click] Services that integrate information – both data and content, regardless of location - to provide a unified view. [click] Services that add business context to the raw information; so transaction data takes the form of a policy, for example. [click] And services that expose insightful relationships in the information – through advanced analysis, so you can make better decisions.
[click] To achieve this, information as a service must be flexible, therefore standards like XML, XQuery, JSR170, which is an unstructured content standard, or web services are critical.
[click] Information needs to be delivered in real time, like our federation capabilities allow for up-to-date information in a call center,
or extracted, or to support warehouse or consolidation activities.
[click] Adding value to information takes demand capabilities, above and beyond traditional data management. E.g. Master Data to help organize key information domains like product or customer data, and provide business context. Or, entity analytics to identify relationships in data so you really know who is who and can detect AML in Finance or Slip and Fall fraud in Retail. Or, embedded analytic capabilities so dashboard analysis can be embedded in a business process and extend analytic insight to a wider audience of users….and so forth.
So as you can see, Information as a Service, delivering information more flexibly, is critical to meeting the goals of any On Demand Business.
And that’s where we have been investing, to enable Information as a Service – over the past several years, multiple billions of dollars in both internal development and acquisitions. Let’s take a closer look…
Information Management – Informix
© 2009 IBM Corporation
The “Integration” Challenge
In the 1980s and early 1990s we were buying best of breed point solutions for automating specific business tasks.
Result: islands of automation.
Late 1990’s saw a huge push towards integrating islands of automation in to cohesive end-to-end systems:
Large in-house integration projects
Huge investments in to integrated product suites for ERP, CRM etc.
Integration is very hard and very expensive:
requires a lot of planning and coordination between all of the systems involved
Integrated systems become inflexible and unable to adapt to changes in business processes
The challenge of integration :
Desire to build integrated business processes backed up by integrated IT processes and infrastructure has been with us for the past 15 years. It has proved to be an illusive goal. Projects to integrate desperate applications are always characterized by their large scope and size, unbound degree of complexity and requirement for tremendous amount of planning and coordination between all of the systems involved. It is not enough for an IT infrastructure today to be integrated. It must be able to respond to frequent and rapid changes in business processes. IBM calls it ability to support an “on Demand” business.
The Role of SOA: Solving the Integration Challenge
Systems that can accommodate new business processes and new relationships as needed
Systems based on loosely coupled distributed components
Simplify implementations by making components autonomous and allow them to be used when needed
Allow selection of best-of-breed components to lower cost and deliver higher business value
IBM view for an “on Demand Business”
An on demand business is an enterprise whose business processes – integrated, end-to-end, across the company and with key partners, suppliers and customers – can respond with speed to any customer demand, market opportunity or external threat.
What is SOA?
“Service-Oriented Architectures (SOA) is a set of patterns for building distributed systems where one application that comprises a system can find another application that provides needed service and can exchange data with it.”
SOA is not a product
First and foremost, SOA is not a product or even a set of products. You can not buy SOA … you can’t even implement it. SOA is a “philosophy” for building distributed applications that you can follow and practice.
SOA is not new. We have been building distributed systems for a long time. What distinguishes SOA from the prescriptive architectures and patterns we used in the past is its emphasis on delivering on core values such as flexibility, resilience and lower cost through the use of industry standards.
Platform and language independent
Proven interoperability
Business Innovation & Optimization Services
Development
Services
Interaction Services
Process Services
Information Services
ESB
Access Services
IT Service
resources
Data access
Info Assets
The SOA reference architecture is a way of looking at the set of services that go into building an SOA. These capabilities can be implemented on a build-as-you-go basis allowing capabilities and project level solutions to be easily added as new requirements are addressed over time. The reference architecture is a great tool for laying out roadmaps for pursuing SOA.
We’ll get back to it later in the presentation.
Additional detail:
The SOA Reference Architecture outlines the key capabilities that are required for comprehensive, enterprise wide SOA solutions. These capabilities can be implemented on a build-as-you-go basis allowing capabilities and project level solutions to be easily added as new requirements are addressed over time.
Tools are an essential component of any comprehensive integration architecture. The SOA Architecture includes both Development Services which are used to implement custom artifacts that leverage the infrastructure capabilities, and Business Innovation & Optimization Services which are used to monitor and manage the runtime implementations at both the IT and business process levels.
At the core of the SOA Reference Architecture is the Enterprise Service Bus. This delivers all of the inter-connectivity capabilities required to leverage the services implemented across the entire architecture. Transport services, event services, and mediation services are all provided through the ESB.
The SOA Reference Architecture also contains a set of services that are oriented toward the integration of people, processes, and information:
Interaction Services provide the capabilities required to deliver IT functions and data to end users, meeting the end-user's specific usage preferences.
Process Services provide the control services required to manage the flow and interactions of multiple services in ways that implement business processes.
Information Services provide the capabilities required to federate, replicate, and transform data sources that may be implemented in a variety of ways.
Many of the services in an SOA are provided through existing applications; others are provided in newly implemented components; and others are provided through external connections to third party systems.
Existing enterprise applications and enterprise data are accessible from the ESB through a set of Access Services that provide the bridging capabilities between legacy applications, pre-packaged applications, enterprise data stores and the ESB.
The SOA Reference Architecture also contains a set of Partner Services that provide the document, protocol, and partner management capabilities required for business processes that involve inter-actions with outside partners and suppliers.
Business Application Services provide runtime services required for new application components to be included in the integrated system.
Underlying all these capabilities of the SOA Reference Architecture is a set of Infrastructure Services which are used to optimize throughput, availability and performance.
IT Services Management Services include capabilities that relate to scale and performance, for example edge services, clustering services, and virtualization capabilities allow efficient use of computing resources based on load patterns.
The SOA Reference Architecture is a complete and comprehensive architecture that covers all the integration needs of an enterprise. Its services are well integrated and are delivered in a modular way, allowing SOA implementations to start at a small project level. As each additional project is addressed, new functions can be easily added, incrementally enhancing the scope of integration across the enterprise.
Background:
The IBM SOA Foundation delivers the capabilities you need to adopt SOA through a comprehensive architecture. These capabilities can be implemented on a build-as-you-go basis, and yet, because of the architecture and its service orientation, capabilities and project level solutions can be easily added as new requirements are addressed over time.
The SOA Reference Architecture shows the key capabilities that are required for comprehensive, enterprise wide SOA solutions.
Development Services are an essential component of any comprehensive integration architecture. The SOA Architecture includes development tools, used to implement custom artifacts that leverage the infrastructure capabilities, and business performance management tools, used to monitor and manage the runtime implementations at both the IT and business process levels. Development tools allow people to efficiently complete specific tasks and create specific output based on their skills, their expertise, and their role within the enterprise. Business Analysts who analyze business process requirements need modeling tools that allow business processes to be charted and simulated. Software Architects need tool perspectives that allow them to model data, functional flows, system interactions, etc. Integration Specialists require capabilities that allow them to configure specific inter-connections in the integration solution. Programmers need tools that allow them to develop new business logic with little concern for the underlying platform. Yet, while it is important for each person to have a specific set of tool functions based on their role in the enterprise, the tooling environment must provide a framework that promotes joint development, asset management and deep collaboration among all these people. A common repository and functions common across all the developer perspectives (e.g. version control functions, project management functions, etc) are provided in the SOA Reference Architecture through a unified development platform.
The Business Innovation & Optimization Services incorporate monitoring capabilities that aggregate operational and process metrics in order to efficiently manage systems and processes. Managing these systems requires a set of capabilities that span the needs of IT operations professionals and business analysts who manage the business operations of the enterprise. These capabilities are delivered through a set of comprehensive services that collect and present both IT and process-level data, allowing business dashboards, administrative dashboards, and other IT level displays to be used to manage system resources and business processes. Through these displays and services, it is possible for LOB and IT personnel to collaborate to determine, for example, what business process paths may not be performing at maximum efficiency, the impact of system problems on specific processes, or the relationship of system performance to business process performance. This collaboration allows IT personnel and assets to be tied more directly to the business success of the enterprise than they traditionally have been.
One key feature of the SOA Reference Architecture is the linkage between the Development and the Business Innovation & Optimization Services. The ability to deliver runtime data and statistics into the development environment allows analyses to be completed that drive iterative process re-engineering through a continuous business process improvement cycle.
At the core of the SOA Reference Architecture is the Enterprise Service Bus. This architectural construct delivers all the inter-connectivity capabilities required to leverage and use services implemented across the entire architecture. Transport services, event services, and mediation services are all provided through the ESB. Transport services provide the fundamental connection layer; event services allow the system to respond to specific stimuli that are part of a business process; and mediation services allow loose-coupling between interacting services in the system. The ESB is a key factor in enabling the service orientation of the SOA Reference Architecture to be leveraged in implementing service oriented solutions and can be implemented today to meet the quality of service requirements of any integration solution.
The SOA Reference Architecture also contains a set of services that are oriented toward the integration of people, processes, and information. These services control the flow of interactions and data among people and automated application services in ways appropriate to the realization of a business process:
- Interaction Services provide the capabilities required to deliver IT functions and data to end users, meeting the end-user's specific usage preferences.
- Process Services provide the control services required to manage the flow and interactions of multiple services in ways that implement business processes.
- Information Services provide the capabilities required to federate, replicate, and transform data sources that may be implemented in a variety of ways.
Automated application services, implementations of business logic in automated systems, are a critical part of any integration architecture or solution. Many of these services are provided through existing applications; others are provided in newly implemented components; and others are provided through external connections to third party systems. Existing enterprise applications and enterprise data are accessible from the ESB through a set of access services. These Access Services provide the bridging capabilities between legacy applications, pre-packaged applications, enterprise data stores (including relational, hierarchical and nontraditional, unstructured sources such as XML and Text), etc and the ESB. Using a consistent approach, these access services expose the data and functions of the existing enterprise applications, allowing them to be fully re-used and incorporated into functional flows that represent business processes. Existing enterprise applications and data leverage the Business Application and Data Services of their operating environments such as CICS, IMS, DB2, etc. As these applications and data implementations evolve to become more flexible participants in business processes, enhanced capabilities of their underlying operating environments, for example support of emerging standards, can be fully utilized.
The SOA Reference Architecture also contains a set of Business Application Services that provide runtime services required for new application components to be included in the integrated system. These application components provide new business logic required to adapt existing business processes to meet changing competitive and customer demands of the enterprise. Design and implementation of new business logic components for integration enables them to be fully re-useable, allowing them to participate in new and updated business processes over time. The Business Application Services include functions important to the traditional programmer for building maintainable, flexible, and re-useable business logic components.
In many enterprise scenarios, business processes involve inter-actions with outside partners and suppliers. Integrating the systems of the partners and suppliers with those of the enterprise improves efficiency of the overall value chain. Partner Services provide the document, protocol, and partner management services required for efficient implementation of business-to-business processes and inter-actions.
Underlying all these capabilities of the SOA Reference Architecture is a set of Infrastructure Services which provide security, directory, IT system management, and virtualization functions. The security and directory services include functions involving authentication and authorizations required for implementing, for example, single sign-on capabilities across a distributed and heterogeneous system.
IT Services Management Services include functions that relate to scale and performance, for example edge services and clustering services, and the virtualization capabilities allow efficient use of computing resources based on load patterns, etc. The ability to leverage grids and grid computing are also included in infrastructural services.
While many of the Infrastructure and IT Service Management services perform functions tied directly to hardware or system implementations, others provide functions that interact directly with integration services provided in other elements of the architecture through the ESB. These interactions typically involve services related to security, directory, and I/T operational systems management.
The SOA Reference Architecture is a complete and comprehensive architecture that covers all the integration needs of an enterprise. Its services are well integrated and are delivered in a modular way, allowing SOA implementations to start at a small project level. As each additional project is addressed, new functions can be easily added, incrementally enhancing the scope of integration across the enterprise. In addition to supporting SOA strategies and solutions, the architecture itself is designed using principles of service orientation and function isolation.
Service
Composition
Transports
Messaging
Description
Business Web Services (Best Practices) : Service offerings and components (e.g., Book Flight, Low Fare Search, Update PNR Data, TEA, Request For Design)
Evolving industry semantics
Current SOA implementation also use FTP, batch files, asynchronous messaging, etc – mature technologies.
You don’t need to know al these standards (at least for now). Just be aware that they exist. The ones that impact us more are HTTP, XML, SOAP, and WSDL.
Note that XML appears almost everywhere.
To save money:
Integrated systems save money
Open standards and common components means lower labor cost and bigger pool of skill
Extend the life of current applications and other assets while building new systems
“Pay as you go” schemes for web services are possible
… and to help the business make money:
Open up new business opportunities: new markets, new partners
Bring products and services to market faster
What is a Web Service? (W3C definition)
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
What is a Web Service: A Simpler Definition
A Web Service is a standards-based way for an application to call a function over a network and to do it without having to know:
the location where the function will be executed,
the platform where the function will be run,
the programming language it is written in, or even
who built it.
Most important: Web Services are Easy!
Simply put, Web Services is a way for one application to exchange data with another application using extensible industry standard protocols based on XML. Basically, it is yet another way for two applications to communicate with each other. Why are Web Services different and why do they hold so much promise where previous technologies such as CORBA and DCOM failed? The answer is very simple; where as previous technologies used specialized and proprietary protocols Web Services is based on open and extensible protocols based on XML lingua franca for open communications.
Because Web Services are build using extensible industry standards it provides application developers with:
Ability to conduct communication data exchange regardless of the location (same machine, another machine on an intranet, a service somewhere on internet)
Ability to use a service no matter what platform the service is run or what platform the consuming application is run
Ability to completely ignore details of the implementation of the service such as the programming language that was used or the underlying application technologies.
Web Services will succeed, one might say have already succeeded, where others have failed.
Web services are technologies that allow applications to communicate with each other in a platform- and programming language-independent manner. A Web service is a software interface that describes a collection of operations that can be accessed over the network through standardized XML messaging. It uses protocols based on the XML language to describe an operation to execute or data to exchange with another Web service. A group of Web services interacting together in this manner defines a particular Web service application in a Service-Oriented Architecture (SOA). While Web services allow dynamic features to combine multiple services into applications, you still have to build the services first. Programming languages in computer science are continually evolving. We began decades ago with the idea of a function in which you provide some parameters, it executes some operation on those parameters, and it returns a value based on its calculations. Eventually, this first concept evolved into the object where each object had not just a number of functions it can perform, but also its own private data variables, rather than relying on external system-wide data variables that previously made it more complex to develop applications. As applications began communicating with each other, the concept of defined universal interfaces for objects became important, allowing objects on other platforms to communicate even if they were written in other programming languages and ran on other operating systems.
Discovery
Messaging
Web Service: Standard is Key
WSDL is used to describe the function(s) that an application will be calling documenting in a standard way its entry points, parameters and output
XML is used to carry the values of parameters and the outputs of the function
SOAP is used as the messaging protocol that carries content (XML) over a network transport (typically HTTP)
HTTP is used as the network transport layer
Four key specifications form the Web Services stack.
WSDL provides the description of the web service by specifying the collection of functions that a web service can perform, the inputs that these functions expect to receive and the type of output that a caller can expect to get back. Because WSDL is a standard, it can be interpreted by an application that needs to call the service automatically i.e. without a need for human intervention. There is no need to call the writer of the service, get a specification from him/her etc. Someone who wants to use the service simply needs to be able to get its WSDL.
The data that is carried between the caller of a web service (web service consumer) and the web service itself (web service provider) is encoded using XML. Because XML allows for standard data representation, both web service consumer and the web service provider do not have to know or care about either the platform that each is running on or the programming language or application framework that each is using. For example, a consumer written in C# can call a web service written in Java in exactly the same way as a web service written in C#. As a matter of fact, the consumer never knows how a web service he is consuming is implemented.
SOAP is a standard messaging protocol that is used to make a call to a web service and to bring the results back. SOAP is frequently described as an envelope which contains the XML payload.
HTTP is the most popular network transport for carrying SOAP messages for Web Services. It is popular because of its ability to traverse firewalls and because it is ubiquitous. Web Services allows for use of other protocols (e.g. MQ) but their use is quite rare.
Tools should be used for development
Ex: IBM Data Studio
Websphere Application Servers, Geronimo, etc.
Apache Soap (based on IBM SOAP4J) with Xerces XML parser (also contributed by IBM)
Other tools
WSDL generation, UDDI, etc.
The point here is that you must have the proper infrastructure to support Web services.
Note also that because of this a database can depend on these tools to be integrated into web services
WSDL: Web Service Description Language
WSDL (Web Services Description Language) is a public description of the interfaces offered by a web service. Expressed in XML, it provides machine readable document that provides a calling application all of the information required to interact with a web service.
WSDL is really at the very core of the Web Services architecture. It provides complete specification for the functionality exposed by a web service, all of the input and output formats and all other information required to communicate with a web service. It is expressed entirely in XML using a well known schema.
WSDL describes services as a set of endpoints. WSDL can describe the 2 styles of Web Services: document-oriented or procedure-oriented. WSDL allows for a description of each individual message and operation and then binding them to a specific protocol (e.g. HTTP) to create an endpoint. A collection of endpoints is what defines a web service.
<message>: messages transmitted
<portType>: functions supported
The XML Schema built-in types include string, boolean, float, double, decimal, binary, integer, nonPositiveInteger, negativeInteger, long, int, short, byte, nonNegativeInteger, unsignedLong, unsignedInt, unsignedShort, unsignedByte, positiveInteger, date, time.
<?xml version="1.0" ?>
</message>
</message>
… (continued from previous page)
- <operation name="getTemp">
</input>
- <output>
</output>
</operation>
</binding>
- <port name="TemperaturePort" binding="tns:TemperatureBinding">
<soap:address location="http://services.xmethods.net:80/soap/servlet/rpcrouter" />
SOAP: A Description
Industry standard message format for sending and receiving data between a web services consumer and a web service provider
SOAP messages are XML documents which have an envelope and:
Header (optional): contains information about the message such as date/time it was sent or security information
Body: contains the message itself
SOAP used to stand for Simple Object Access Protocol
SOAP Message
Attachment Part
SOAP Part
SOAP Envelope
SOAP Body
SOAP Header
The SOAP runtime you use provides the appropriate API to limit the complexity of communication
SOAP: Request Example
Call to a fictional web service to get details on product
with product id=827635
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<productID>827635</productID>
<price>96.50</price>
<inStock>true</inStock>
REST: REpresentation State Transfer
Restful: Follows the REST principles
Not strictly for web services
Term used loosely as a method of sending information over HTTP without using a messaging envelope
Enterprise Service Bus
Enterprise Service Bus is a set of patterns that can be applied to implement SOA-based systems. These patterns make extensive use of messaging and event notification to deliver core values.
Enterprise Service Bus
“Enterprise Service Bus is a set of patterns that can be applied to implement SOA-based systems. These patterns make extensive use of messaging and event notification to deliver core values.”
ESB is a intermediary between the clients that consume services and various systems that provide these services.
Instead of client talking directly to a service provider, requests are routed through a middleware system that handles the specific details of locating the service provider, negotiating integration with the service provider, interacting with the service provider, and so on.
ESB replaces RPC-like synchronous Web Service invocations with message-based and event-based interactions.
ESB enhances traditional message-based systems with discovery and self-describing characteristics typically attributed to Web Services.
In the traditional (if there is such a thing) Web Services scenario, the interactions between the client and the service provider are direct and synchronous. ESB pattern basically proposes to replace direct RPC-based invocation of a service by a client using a message and event based middleware. Instead of calling a service directly, a client calls a proxy service and the proxy service in turn calls one of the appropriate providers of the service based on characteristics such as load, response time etc. For example, there are a number of providers of a currency conversion Web Services on the web. Instead of the client locating these services and deciding which one should be called, ESB proposes to create a single well known proxy service for currency conversion which can in turn select the proper Web Service to call at the time of invocation. This way he proxy service can handle changes in location of the real services, deal with reliability and scalability aspects, perform service equalization and mapping etc. Furthermore, ESB proposes replacing synchronous RPC-style invocation of the service with an asynchronous message-based invocation.
Turn this …
The number and complexity of the interfaces is reduced
Rich business abstractions describe the application interface
But separate connection points still leaving bloated interfaces ….
Service
Interface
Interface
interface
Service
Service
Service
Service
Service
Service
Service
Interface
Interface
Interface
Interface
Interface
So how does basic SOA decouple the interfaces from their applications?
1) SOA uses a programming model that allows a rich abstraction of both the business app and the interface.
2) By abstracting, the interfaces can be clearly separated from the business applications.
3) This enables you to reduce the number and complexity of those interfaces.
4) It allows you to reuse both the interfaces and the business applications.
The problem is that you still have to build, find, and manage all of those interfaces somewhere.
RESULT Greater Business Responsiveness
Allows for dynamic selection, substitution, and matching
Enables you to find both the applications and the interfaces for re-use
Decouples the point-to-point connections from the interfaces
Turn this (web services)…
…into this
The ESB shrinks the interfaces further.
It virtualizes the interface, or in other words, it decouples the point-to-point connections from the interfaces themselves.
2) The interfaces are put into a third party broker which helps you manage the interfaces better.
3) This enables faster and more flexible coupling and decoupling of applications.
4) Because you can find all of the applications and the interfaces, you can then reuse both.
Financial transparency
Business/IT alignment
Process control
Customers think about SOA in terms of a lifecycle. They start in the Model phase by gathering business requirements and designing their business processes. Once they have optimized the business processes, they implement it by combining new and existing services. The assets are then deployed into a secure and integrated environment for integrating people, processes and information. Once deployed, customers manage and monitor from both an IT and a business perspective. Information gathered during the Manage phase is fed back into the lifecycle for continuous process improvement. Underpinning all of these lifecycle stages is governance which provides guidance and oversight for the SOA project.
Tivoli Composite Application Manager*
Tivoli Identity & Access Manager
WebSphere Business Modeler*
Rational Software Architect*
WebSphere Integration Developer*
Rational Application Developer*
* New or Enhanced
The SOA Foundation is built with software that was carefully selected from a broader software portfolio. These are the specific, targeted software products that support each stage of the SOA lifecycle. They are interoperable and fully modular so you can select just what you need today with the comfort that it will work well with other additions you may want to make in the future.
A new opportunity
It should be noted that DB2 has more accessible functionality than IDS but the IDS customers should not be ignored since they represent around 30% of the DB planned revenue in 2006
Content
Management
Standards-based
Virtualized
Master Data Management
Business
Intelligence
Within the SOA Foundation we are going to look at the capabilities available for Information Composition.
IBM Information Management portfolio provides key capabilities in the areas of:
Master Data Management (Product Information Management with WPC and Customer Data Integration with DWL)
Business Intelligence (e.g. DB2 AlphaBlox and DB2 Data Warehouse Edition)
Content Management (e.g. DB2 Content Manager)
Information Integration (with solutions for Enterprise Information Integration, Extract / Transform / Load, Enterprise Content Integration, Data Quality etc.), and
Data Management (including the DB2 UDB and Informix databases).
These capabilities follow open standards where available and IBM is committed to contributing to the development of these standards including making donations of code and intellectual property such as the case with the Unstructured Information Management Architecture (UIMA) framework for Text Analytics recently released into the open source community.
IBM Data Servers
Data Server
Key value proposition
Instantly transform existing stored procedures into a collection of reusable services.
DRY = Don’t Repeat Yourself. Build new logic once and make it accessible via SQL or as a service
Instantly SOA enable mainframe and iSeries data
IDS
IDS
A better way
Key value proposition
DRY = Don’t Repeat Yourself. Build reusable services instead of putting the same logic in every application
Gain flexibility of proper data architecture and data placement
Build agile applications that are able to respond to business needs
IDS
IDS
WebSphere
Summary
SOA and Web Services are not as scary or new and different as acronyms may imply. Just a set of standards-based architecture patterns for building distributed systems.
SOA deploys to an existing IT infrastructure and IBM SOA offers comprehensive solutions for overlaying SOA on top.
DB2 is already SOA-enabled:
Tools and facilities to expose DB2 objects as a service
Tools and facilities to consume data delivered through Web Services
Tools coming to bring business perspective to DB2 web services (BPEL)
Existing investments in stored procedures and functions are going to pay off in new ways.

Documents

0207service-oriented-architecture-and-web-servicesppt404.ppt