[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [regrep] RE: Updated ROWS proposal ...
Makes sense to me. -----Original Message----- From: Patil, Sanjay [mailto:SPatil@iona.com] Sent: Thursday, October 18, 2001 3:07 PM To: 'Dan Chang'; Munter, Joel D Cc: Oasis Registry TC Subject: RE: [regrep] RE: Updated ROWS proposal ... 1> The proposal is not for "business service registration". It is for registration of a general "Service" and related objects. An example of such a general Service is - "Order Food". A late working employee uses web service and a corporate meeting organizer uses purchasing service interface for the same internal service. 2> Yes, the pattern of registry and discovery of Service and related objects is similar to UDDI. I strongly believe in adopting good technical patterns and found the work undertaken in UDDI worthy to borrow a "technical pattern". Services are very commonly used objects in lot of current product architectures. By supporting Service objects natively will alleviate lot of pain on the parts of ebXML Registry adopters by getting an out of the box support for Service objects. Leaving out Services and requiring to use another Registry just for this purpose alone will not fly, IMHO. thanks, Sanjay Patil ---------------------------------------------------------------------------- ------------------------------ IONA Total Business Integration (TM) Phone: 408 350 9619 http://www.iona.com -----Original Message----- From: Dan Chang [mailto:dtchang@us.ibm.com] Sent: Thursday, October 18, 2001 2:47 PM To: Munter, Joel D Cc: Oasis Registry TC Subject: Re: [regrep] RE: Updated ROWS proposal ... Joel, I agree with your objections to this proposal. It is strange and non-uniform to make ebXML Registry a general purpose registry AND a business service registry. I am also deeply concerned that this proposal explicitly duplicates/overlaps UDDI functionality. I believe the industry is better served with a single set of complementary and consistent specifications rather than with multiple specifications having duplicate/overlapping functionality. Regards, Dan Metadata Management Technology and Standard IBM DBTI for e-Business Notes: Dan Chang/Santa Teresa/IBM@IBMUS Internet: dtchang@us.ibm.com VM: IBMUSM50(DTCHANG) Phone: (408)-463-2319 "Munter, Joel D" To: Oasis Registry TC <regrep@lists.oasis-open.org> <joel.d.munter@ cc: intel.com> Subject: [regrep] RE: Updated ROWS proposal ... 10/18/2001 01:50 PM reply: This is just a nitpick. I was curious why Section 3 is entitled Use Cases and then the key Use Case is described within Section 4. I have raised objections to this proposal in the past and those objections stay the same. I am still against this proposal as it deviates from the stated purpose of the Oasis ebXML Registry and Repository Technical Committee. In this case, I am referring to the statement that the Oasis ebXML Registry TC is creating specifications for a general purpose registry. Joel -----Original Message----- From: Patil, Sanjay [mailto:SPatil@iona.com] Sent: Monday, October 08, 2001 6:31 PM To: 'regrep@lists.oasis-open.org' Subject: Updated ROWS proposal ... Team, Attached is an updated ROWS proposal. The change is to reword "Business Service" to "Service" such that there is no confusion about the business use case overlap of the ROWS proposal with the UDDI proposal. <<SupportServiceAndServiceBinding.doc>> An example business use case targeted by the proposal is outlined in the section 4 of the proposal. I have cut-pasted the use case below for your convenience. I hope this use case is clear enough to stand for the primary objective of the proposal i.e. Service is a very commonly used object and providing first class support to Service will be great value add in making the ebXML Registry readily useful (out-of-the-box complete solution without requiring additional Registry software). A business organization provides an OfficeProductsPurchasing "Service" to its internal users. The service can be accessed by individuals working in the organization using the web interface. The same service can also be accessed by automated purchasing processes in the organization. The web interface relies on a SOAP/WSDL based "Service Binding" of the Purchasing service. The Purchasing service also provides an IIOP based "Service Binding" for the automated business processes in the organization. The SOAP/WSDL based service binding makes use of the SOAP, WSDL and HTTP technical "Specifications". Each of these specifications requires a set of runtime parameters ex. HTTP URL. The set of runtime parameters for each technical specification can be perceived as a "Specification Link" between the technical specification and the instance of service binding. thanks, Sanjay Patil ---------------------------------------------------------------------------- ------------------------------ IONA Total Business Integration (TM) Phone: 408 350 9619 http://www.iona.com ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC