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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa-ws message

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


Subject: Re: [ebxml-cppa-ws] initial discussion


Rajesh Pradhan wrote:

>Hi Keith,
>
>Thanks for the heads up. I had a few comments / observations  ...
>
>1. I agree with your assessment about the Arvola docs. They definitely seem
>to be in camp I.
>
>2. I think that WS Interoperability needs to be at a much deeper level. e.g.
>one of the scenarios we are working with involves a vendor who has already
>implemented a Basic web services framework. They now need the business
>capabilities of the CPPA thrown around it. In addition, they need the key
>features of a ebMSH runtime to augment their services.
>
>We thought that the logical fit seems to be a ebMSH runtime with the CPPA
>for configuration and a web services based BSI. However, we were not sure
>how the mapping would be effected.
>  
>
mm1: Wouldn't the BSI be coordinated with or the effort reside in BPSS?

>3. Publishing the CPPA as a WSDL is a good solution for an inside - out
>scenario : connecting web services infrastructures to to ebXML ecosystems.
>We have not run into these so far, so I have no comments for this :)
>
>
>Are we going to look at the ebMSH bindings too ? Or is our scope restricted
>to just the CPPA and its WSDL bindings ?
>
>I hope this makes some sense in our context ....
>
>
>Regards,
>
>Rajesh.
>
>-----Original Message-----
>From: Keith Babo [mailto:keith.babo@Sun.COM]
>Sent: Friday, May 09, 2003 1:44 AM
>To:
>Subject: [ebxml-cppa-ws] initial discussion
>
>
>
>Greetings,
>
>This is the first in a series of messages that I will send to the list
>to
>get things kicked off in the Web Services subgroup.  Unless there are
>any
>objections, the initial order of business will be to establish the
>requirements
>and objectives of the team.  Next, I would like to have a series of
>high-level
>discussions on possible solutions/approaches, followed by a concrete
>plan of
>action for implementation.  Pretty standard stuff. ;-)
>
>
>One of the most important things we need to iron out is what our
>operating
>charter will be in the upcoming months.  Based on my review of previous
>activities in this SC, the web services effort seems to break down into
>two
>separate camps:
>
> Camp 1) Identify integration points between CPP (and possibly CPA?) and
>
> WSDL documents to achieve a WSDL representation of CPP content.
>
> Camp 2) Identify methods for introducing variability into the existing
> CPPA schema to accommodate a broader range of web services activities
> (business choreography, security, reliability, etc.)
>
>
>I definitely get the impression that the previous work done by Arvola,
>et al.,
>was in Camp 1.  Based on previous F2F presentation materials, I gathered
>that
>the main thrust of their activity was towards establishing an
>'exportable'
>representation of CPP/CPA content in the form of WSDL.  Naturally, the
>effort
>focused on representing configuration details below the business
>collaboration
>layer.  One open item is whether this work should be continued.  Yet
>another
>is whether or not the scope of this work should be expanded to include
>the
>representation of business collaboration details within WSDL (perhaps by
>
>importing/substituting CPPA collaboration definitions??).
>
>Camp 2 seems to be a bit more apropos given the alignment discussions of
>late.
>Essentially, the main effort involved here is to allow for the
>integration of
>other WS definitions within a CPP/A document.  Without getting into the
>technical details at this point, I would like to iron out the goals of
>the
>effort.  Specifically, I feel we should develop a strategy for including
>
>additional specifications 'by reference' that will not lead to a
>hard-coded
>binding to any particular definition/specification.
>
>In the upcoming weeks, I would like to narrow down our focus a bit to
>include
>some substantial (yet achievable) objectives.  Once we trim the fat, so
>to
>speak, then we can go neck deep into the technical details.
>
>cheers,
>keith
>
>
>
>  
>




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