OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: ebXML Messaging Service Layers


> I believe your diagram is more of an implementation diagram than
> an architectural layering diagram.  Leaving out the repository and
> TPA for the moment, I believe we are looking at something like this:
> Application Layer
> ----------------------- API (either real or conceptual)
> ebXML Messaging Service
> ----------------------- Mapping to transport(s), e.g., HTTP, MQ
> Transport Service(s)

I agree with the above diagrams, except I believe we call the API the
"services interface". I believe we could and should diagram a conceptual
inteface using UML (as discussed in last week's con call).

I do appreciate David's implementation diagram too, in that it captures
the roles of the components. I believe we do need something like this in
addition to the architectural layering diagram that Henry created.

> I don't really understand, archtecturally, what either the "ebXML
> Application Support Layer" 

It appears to be an optional support package containing commonly used
functions. Not a bad idea, but I do worry about having time to specify
something like this. 

> or the "ebXML Communications Layer" do.

Mappings to transports, I'd reckon.

> I don't believe we defined these (though an implementation may well
> want to build it this way).  Also, the arrow (API) from the Application
> Layer down to the ebXML Messaging Service Layer violates the idea
> of having a layered architecture (however, this is perfectly OK in
> an implementation).

Not if the Application Support Layer is an optional package that employs
the messaging service to provide specific optional functions.

> Also, I would suggest that the Security stuff shouldn't be off to
> the side, but rather be integrated into the Messaging Services Layer
> as though you're serious about security.  Ditto for the Security API.


n:Van Huizen;Gordon
org:Progress Software;XML and Internet Technology
adr:;;14 Oak Park;Bedford;MA;01730;
title:Director, Product Management
fn:Gordon Van Huizen

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC