[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: ebXML TP&R Overview & Requirements Doc diagrams
Khwaja What I really think ebXML need to do is develop specific requirements for how to access and maintain data in: 1. a Messaging Policy Repository, and 2. Repositories that keep, DTD, Document Choreographies, Business Process Rules etc. I think the first is clearly within the responsibility of the ebXML TR&P group and the second the ebXML Registry/Repository group. As you say, we need to have mechanisms/service interfaces for: 1. Discovering the existence of a repository, and 2. Accessing/maintaining the data in the repository once you know the repository you want to use. What I'm not so certain about is the extent to which we want (or need) common Servuce Interfaces for both types of repository. Thoughts? David -----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org] Sent: Monday, February 21, 2000 9:17 AM To: Dick Brooks; David Burdett Cc: ebXML Transport (E-mail); Nikola Stojanovic Subject: RE: ebXML TP&R Overview & Requirements Doc diagrams Dick and David, Is it a good idea for internal systems that require access to a repository would 1. invoke a service through the directory service interface (LDAP or X.500 ) to find the location of repository and 2. then use the messaging Service service Interface to interact with the repository on behalf of the requestor. Or Is it assumed that repository itself will have a directory service interface to get the location info of other repositories to make global ebusiness pervasive. Thanks, Khwaja Dick Brooks <email@example.com> on 02/21/2000 10:28:53 AM To: David Burdett <firstname.lastname@example.org> cc: "ebXML Transport (E-mail)" <ebXML-Transport@lists.oasis-open.org>, Nikola Stojanovic <email@example.com> Subject: RE: ebXML TP&R Overview & Requirements Doc diagrams David, This latest diagram matches my understanding from the Orlando meeting. In addition, internal systems that require access to a repository would invoke a service through the Messaging Service service interface. The Messaging Service interacts with the repository on behalf of the requester. It may be worthwhile to depict an internal system interfacing with the Messaging System for repository access. Thanks, Dick -----Original Message----- From: David Burdett [mailto:firstname.lastname@example.org] Sent: Monday, February 21, 2000 1:19 AM To: Dick Brooks (E) Cc: ebXML Transport (E-mail); Nikola Stojanovic Subject: RE: ebXML TP&R Overview & Requirements Doc diagrams Dick You say ... >>>it appears that access to the repository is not part of the service interface of the messaging system ... as I recall, it was decided that the messaging service interface would provide a "service" for accessing the repository (read & update)<<< In a senses I think we are both right. My view is that: 1. We need a basic "Messaging Sservice" that can reliably exchange messages over the net between any two parties that is completely independent of the content or the payload of the message 2. We define a "Repository Management Service" that can be used to read/update a repository that we identified. The Repository Management Service would: 1. Have a Service Interface so that the content of the data in a repository held locally could be maintained, and 2. Use the Service Interface of the Messaging Service to access the content of repositories held remotely. The attached diagram provides (I think) are more accurate representation than my original one. The rationale is that the Repository Management Service is really nothing more than a distributed system that reads or updates data on local or remote repositories that has a Service Interface to manage/access the repository content. I think that this type of "layering" is important as I think that eventually we will want to describe a number of other Service Interfaces that will use the basic messaging service interface, for example: 1. A Publish & Subscribe Interface 2. A Large Document Transfer Service (e.g. to transport multi-MB files reliably by splitting them into several parts). I'd appreciate your thoughts. David -----Original Message----- From: Dick Brooks (E) [mailto:email@example.com] Sent: Saturday, February 19, 2000 3:20 PM To: David Burdett; Nikola Stojanovic Cc: ebXML Transport (E-mail) Subject: RE: ebXML TP&R Overview & Requirements Doc diagrams David, I believe you've captured what people are expecting in terms of a solution from the ebXML MR&T group. Nicely done. Only one comment, regarding diagram 5, Repository physical flows of information, it appears that access to the repository is not part of the service interface of the messaging system. This is different from what I recall from our discussions in Orlando. As I recall, it was decided that the messaging service interface would provide a "service" for accessing the repository (read & update). This was discussed around the time that John I. introduced the tpaML spec. Dick Brooks -----Original Message----- From: firstname.lastname@example.org [mailto:email@example.com]On Behalf Of David Burdett Sent: Tuesday, February 15, 2000 12:27 AM To: Nikola Stojanovic Cc: ebXML Transport (E-mail) Subject: RE: ebXML TP&R Overview & Requirements Doc diagrams Nikola I agree with your comments. I'm copying my reply to the TP&R group since I'd like the groups comments on the diagrams and attached notes during the conference call on Wednesday with a view to including them in the Requirements document. David -----Original Message----- From: Nikola Stojanovic [mailto:firstname.lastname@example.org] Sent: Monday, February 14, 2000 11:54 AM To: David Burdett Subject: Re: ebXML TP&R Overview & Requirements Doc diagrams <snip> As I understand then: 1) We will use TP&R services only to go remotely (via Internet only?). There is no need for formal (header, doc, signature,...) XML packing between ebXML components. Internally Systems talk to each other via specified Service Interfaces ("Program Language independent ..."). There are some ebXML threads regarding "Syntax neutral" (some call it syntax-free?) notion of Interfaces and Components. It would be necessary to decide which syntaxes to use as examples, because there has to be at least one. 2) Integration System (ebXML Gateway, Service Handler) will be the one which will handle (route, ...) ebXML Service Processing. It will serve the purpose of a "Facade controller" for the overall ebXML space. It will also serve the purpose of "Indirection" in order to avoid "Direct Coupling" of Systems (Components), which will never talk directly to each other, like: Message System will go via Integration System to Repository System to get needed Messaging Policies. I will need to read your docs again to have a better understanding of all the entities involved. Nikola ----- Original Message ----- From: "David Burdett" <email@example.com> To: "Nikola Stojanovic" <firstname.lastname@example.org> Sent: Friday, February 11, 2000 9:20 PM Subject: RE: ebXML TP&R Overview & Requirements Doc diagrams > Nikola > > I've looked at your diagram and think that there is too much information on > it for it to easily make it easy to understand. So I've added a few more > diagrams to explain a number of different aspects. > > Tell me what you think. > > David > > > -----Original Message----- > From: Nikola Stojanovic [mailto:email@example.com] > Sent: Friday, February 11, 2000 7:22 AM > To: David Burdett > Subject: Fw: ebXML TP&R Overview & Requirements Doc diagrams > > > Hi David. > > 1) A few more changes (corrections) from me. > Message System now talks to: > - Another Message System via Internet (or something else?) in order > to reach another Party. I guess we don't need local version of this? > - Another Message System via Internet (or something else?) in order > to reach Repository Server (Repository). > - Repository System locally. > > 2) I am of the opinion that sometimes smaller group of people can do more > then a larger one. In XP (Extreme Programming) they have 2 people (2 pair of > eyes, ...) working on a task. I thought if you and me can just discuss this > version and then, if we agree on it, give it to a one person from each of > our groups for comments and then present to whole groups? If not in > agreement or not working together, I assume you'll pass it to your group and > I pass it to my group. > > Thanks > Nikola > > ----- Original Message ----- > From: "Nikola Stojanovic" <firstname.lastname@example.org> > To: "David Burdett" <email@example.com> > Sent: Thursday, February 10, 2000 2:49 PM > Subject: Re: ebXML TP&R Overview & Requirements Doc diagrams > > > > Hi David. > > These are just few of mine initial changes. I have informed our group > about > > your meeting and what was discussed. > > > > Why changes: > > > > Assumption #1: Everything is a Service. Not only business services, but > > technical (infrastructure) as well. That would imply that Registry and > > Repository (RR) should comply with this design => you can ask RR if it can > > Change a Core Component or just Browse Core Components, ... Even Message > > Systems comply with this => thus Service Interfaces instead of API. > Message > > systems' Services could be "Discovered" as well. > > > > Implication #1: Everything talks uniformly via Message Systems. I guess > > language is XML. > > > > Assumption #2: RR could be available both Locally and Remotely (via > > Internet, ...). > > > > Implication #2: Integration System just talks (is a Broker) between > > Enterprise and ebXML space. It can also talk to other spaces (we can hope > > ebXML will be a meta one so it wouldn't need to) if needed. > > > > Assumption #3: Policies are Business Rules. > > > > Implication #3: Policies are part of Business Rules. As such they could > also > > be Local or Distributed. > > > > What do you think? > > > > Nikola > > > > > ---------------------------------------------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC