Novas Arquitecturas baseadas em Web Services

Apresentação em tema: "Novas Arquitecturas baseadas em Web Services"— Transcrição da apresentação:

1 Novas Arquitecturas baseadas em Web Services
XATA 2004 – Fev 2004 José António Silva Architect Evangelist

2 vamos falar sobre… Service-Orientation XML, SOAP, WSDL, UDDI
Novos Protocolos WS-* WS-* Workshop Process Web Services Interoperability WS-I.ORG

3 Service-Orientation

4 porque é que construímos sistemas distribuídos?
demasiado trabalho para uma só máquina dados pertencem a diferentes organizações dados pertencem a diferentes sistemas funcionalidades de determinados sistemas necessidades de execução diferentes necessidades de segurança diferentes

5 Protocolos na NET XML Web Services HTML IP composição de serviços
Aplicações com Aplicações HTML browser Pessoas com Informação IP Pessoas com Pessoas

6 Exemplo: Aplicação 3 camadas
boa arquitectura DNA Aplicação Central Compras Data Layer Business Layer Presentation Layer Interface da aplicação dá acesso aos dados aplicacionais

7 Aplicação Contabilidade
O utilizador é o elo de ligação dos processos, o que é lento, caro e propício a erros Aplicação Contabilidade Processo de negócio atravessa várias aplicações Aplicação Central Compras Aplicação RH

8 Service Oriented Architecture
Interface desacoplado da lógica de processamento dos dados troca de mensagens boa arquitectura 3-tier service Serviço Central Compras UI Business Layer Service Façade Data Layer Presentation Layer Web Service Standards permitem ligações cross-platform Dados e Lógica Negócio encapsulados por uma Web Service Façade

9 Automação de Processos de Negócio
Serviços Contabilidade integração com diferentes plataformas Serviço Central Compras UI Processo Compras Business Process Automation Serviço RH Múltiplos serviços combinados num único processo de negócio

10 gerações Mainframe 60s–80s Procedural (COBOL) Automated business
Paradigma Período Modelo Programação Motivação Mainframe 60s–80s Procedural (COBOL) Automated business Cliente/Servidor 80s-90s Database (SQL) fat-client (VB) Desktop power n-Tier 90s-00s Object-Oriented (Java, COM, ASP) Internet/Browser SOA 2000s Service-oriented (SOAP, WSDL, UDDI) Business agility

11 Serviços, Componentes, Objectos, …
Evolução natural Function  Component  Service Serviços contem mensagens, componentes e dados Dados privados e completamente encapsulados pelo serviço Mensagens são a única forma de entrada e saída num serviço Service Private Data Components Functions

12 Tightly Coupled Programming Language Database Agreements Database
Object Model Before Web services, you and your partners had to agree on programming language, object model, app server, in fact you probably had to agree on the vendor stack in general… sure RMI if you have a J2EE server from BEA… what it’s not from BEA hmmm, better get your developer to call mine. Same w/ CORBA and others. Web services removes the need to run the same stack on both sides… you can disagree about everything in computing as long as you agree on the documents, (Schema) and the business arrangements around those documents… I expect you send an acknowledgement after you ship the widget from your warehouse. Tie this back to the business discussion… Businesses need to be more flexible, IT needs to be more flexible. Schema Operating System Operating System Application Server

13 Loosely Coupled Programming Language Programming Language Database
Agreements Database Object Model Object Model Before Web services, you and your partners had to agree on programming language, object model, app server, in fact you probably had to agree on the vendor stack in general… sure RMI if you have a J2EE server from BEA… what it’s not from BEA hmmm, better get your developer to call mine. Same w/ CORBA and others. Web services removes the need to run the same stack on both sides… you can disagree about everything in computing as long as you agree on the documents, (Schema) and the business arrangements around those documents… I expect you send an acknowledgement after you ship the widget from your warehouse. Tie this back to the business discussion… Businesses need to be more flexible, IT needs to be more flexible. Operating System Operating System Schema Application Server Application Server

14 Basic Standards

15 SOAP Web Service

