RE: ebXML TP&R Overview & Requirements Doc diagrams

["Dick Brooks" <dick@8760.com>]

Rik,

There are some good reasons why one may want to have the repository access
contained within the Messaging Services component,
for example:

	- The Messaging Services component will likely have an interface with the
repository (for DTD's, trading partner
        data, etc.). Why not re-use this code and manage the processing in
one place.

	- As repositories evolve there will likely be differences in
version/capability across implementations. It would be
	  easier to manage these differences if the code is in one place as opposed
to several backend systems running
	  on various platforms.

	- The repository location, I assume, will be dependant on the trading
partner involved in any transaction exchange.
	  If this is true then the backend system will need to interface with the
Message Service to get access to the trading
	  partner information.

	- The Message Server can provide some economies of scale, for example,
caching services for frequently accessed sites.

	- Eliminate redundancy/code management that exists when there are multiple
implementations of the repository interface.

These are just a few advantages of having a centralized repository interface
through the Messaging Service.

Dick


-----Original Message-----
From: Rik Drummond [mailto:drummond@onramp.net]
Sent: Monday, February 21, 2000 3:07 PM
To: David Burdett; Dick Brooks (E)
Cc: ebXML Transport (E-mail); Nikola Stojanovic
Subject: RE: ebXML TP&R Overview & Requirements Doc diagrams


If we follow david's logic, our service could connect and be used easily by
other repositories that don't follow the details of the one ebxml is putting
in place. so i agree with david's take on this.... best regards, rik

-----Original Message-----
From: owner-ebxml-transport@lists.oasis-open.org
[mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of David
Burdett
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:dick@8760.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: owner-ebxml-transport@lists.oasis-open.org
[mailto:owner-ebxml-transport@lists.oasis-open.org]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:nstojano@cjds.com]
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" <david.burdett@commerceone.com>
To: "Nikola Stojanovic" <nstojano@cjds.com>
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:nstojano@cjds.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" <nstojano@cjds.com>
> To: "David Burdett" <david.burdett@commerceone.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
> >
>
>
>