Subject: RE: Help
c. A registry shall incorporate a mechanism for querying a repository or a cache of a repository's index via an API (see "2.15 ebXML Business Process Search Requirements"). Here's a fundamental problem. It is the registry that should be searched not the repository, basically searching the stored metadata ABOUT the information in the repository. this metadata is a result of manually entering of information as well indexing, either 1) according to a predefined classification scheme or 2) a full text (if possible), concept based indexing to extract and index all important terms. We talked about this for quite a while in Orlando that searching is only done in the registry. As far as the TRP server comment, the message request could come from anywhere, such as HTTP, or from another application. I know this is different than the XML.ORG impl. In Part2, I supposed we could put "Guest User" as the actor, but in REALITY it is a SYSTEM that is marshalling that request and passing it to SOMETHING. That is a combination of the HTML form, HTTP and a Java servlet (e.g.). In the final analysis phase (Part3), I am proposing that the model reflect that as a TRP proxy and server, because in physical reality a client could be installed on an HTTP server to pass an ebXML TRP request via a proxy to a TRP server (could be multiple load balanced servers) which deserializes the request and invokes executes the correct member function. I was jumping the gun a bit, knowing that the proof of concept will need to receive and respond to a TRP-based registry request. Scott -----Original Message----- From: Joe Dalman To: 'Nieman, Scott' Sent: 8/10/00 7:34 PM Subject: Help Scott, Here is the document that you started but we are still not making good progress if you can expand areas we should add comments we can try harder to make changes. We miss you this week. I think we are going to have to plan bi-weekly phone calls to get on track. Thanks for your help... <<Reg_Rep2_start_stn.doc>>
Powered by
eList eXpress LLC