16 SOAP: Expansível Informação extra Opcional Qualificável
soap:Header vs soap:Body Opcional soap:mustUnderstand Qualificável soap:role (soap:actor in SOAP 1.1) From its earliest incarnations dating back to 1998, SOAP has focused on providing mechanisms for mixing application and infrastructure protocols. Moreover, the W3C SOAP 1.2 specification explicitly separates these mechanisms from other aspects of the protocol, such as data encoding and HTTP bindings. Part I of the SOAP 1.2 specification provides a message-processing model that is the kernel of the GXA architecture. SOAP messages are XML documents that adhere to a predefined schema. This schema defines a framing convention in which the primary payload of the message (called the body) may be augmented by zero or more auxiliary pieces of XML called headers. Consider the following SOAP 1.1 message: <soap:Envelope xmlns:soap=" xmlns:ns1=" xmlns:ns2=" xmlns:ns3="urn:schemas-acme-com:pvr.v1" > <soap:Header> <ns1:preferences> <genre>Noir</genre> <format>WMV</format> </ns1:preferences> <ns2:priority> <level>low</level> </ns2:priority> </soap:Header> <soap:Body> <ns3:Record> <channel>11</channel> <start> T08:00:00-8:00</start> <duration>P30M</duration> </ns3:Record> </soap:Body> </soap:Envelope> In this example, the Record element is the body of the message. The preferences and priority elements are each distinct message headers. In the parlance of GXA, the SOAP body conveys information specific to an application protocol; the header elements convey information that is part of an infrastructure protocol. SOAP headers are strongly typed and each header's role is determined by its namespace-qualified element name. To allow new header types to be introduced over time, SOAP provides explicit support for marking headers as either optional or mandatory via the soap:mustUnderstand attribute. Headers are marked as mandatory to indicate that the message as a whole cannot be properly (or safely) interpreted without also processing the mandatory header. SOAP provides a well-known fault code to indicate that an unrecognized header was encountered. In contrast, optional headers may be safely ignored by software that doesn't recognize the header's element type. Optional headers often convey advisory information about the message. Mandatory headers often convey critical aspects of the message, such as digital signatures, transaction identifiers, etc. The following SOAP message carries two headers: one optional header and one mandatory header. <soap:Envelope xmlns:soap=" xmlns:ns1=" xmlns:ns2=" xmlns:ns3="urn:schemas-acme-com:pvr.v1" > <soap:Header> <ns1:preferences soap:mustUnderstand='1'> <genre>Noir</genre> <format>WMV</format> </ns1:preferences> <ns2:priority> <level>low</level> </ns2:priority> </soap:Header> <soap:Body> <ns3:Record> <channel>11</channel> <start> T08:00:00-8:00</start> <duration>P30M</duration> </ns3:Record> </soap:Body> </soap:Envelope> In this example, the preferences header is a mandatory header, as it carries a soap:mustUnderstand attribute with a value of "1." The recipient of this message is required to recognize this header and properly process it according to the corresponding header-specific protocol. If the header cannot be processed because the receiver has no a priori knowledge of the header, then a SOAP fault message must be returned indicating as much. For many SOAP headers, the namespace-qualified element name is sufficient to convey the intention of the sender. In some circumstances, an additional identifier is needed to identify exactly which piece of software is expected to process the message. Rather than push this identifier into each header type that needs this functionality, SOAP formalizes the idea via its soap:role attribute (called soap:actor in SOAP/1.1). SOAP header elements may carry a soap:role attribute whose value is simply an opaque URI. How that URI is processed is dependent on the node that is processing the message.

17 Exemplo: Composição Addressing Security Reliability
<S:Envelope … > <S:Header> <wsa:ReplyTo> <wsa:Address> </wsa:ReplyTo> <wsa:To> <wsa:Action> <wssec:Security> <wssec:BinarySecurityToken ValueType="wssec:X509v3" EncodingType=“wssec:Base64Binary">      dWJzY3JpYmVyLVBlc…..eFw0wMTEwMTAwMD </wssec:BinarySecurityToken> </wssec:Security> <wsrm:Sequence>zzz <wsu:Identifier> <wsrm:MessageNumber>10</wsrm:MessageNumber> </wsrm:Sequence> </S:Header> <S:Body> <app:TrafficStatus xmlns:app=" <road>520W</road><speed>3MPH</speed> </app:TrafficStatus> </S:Body> </S:Envelope> Addressing Security Here’s a great example of how this works. In this case, the developer can swap routing and security in and out of the SOAP envelop. Think Modularity! Reliability

