[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: missing(?) header element
Please find my comments embedded: /Stefano > -----Original Message----- > From: Burdett, David [mailto:david.burdett@commerceone.com] > Sent: Saturday, November 18, 2000 12:09 AM > To: 'stefano.pogliani@sun.com' > Subject: RE: missing(?) header element > > > I think that most of what Stefan says, makes sense. In short we should > define a simple PING that proves that the message service handler is a) > awake and working and b) considers the message it has received is valid. > > What is not so clear, is who has the responsibility for checking that the > message is constructed in accordance with the rules of the business process, > e.g. is it the MSH or the application that checks the validity of: Service, > Action, From, To, Manifest and its correspondence to the requirements of > the business process/protocol that is being followed. > In my opinion, the MSH should check the consistency and the semantic of the Envelope and of the Header and should treat the payload and the manifest as an opaque information. The Application Layer should receive the manifest and the payload and deal with them. The reason that I see in this is that the Manifest (as proposed by someone before, I believe) may contain weak references to some other document. These weak references may be "optional" in the context of message processing, i.e. the application layer may decide to get them or not depending on: - the state of the conversation - the content of some part of the MIME that is processed before - etc etc. /Stefano > David > > -----Original Message----- > From: Stefano POGLIANI [mailto:stefano.pogliani@sun.com] > Sent: Friday, November 17, 2000 6:27 AM > To: ebxml transport > Subject: RE: missing(?) header element > > > At this point, it seems to me that the safest way of dealing would be > to use the "Ping" approach that was proposed somewhere in a previous mail. > > It depends on what the goal is: > > - if the goal is the one originally mentioned by Chris: > > > The purpose of this element (or attribute as the case may > > be) is to enable parties to exchange messages prior to > > actually engaging in e-business, to ensure that their > > systems are prepared to correctly handle the messages > > they send eachother. > > then I think that this is an MSH issue and, for that reason, it > is of no-use to send any "application meaningful" payload along > with the message. > The MSH should be able to use the special type of message (PING ?) > as a way to test its readiness to engage. > > - if the goal is to "test" the application layer, than this should > be completely transparent to the MSH, IMHO. > In this case, the "Test" should be something semantically > understood by the application layer and, thus, part of the > payload. > > The MSH should see this as a message to be passed to the > Application > Layer, as just (almost) any other message. It will be the > App layer to understand that this message has a "particular" > meaning > and to treat it accordingly. > > Again, the Choreography could specify that this "special" message > could be received at some very point of the chain of messages and > should be trated in some way. > > /Stefano > > > > -----Original Message----- > > From: Henry Lowe [mailto:hlowe@omg.org] > > Sent: Friday, November 17, 2000 3:24 PM > > To: ebxml transport > > Subject: Re: missing(?) header element > > > > > > Yep, I agree with Marty -- define an optional application headers > > MIME part for the payload and led the app (BP?) folk decide what > > goes in there. (OK, that's a bit more than what Marty said :-) > > Don't get MS headers munged (good OED word?) by sticking application > > stuff in them!!!! > > > > Best regards, > > Henry > > -------------------- > > At 02:55 PM 11/16/2000 -0500, Martin W Sachs/Watson/IBM wrote: > > > > > >Why would not application headers be simply part of the > > application payload > > >as far as the messaging service is concerned? One answer might > > be that the > > >messaging service (or some plug-in in the application services > > layer) might > > >have to look at information in these headers before the > payload is passed > > >to the application. > > > > > >Regards, > > >Marty > > > > > >***************************************************************** > > *********** > > >********* > > > > > >Martin W. Sachs > > >IBM T. J. Watson Research Center > > >P. O. B. 704 > > >Yorktown Hts, NY 10598 > > >914-784-7287; IBM tie line 863-7287 > > >Notes address: Martin W Sachs/Watson/IBM > > >Internet address: mwsachs @ us.ibm.com > > >***************************************************************** > > *********** > > >********* > > > > > > > > > > > >Christopher Ferris - XTC Advanced Development > <chris.ferris@east.sun.com> > > >@xtacy.East.Sun.COM on 11/16/2000 02:03:09 PM > > > > > >Please respond to ebxml transport <ebxml-transport@lists.ebxml.org> > > > > > >Sent by: cferris@xtacy.East.Sun.COM > > > > > > > > >To: ebxml transport <ebxml-transport@lists.ebxml.org> > > >cc: > > >Subject: Re: missing(?) header element > > > > > > > > > > > >As a follow-up to today's discussion on this topic > > >the following issues were raised: > > > > > >- we need to determine from the other verticals > > > (e.g. RosettaNet, OTA, EDI/INT, Ariba, others) > > > whether this feature is used extensively, and > > > to what end (e.g. does it trickle down to the > > > application layer? via what mechanism is this > > > ensured?)? > > >AI: anyone with specific knowledge or experience > > > in this regard should speak up! ;-) It would > > > also be useful if we could have specific feedback > > > from members participating in other verticals > > > (such as RosettaNet or OTA) as to whether they > > > see this feature as important/critical to > > > acceptance/adoption of ebXML should that question > > > be on the table. > > > > > >- we would need to provide specific language which > > > outlines its purpose and intent. Does it apply > > > exclusively to the MSH or does it apply to the > > > application? Is it used only by convention between > > > two parties engaged in establishing a production > > > exchange, each agreeing to well defined ground-rules > > > for its use? Is its purpose exclusively limited to > > > "testing" the MSH configuration/handling of a > > > given message (e.g. it SHALL NOT be forwarded > > > to application-level routing...) > > > > > >- John Ibbotson and others suggested that a specific > > > MSH Service/Action of MSH/PING might satisfy the > > > requirements better. This would fall into the > > > work (TBD) of defining an MSH "Service Interface" > > > with specific Service/Action pairs which have > > > specific behavior (e.g. expected response, exceptions, > > > etc.) defined. > > > > > >- Scott H and others suggested that without a > > > clearly defined architecture for incorporating > > > "application-level" headers in the ebXML packaging > > > we are essentially left with placing this sort > > > of header element within the body of the ebXMLHeader. > > > > > >- Chris re-raised the issue of adding in an explicit > > > extension mechanism to the ebXML headers to allow for > > > "application-level" headers such as test/production flag, > > > security/session context information, transaction context > > > information (ie. XAML) and others. > > > > > > e.g. > > > > > > <!ELEMENT ebXMLHeader (Manifest, Header, > > > RoutingHeader, ANY)> > > > > > > or > > > > > > <element name="ebXMLHeader" type="ebXMLHeader"/> > > > <complexType name='ebXMLHeader'> > > > <element ref='Manifest' minOccurs='1'/> > > > <element ref='Header' minOccurs='1'/> > > > <element ref='RoutingHeader' minOccurs='0' maxOccurs="1"/> > > > <any minOccurs='0' maxOccurs='*'/> > > > ... > > > </complexType> > > > > > > with the addition of something along the lines of > > > mustUnderstand and actor attributes defined. > > > > > >- Maryann raised the issue of security implications > > > for a test/production indicator as well as possible > > > concerns for XML Signature handling of ebXML headers > > > if an arbitrary extension mechanism were defined. > > > > > >clearly, the issue is still not resolved and there > > >is not yet consensus beyond the fact that the proposed > > >functionality seems to have some potential merit > > >but that the means of conveying this feature needs > > >more work and more thought. > > > > > >Have I captured the highlights of the discussion > > >and issues thus far? > > > > > >Cheers, > > > > > >Chris > > > > > >-- > > > Christopher Ferris > > > _/_/_/_/ _/ _/ _/ _/ Sr Staff Engineer - XTC Advanced > > Development > > > _/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063 > > > _/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM > > > _/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop: UBUR03-313 > > >_/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA > 01803-0903 > > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC