1 / 25

XML and Web Services: The End of the Beginning Jeremy Lehman Capital Markets Technology Strategist Microsoft Corpora

dayo
Download Presentation

XML and Web Services: The End of the Beginning Jeremy Lehman Capital Markets Technology Strategist Microsoft Corpora

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. XML and Web Services: The End of the Beginning Jeremy Lehman Capital Markets Technology Strategist Microsoft Corporation

    2. Integration through Abstraction Capital markets used Web services, in a sense, before the term was formalized to include baseline standards Business model well-established in industry as service bureaus, i.e. ADPCapital markets used Web services, in a sense, before the term was formalized to include baseline standards Business model well-established in industry as service bureaus, i.e. ADP

    3. Web Services Baseline Standards But XML alone cant do the whole job. In order to have solid, reliable connections between applications you need more structure in the relationship. A series of open industry standards have been developed on top of XML to provide that kind of structure. These standards: are not owned by any company -- but they are supported very broadly across the industry are open meaning that everyone will write to them, will build their applications or services on top of them so that they can interoperate, so you can have complete confidence that no matter which service or vendor you go to, those services are likely to work together. This is a very important part of the XML Web Services dynamic. When you have everyone in the industry supporting the same set of standards and developing their solutions to integrate using them, you get incredible benefits across your business. Slide Transition: Strips Right-Down Additional information for presenter: Simple standards stack Internet lowest cost way to move bits, broadest reach, deepest investment XML W3C standard SOAP W3C effort UDDI open, founded by MS, IBM, Ariba, over 200 members Easy integration, distributed control Vendor, platform, language neutral But XML alone cant do the whole job. In order to have solid, reliable connections between applications you need more structure in the relationship. A series of open industry standards have been developed on top of XML to provide that kind of structure. These standards: are not owned by any company -- but they are supported very broadly across the industry are open meaning that everyone will write to them, will build their applications or services on top of them so that they can interoperate, so you can have complete confidence that no matter which service or vendor you go to, those services are likely to work together. This is a very important part of the XML Web Services dynamic. When you have everyone in the industry supporting the same set of standards and developing their solutions to integrate using them, you get incredible benefits across your business. Slide Transition: Strips Right-Down Additional information for presenter: Simple standards stack Internet lowest cost way to move bits, broadest reach, deepest investment XML W3C standard SOAP W3C effort UDDI open, founded by MS, IBM, Ariba, over 200 members Easy integration, distributed control Vendor, platform, language neutral

    4. Web Services in Action

    5. Evolution of Financial Technology Single view in real time across all asset classes

    6. One View Across the Enterprise Expose bank functions as Web services Services mask underlying complexity Common channel to each bank function Revitalizes legacy systems Capital markets is a pure information industry. There is nothing tangible in the supply chain. (Disjointed) A bank can be thought of as a set of value chain functions which are implemented by IT systems. Web services provide a common way into these systems. Web services offer a standard way to reach all value chain functions. Customers, traders, developers and other users are essentially presented with a menu of self-organizing Web services that can be rapidly assembled together or integrated with other applications whether on a device, internal applications, or within a customers systems. This standardization accelerates creating new applications. The firm overall gains greater competitive agility by reacting faster. Another way to look at this is that Web services are a layer of abstraction that can separate the implementation from the business effect. Each value chain function may have highly complex and disjointed systems behind it, but the firms enterprise architecture is composed of a set of logically organized and readily integrated Web services. Consider the example of a banking starting a project to encourage cross-selling. Several new applications must be built that need a single view of the customer. Like many banks that have weathered years of industry consolidation, customer reference data is spread across 40 different applications on a variety of computing platforms. The bank can first create a Web service that masks all the different legacy apps and shows one view of the customer. Thats not a trivial task, but once completed the bank can rapidly introduce new applicationsand set the foundation to sustainably move fast. With a technical audience, we can use a database analogy. Consider the concept of views in a database. Database views present a controlled set of data from a variety of back end tables. The view abstracts the source tables. Similarly, Web services provide a business logic view. They abstract the source systems. Web services go further than database views because they are executable code and work across operating systems and object models. Web services help solve a lot of integration issues, but they need to be connected to form business processes. We need another element here to link these services into a business process. Thats a role that BizTalk orchestration can play Capital markets is a pure information industry. There is nothing tangible in the supply chain. (Disjointed) A bank can be thought of as a set of value chain functions which are implemented by IT systems. Web services provide a common way into these systems. Web services offer a standard way to reach all value chain functions. Customers, traders, developers and other users are essentially presented with a menu of self-organizing Web services that can be rapidly assembled together or integrated with other applications whether on a device, internal applications, or within a customers systems. This standardization accelerates creating new applications. The firm overall gains greater competitive agility by reacting faster. Another way to look at this is that Web services are a layer of abstraction that can separate the implementation from the business effect. Each value chain function may have highly complex and disjointed systems behind it, but the firms enterprise architecture is composed of a set of logically organized and readily integrated Web services. Consider the example of a banking starting a project to encourage cross-selling. Several new applications must be built that need a single view of the customer. Like many banks that have weathered years of industry consolidation, customer reference data is spread across 40 different applications on a variety of computing platforms. The bank can first create a Web service that masks all the different legacy apps and shows one view of the customer. Thats not a trivial task, but once completed the bank can rapidly introduce new applicationsand set the foundation to sustainably move fast. With a technical audience, we can use a database analogy. Consider the concept of views in a database. Database views present a controlled set of data from a variety of back end tables. The view abstracts the source tables. Similarly, Web services provide a business logic view. They abstract the source systems. Web services go further than database views because they are executable code and work across operating systems and object models. Web services help solve a lot of integration issues, but they need to be connected to form business processes. We need another element here to link these services into a business process. Thats a role that BizTalk orchestration can play

    7. .NET for Time to Market & Agility Fundamentally for loosely coupled model Software as a service Device innovation Business processes on the web Sustained edge: $5.3 billion in R&D vs. Sun at $1.6, Oracle at $1.0 Software as a service example: integrate price improvement statistics in OMS liquidity shopping in real timeSoftware as a service example: integrate price improvement statistics in OMS liquidity shopping in real time

    8. BizTalk Orchestration Rapidly deploy and evolve business processes Fundamentally around processes and XML One model for EAI and trading partner integration Connects legacy systems Tool for data integration Octavios string along the different formatsTool for data integration Octavios string along the different formats

    9. Demonstration

    10. Standards Leadership

    11. Global XML Web Services Architecture - GXA Modular Simplicity through modularity General Purpose Open-ended set of applications and services Consistent model across network environments Federated No globally central server or administration Assumes applications span trust boundaries Heterogeneous No single programming model or platformModular Simplicity through modularity General Purpose Open-ended set of applications and services Consistent model across network environments Federated No globally central server or administration Assumes applications span trust boundaries Heterogeneous No single programming model or platform

    12. WS - Routing WS-Routing is a SOAP-based, stateless protocol for exchanging one-way SOAP messages from an initial sender to the ultimate receiver, potentially via a set of intermediaries. In addition, SOAP-RP provides an optional reverse message path enabling two-way message exchange patterns like request/response, peer-to-peer conversations, and the return of message acknowledgements and faults. SOAP-RP is expressed as a SOAP header entry within a SOAP envelope making it relatively independent of the underlying protocol. This specification defines the use of SOAP-RP in combination with TCP, UDP, and HTTP but other underlying protocols are possible. The Web Services Routing Protocol (WS-Routing) defines mechanisms for routing SOAP messages. SOAP is a lightweight wire protocol that defines a serialization mechanism to transport method calls to be used in application layer protocols. SOAP does not actually define a mechanism for sending a message from one party to another, even though it refers to a virtual message path. WS-Routing (formerly known as SOAP-RP) is a stateless protocol that extends SOAP by defining a means to specify an ordered route, or path, from the originator of the message, through intermediaries, to the ultimate message receiver. Bottom line: achieves one way, two way, and correlated messages. Our view on SOAP-based asynchronous messaging Previously known as SOAP-RP Builds on SOAP extensibility model Entirely carried within a SOAP message Deliberately does not provide Guaranteed Messaging, Caching, Pub/Sub, Notification, Privacy, Signing, Encryption, etc. <to> is the destination of the message <from> is like "from" in emails <fwd> specifies the forward path <rev> specifies the reverse path <action> indicates the message type <id> is a message ID <relatesTo> links to message IDs WS-Routing is a SOAP-based, stateless protocol for exchanging one-way SOAP messages from an initial sender to the ultimate receiver, potentially via a set of intermediaries. In addition, SOAP-RP provides an optional reverse message path enabling two-way message exchange patterns like request/response, peer-to-peer conversations, and the return of message acknowledgements and faults. SOAP-RP is expressed as a SOAP header entry within a SOAP envelope making it relatively independent of the underlying protocol. This specification defines the use of SOAP-RP in combination with TCP, UDP, and HTTP but other underlying protocols are possible. The Web Services Routing Protocol (WS-Routing) defines mechanisms for routing SOAP messages. SOAP is a lightweight wire protocol that defines a serialization mechanism to transport method calls to be used in application layer protocols. SOAP does not actually define a mechanism for sending a message from one party to another, even though it refers to a virtual message path. WS-Routing (formerly known as SOAP-RP) is a stateless protocol that extends SOAP by defining a means to specify an ordered route, or path, from the originator of the message, through intermediaries, to the ultimate message receiver. Bottom line: achieves one way, two way, and correlated messages. Our view on SOAP-based asynchronous messaging Previously known as SOAP-RP Builds on SOAP extensibility model Entirely carried within a SOAP message Deliberately does not provide Guaranteed Messaging, Caching, Pub/Sub, Notification, Privacy, Signing, Encryption, etc. <to> is the destination of the message <from> is like "from" in emails <fwd> specifies the forward path <rev> specifies the reverse path <action> indicates the message type <id> is a message ID <relatesTo> links to message IDs

    13. WS-Referral Dynamically set SOAP routing nodes Configures SOAP routers <for> contains the destinations a referral talks about <if> contains the set of conditions for using the referral <go> is the set of SOAP routers to go via <refId> is a referral ID Request, query, insert, and delete referrals at SOAP router

    14. WS-Routing/Referral Application Abstract end points at firewall, then Refer user to closet global scale away server

    15. Key Points Computing is shifting from closed APIs to loose coupling using XML Standards leadership shows the best platform .NET is designed fundamentally for XML Web Services Microsoft booth and breakout at 5:30

    17. Back-up Slides

    18. .NET Framework Designed for Loosely-coupled Computing Built for Web services Integral SOAP & XML support High-productivity, multi-language development Unified, simplified programming model Secure, scalable, high-performance execution Advanced security and compiler technologies

    19. Inside the .NET Framework

    20. Inside the .NET Framework

    21. Inside the .NET Framework

    22. Inside the .NET Framework

    23. Inside the .NET Framework

    24. WS-Referral Example

    25. XML Web Services Leadership Competition shifts to the best tools for standards Standards leadership means deeper, faster support in developer tools and servers

    26. XML Web Services Standards Leadership From http://www.sun.com/software/sunone/wp-arch/ June 28, 2001 dsfsdfsdfdsfsdfsdf

More Related