18 Web Services Basic Standards Stack
UDDI (discovery) WSDL (API description) SOAP (messaging) XML (lingua franca) The standards at the heart of basic Web services—XML, SOAP, XSD, WSDL, and UDDI—provide enough functionality to build simple distributed systems. There are lots of toolkits that support these protocols, mapping them to a range of programming models, from raw XML messaging to method invocations against objects. While the basic Web service standards are necessary, they are not sufficient for building complex applications. For instance, there is no standard approach to building secure Web services. If you want to build a secure Web service, you have to roll your own solution. Most people rely on the security infrastructure of their service's underlying transport protocol, typically HTTP. HTTP (transport)

19 Limitações actuais: Segurança? Garantias de Entrega? Transacções?
Outros Transportes? Mensagens Assíncronas (One-Way)? Encaminhamento (Routing/Addressing)? Outros padrões (Ex: Pub/Sub)?

20 Web Services Security Roadmap
Authorization Federation SecureConversation Privacy Trust Policy Hoje Security SOAP Foundation Security in a Web Services World – IBM/MSFT White Paper Abril 2002 WS-Security Specification

21 Novos Protocolos

22 Web Services Protocols (WS-*)
Messaging Specifications SOAP WS-Addressing MTOM (Attachments) WS-Eventing    Security Specifications WS-Security WS-SecureConversation WS-Trust WS-Federation WS-Federation Active Requestor Profile WS-Federation Passive Requestor Profile Web Services Security Kerberos Binding    Reliable Messaging Specifications WS-ReliableMessaging Transaction Specifications WS-Coordination WS-AtomicTransaction WS-BusinessActivity Metadata Specifications WSDL UDDI WS-Policy WS-PolicyAssertions WS-PolicyAttachment WS-SecurityPolicy XML Specifications XML Namespaces in XML XML Information Set XInclude    Connected Applications Business Process Management … Security Reliability Transactions Metadata I was a bit apprehensive about putting this slide in this deck; but, I want everyone to know that these additional standards being worked on today represent a great body of work and solve most if not all the problems that occur when organizations try to connect their applications across different trust boundaries. These specifications pick up where the basic specifications left off and once complete will allow Web Services to be used for application-to-application integration between organizations with different management, infrastructure, and trust domains. Advanced Web Services Messaging XML HTTP TCP SMTP …

23 WS-* Objectivos Arquitectura Resultados tangíveis Modular/Composable
De Aplicabilidade Genérica (B2B, EAI, Devices) Baseado em Standards Modelo Federado Resultados tangíveis Qualidade no desenvolvimento Adopção generalizada por todos os intervenientes do mercado Rápido time-to-market Stress that Federation has implications about trust and about the needed flexibility in the security infrastructure. Federated means - Fully distributed, Crosses organization and trust domains, Can be inspected by firewalls, Does not require centralized servers or administration, Will sometimes require “edge” software to do protocol translation, security work, routing, etc. On specifications: the intersection of domains gives rise to the versioning problem and the difference of their domains gives rise to the composition problem. Say that one has a specification A and a new specification B appears. We say that specification A and specification B compose if the if the features specified in B operate without any modification in specification A. This means that the domain of the features in B to not intersect with the domain of the features in A.

