OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: GRID standards

These are the GRID standards which replace OGSI (referenced in the
current GRID requirements document).

Matthew
--- Begin Message --- 
A new OASIS technical committee is being formed. The OASIS Web Services 
Notification (WSN) TC has been proposed by the following members of 
OASIS:  Fred Carter, Amberpoint; David Chappell, Sonic Software; Andreas 
Dharmawan, Westbridge Technology; David Hull, Tibco; Ian Foster, ANL; 
Hiro Kishimoto, Fujitsu; Hitoshi Komori, Fujitsu; Lily Liu, WebMethods; 
Bryan Murray, Hewlett-Packard; Peter Niblett, IBM; Richard Nikula, BMC; 
Sanjay Patil, SAP AG; Homayoun Pourheidari, Hewlett-Packard; Igor 
Sedukhin, Computer Associates; Hitoshi Sekine, Ricoh; Latha Srinivasan, 
  Hewlett-Packard; Jem Treadwell, Hewlett-Packard; Steve Tuecke, ANL; 
William Vambenepe, Hewlett-Packard; Alan Weissberger, NEC, and Dave 
Orchard, BEA.

The proposal for a new TC meets the requirements of the OASIS TC Process
(see http://oasis-open.org/committees/process.shtml), and is appended to
this message. The TC name, statement of purpose, scope, list of 
deliverables, audience, and language specified in the proposal will 
constitute the TC's charter. The TC Process allows these items to be 
clarified (revised); such clarifications (revisions), as well as 
submissions of technology for consideration by the TC and the beginning 
of technical discussions, may occur no sooner than the TC's first meeting.

As specified by the OASIS TC Process, the requirements for becoming a
member of the TC at the first meeting are that you must 1) be an
employee of an OASIS member organization or an Individual member of
OASIS; 2) notify the TC chair of your intent to participate at least 15
days prior to the first meeting; and 3) attend the first meeting of the
TC. For OASIS members, to register for the TC using the OASIS
collaborative tools, go to the TC's public web page at
http://www.oasis-open.org/committees/wsn and click on the button for
"Join This TC" at the top of the page. You may add yourself to the
roster of the TC either as a Prospective Member (if you intend to become
a member of the TC) or an Observer. A notice will automatically be sent
to the TC chair, which fulfills requirement #2 above.

OASIS members may also join the TC after the first meeting. Note that
membership in OASIS TCs is by individual, and not by organization.

Non-OASIS members may read the TC's mail list archive, view the TC's web
page, and send comments to the TC using a web form available on the TC's
web page; click the "Send A Comment" button. The archives of the TC's
mail list and public comments are visible at
http://lists.oasis-open.org/archives/

Further information about the topic of this TC may be found on the Cover
Pages under "Stateful Web Services" at 
http://xml.coverpages.org/statefulWebServices.html

-Karl

=================================================================
Karl F. Best
Vice President, OASIS
office  +1 978.667.5115 x206     mobile +1 978.761.1648
karl.best@oasis-open.org      http://www.oasis-open.org



Name of the TC:

OASIS Web Services Notification (WSN) Technical Committee


Statement of Purpose

The purpose of the Web Services Notification (WSN) TC is to define a set 
of specifications that standardise the way Web services interact using 
the Notification pattern.

In the Notification pattern a Web service, or other entity, disseminates 
information to a set of other Web services, without having to have prior 
knowledge of these other Web Services. Characteristics of this pattern 
include:

1. The Web services that wish to consume information are registered with 
the Web service that is capable of distributing it. As part of this 
registration process they may provide some indication of the nature of 
the information that they wish to receive.
2. The distributing Web service disseminates information by sending 
one-way messages to the Web services that are registered to receive it. 
It is possible that more than one Web service is registered to consume 
the same information. In such cases, each Web service that is registered 
receives a separate copy of the information.
3. The distributing Web service may send any number of messages to each 
registered Web service; it is not limited to sending just a single message.

