 |
An approach to moving industry business messaging standards to Web services
The authors of this whitepaper show you how you can integrate various industry standards-based business messaging systems such as CIDX, OAGi, PIDX, and RosettaNet Web services technology at both the message and document levels.
|
| |
BPELJ: BPEL for Java technology
BPELJ is a combination of Business Process Execution Language (BPEL) and the Java programming language, allowing the two languages to be used together to build business process applications.
|
| |
Business Information Conformance Statements (BICS) 2
The Business Information Conformance Statement specifications define information constraints for service information exchanged by business-to-business (B2B) communications in a Service-Oriented Architecture (SOA) environment.
|
| |
Business Information Conformance Statements (BICS) 2
The Business Information Conformance Statement (BICS) specifications define information constraints for service information exchanged by business-to-business (B2B) communications in a Service-Oriented Architecture (SOA) environment. The BICS 2 specifications describe the core XML framework (BICS 2 core framework) and three constraint mechanisms: W3C XML Schema Constraint Mechanism (WXSCM), Schematron Schema Constraint Mechanism (SSCM), and MIME Constraint Mechanism (MCM).
|
| |
Business Process Execution Language for Web Services version 1.1
Business Process Execution Language for Web Services provides a means to formally specify business processes and interaction protocols.
|
| |
Common Base Event
The Common Base Event specification defines a new mechanism for managing events in business enterprise applications and how to communicate self-healing events in the Autonomic computing model.
|
| |
Common Base Event
The Common Base Event specification defines a new mechanism for managing events in business enterprise applications in the Autonomic computing model.
|
| |
DNS Endpoint Discovery (DNS-EPD)
DNS-EPD introduces a process for resolving the location of common services that is similar in nature to using the telephone white pages directory. With DNS-EPD, if a client wishes to locate a specific instance of a Web service, it would go to DNS and resolve the current location of that service by name. A second key issue is that once a Web service's location has been resolved, how can one automatically detect changes that may occur in the configuration and deployment of those services? DNS-EPD's approach is to assign names to services and to allow components a means of using those names to dynamically resolve - at run-time - the metadata necessary to access those resources, allowing applications to intelligently respond to changes and promoting loose coupling between applications and the supporting infrastructure.
|
| |
Definition languages for RESTful Web services: WADL vs. WSDL 2.0
There are two specifications for describing interfaces of HTTP-based Web applications: Web Application Description Language (WADL) and the Web Services Description Language (WSDL) 2.0 HTTP binding extension. These two languages are very similar, but there are some differences. This white paper provides an unbiased, objective comparison of the two technologies, highlighting both the differences and similarities between WADL and the WSDL 2.0 HTTP binding.
|
| |
Definition languages for RESTful Web services: WADL vs. WSDL 2.0
There are two specifications for describing interfaces of HTTP-based Web
applications:
Web Application Description Language (WADL) and the Web Services Description
Language (WSDL) 2.0 HTTP binding extension. These two languages are very similar, but
there are some differences. This white paper (see below) provides an unbiased, objective comparison
of the two technologies, highlighting both the differences and similarities between WADL and
the WSDL 2.0 HTTP binding.
|
| |
Enterprise Service Bus (ESB) Interoperability Standards
This white paper outlines the specific standards used to achieve ESB interoperability. These include the standards for message transfer (HTTP and HTTPS), message formats and protocols (SOAP), and identity or location (WS-Addressing). See a number of scenarios that illustrate how you can use a standards-based approach to satisfy specific customer use-case requirements. And get an understanding of the relationship with existing WS-I profiles and the work necessary to define additional profiles related to ESB.
|
| |
Enterprise Service Bus (ESB) Interoperability Standards
Read about the concepts and capabilities of the Enterprise Service Bus (ESB) and the standards that deliver the value of an ESB in a heterogeneous environment.
|
| |
Evolving Web services standards for managing system resources
In response to our customers asking us to resolve their concerns with competing management specifications, IBM, Microsoft, HP and Intel are planning to develop a common set of specifications for resources, events, and management that can be broadly supported across multiple platforms. To support the launch of this work the participants have jointly developed a Roadmap which outlines a plan to develop a harmonized set of specifications, with provisions for a smooth migration to the new specifications as they emerge and move through to standardization.
|
| |
From Open Grid Services Infrastructure to WS-Resource Framework: Refactoring and Evolution
This paper explain the relationship between OGSI and WSRF and the related WS-Notification specifications, the common requirements that both address, and compares and contrasts the approaches taken to the realization of those requirements.
|
| |
From Web interfaces to native code
This white paper details the basics of implementing Java 2 Platform, Enterprise Edition (J2EE) Connector Architecture (JCA) with managed connections and inbound resource adaptation. It also describes two different means to access and drive native instrumentation services: the Java Native Interface (JNI) and a Surrogate Process/Inter-Process Communication (IPC).
|
| |
IBM Basic B2B Profile
The IBM Basic Business-to-Business (B2B) Profile 1.0 is a profile that, in the fashion of the WS-I profiles, enables basic B2B integration scenarios using Web services technologies.
|
| |
IBM Basic B2B Profile
The IBM Basic Business-to-Business (B2B) Profile 1.0 is a profile that, in the fashion of the WS-I profiles, enables basic B2B integration scenarios using Web services technologies.
|
| |
IBM SOA Foundation: An architectural introduction and overview
This paper introduces the SOA Foundation as defined by IBM and explains IBM's view of what Service-Oriented Architecture is about. It also provides a high-level description of the architecture with a focus on its lifecycle model, logical architecture, programming model, and physical architecture. It goes on to provide some insight to the roadmaps for becoming a SOA-enabled enterprise and the role of SOA Governance in making SOA operational in your enterprise. It also acts as a guide to a wealth of SOA-related resources.
|
| |
Information integration services
In this series of whitepapers we will provide a comparison of Web services
technologies, followed by a study of different Web services types for integration
specific problems, provided both by IBM WebSphere SOA Edition and IBM Rational
Application Developer. Finally we will outline an SOA case study, which will use Web
service technology for Information Services, and at the same time, indicate that
Information Services are only components in an overall SOA architecture.
|
| |
JSR 172: J2ME Web services
This J2ME specification is designed to provide an infrastructure for basic XML processing capabilities, enable reusable Web services for J2ME clients, APIs for programming enterprise services in J2ME clients, enable interoperability with other services, and provide a consistent programming model for J2ME client communication for Web services consistent with that for other Java clients.
|
| |
JSR-235 Service Data Objects
The Java Specification JSR-235 defines the Service Data Object (SDO 2.1.1) API. This API enables application developers to uniformly access and manipulate data from heterogeneous data sources.
|
| |
JSR109 (Web services for J2EE) 0.3
Web Services for J2EE architecture is a service architecture which leverages the J2EE component architecture to provide a decoupled client and server programming model which is portable across application servers, provides a scalable secure environment, and yet is familiar to J2EE developers.
|
| |
MTOM Serialization Policy Assertion (WS-MTOMPolicy) Version 1.0
IBM and Microsoft have collaborated on MTOM Serialization Policy Assertion (WS-MTOMPolicy).
|
| |
Modeling stateful resource with Web services
This paper explains how the Web Services Resource Framework is structured and how it operates.
|
| |
Proposal for a CIM mapping to WSDM
This document describes a proposal for how to represent Common Information Model (CIM)-modeled resources as Web Services Distributed Management (WSDM) Manageable Resource Web services. It describes how to represent and access the content of the CIM model using Web services, WS-Resource Framework, WS-Notification specifications, and WSDM. This draft proposal has been submitted for consideration by the Distributed Management Task Force (DFTM).
|
| |
Reliable Asynchronous Messaging Profile 1.0
The Reliable Asynchronous Messaging Profile (RAMP) 1.0 is a profile, in the fashion of the WS-I profiles, that enables, among other things, basic B2B integration scenarios using Web services technologies.
|
| |
Reliable Asynchronous Messaging Profile 1.0
The Reliable Asynchronous Messaging Profile (RAMP) 1.0 is a profile, in the fashion of the WS-I profiles, that enables, among other things, basic B2B integration scenarios using Web services technologies.
|
| |
SOAP (Simple Object Access Protocol) 1.1
SOAP is a lightweight XML-based protocol for exchange of information in a decentralized, distributed environment. SOAP can potentially be used in combination with a variety of protocols. However, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework.
|
| |
SOAP (Simple Object Access Protocol) 1.2
This is an updated release (on 2003-06-24) of the SOAP protocol specification, the foundation delivery protocol for Web services. The changes between the prevalent version 1.1 and the newer 1.2 are in modified and new syntax, modified SOAP to HTTP binding, refined RPC behavior, and a new model for SOAP encoding data model.
|
| |
SOAP 1.1 Binding for MTOM 1.0 and WSDL 1.1 Binding Extension for SOAP 1.2
The following two specifications provide direction on SOAP bindings, and are authored with IBM, Microsoft, Oracle, and SAP.
|
| |
Security in a Web Services World: A Proposed Architecture and Roadmap
This document describes a proposed strategy for addressing security within a Web service environment. It defines a comprehensive Web service security model that supports, integrates and unifies several popular security models, mechanisms, and technologies (including both symmetric and public key technologies) in a way that enables a variety of systems to securely interoperate in a platform- and language-neutral manner. It also describes a set of specifications and scenarios that show how these specifications might be used together.
|
| |
Service Component Architecture
In response to requests from customers and Independent Software Vendor (ISV) partners, BEA, Cape Clear, IBM, Interface21, IONA, Oracle, Primeton Technologies, Progress Software, Red Hat., Rogue Wave, SAP, Siemens, Software AG, Sun, Sybase and TIBCO are collaborating on specifications for building systems that use a Service-Oriented Architecture (SOA), which aim to provide developers with simpler and more powerful ways of constructing applications based on SOA. These specifications are published under royalty-free terms.
|
| |
Service Component Architecture
Service Component Architecture (SCA) is a set of specifications that describe a model for building applications and systems using a Service-Oriented Architecture. SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services. These specifications are published under royalty-free terms.
|
| |
Service Component Architecture
In response to requests from customers and Independent Software Vendor (ISV) partners, BEA, IBM, IONA, Oracle, SAP, Siebel Systems, and Sybase are collaborating on specifications for building systems that use a Service-Oriented Architecture (SOA), which aim to provide developers with simpler and more powerful ways of constructing applications based on SOA. These specifications are published under royalty-free terms.
|
| |
Service Components Architecture (SCA) and Service Development Objects (SDO)
submitted to OASIS
This white paper provides a status of the SCA and SDO specifications that
have been submitted to OASIS.
|
| |
Service Data Objects
In response to requests from customers and joint Independent Software Vendor (ISV) partners, BEA, IBM, Oracle, Primeton Technologies, Rogue Wave, SAP, Software AG, Sun, Sybase, Xcalia and Zend are collaborating on specifications for building systems that use a Service-Oriented Architecture (SOA), which aim to provide developers with simpler and more powerful ways of constructing applications based on SOA. These specifications are published under royalty-free terms.
|
| |
Service Data Objects
Service Data Objects (SDO) is designed to simplify and unify the way in which applications handle data. Using SDO, application programmers can uniformly access and manipulate data from heterogeneous data sources, including relational databases, XML data sources, Web services, and enterprise information systems. The SDO specifications are published under royalty-free terms.
|
| |
Service Data Objects, WorkManager, and Timers
In response to requests from customers and joint Independent Software Vendor (ISV) partners, IBM and BEA are collaborating on specifications for programming models and APIs for Java 2 Enterprise Edition (J2EE) application servers that provide programmers with simpler and more powerful ways of building portable server applications. Three specifications have been published under royalty-free terms and will be implemented in upcoming releases of WebSphere Application Server and of the WebLogic Platform.
|
| |
Specifications: Service Component Architecture (SCA) and Service Data Objects (SDO)
In response to requests from customers and Independent Software Vendor (ISV) partners, IBM is jointly delivering two specifications for building systems that use a Service-Oriented Architecture (SOA), which aim to provide developers with simpler and more powerful ways of constructing applications based on SOA: Service Component Architecture (SCA) and Service Data Objects (SDO).
|
| |
Superceded: Web Services Resource Framework
The Web Services Resource Framework defines a system for creating stateful resources between Web services in terms of an implied resource pattern.
|
| |
The Common Base Event specification and the IBM Common Event Infrastructure
A growing number of IBM foundation products and Business Partner applications are adopting the Common Base Event (CBE) format to leverage the IBM Common Event Infrastructure (CEI), a set of modular event-processing components that are designed to simplify event management. By providing a standard, consistent format for the creation and sharing of a wide range of events, the CBE works with CEI to provide any application that uses it with the ability to consolidate event information to quickly and efficiently communicate what is occurring in end-users’ businesses.
|
| |
The Common Base Event specification and the IBM Common Event Infrastructure
A growing number of IBM foundation products and Business Partner applications are adopting the Common Base Event (CBE) format to leverage the IBM Common Event Infrastructure (CEI), a set of modular event-processing components that are designed to simplify event management. By providing a standard, consistent format for the creation and sharing of a wide range of events, the CBE works with CEI to provide any application that uses it with the ability to consolidate event information to quickly and efficiently communicate what is occurring in end-users’ businesses.
|
| |
The WS-Resource Framework
This whitepaper introduces the WS-Resource framework specifications that express the relationship between stateful resources and Web services.
|
| |
This is a test document. Please disregard.
This is a test document. Please disregard.
|
| |
UDDI (Universal Description, Discovery and Integration) 3.0
The focus of Universal Description Discovery and Integration (UDDI) is the definition of a set of services supporting the description and discovery of (1) businesses, organizations, and other Web services providers, (2) the Web services they make available, and (3) the technical interfaces which may be used to access those services. Based on a common set of industry standards, including HTTP, XML, XML Schema, and SOAP, UDDI provides an interoperable, foundational infrastructure for a Web services-based software environment for both publicly available services and services only exposed internally within an organization.
|
| |
Updated: Web Services Security Policy Language
The recently updated Web Services Security Policy Language (WS-SecurityPolicy) specification indicates the policy assertions which apply to Web Services Security: SOAP Message Security, WS-Trust, and WS-SecureConversation.
|
| |
WS-Addressing
WS-Addressing provides transport-neutral mechanisms to address Web services and messages. Specifically, this specification defines XML elements to identify Web service endpoints and to secure end-to-end endpoint identification in messages. This specification enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner.
|
| |
WS-AtomicTransactions
This specification provides the definition of the atomic transaction coordination type that is to be used with the extensible coordination framework described in the WS-Coordination specification. The specification defines three specific agreement coordination protocols for the atomic transaction coordination type: completion, volatile two-phase commit, and durable two-phase commit. Developers can use any or all of these protocols when building applications that require consistent agreement on the outcome of short-lived distributed activities that have the all-or-nothing property.
|
| |
WS-Attachments
This document defines an abstract model for SOAP attachments and based on this model defines a mechanism for encapsulating a SOAP message and zero or more attachments in a DIME message. SOAP attachments are described using the notion of a compound document structure consisting of a primary SOAP message and zero or more related documents known as attachments.
|
| |
WS-BPEL 2.0 Extensions for Sub-Processes
Designing complex and large business processes requires a language that
supports modularization and re-use in a portable, interoperable way. This white paper
outlines an extension to WS-BPEL that allows for the definition of sub-processes that
can be reused within the same or across multiple WS-BPEL processes. The white paper
also describes different invocation scenarios and introduces an appropriate coordination protocol used for interoperable invocation of sub-processes across infrastructures from different vendors.
|
| |
WS-BPEL Extension for People
Human user interactions are currently not covered by the Web Services Business Process Execution Language (WS-BPEL), which is primarily designed to support automated business processes based on Web services. However the spectrum of activities that make up general purpose business processes is broader than this, because people often participate in the execution of business processes. To support a broad range of scenarios involving people within business processes, a BPEL extension is required.
|
| |
WS-BaseNotification
WS-BaseNotification defines the Web services interfaces for NotificationProducers and NotificationConsumers. It includes standard message exchanges to be implemented by service providers that wish to act in these roles, along with operational requirements expected of them. This is the base specification on which the other WS-Notification specification documents depend. An implementer interested just in direct, point to point, notification need only read this WS-BaseNotification specification, together with the "Publish-Subscribe Notification for Web Services" white paper.
|
| |
WS-BrokeredNotification
WS-BrokeredNotification defines the Web services interface for the NotificationBroker. A NotificationBroker is an intermediary which, among other things, allows publication of messages from entities that are not themselves service providers. It includes standard message exchanges to be implemented by NotificationBroker service providers along with operational requirements expected of service providers and requestors that participate in brokered notifications. This work relies upon WS-BaseNotification and WS-Topics, as well as the "Publish-Subscribe Notification for Web Services" document.
|
| |
WS-BusinessActivity
This specification provides the definition of a business activity coordination type used to coordinate activities that apply business logic to handle business exceptions. Actions are applied immediately and are permanent. Compensating actions may be invoked in the event of an error. The BusinessActivity specification defines protocols that enable existing business process and work flow systems to wrap their proprietary mechanisms and interoperate across trust boundaries and different vendor implementations.
|
| |
WS-Coordination
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 activities.
|
| |
WS-Distributed Management: Proposal for a CIM mapping to WSDM
This document describes a proposal for how to represent Common Information Model (CIM)-modeled resources as Web Services Distributed Management (WSDM) Manageable Resource Web services. It describes how to represent and access the content of the CIM model using Web services, WS-Resource Framework, WS-Notification specifications, and WSDM. This draft proposal has been submitted for consideration by the Distributed Management Task Force (DFTM).
|
| |
WS-Eventing
This specification defines how Web Services Eventing supports the simplest levels of Web services interfaces for notification producers and consumers for a distributed event management system.
|
| |
WS-Experience Language (WSXL) 2.0
WSXL (Web Services Experience Language) is a Web services centric component model for interactive Web applications, that is, for applications that provide a user experience across the Internet. WSXL is designed to achieve two main goals: enable businesses to deliver interactive Web applications through multiple distribution channels and enable new services or applications to be created by leveraging other interactive applications across the Web.
|
| |
WS-Federation Language
This specification defines mechanisms to allow different security realms to federate by allowing and brokering trust of identities, attributes, authentication between participating Web services.
|
| |
WS-Federation: Active Requestor Profile
This specification defines how the cross trust realm identity, authentication and authorization federation mechanisms defined in WS-Federation are used by active requestors such as SOAP-enabled applications.
|
| |
WS-Federation: Active Requestor Profile
This document describes the issues around federated identity management and describes a comprehensive solution based on the Web services specifications outlined in the WS-Security roadmap and other related Web services specifications.
|
| |
WS-Federation: Passive Requestor Profile
The WS-Federation specification defines an integrated model for federating identity, authentication and authorization across different trust realms and protocols. This specification defines how the WS-Federation model is applied to passive requestors such as Web browsers that support the HTTP protocol.
|
| |
WS-Federation: Passive Requestor Profile
The WS-Federation specification defines an integrated model for federating identity, authentication and authorization across different trust realms and protocols. This specification defines how the WS-Federation model is applied to passive requestors such as Web browsers that support the HTTP protocol.
|
| |
WS-I Attachments Profile 1.0
WS-I Profiles are comprised of a set of named and versioned Web services specifications together with constraints and clarifications of the referenced specifications and interoperability guidelines recommending how the specifications may be used together to develop interoperable Web services. The WS-I Attachment Profile 1.0 is intended to be composed with the WS-I Basic Profile 1.1 and defines the conformance criteria for use of the WSDL1.1 MIME Binding extension and the SOAP Messages with Attachments specifications.
|
| |
WS-I Basic Profile 1.0
WS-I Profiles are comprised of a set of named and versioned Web services specifications together with constraints and clarifications of the referenced specifications and interoperability guidelines recommending how the specifications may be used together to develop interoperable Web services. The WS-I Basic Profile 1.0 is comprised of SOAP1.1, WSDL1.1, UDDI2.0, XML Schema 1.0, XML 1.0 (Second Edition) and HTTP1.1 as well as references to a few relevant IETF RFCs. It defines an interoperability profile for basic Web services (e.g. without advanced functionality such as might be provided by some of the other WS-* specifications being developed by IBM and Microsoft).
|
| |
WS-I Basic Profile 1.1
WS-I Profiles are comprised of a set of named and versioned Web services specifications together with constraints and clarifications of the referenced specifications and interoperability guidelines recommending how the specifications may be used together to develop interoperable Web services. The Basic Profile 1.1 specification is an update of the Basic Profile 1.0 standard, incorporating errata and providing for improved composability to enable multiple conformant bindings (see Simple SOAP Binding Profile 1.0 and Attachments Profile 1.0). It is comprised of the same set of underlying Web services specifications as Basic Profile 1.0.
|
| |
WS-I Simple SOAP Binding Profile 1.0
WS-I Profiles are comprised of a set of named and versioned Web services specifications together with constraints and clarifications of the referenced specifications and interoperability guidelines recommending how the specifications may be used together to develop interoperable Web services. The WS-I Simple SOAP Binding Profile 1.0 is intended to be composed with the WS-I Basic Profile 1.1 and defines the conformance criteria for the SOAP over HTTP binding.
|
| |
WS-Inspection 1.0
The WS-Inspection specification provides an XML format for assisting in the inspection of a site for available services and a collection of rules for how inspection related information should be made available for consumption. A WS-Inspection document provides a means for aggregating references to pre-existing service description documents which have been authored in any number of formats. These inspection documents are then made available at the point-of-offering of the service as well as through references which may be placed within a content medium such as HTML.
|
| |
WS-Manageability - Concepts
The WS-Manageability -- Concepts document outlines the scope and definitions for the specification. It provides an overview of Web services architecture and implications for management of that architecture. The Concepts document further defines the role of the manager in the Web services architecture and provides practical information on manageability implementation patterns and discovery considerations.
|
| |
WS-Manageability - Representation
The WS-Manageability -- Representation document provides the interface definitions based on the model as WSDL 1.1 and GWSDL renderings. These definitions are meant to show how the topics and aspects concepts along with concrete models can influence the development of consistent Web services interfaces for accessing the manageability information of Web services. The interfaces illustrate how the manageability model for Web services can be divided into aspects of topics that apply to all manageable resources and aspects of topics that apply only to the manageability of Web service endpoints.
|
| |
WS-Manageability 1.0
The WS-Manageability - Specification begins by introducing the general concepts of a manageability model in terms of manageability topics, (identification, configuration, state, metrics, and relationships) and the aspects (properties, operations and events) used to define them. These abstract concepts apply to understanding and describing the manageability information and behavior of any IT resource, not just Web services. We use these concepts to organize our approach to Web services manageability.
|
| |
WS-Manageability: Concepts
The WS-Manageability: Concepts document outlines the scope and definitions for the specification.
|
| |
WS-Manageability: Representation
The WS-Manageability: Representation document provides the interface definitions based on the model as WSDL 1.1 and GWSDL renderings.
|
| |
WS-MetadataExchange
Web services use metadata to describe what other endpoints need to know to interact with them. To bootstrap communication with a Web service, this specification defines three request-response message pairs to retrieve these three types of metadata: one retrieves the WS-Policy associated with the receiving endpoint or with a given target namespace, another retrieves either the WSDL associated with the receiving endpoint or with a given target namespace, and a third retrieves the XML Schema with a given target namespace. Together these messages allow efficient, incremental retrieval of a Web service's metadata.
|
| |
WS-Notification
WS-Notification implements the Notification pattern, where a service provider, or other entity, initiates messages based on a subscription or registration of interest from a service requestor. It defines how the publish/subscribe (pub sub) pattern commonly used in Message-Oriented middleware products can be realized using Web services. This includes brokered as well as direct pub sub which allows the publisher/subscribers to be decoupled and provides greater scalability.
|
| |
WS-PolicyAssertions
The goal of WS-PolicyAssertions is to provide basic assertions needed to enable Web Services applications. This document specifies a set of common message policy assertions that can be specified within a policy.
|
| |
WS-PolicyAttachments
The Web Services Policy Attachments specification provides a general-purpose mechanism for associating policy assertions with subjects (services). It provides for two approaches for making assertions: policy assertions defined as part of the definition of the subject, or policy assertions defined independently of and associated through an external binding to the subject.
|
| |
WS-PolicyFramework
The Web Services Policy Framework defines a general purpose model and corresponding syntax to describe and communicate Web services policies so that Service consumers can discover the information they need to know to be able to access services from a Service Provider.
|
| |
WS-Polling
The WS-Polling specification is aimed at addressing a problem with Web services that appears to be popping up in quite a few places. In environments where connections between SOAP endpoints can be freely created, asynchronous message processing can be done without any problems. However, this isn't always the situation. Firewalls must be in place to protect your company's assets. This is where this new specfication comes in. WS-Polling tries to help address this issue in a non-application, non-domain, -specific way.
|
| |
WS-Provisioning
WS-Provisioning describes the APIs and schemas necessary to facilitate interoperability between provisioning systems and to allow software vendors to provide provisioning facilities in a consistent way. The specification addresses many of the problems faced by provisioning vendors in their use of existing protocols, commonly based on directory concepts, and confronts the challenges involved in provisioning Web Services described using WSDL and XML Schema.
|
| |
WS-ReliableMessaging
This specification describes a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. To support interoperable Web services, a SOAP binding is defined within this specification.
|
| |
WS-ResourceCatalog
The Web Services Resource Catalog (WS-RC) specification describes an XML
document format that supports the description of resources and services and their
associated metadata in a model-neutral manner. This information allows for
classification, linking, discovery, and access to relevant resources. Applications
that need to discover resources and services can use a service that offers this
catalog information via Web or Web services protocols.
|
| |
WS-ResourceLifetime
WS-ResourceLifetime defines two ways of destroying a WS-Resource: immediate and scheduled. This allows designers flexibility to design how their Web services applications can clean up resources no longer needed.
|
| |
WS-ResourceProperties
WS-ResourceProperties defines how the data associated with a stateful resource can be queried and changed using Web services technologies. This allows a standard means by which data associated with a WS-Resource can be accessed by clients.
|
| |
WS-ResourceTransfer
In March 2006, HP, IBM, Intel, and Microsoft announced plans to address customers' concerns around competing management specifications. The roadmap provided a high-level overview of the strategy being used to achieve the goal of having a single set of specifications for resource access/manipulation, events and management. As the work progresses specifications will be made available for public review and feedback. The first of these specifications is WS-ResourceTransfer.
|
| |
WS-SecureConversation
The Web Services Secure Conversation Language is built on top of the WS-Security and WS-Policy models to provide secure communication between services. WS-Security focuses on the message authentication model but not a security context, and thus is subject several forms of security attacks. This specification defines mechanisms for establishing and sharing security contexts, and deriving keys from security contexts, to enable a secure conversation.
|
| |
WS-Security 1.0
Web Services Security (WSS) offers a trusted means for applying security to Web services by providing the necessary technical foundation for higher-level services. WSS builds upon existing security technologies such as XML Digital Signature, XML Encryption and X.509 Certificates to deliver an industry standard way of securing Web services message exchanges. Providing a framework within which authentication and authorization take place, WSS lets you apply existing security technology and infrastructure in a Web services environment.
|
| |
WS-Security Addendum
This addendum to the WS-Security specification clarifies elements released in the original document and introduces some new items including timestamps, and passing around passwords and security certificates.
|
| |
WS-Security Kerberos Binding
This document describes how to use Web services Security Specifications with Kerberos.
|
| |
WS-Security Profile for XML-based Tokens
This document describes a general framework to enable XML-based security tokens to be used with WS-Security.
|
| |
WS-SecurityPolicy
The Web Services Security Policy Language defines a model and syntax to describe and communicate security policy assertions within the larger Policy Framework. It covers assertions for security tokens, data integrity, confidentiality, visibility, security headers and the age of a message.
|
| |
WS-Semantics (WSDL-S)
The Web Services Semantics - WSDL-S specification is a W3C Member Submission that defines how to add semantic information to WSDL documents. Semantic annotations define the meaning of the inputs, outputs, preconditions and effects of the operations described in a service interface. These annotations reference concepts in an ontology. Semantic annotations are used to automate service discovery, composition, mediation and monitoring.
|
| |
WS-Topics
WS-Topics defines a mechanism to organize and categorize items of interest for subscription known as "topics." These are used in conjunction with the notification mechanisms defined in WS-BaseNotification. WS-Topics defines three topic expression dialects that can be used as subscription expressions in subscribe request messages and other parts of the WS-Notification system. It further specifies an XML model for describing metadata associated with topics. This specification should be read in conjunction with the WS-BaseNotification specification and the "Publish-Subscribe Notification for Web Services" document.
|
| |
WS-Transactions
The Web Services Transactions specifications (WS-BusinessActivity, WS-AtomicTransactions, WS-Coordination) define mechanisms for transactional interoperability between Web services domains and provide a means to compose transactional qualities of service into Web services applications.
|
| |
WS-Trust
The Web Services Trust Language (WS-Trust) uses the secure messaging mechanisms of WS-Security to define additional primitives and extensions for security token exchange to enable the issuance and dissemination of credentials within different trust domains.
|
| |
WSDL (Web Services Description Language) 1.1
WSDL is an XML format for describing network services as a set of end points operating on messages containing document- or procedure-oriented information. WSDL is extensible to allow description of end points and their messages regardless of what message formats or network protocols are used to communicate. However, the bindings in this document describe how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME.
|
| |
WSDL (Web Services Description Language) 1.2
This is an update (Draft 11 2003-06) to the WSDL protocol specification, the foundation description protocol for Web services. The changes currently suggested for version 1.2 include new definitions on message patterns and WSDL bindings for SOAP version 1.2.
|
| |
WSDM Management white paper
In March 2006 HP, IBM, Intel, and Microsoft announced plans to address
customer concerns around competing management specifications. The roadmap provided a
high-level overview of the strategy being used to achieve the goal of having a
single set of specifications for resource access and manipulation, events, and
management. As the work progresses, specifications are being made available for
public review and feedback. In addition to WS-Resource Transfer, the second of these
specifications, WS-ResourceCatalog, is now available.
|
| |
WSRP (Web Services for Remote Portals) 1.0
WSRP standardizes the consumption of Web services in portal front-ends, as well as the way in which content providers write Web services for portals. WSRP eliminates the need for content aggregators to choose between locally hosting a content source or writing code specific to each remote content source. Instead, WSRP allows content to be hosted in the environment most suitable for its execution while still being easily accessed by content aggregators. The standard enables content producers to maintain control over the code that formats the presentation of their content. By reducing the cost for aggregators to access their content, WSRP increases the rate at which content sources may be easily integrated into pages for end-users.
|
| |
Web Service Experience Language
WSXL (Web Services Experience Language) is a Web services-centric component model for interactive Web applications, that is, for applications that provide a user experience across the Internet.
|
| |