24 Novas especificações (1)
WS-Security – protecção via integridade, confidencialidade e autenticação directamente na mensagem XML (XML-SIG, XML-ENC) WS-Security WS-SecureConversation WS-Trust WS-Federation WS-Policy – descrição e comunicação das políticas de utilização de WS WS-SecurityPolicy WS-PolicyAssertions WS-PolicyAttachment WS-Security Specification Index Page Brief WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. These mechanisms can be used to accommodate a wide variety of security models and encryption technologies. WS-Security also provides a general-purpose mechanism for associating security tokens with messages. However, no specific type of security token is required by WS-Security. It is designed to be extensible (that is, support multiple security token formats). For example, a client might provide proof of identity and proof that it has a particular business certification. Additionally, WS-Security describes how to encode binary security tokens. Specifically, the specification describes how to encode X.509 certificates and Kerberos tickets, as well as how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics of the credentials that are included with a message. The Web Services Security Addendum describes clarifications, enhancements, best practices, and errata of the WS-Security specification. The Web Services Security Profile for XML-based Tokens describes how to use XML-based tokens such as the Security Assertion Markup Language (SAML) or the eXtensible rights Markup Language (XrML) with the WS-Security specification. WS-Trust defines extensions that build on WS-Security to request and issue security tokens and to manage trust relationships. WS-SecureConversation defines extensions that build on WS-Security to provide secure communication. Specifically, we define mechanisms for establishing and sharing security contexts, and deriving session keys from security contexts. WS-SecurityPolicy is an addendum to WS-Security and indicates the policy assertions for WS-Policy that apply to WS-Security. The Web Services Security AppNotes provide guidance and additional examples to implementers of the WS-Security specification. WS-Policy Specification Index Page The Web Services Policy Framework (WS-Policy) provides a general-purpose model and corresponding syntax to describe and communicate the policies of a Web service. WS-Policy defines a base set of constructs that can be used and extended by other Web services specifications to describe a broad range of service requirements, preferences, and capabilities. WS-PolicyAssertions specifies a set of common message policy assertions that can be specified within a policy. WS-PolicyAttachment specifies three specific attachment mechanisms for using policy expressions with existing XML Web service technologies. Specifically, we define how to associate policy expressions with WSDL type definitions and UDDI entities. We also define how to associate implementation-specific policy with all or part of a WSDL portType when exposed from a specific implementation.

25 Novas especificações (2)
WS-Addressing – Virtualização dos endpoints para cada serviço WS-Addressing WS-Eventing Attachments - Message Transmission Optimization Mechanism MTOM WS-Security Specification Index Page Brief WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. These mechanisms can be used to accommodate a wide variety of security models and encryption technologies. WS-Security also provides a general-purpose mechanism for associating security tokens with messages. However, no specific type of security token is required by WS-Security. It is designed to be extensible (that is, support multiple security token formats). For example, a client might provide proof of identity and proof that it has a particular business certification. Additionally, WS-Security describes how to encode binary security tokens. Specifically, the specification describes how to encode X.509 certificates and Kerberos tickets, as well as how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics of the credentials that are included with a message. The Web Services Security Addendum describes clarifications, enhancements, best practices, and errata of the WS-Security specification. The Web Services Security Profile for XML-based Tokens describes how to use XML-based tokens such as the Security Assertion Markup Language (SAML) or the eXtensible rights Markup Language (XrML) with the WS-Security specification. WS-Trust defines extensions that build on WS-Security to request and issue security tokens and to manage trust relationships. WS-SecureConversation defines extensions that build on WS-Security to provide secure communication. Specifically, we define mechanisms for establishing and sharing security contexts, and deriving session keys from security contexts. WS-SecurityPolicy is an addendum to WS-Security and indicates the policy assertions for WS-Policy that apply to WS-Security. The Web Services Security AppNotes provide guidance and additional examples to implementers of the WS-Security specification. WS-Policy Specification Index Page The Web Services Policy Framework (WS-Policy) provides a general-purpose model and corresponding syntax to describe and communicate the policies of a Web service. WS-Policy defines a base set of constructs that can be used and extended by other Web services specifications to describe a broad range of service requirements, preferences, and capabilities. WS-PolicyAssertions specifies a set of common message policy assertions that can be specified within a policy. WS-PolicyAttachment specifies three specific attachment mechanisms for using policy expressions with existing XML Web service technologies. Specifically, we define how to associate policy expressions with WSDL type definitions and UDDI entities. We also define how to associate implementation-specific policy with all or part of a WSDL portType when exposed from a specific implementation.

