[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: FW: Do we need to revisit the Overview & Requirements document
Resending as original bounced -----Original Message----- From: David Burdett Sent: Wednesday, August 23, 2000 1:42 PM To: ebxml-transport@lists.ebxml.org Subject: Do we need to revisit the Overview & Requirements document Folks I'm replying to Chris's email as a symptom of a problem that I think we should address (so this isn't personal Chris). Basically though, I think we have a problem of scope creep/change with the work we are trying to do. For example Chris says in his email below ... >>>As for the service interface between the MS and the "application", I feel that too is outside our charter.<<< ... whether this is right or not is immaterial. The fact is we have an Overview & Requirements spec that has been out for quite a while which contradicts Chris's view (see figure 2 in the spec). If we continue to allow changes, without using the Overview & Requirements Document to guide what we do, we will get in continuous, and perhaps not very constructive, debate about what is (or is not) in scope. I suggest therefore that we ... 1. All review the existing Overview & Requirements document 2. Each identify changes that we would like to see (either additions or deletions) 3. List all the suggestions in the same way as we listed changes on the current messaging services spec 4. Agree collectively which suggestions are accepted 5. Update the Overview & Requirements document ... and then WE JUST BUILD A SOLUTION THAT MEETS THE REQUIREMENTS !! Who thinks that this would be a sensible process for us to follow. David -----Original Message----- From: Christopher Ferris [mailto:chris.ferris@east.sun.com] Sent: Wednesday, August 23, 2000 11:24 AM To: mwsachs@us.ibm.com Cc: ebxml-transport@lists.ebxml.org Subject: Re: Messaging Service Comment In a way, I concur with Marty's assessment. However, it would seem to me that rather than an "interface" definition (eg API) that it is important that we ensure that all of the requisite information is present, either in the headers themselves or in the associated TPA to enable an implementation to perform the necessary magic. An example, the use of a "logical" To address. This must be mapped to an appropriate URL (for HTTP), email address (for SMTP), etc. We shouldn't need to provide an interface to a name resolution service (such as DNS or THTTP). This is strictly implementation detail. We shouldn't even suggest where this name resolution should take place (within the MS or within the communication service implementation. It would seem to me that the appropriate place for this sort of thing might be OMG, Apache or as a JCP JSR (JAXP?) for Java implementations. I would expect that most providers of an ebXML TR&P MS would provide both the MS and the CS (communication service adaptors). If someone were to develop a standalone MS with a well defined API for the CS adaptors, that might be a good thing, but I don't believe that it is in our charter to do so. The POC demos are providing us with valuable feedback as to whether we're providing all of the requisite bits in the headers and/or TPA such that a provider can effectively develop an interoperable implementation. I think that thus far, we're on track in that regard. If not, then we must work with them to understand what their perceived needs are and figure out how they can and should be mapped to either the headers or the TPA. As for the service interface between the MS and the "application", I feel that too is outside our charter. Yes, it would be a good thing if there were a standard by which all MS implementations were developed, but again, OMG, Apache or elsewhere would seem to me to be a more suitable choice for this manner of standards development. Possibly, we should be working with one of these (or other) organizations towards this end. However, let's not lose sight of the prime objective here. The interoperability we seek with ebXML is focused on inter-enterprise interoperability. This is acheived by defining the headers and the TPA, not a set of APIs which would allow for an enterprise to exchange implementations without having to do much in the way of reengineering. YES, that is a good thing to have (eventually) but it is NOT a requirement for enabling interoperable exchange of messages between enterprises, small or large. My $0.02, Chris mwsachs@us.ibm.com wrote: > > Again, sorry about the deadline. This comment belongs on the work list, > not as a correction to the current version. > > Some of the dicussions about interrelations between Reliable Messaging and > transport protocols point up the need to state the assumptions about the > transport function in some manner. One possibility is some kind of > definition of a conceptual interface between the Messaging Service and the > transport function. It's fine to say that the messaging service is > agnostic to the transport protocol but in real life, the Messaging Service > run-time must interact with the transport run-time. Design of the messaging > service protocol must be with the understanding of what goes on in the most > likely transports. > > Since it is highly likely that an implementation will include both the > messaging service and the transport function, it may be sufficient to > express the interactions as a series of informative notes (or an > informative appendix) rather than as a formal interface definition. The > important point is that the assumptions have to be stated to ensure that > the messaging service and transport function will work together correctly. > > Regards, > Marty > > **************************************************************************** ********* > > Martin W. Sachs > IBM T. J. Watson Research Center > P. O. B. 704 > Yorktown Hts, NY 10598 > 914-784-7287; IBM tie line 863-7287 > Notes address: Martin W Sachs/Watson/IBM > Internet address: mwsachs @ us.ibm.com > **************************************************************************** ********* -- _/_/_/_/ _/ _/ _/ _/ Christopher Ferris - Enterprise Architect _/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063 _/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM _/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop: UBUR03-313 _/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA 01803-0903
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC