Re: [ebxml-jc] RE: update on Versatile B2B gateway

[Monica J Martin <Monica.Martin@Sun.COM>]

Jacques, do you intend to have this published on ebxml.org? Thanks.

> durand: Here is an update based on Pim's comments. Mostly:
>
>  - not making the gateway appear as only possible with ebMS V3.
>
> - reduce emphasis on WS-Addressing (not critical to its function, 
> though a natural enabler with ebMS3)
>
> - reminding that SOAP and WS on the back-end are just use cases...
>
>  
>
> Jacques
>
> ------------------------------------------------------------------------
>
> *From:* Pim van der Eijk [mailto:pim.vandereijk@oasis-open.org]
> *Sent:* Tuesday, January 24, 2006 1:13 AM
> *To:* ebxml-jc@lists.oasis-open.org
> *Subject:* [ebxml-jc] RE: update on Versatile B2B gateway
>
>  
>
> Hello Jacques,
>
>  
>
> This document was mentioned on the call yesterday, and I remembered I 
> hadn't provided feedback to it yet.
>
>  
>
> First of all, I think it is a really good document, which I think 
> should be posted, when final, on the ebXML.org site (I'll check with 
> my colleagues).  There is a recently updated OASIS template for white 
> papers you could use for it. 
>
> http://docs.oasis-open.org/templates/ 
>
>  
>
> Some other comments:
>
> Page 2, when a message is not a service invocation.
>
> Implicit in the first bullet where you mention BPM, the message may be 
> just a way to transport e.g. documents intended for human 
> consumption.  There may be a mapping from ebMS header fields 
> RefToMessageId and ConversationId to workflow processes or to route 
> the document to the responsible employee.  There are actual projects 
> using ebXML for this, e.g. in eGovernment to reduce paper-based 
> processing.
>
>  
>
> <JD> right, the mapping of the message to the process instance is 
> likely to involve content semantics, i.e. some value in a field. If a 
> service were to do this, its job would be to dispatch the doc to the 
> right service instance after looking at this content (say a 
> conversationId). Rather contrived... Plus, as a doc may be expected at 
> different places in the process instance, and again the "type" of the 
> document is not necessarily 1-to-1 with the workstep in the process, 
> then the service would not have this intelligence. It would be a 
> rather lame publisher to a queue.
>
>  
>
> Page 4 and Figure 1 on page 5, these mention ebMSv3.  The current 
> OASIS/ISO 15000-2 Standard offers many of the same benefits, and its 
> security and reliability features (while further updated in some WS 
> specifications) are quite stable and reliable.  It is good to mention 
> the added features of ebMSv3, but I would suggest you talk about ebMS 
> (without version number) in the general text. I am a bit concerned 
> that people may interpret this as saying there is no (longer any) 
> value in ebMS2 today, which isn't true and may upset some people that 
> actually use it today.  This comment applies to other figures.
>
>  
>
> <JD> Right, Fig 1 should have just ebMS. Now, every other fig involves 
> message "pulling" which is only supported by V3. Also, Fig 2 shows a 
> "SOAP intermediary" usage of the MSH that was not possible in ebMS2. 
> However, Fig 3 could be made ebMS too: the pulling is not essential to 
> Fig 3. I agree that the doc should also apply to ebMS2 even if V3 
> provides additional support for the SOA pattern. Will modify.
>
>  
>
> Perhaps this and other diagrams should also explicitly indicate that 
> within the enterprise SOAP requests are just one way of connecting to 
> backend systems (JMS, MQ, Tib/Rendezvous etc.). This is implicit in 
> later references to integration brokers.
>
>  
>
> <JD> yes. Although Fig 2 and 4 are focusing on the SOAP request case 
> (using the MSH for routing WS invocations).
>
>  
>
> Page 5, this suggests WS-Addressing is effectively a prerequisite to 
> support this pattern, which seems too strong (it is useful, but 
> couldn't the functionality described be achieved using more convential 
> methods?).
>
>  
>
> <JD> good point: WS-A is mostly of interest when forwarding to WS on 
> the back-end. Will make this requirement more relative to this.
>
>  
>
> As a more general comment, the document is mainly focussed on the 
> connectivity and decoupling features of the B2B gateway. It does not 
> discuss trading configuration, partner management, activity monitoring 
> and business process (choreography) support.  But perhaps those 
> deserve separate white papers ...
>
>  
>
> <JD> Right. The doc just addresses one function (connectivity) in the 
> SOA architecture, and this "integration pattern" does not exclude 
> these other functions - it only involves messaging. Clearly there 
> should be other integration patterns involving other ebXML specs - it 
> is just we expect them to be separately described. I should make that 
> clearer.
>
>  
>
> I hope you find these comments useful.
>
>  
>
> <JD> definitely - thanks!
>
>  
>
> Best regards,
>
>  
>
> Pim van der Eijk
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
> Since there will be quite some time until ebMS
>
> I would suggest you mention In figure  
>
>  
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Jacques Durand [mailto:JDurand@us.fujitsu.com]
> *Sent:* 08 December 2005 02:37
> *To:* 'Monica J Martin'; Breininger, Kathryn R; Ian Jones
> *Cc:* 'Pim van der Eijk'
> *Subject:* update on Versatile B2B gateway
>
> An update of the previous "Versatile B2B gateway" SOA design pattern 
> draft, that was submitted to ebSOA TC.
> - The "synchronous WS request-response" case was added as one of the 
> cases for Fig 2.
> - Fig 3 was remodeled to show the document exchanges and its back-end 
> binding to be appropriate in case of business processes.
>
> Jacques
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>  
>