The Notification pattern has many applications, for example in the 
arenas of system or device management, or in commercial applications 
such as electronic trading.

The goal of this TC is to define a set of royalty-free, related, 
interoperable and modular specifications that allow this pattern to be 
modeled in an explicit and standardized fashion. The benefits of such 
standardization include interoperation between application entities 
written by different authors, as well as interoperation between 
different publish/subscribe messaging middleware providers.


Scope of Work

The scope of this work is to define a set of related, interoperable and 
modular specifications that standardize the concepts, message exchanges, 
WSDL and XML schema renderings required to express the Notification 
pattern, as outlined in the previous section.

These specifications will cover the basic Notification pattern along 
with additional functions that support the use of this pattern. The 
items to be specified include:

* The means by which one Web service can be registered with another in 
order to receive notifications. It will be possible for this 
registration to be performed by a third party. This includes the means 
by which the registration indicates the kind of information that it covers.
* The means by which such registrations (subscriptions) can be modified 
or deleted.
* The means by which a Web service delivers information to those Web 
services that are registered with it. This includes the possibility of 
"bulk notification", i.e. batching multiple pieces of information into a 
single message.
* The means by which a Web service can limit the amount of information 
that is being sent to it.
* The means by which a Web service can act as a "notification broker". A 
notification broker can act as a intermediary between the producer of 
the information and the Web services that receive it.
* The means by which an entity which is not itself a Web service can use 
a notification broker to deliver information to Web services.
* A language that can be used to describe a Topic information space, and 
associated metadata. Topics are used to categorize the kinds of 
information that can be sent or subscribed to as part of a subscription 
registration.
* One or more Topic Expression dialects, used to identify Topics or sets 
of Topics, within a Topic information space.
* The means by which a Web service can provide runtime metadata showing 
what Topics it has available for subscription, and in what formats the 
subscription can be made.
* One or more Policy language(s) that express the policies that can be 
applied to a subscription (for example maximum message rate or quality 
of service) and to other roles and components within the scope of work 
of the TC.
* A list of the various roles that Web services, or other entities, can 
assume within the Notification pattern, along with a description of the 
function required in order to fulfill each role.
* Concepts and Terminology to support the above

The specifications produced by the TC will be independent of 
binding-level details. The method of registering for information, and 
the actual delivery of that information will be orthogonal to transport 
protocols, so that the specifications can be used over a variety of 
different transports.

The specifications will be factored in a way that allows 
resource-constrained devices to participate in the Notification pattern. 
Such devices will be able to send information to, and receive 
information from Web services, without having to implement all the 
features of the specifications.

The specifications will be designed so that implementations of the 
specifications can map naturally onto traditional Messaging Middleware 
systems. The specifications will not describe or attempt to standardize 
the nature of this mapping.

The WSN TC takes, as its starting point, the Web Service Notification 
specification documents recently published by Akamai Technologies, 
Computer Associates International, Fujitsu Laboratories of Europe, the 
Globus Alliance/Argonne National Laboratory, Hewlett-Packard, IBM, SAP 
AG, Sonic Software, and Tibco Software. These documents are :

* Publish-Subscribe Notification for Web services, Version 1.0 dated 
03/05/2004. Available at
  -  http://www.ibm.com/developerworks/library/ws-pubsub/WS-PubSub.pdf
  -  http://devresource.hp.com/drc/specifications/wsrf/WSNpubsub-1-0.pdf
  -  http://ifr.sap.com/ws-notification/WS-PubSubWhitePaper.pdf

* Web Services Base Notification, Version 1.0 dated 03/05/2004. 
Available at
  - 
ftp://www6.software.ibm.com/software/developer/library/ws-notification/WS-BaseN.pdf
  - 
http://devresource.hp.com/drc/specifications/wsrf/WS-BaseNotification-1-0.pdf
  - http://ifr.sap.com/ws-notification/WS-BaseNotification.pdf