26 Novas especificações (3)
WS-Coordination coordenação das acções de sistemas distribuídos. Por exemplo o acordo no resultado de uma transacção em vários sistemas WS-AtomicTransaction WS-BusinessActivity tipos de coordenação: Atomic Transaction (AT) and Business Activity (BA). WS-ReliableMessaging Garantia de entrega, uma e uma só vez BPEL4WS gestão de processos e protocolos de interacção (BPM) WS-Coordination Specification Index Page Brief This specification (WS-Coordination) describes an extensible framework for providing protocols that coordinate the actions of distributed applications. Such coordination protocols are used to support a number of applications, including those that need to reach consistent agreement on the outcome of distributed transactions. The framework defined in this specification enables an application service to create a context needed to propagate an activity to other services and to register for coordination protocols. The framework enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary protocols and to operate in a heterogeneous environment. BPEL4WS provides a language for the formal specification of business processes and business interaction protocols. By doing so, it extends the Web services interaction model and enables it to support business transactions. BPEL4WS defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intracorporate and the business-to-business spaces. WS-Transaction Specification Index Page This specification describes coordination types that are used with the extensible coordination framework described in the WS-Coordination specification. It defines two coordination types: Atomic Transaction (AT) and Business Activity (BA). Developers can use either or both of these coordination types when building applications that require consistent agreement on the outcome of distributed activities.

27

28 WS-* Workshop Process Processo de desenvolvimento de novas especificações

29 WS Architecture Evolution Secure, Reliable, Transacted
July 2003 WS-Federation March 2003 WS-ReliableMessaging WS-Addressing RM Roadmap April 2002 WS-Security and Security Roadmap September 2003 WS-AtomicTransaction WS-Coordination SRT WS Whitepaper December 2002 WS-Policy WS-Trust WS-SecureConversation UDDI SOAP WS-I August 2002 WS-Transaction WS-Coordination 2000 WSDL

30 Web Services Specifications Process
Specification Published Feedback and Interop Workshops Revise spec Standards Org WS-I Publish specs, gather feedback through workshops, demonstrate interoperability, build tools and implementations, take to a standards body Help provide feedback!! Participation

31 WS-Security demonstrou sucesso do processo
Specification Published Customer and Industry Feedback Gathered Publish Addendum, Deliver Dev Product OASIS Standardization WS-I Interoperability Profile April 2002 April - August 2002 August 2002 September 2002 April 2003 Three Partners Over 30 Partners Over 100 Partners

32 Interoperability Events & Workshops
Nov 2003 WS-Trust WS-SecureConversation (workshop) September 2003 Bill Gates (Microsoft) Steve Mills (IBM) TBD 2004 WS-Federation (workshop) SOAP Builders 2002 December 2002 CDBi - EMEA October 2003 WS-ReliableMessaging (workshop) Interoperability Workshops WS-ReliableMessaging (interoperability) – October 2003, IBM, Raleigh, NC Attendees: 21 people, 7 implementations Results achieved: Achieved interoperability among all implementations Also completed additional test scenarios defined during the workshop meeting itself Generated feedback for the specification authors Some clarifications of minor areas in the specs, but no flaws in the basic design of the specifications identified WS-SecureConversation and Trust (interoperability) – November 2003, VeriSign, Mountain View, CA Attendees: 20 people, 4 implementations (RSA, Systinet, IBM, MS, Verisign) After resolving some minor issues with the scenarios, achieved interoperability among all implementations Generated some feedback for the specification authors Interoperability demonstrations XML Web Services One East - August/ WS-Security CBDi December/2002 – WS-Security, .NET and WebSphere ( is the source) Catalyst/Burton – July 2003 (7/10) – WS-Security, WS-Federation, WS-Trust (passive and active clients), WS-RM Gates/Mills – September 2003 – Burton + more RM + WS-Coordination, WS-AtomicTransaction OASIS – September security July 2003 Catalyst (Burton conference) September 2003 OASIS WS-Security August 2002 XML Web Services One (East)

