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

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-messaging message

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


Subject: RE: Post-SJ messaging issues


James,

 

Since I am not expecting the hierarchy tree to be deep, it doesn’t really matter whether we adopt such an approach. A flat approach where information is duplicated instead of inherited will not be very different from a one or two level hierarchical approach.

 

So, I suggest that you proceed with what you originally had in mind and then we can discuss further when we have something to play with.

 

I do believe that the composition approach is better than relying on an attribute to indicate relation between messages. What do you think?

--
Dr. Savas Parastatidis
Research Associate - University of Newcastle upon Tyne, UK
http://www.staff.ncl.ac.uk/savas.parastatidis
 

-----Original Message-----
From: James Tauber [mailto:jtauber@bowstreet.com]
Sent:
Friday, August 03, 2001 6:37 PM
To: 'Savas Parastatidis'; bt-messaging@lists.oasis-open.org
Subject: RE: Post-SJ messaging issues

 

Perhaps we can construct the hierarchy as a straw man proposal and use it to help decide whether to adopt that approach.

 

James

-----Original Message-----
From: Savas Parastatidis [mailto:Savas.Parastatidis@arjuna.com]
Sent: Friday, August 03, 2001 1:30 PM
To: bt-messaging@lists.oasis-open.org
Subject: RE: Post-SJ messaging issues

James,

 

If you agree with 6b and also if you think that I can be of help in structuring such a hierarchy, let me know.

 

Thanks,

--
Dr. Savas Parastatidis
Research Associate -
University of Newcastle upon Tyne, UK
http://www.staff.ncl.ac.uk/savas.parastatidis
 

-----Original Message-----
From: James Tauber [mailto:jtauber@bowstreet.com]
Sent:
Friday, August 03, 2001 6:11 PM
To: 'Alastair Green'; Alex Ceponkus
Cc: Peter Furniss; pal.takasci; savas.parastatidis@arjuna.com; bt-messaging@lists.oasis-open.org; mark.hale@interwoven.com
Subject: RE: Post-SJ messaging issues

 

I'll prepare a new messaging section this weekend.

 

Anyone else on the messaging group want to weigh in on the open issue(s) as I do that?

 

James

-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Thursday, August 02, 2001 6:49 AM
To: James Tauber; Alex Ceponkus
Cc: Peter Furniss; pal.takasci; savas.parastatidis@arjuna.com; bt-messaging@lists.oasis-open.org; mark.hale@interwoven.com
Subject: Post-SJ messaging issues

Hi Alex and James:

I wanted to make sure you were aware of the decisions at the FTF in San Jose relating to messaging, and are also aware of a discussion that arose there which leaves us with an unresolved issue to be decided by the messaging sub-committee.

Please note that the desire is a) to get a final draft by 31 August for voting on or about 14 September, and b) that we aim to wrap up issues like those below by the time of the next conference call next Thursday 9 August, via e-mail discussion, with a bias towards fast back-room fixes among interested specialists, leading to well-formed proposals.

0) Mark Hale of Interwoven, who was involved in ebXML Messaging, raised an argument in favour of using MIME attachments for multiple (compound) messages, rather than putting a bundle of BTP messages inside a SOAP header. The argument was based on efficiency of processing given current tools. I wasn't able to note down precisely his description of this.

I'm not the best qualified to comment on this, although I would have thought that a brisk parse with the likes of SAX would get you pretty quickly to the SOAP header where a namespace with the BTP URI was used.

From our prior discussions, where I raised the question of MIME attachments, I believe that you will favour the use of a SOAP header, which seems cleaner and simpler to me.

Can I request that the messaging group take this bull by whichever horn appeals, and drive the matter through to an early conclusion?

In what follows I am going to assume that we go for SOAP header. Otherwise some bets are off, and we need some new proposals to meet the requirements.

1) We have decided (London, reaffirmed SJ) that BTP protocol actor-in-role transmitting to BTP protocol actor-in-role we will put BTP messages in the SOAP body; when BTP messages are related to application messages and travel with them we will put them in the BTP header.

2) We have decided to place the BTP messages inside some wrapper element, e.g.

<SOAP-ENV:Envelope>
    <SOAP-ENV:Header>
        <btp:messages
          xmlns:btp="http://www.oasis-open.org/2001/BTP">
           ...
        </btp:messages>
    </SOAP-ENV:Header>

    ... other people's headers ...

    <SOAP-ENV:Body>
       ... application message ...
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The name of the wrapper was not nailed down: personally I would favour "btp:messages" as being precise longhand.

3) Side-point: We need to nail down the URI in consultation with Karl Best, if we hadn't already done so.

4) The SOAP envelope is appropriate to any means of transmission (carrier protocol, binding) [Assaf Arkin, Intalio]. In other words, we should not attempt to duplicate the expression of relationship between application messages and BTP messages in a proprietary BTP manner, but should rather always use the standard SOAP envelope structure for this purpose. It's just an XML schema, and it's better to use an existing one with standing than a new one which is narrow and novel. I believe this conclusion will align with Alex's expressed concern that we not compete unwittingly with SOAP. (It has taken me a while to understand how little SOAP covers, but the penny is dropping.)

5) The relationship of BTP message to BTP message (as noted by & in the specification) is to be expressed by containment (proposal of Savas and Fred), thus:

<btp:BEGUN>
   ... some stuff ...
   <btp:CONTEXT> ... </btp:CONTEXT>
</btp:BEGUN>

contrasted with simple box-carring, where messages will simply be aggregated in the top wrapper:

    <btp:messages
        xmlns:btp="http://www.oasis-open.org/2001/BTP">
        <btp:ENROL> ... </btp:ENROL>
        <btp:PREPARED> ... <btp:PREPARED>
       ...
    </btp:messages>

6) Side-notes to 5):

a) I believe there is a case for using the upper-case notation for the names of the message elements, as shown in my pseudo-code, to match the convention of the spec. I think I may have raised this in private discussion with Bowstreet, but it has not been discussed at all in the committee, so I raise it now.

b) I believe that Savas wanted to schematize the above as an inheritance hierarchy where all specific message schemata derived from a base message schema, where any message could be contained within any message. The actual permitted containments (like CONTEXT within BEGUN) would be constrained by the specialized schemata. If I understand this approach aright, the outermost wrapper that I have proposed be called btp:messages becomes a specialization of btp:message which allows any btp:message to be contained; whereas other specializations are very choosy about which parasites they will host. Can I request that you liaise with Savas on these issues and let us know the outcome?

c) I believe we have no known need to put btp:messages inside btp:messages, but equally have no particular reason to prevent it. I have no strong feelings about this, and I don't believe the issue has been discussed other than by Alex and myself at some point.

7) The abstract message READY has been renamed PREPARED on grounds of consistency (everything else is imperative/past participle, so this one is now the same).

8) The spec is written in British English (perhaps that should be Hiberno-British English, or North Atlantic Archipelago English or These-Isles English), hence ENROL and ENROLLED which are the first readings given by the Shorter Oxford Dictionary. Enrolment is the noun, as used in the text, doesn't affect the message content.

I hope I've captured the issues list here.

Yours,

Alastair



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


Powered by eList eXpress LLC