* Web Services Topics, Version 1.0 dated 03/05/2004. Available at
  - 
ftp://www6.software.ibm.com/software/developer/library/ws-notification/WS-Topics.pdf
  - http://devresource.hp.com/drc/specifications/wsrf/WS-Topics-1-0.pdf
  - http://ifr.sap.com/ws-notification/WS-Topics.pdf

* Web Services Brokered Notification, Version 1.0 dated 03/05/2004. 
Available at
  - 
ftp://www6.software.ibm.com/software/developer/library/ws-notification/WS-BrokeredN.pdf
  - 
http://devresource.hp.com/drc/specifications/wsrf/WS-BrokeredNotification-1-0.pdf
  - http://ifr.sap.com/ws-notification/WS-BrokeredNotification.pdf

The TC will coordinate with the proposed WSRF TC, and the standards 
produced by the WSN TC will conform to the implied resource pattern 
specified by the WSRF TC. Specifications produced by the WSN TC will 
make use of specifications from the WSRF TC concerning lifetime and 
properties of WS-Resources.

Other contributions in addition to those listed above will be accepted 
for consideration  without any prejudice or restrictions, and evaluated 
on their technical merit, as long as the contributions conform to this 
charter

Out of Scope

The following topics are outside the scope of this TC:

1. The TC will not prescribe any particular format for the information 
transmitted in a Notification (other than requiring it to be expressible 
as a WSDL message).
2. The TC will not define schemas for notification messages for use in 
particular application domains.
3. The TC will not define standard Topic information spaces.
4. The TC will not define the mapping to any particular programming 
language, or to any particular messaging middleware.
5. The TC will not attempt to provide specifications for things which 
have a wider applicability within Web Services. For example, the TC will 
not provide specifications for the following features:
  - Routing
  - Addressing
  - Policy Framework
  - Resource destruction
  - Resource properties
  - Reliable Messaging
  - Encryption
  - Message Integrity
  - Mechanisms to protect against corruption of an individual message
  - Authentication
  - Message Non-Repudiation
  - Transactions and Compensation

Where required, these features are provided by composing Notification 
with other Web Services standards.


List of Deliverables

* A revised set of WS-Notification specifications (WS-Base Notification, 
WS-Topics, WS-Brokered Notification). Committee Drafts due within one 
year of the first meeting.
* A WS-NotificationPolicy specification detailing the policy language 
associated with Notification. Committee Draft due within one year of the 
first meeting.
* A primer introducing the above specifications, including use cases, 
scenarios and suggested best practices for domain experts, as 
appropriate. Committee Draft due within one year of the first meeting.

These specifications will reflect refinements and changes made to, and 
by, contributions to the TC that are identified by members for 
additional functionality and semantic clarity within the scope of the TC 
charter. The TC may choose to vary the number of the specification 
documents and their titles.


Audience

The anticipated audience for this work includes:

* other specification writers that need the notification pattern for Web 
services;
* vendors offering web service or message oriented middleware products; and
* software architects and programmers who design and write distributed 
applications requiring notification.


Language

English


--------------------------------
The following is informational only for the purposes of starting the TC, 
and will not be part of the TC's charter:


Identification of Existing Activities:

A number of efforts that use or require the notification pattern in Web 
services are underway throughout the industry. The following work may be 
relevant to this Web Services Notification TC:

* OASIS Web Services Business Process Execution Language (WSBPEL) TC, 
http://www.oasis-open.org/committees/wsbpel/charter.php
* OASIS Web Services Distributed Management (WSDM) TC, 
http://www.oasis-open.org/committees/wsdm/charter.php
* OASIS Universal Description, Discovery and Integration (UDDI) 
Specification TC, http://www.oasis-open.org/committees/uddi-spec/charter.php
* The Global Grid Forum (GGF) Open Grid Services Infrastructure, 
http://www.ggf.org/ogsi-wg
* Grid Data Distribution (GDD) - part of the GGF DAIS-WG, 
https://forge.gridforum.org/projects/dais-wg