33 Feedback Workshops November 2003 2002 TBD 2004 WS-Transaction
July 2003 WS-ReliableMessaging February 2003 WS-Policy and WS-Trust TBD 2004 WS-Policy November 2003 WS-Federation 2002 March 2003 WS-Policy and WS-Trust Feedback Workshops WS-Policy and WS-Trust (feedback) – February 2003, Where: Microsoft, Redmond, WA Attendees: 28 people, 14 companies Topics discussed: eXtensible Access Control Markup Language – Overview, Anthony Nadalin, IBM Corporation eXtensible Access Control Markup Language – Requirements, Anthony Nadalin, IBM Corporation  Policy and Metadata Requirements, Maryann Hondo, IBM Corporation Security Policy – Requirements, Phillip Hallam-Baker, VeriSign, Inc.   Policy, Mark Nottingham, BEA Systems, Inc., Maryann Hondo, IBM Corporation, Don Box, Microsoft Corporation WS-SecurityPolicy—Solutions and Approach, Phillip Hallam-Baker, VeriSign, Inc.  Trust and Secure Conversation, Chris Kaler, Microsoft Corporation  WS-Trust Specification – Overview, Anthony Nadalin, IBM Corporation WS-SecureConversation Specification – Overview, Anthony Nadalin, IBM Corporation WS-Policy and WS-Trust (feedback) - March 2003, Where: IBM, Palisades, NY Attendees: 31 people, 15 companies Example Policy Scenario - Collaborative Business Policy, Claus von Riegen, SAP, Inc. Example Policy Scenarios - Privacy and Policy, Mark Nottingham, BEA Systems, Inc. Reliable Messaging, Chris Ferris, IBM Corporation                        Policy Updates, Maryann Hondo, IBM Corporation, Don Box, Microsoft Corporation, Claus von Riegen, SAP Inc. Best Practices for Policy, Mark Nottingham, BEA Systems, Inc. Direct Trust and Key Exchange, Phillip Hallam-Baker, VeriSign, Inc.  Ad-Hoc Comments on Security Specifications, John Linn, RSA Security, Inc. WS-ReliableMessaging (feedback) – July 2003 Where: Microsoft, Redmond, WA Attendees: 27 people, 11 companies Introduction/Web Services Architecture, Omri Gazitt, Microsoft Corporation Reliable Messaging Scenarios, Rodney Limprecht, Microsoft Corporation WS-ReliableMessaging Protocol Overview and Walkthrough, Dave Orchard, BEA Systems, Inc. Reliable Messaging and Security Demo, Chris Ferris, IBM Corporation WS-ReliableMessaging Scalability and Durability John Dart, TIBCO Software, Inc. WS-Federation (feedback) –November 2003 4 message exchanges flying around to create a secure channel and a dialog beyond that 35 Attendees from 15 different companies

34

35 WS-* Specifications Timeline
NEED BPEL4WS on this slide. Greyed out - superseded by another spec Green - expected

36 Boas Práticas WS-I.ORG

37 www.ws-i.org 170+ fabricantes software envolvidos
Interoperabilidade entre plataformas, aplicações e linguagens Maior evidência de que a indústria está alinhada com os web services

38

39 Um slide do Patrocinador 

40 Framework (Microsoft)
ASP.NET Web Services Web Service Enhancements Indigo

41 Web Services Enhancements 2.0 Segurança
Company A Credit Card Web Browser HTML User Interface Let’s go back to Company A and investigate a more complicated - but very typical – scenario. Let’s look at an eCommerce scenario where we have Credit card processing, inventory management and shipping. In a perfect world the eClient has sufficient credit, the item is in stock and you can ship immediately. However … What if you call all these WS at once and the client has bad credit? What if your warehouse does not have the item in stock? What if you no longer carry the item? What if for some reason your shipping company can not ship for several weeks? This is why we need additional standards. Note I did not say new standards. SOAP, WSDL, and UDDI are here to stay. Business Logic SOAP Authentication - HTTP Integrity - HTTPS SOAP Database Confidentiality - HTTPS

42 Web Services Enhancements 2.0 WS-Security
<soap:Envelope xmlns:soap=“ .. <soap:Header> <wsse:Security soap:mustUnderstand="1"> …Security Tokens… …Digital Signatures… …Key Identifiers… </wsse:Security> </soap:Header> <soap:Body> <! -- Message goes here. -- > </soap:body> </soap:Envelope>

43 Web Services Enhancements 2
Web Services Enhancements 2.0 O problema do endereçamento/encaminhamento Apenas serviços públicos podem receber mensagens Existe um intermediário para serviços internos Firewall Company A Firewall Company B Public Service Private Service Private Service X

44 Web Services Enhancements 2.0 WS-Addressing
To = From = [protected process] ReplyTo = Firewall Company A Joe’s Mailbox Firewall Company B One-Way SMTP SOAP Protected Process Protected Process Alice’s Mailbox

