 |
|
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. | |
| |
BPEL4WS (Business Process Execution Language for Web Services) 1.1
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 intra-corporate and the business-to-business spaces. | |
| |
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 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 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. | |
| |
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 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 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. | |
| |
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. | |
| |
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. | |
| |
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. | |
| |
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 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, IBM, BEA, Oracle, SAP, Siebel, Sybase, and Xcalia 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, 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. | |
| |
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: 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. | |
| |
Web Services Addressing
The lastest version of WS-Addressing, a key part of the core Web services architecture, has been submitted to the World Wide Web Consortium (W3C) for the standardization process as part of a longer-term effort to provide a standards-based foundation for the development of secure, transacted, asynchronous, and reliable Web services. Read the press release and find links to the submissions on W3C. | |
| |
Web Services Description Language (WSDL) Version 2.0: RDF Mapping
This specification provides a representation of WSDL in the Resource Description Framework language (RDF) and in the Web Ontology Language (OWL), and also a RDF mapping procedure. | |
| |
Web Services 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. | |
| |
Web Services 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. | |
| |
Web Services Inspection Language
The WS-Inspection specification provides an XML format for assisting in the
inspection of a site for available services and a set 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 for the
service as well as through references which may be placed within a content medium
such as HTML. | |
| |
Web Services Manageability
The WS-Manageability specification introduces the general concepts of a manageability model in terms of manageability topics and the aspects used to define them. | |
| |
Web Services Metadata Exchange
This specification explains how the Web Services MetadataExchange Framework is structured and how it operates. It is an update to the version previous published on September 1, 2004. | |
| |
Web Services Policy Assertions Language
This document specifies a set of common message policy assertions that can be specified within a policy. | |
| |
Web Services Policy Attachment
WS-Policy provides a general purpose model and syntax to describe and communicate the policies of a Web service. | |
| |
Web Services Policy Framework
WS-Policy provides a general purpose model and syntax to describe and communicate the policies of a Web service. | |
| |
Web Services Reliable Messaging
This specification (WS-ReliableMessaging) describes a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. | |
| |
Web Services Secure Conversation Language
The recently updated Web Services Secure Conversation Language (WS-SecureConversation) is built on top of the WS-Security and WS-Trust models to provide secure communication between services. | |
| |
Web Services Security
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. | |
| |
Web Services Security Addendum
This document describes clarifications, enhancements, best practices, and errata of the WS-Security specification. | |
| |
Web Services Security Kerberos
This specification builds on the WS-Security, WS-Trust, and WS-SecureConversation specifications to integrate Kerberos functionality. | |
| |
Web Services Transactions specifications
The Web Services Transactions specifications define mechanisms for
transactional interoperability between Web services domains and provide a means to
compose transactional qualities of service into Web services applications. | |
| |
Web Services Trust Language
The recently updated 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. | |
| |
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. | |
| |
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. | |
| |
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. | |
| |
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. | |
| |
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. | |
| |