Date and Time of the First Meeting:

The first meeting of the TC will be face-to-face on 29 April 2004 from 
9am to 5pm, in New Orleans, in conjunction with the OASIS Symposium on 
Reliable Infrastructures.


Meeting Schedule for the First Year:

Following the first meeting, the TC is expected to meet bi-weekly via 
teleconference and to have quarterly face to face meetings, unless a 
different schedule is agreed upon. The initial sponsors for 
teleconference and face to face meetings will be Hewlett-Packard and IBM


Proposers

The following eligible people are in support of this proposal:

Fred Carter, Amberpoint, fred.carter@amberpoint.com
David Chappell, Sonic Software, chappell@sonicsoftware.com
Andreas Dharmawan, Westbridge Technology, andreas@westbridgetech.com
David Hull, Tibco, dmh@tibco.com
Ian Foster, ANL, foster@mcs.anl.gov
Hiro Kishimoto,  Fujitsu, hiro.kishimoto@jp.fujitsu.com
Hitoshi Komori,  Fujitsu, komori.h@jp.fujitsu.com
Lily Liu,  WebMethods, lily@webmethods.com
Bryan Murray, Hewlett-Packard, bryan_murray@hp.com
Peter Niblett,  IBM, peter_niblett@uk.ibm.com
Richard Nikula, BMC, richard_nikula@bmc.com
Sanjay Patil,  SAP AG, sanjay.patil@sap.com
Homayoun Pourheidari,  Hewlett-Packard, homayoun@hp.com
Igor Sedukhin,  Computer Associates, igor.sedukhin@hp.com
Hitoshi Sekine,  Ricoh, Hitoshi.Sekine@ricoh-usa.com
Latha Srinivasan,  Hewlett-Packard, latha.srinivasan@hp.com
Jem Treadwell,  Hewlett-Packard, jem.treadwell@hp.com
Steve Tuecke,  ANL, tuecke@mcs.anl.gov
William Vambenepe,  Hewlett-Packard, vbp@hp.com
Alan Weissberger,  NEC, ajwdct@technologist.com
Dave Orchard, BEA, dorchard@bea.com


Convener

Peter Niblett


Proposed Co-Chairs:

Peter Niblett
William Vambenepe




_______________________________________________________________
This email list is used solely by OASIS for official consortium
communications. Opt-out requests may be sent to
member_services@oasis-open.org, however, all members are strongly
encouraged to maintain a subscription to this list.
--- End Message ---
--- Begin Message --- 
A new OASIS technical committee is being formed. The OASIS Web Services 
Resource Framework (WSRF) TC has been proposed by the following members 
of OASIS: Fred Carter, AmberPoint; Glen Daniels, Sonic Software; Andreas 
Dharmawan, Individual; Ian Foster, ANL; Hiro Kishimoto, Fujitsu; Hitoshi 
Komori, Fujitsu; Lily Liu, webMethods; Bryan Murray, Hewlett-Packard 
Company; Richard Nikula, BMC Software; Homayoun Pourheidari, 
Hewlett-Packard Company; Alain Regnier, Ricoh; Ian Robinson, IBM; Igor 
Sedhuck, Computer Associates; Hitoshi Sekine, Ricoh; David Snelling, 
Fujitsu; Latha Srinivasan, Hewlett-Packard Company; Jem Treadwell, 
Hewlett-Packard Company; Steve Tuecke, ANL; William Vambenepe, 
Hewlett-Packard Company; Alan Weissberger, NEC; and Dave Orchard, BEA.