45 Web Services Enhancements 2.0 WS-Addressing
<soap:Envelope xmlns:soap=“ .. <soap:Header> <wsa:Action … </wsa:Action> <wsa:To ...</wsa:To> <wsa:From ...</wsa:From> <wsa:ReplyTo ...</wsa:ReplyTo> <wsa:TimeStamp ...</wsa:TimeStamp> </soap:Header> <soap:Body> <! -- Message goes here. -- > </soap:body> </soap:Envelope>

46 Web Services Enhancements 2.0 WS-Addressing (WS-Eventing)
To = From = [protected process] ReplyTo = soap.tcp//machine:3131/action One-Way HTTP SOAP SOAP HTTP MyStore Web Service Firewall Company A Browser, Service, Desktop, Or Device Order Monitor SOAP TCP Port = 3131

47 Web Service Enhancements 2.0 Lista de funcionalidades
Modelo programação orientado a Mensagens Suporte para variados hosts WS-Addressing WS-Policy WS-Security WS-SecurityPolicy WS-SecureConversation WS-Trust Download, Documentação e Anúncios: Web Services Enhancements (WSE) 2.0 Technology Preview The technology preview of WSE 2.0 provides early access to new advanced Web services capabilities. New features include a policy framework, enhanced security model, message-oriented programming model, and support for multiple hosting environments. Overview About WSE Web Services Enhancements for Microsoft® .NET (WSE) is an add-on to Microsoft Visual Studio® .NET and the Microsoft .NET Framework providing developers the latest advanced Web services capabilities to keep pace with the evolving Web services protocol specifications. About WSE 2.0 Technology Preview The technology preview of WSE 2.0 is unsupported and is not licensed for production use. WSE 2.0 Technology Preview builds on the security, routing, and attachments capabilities with new features including a policy framework, enhanced security model, message-based programming model, and support for multiple hosting environments. WSE 2.0 simplifies coding by enabling developers and administrators to apply security policies on Web services running on the Microsoft .NET Framework. Web services communication can be signed and encrypted using Kerberos tickets, X.509 certificates, username/password credentials, and other custom binary and XML based security tokens. WSE's enhanced security model provides a policy-driven foundation for securing Web services across trust domains. A Trust issuing service can be established for retrieving and validating security tokens. A secure conversation can also be established by parties so that authentication and authorization of calls within a session can happen more quickly than more complex cryptographic operations. The new message-oriented programming model enables asynchronous communication for Web services implementations that require support for long lived operations, batch processing, peer to peer programs, or event driven application models. Web services that leverage WSE can now be hosted in multiple environments including ASP.NET, standalone executables, NT Services, etc. and can communicate over alternative transports including HTTP or TCP. WSE provides a foundation for building applications based on Web services specifications published by Microsoft and industry partners including WS-Security, WS-Policy, WS-SecurityPolicy, WS-Trust, WS-SecureConversation and WS-Addressing. System Requirements Supported Operating Systems: Windows 2000, Windows Server 2003, Windows XP Microsoft Windows XP Professional with Service Pack 1 or later Microsoft Windows 2000 Server with Service Pack 3 or later Microsoft Windows 2000 Advanced Server with Service Pack 3 or later Microsoft Windows 2003 Server Hardware requirements: Processor Pentium 233 MHz; recommended: Pentium 300 MHz or faster RAM 64 MB; recommended: 128 MB or higher Additional Software: Microsoft Internet Information Services (IIS) 5.0 or later One of the following: Microsoft .NET Framework SDK version 1.0 with Service Pack 2 or later Microsoft .NET Framework SDK version 1.1. Microsoft Visual Studio .NET Microsoft Visual Studio .NET 2003

48 sumário Service-Orientation Desacoplados Bem limitados/Autónomos
Partilhar apenas Contratos/Politica Composição de protocolos WS-* Processo Ágil de desenvolvimento de novas specs Interoperabilidade aplicando as recomendações do WS-I.ORG

49 Referências Microsoft Weblogs MSDN Portugal
Microsoft Patterns & Practices WS-* specs Weblogs Don Box (Microsoft) Clemens Vasters (Newtelligence AG) LooselyCoupled.com Canoas’blog (o meu !)

50 © 2003-2004 Microsoft Corporation. All rights reserved.
Obrigado  © Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.