The proposal for a new TC meets the requirements of the OASIS TC Process
(see http://oasis-open.org/committees/process.shtml), and is appended to
this message. The TC name, statement of purpose, scope, list of 
deliverables, audience, and language specified in the proposal will 
constitute the TC's charter. The TC Process allows these items to be 
clarified (revised); such clarifications (revisions), as well as 
submissions of technology for consideration by the TC and the beginning 
of technical discussions, may occur no sooner than the TC's first meeting.

As specified by the OASIS TC Process, the requirements for becoming a
member of the TC at the first meeting are that you must 1) be an
employee of an OASIS member organization or an Individual member of
OASIS; 2) notify the TC chair of your intent to participate at least 15
days prior to the first meeting; and 3) attend the first meeting of the
TC. For OASIS members, to register for the TC using the OASIS
collaborative tools, go to the TC's public web page at
http://www.oasis-open.org/committees/wsrf and click on the button for
"Join This TC" at the top of the page. You may add yourself to the
roster of the TC either as a Prospective Member (if you intend to become
a member of the TC) or an Observer. A notice will automatically be sent
to the TC chair, which fulfills requirement #2 above.

OASIS members may also join the TC after the first meeting. Note that
membership in OASIS TCs is by individual, and not by organization.

Non-OASIS members may read the TC's mail list archive, view the TC's web
page, and send comments to the TC using a web form available on the TC's
web page; click the "Send A Comment" button. The archives of the TC's
mail list and public comments are visible at
http://lists.oasis-open.org/archives/

Further information about the topic of this TC may be found on the Cover
Pages under "Stateful Web Services" at 
http://xml.coverpages.org/statefulWebServices.html

-Karl

=================================================================
Karl F. Best
Vice President, OASIS
office  +1 978.667.5115 x206     mobile +1 978.761.1648
karl.best@oasis-open.org      http://www.oasis-open.org




Name of the TC:

OASIS Web Services Resource Framework (WSRF) Technical Committee


Statement of Purpose:

The purpose of the Web Services Resource Framework (WSRF) TC is to 
define a generic and open framework for modeling and accessing stateful 
resources using Web services. This includes mechanisms to describe views 
on the state, to support management of the state through properties 
associated with the Web service, and to describe how these mechanisms 
are extensible to groups of Web services.

Web services implementations are often stateless in that they maintain 
no dynamic state whose lifetime exceeds the processing of an individual 
message. The statelessness of Web service implementations is a valuable 
asset to their availability and ability to accommodate dynamic workloads.

Web service interfaces, on the other hand, often imply the need for some 
form of stateful interaction with the clients of the service. This may 
be manifest in a conversational style of use of a particular Web service 
interface in which some aspect of the result of one operation influences 
the execution of the next operation. The state in interactions with such 
interfaces is typically contained in or referred to from the messages 
that are exchanged with the target service. Inferences concerning the 
nature of the state may sometimes be made, but only in an 
application-specific fashion and not in a generic manner that can be 
exploited easily by tooling.

The goal of this TC is to define a set of royalty-free, related, 
interoperable and modular specifications that will allow the 
relationship between a Web service and state to be modelled in an 
explicit and standardized fashion. This will simplify the definition of 
new service interfaces and enable more powerful discovery, management 
and development tools. These specifications will be composable with 
other available Web services specifications enabling applications to 
access state with the qualities of service - for example security, 
transactions and reliability - provided for in those specifications.


Scope of Work:

The scope of this work is to define a framework within which Web 
services can access state in a consistent and interoperable manner, and 
an access pattern through which service requesters can interact 
indirectly with stateful resources through a Web service that 
encapsulates the state. An architectural separation will be maintained 
between a stateful resource and the Web service that encapsulates it to 
promote the desirable loose coupling between service requestor and the 
stateless service provider and to provide a highly available and 
scalable means to interact with state.

This TC will define the means by which:

* Web services can be associated with one or more stateful resources 
(named, typed, state components).
* Service requestors access stateful resources indirectly through Web 
services that encapsulate the state and manage all aspects of Web 
service based access to the state.
* Stateful resources can be destroyed, through immediate or time based 
destruction.
* The type definition of a stateful resource can be associated with the 
interface description of a Web service to enable well-formed queries 
against the resource via its Web service interface.
* The state of the stateful resource can be queried and modified via Web 
service message exchanges.
* Endpoint references to Web services that encapsulate stateful 
resources can be renewed when they become invalid, for example due to a 
transient failure in the network.
* Stateful resources can be aggregated for domain-specific purposes.

WSDL is an essential element of Web services architecture. The 
specifications produced by this TC will provide WSDL definitions for all 
normative message exchanges.

The benefits and results of this work will be a standard way for web 
services to access state leading to greater simplification in the 
definition of new Web service interfaces, better service 
interoperability and greater opportunity for tools vendors to provide 
means to manage Web service applications and resources.

The WSRF TC takes, as its starting point, the set of specifications and 
the papers "Modeling Stateful Resources with Web Service" 
(http://www.ibm.com/developerworks/library/ws-resource/ws-modelingresources.pdf 
and 
http://devresource.hp.com/drc/specifications/wsrf/ModelingState-1-1.pdf) 
and "The WS-Resource Framework" 
(http://www.ibm.com/developerworks/library/ws-resource/ws-wsrf.pdf, 
http://www-106.ibm.com/developerworks/library/ws-resource/ws-wsrf.pdf, 
and 
http://devresource.hp.com/drc/specifications/wsrf/WSRF_overview-1-0.pdf) 
recently published by IBM, the Globus Alliance, HP, Fujitsu and CA. The 
papers describe how state associated with a Web service can be modeled 
in terms of a WS-Resource and give an overview of the specifications 
that comprise the framework.

The specifications are:

* WS-ResourceProperties 
(http://www.ibm.com/developerworks/library/ws-resource/ws-resourceproperties.pdf 
and 
http://devresource.hp.com/drc/specifications/wsrf/WS-ResourceProperties-1-1.pdf) 
defines how the type definition of a WS-Resource can be associated with 
the interface description of a Web service, and message exchanges for 
retrieving, changing, and deleting WS-Resource properties.
* WS-ResourceLifetime 
(http://www.ibm.com/developerworks/library/ws-resource/ws-resourcelifetime.pdf 
and 
http://devresource.hp.com/drc/specifications/wsrf/WS-ResourceLifetime-1-1.pdf) 
defines mechanisms for WS-Resource destruction, including message 
exchanges that allow a requestor to destroy a resource, either 
immediately or by using a time-based scheduled resource termination 
mechanism.

Other contributions in addition to those listed above will be accepted 
for consideration without any prejudice or restrictions, and evaluated 
on their technical merit, as long as the contributions are within the 
scope of this charter.

Out of Scope:

The following topics are outside the scope of this TC:

* Quality of service related policy enforcement on resource property 
access. The TC will not address security or transactions implications in 
the specifications it delivers.
* The consideration of protocol-specific bindings.
* Query and update of WS-Resource properties is within the scope of the 
TC, but general purpose XML document query and update, outside the 
context of managing stateful resources with Web services, is out of scope.
* A normative factory pattern for the creation of WS-Resources.


List of Deliverables:

* A revised WS-ResourceProperties specification. Committee Draft due 
within one year of the first meeting.
* A revised WS-ResourceLifetime specification. Committee Draft due 
within one year of the first meeting.
* A WS-RenewableReferences specification, which defines a conventional 
decoration of a Web service endpoint reference with information needed 
to retrieve an updated version of an endpoint reference when it becomes 
invalid. Committee Draft due within one year of the first meeting.
* A WS-ServiceGroup specification, which defines an interface to 
heterogeneous by-reference collections of Web services. Committee Draft 
due within one year of the first meeting.
* A WS-BaseFaults specification, which defines a base fault XML type for 
use when returning faults in a Web services message exchange. Committee 
Draft due within one year of the first meeting.

These specifications will reflect refinements and changes made to, and 
by, contributions to the TC that are identified by members for 
additional functionality and semantic clarity within the scope of the TC 
charter. The titles and granularity of the specifications may change.


Anticipated Audience

The anticipated audience for this work includes:

* other specification writers that need stateful interaction patterns 
for Web services;
* vendors offering web service products;
* software architects and programmers who design and write distributed 
applications requiring the management of state.


Language

English

-
-------------------------------
The following is informational only for the purposes of starting the TC, 
and will not be part of the TC's charter:


Identification of Existing Activities:

A number of efforts that use or require state-access patterns in Web 
services are underway throughout the industry. The following work may be 
relevant to this Web Services Resource Framework TC:

* OASIS Web Services Business Process Execution Language Technical 
Committee (WSBPEL), http://www.oasis-open.org/committees/wsbpel/charter.php
* OASIS Web Services Composite Application Framework (WS-CAF) Technical 
Committee http://www.oasis-open.org/committees/ws-caf/charter.php
* OASIS Web Services Distributed Management Technical Committee (WSDM 
TC) http://www.oasis-open.org/committees/wsdm/charter.php
* GGF Open Grid Services Infrastructure (OGSI) http://www.ggf.org/ogsi-wg
* W3C WSDL Version 2.0 http://www.w3.org/TR/wsdl20/


Date and Time of the First Meeting:

The first meeting of the TC will be face-to-face on 28 April 2004 from 
9am to 5pm, in New Orleans, in conjunction with the OASIS Symposium on 
Reliable Infrastructures.


Meeting Schedule:

Following the first meeting, the TC is expected to meet bi-weekly via 
teleconference and to have quarterly face to face meetings, unless a 
different schedule is agreed upon.

The sponsors for teleconference and further face to face meetings will 
be Fujitsu and IBM.


Proposers

The following eligible people are in support of this proposal:

Fred Carter (fred.carter@amberpoint.com), AmberPoint
Glen Daniels (gdaniels@sonicsoftware.com), Sonic Software
Andreas Dharmawan (andreas@westbridgetech.com), Individual
Ian Foster (foster@mcs.anl.gov), ANL
Hiro Kishimoto (hiro.kishimoto@jp.fujitsu.com), Fujitsu
Hitoshi Komori (komori.h@jp.fujitsu.com), Fujitsu
Lily Liu (lily@webmethods.com), webMethods Inc
Bryan Murray (bryan_murray@hp.com), Hewlett-Packard Company
Richard Nikula (Richard_Nikula@bmc.com), BMC Software
Homayoun Pourheidari (homayoun@hp.com), Hewlett-Packard Company
Alain Regnier (alain@ussj.ricoh.com), Ricoh
Ian Robinson (ian_robinson@uk.ibm.com), IBM
Igor Sedhuck (Igor.Sedukhin@ca.com), Computer Associates
Hitoshi Sekine (hitoshi.sekine@ricoh-usa.com), Ricoh
David Snelling (d.snelling@fle.fujitsu.com), Fujitsu
Latha Srinivasan (latha.srinivasan@hp.com), Hewlett-Packard Company
Jem Treadwell (jem.treadwell@hp.com), Hewlett-Packard Company
Steve Tuecke (tuecke@mcs.anl.gov), ANL
William Vambenepe (vbp@hp.com), Hewlett-Packard Company
Alan Weissberger, ajwdct@technologist.com, NEC
Dave Orchard, dorchard@bea.com, BEA


Convenor:

The convenor for this TC shall be David Snelling


Proposed Co-chairs

Ian Robinson,
David Snelling








_______________________________________________________________
This email list is used solely by OASIS for official consortium
communications. Opt-out requests may be sent to
member_services@oasis-open.org, however, all members are strongly
encouraged to maintain a subscription to this list.
--- End Message ---

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]