One comment inline ...
> -----Original Message-----
> From: Michael Rowley [mailto:]
> Sent: Thursday, Jan 10, 2008 9:37 AM
> To: Anish Karmarkar
> Cc: OASIS BPEL
> Subject: RE: [sca-bpel] Issue 2 - Does the spec allow a
> componentType side file?
>
>
>
> The assembly spec currently says: "The location of the component type
> file depends on the type of the component implementation: it is
> described in the respective client and implementation model
> specification for the implementation type."
>
> In my opinion, the SCA BPEL spec should define _how_ to find
> a component
> type side file for a BPEL process, rather than _where_ to find them.
> This is based on the fact that we don't typically use
> locations to refer
> to XML definitions. <implementation.bpel> and
> <implementation.componentType> both refer to their implementations by
> QName, not by a location.
>
> Therefore, I think that we should say that SCA finds the ComponentType
> for a BPEL process named "foo:bar" by finding any
> ComponentType document
> that has <implementation.bpel qname="foo:bar">, wherever it might be
> within the contribution.
I think it is optional for a ComponentType side file to include an
<implementation.xxx ...> element, which makes me wonder if the proposed
mechanism for 'how' to find a side file will always work.
-- Sanjay
>
> Michael
>
>
> -----Original Message-----
> From: Anish Karmarkar [mailto:]
> Sent: Thursday, November 01, 2007 2:45 AM
> To: Michael Rowley
> Cc: OASIS BPEL
> Subject: Re: [sca-bpel] Issue 2 - Does the spec allow a componentType
> side file?
>
> Comments inlined below as [AK: inline].
>
> -Anish
> --
>
> Michael Rowley wrote:
> >
> >
> > [MR: inline]
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Anish Karmarkar [mailto:]
> > Sent: Friday, October 19, 2007 3:48 PM
> > To: Michael Rowley
> > Cc: OASIS BPEL
> > Subject: Re: [sca-bpel] Issue 2 - Does the spec allow a
> componentType
> > side file?
> >
> >
> >
> > Michael Rowley wrote:
> >
> >> One thing a side file might be used for is to override the default
> >
> >> algorithm that decides on which partnerlinks are services
> and which
> are
> >
> >> references. Do you agree?
> >
> >
> >
> > Yes I do agree. That is why I raised the issue.
> >
> > If the side file is present then the default does not apply.
> >
> >
> >
> > [MR: Unfortunately, the assembly spec says that "Component type
> > information found in the component type file must be compatible with
> the
> > equivalent information found from inspection of the implementation."
> If
> > we "override the default", then we are not compatible with the
> > information found from inspection :-(.]
> >
>
> [AK: I view what is said in the assumbly spec differently. The
> information found in the BPEL process must be compatible with
> the info
> in the CT side file. So, if there are sca extensions in the
> BPEL process
>
> (eg: sca:property attribute) then that must be compatible
> with what is
> in the side file. Such a BPEL process is SCA aware. I would
> image that
> we would have extensions for everything that one could specify in the
> sidefile. I don't think defaults should apply to sca-aware processes.
> Otherwise there is no way to override defaults. If the process is not
> sca-aware and there is no side file than the defaults kick in. If the
> process is not sca-aware and there is side file, then the side file
> rules.]
>
> >
> >
> >> If so, I think the side file would have to
> >
> >> have a way of pointing from a service or reference
> declaration to a
> >
> >> partnerlink.
> >
> >
> >
> > To do so would require extending the <componentType> defined by
> >
> > assembly. We have already done that in section 2 by introducing
> >
> > <implementation.bpel process="xs:QName" .../>.
> >
> >
> >
> > [MR: I think this may have been a mistake in a recent editing pass.
> In
> > the 1.0 version of these documents, it showed a <component> element,
> not
> > a <componentType> element.]
>
> [AK: Ok, I'll raise a separate issue for this]
>
> >
> >
> >
> > ----- sidebar -----
> >
> > BTW, a separate issue: why is that needed? The other C&Is do not do
> >
> > this. Furthermore, the assembly spec says:
> >
> > "A component type file has the same name as the implementation file
> but
> >
> > has the extension ".componentType". The component type is
> defined by a
> >
> > componentType element in the file. The location of the
> component type
> >
> > file depends on the type of the component implementation: it is
> >
> > described in the respective client and implementation model
> >
> > specification for the implementation type."
> >
> > So what we need is is not an <implementation.bpel> element in the
> >
> > componentType file, but the location of the componentType file (or
> raise
> >
> > an issue against the assembly spec).
> >
> > ----- side bar -----
> >
> >
> >
> > So your suggestion would be to extend /componentType/service and
> >
> > /componentType/reference elements to include the partnerlink. Right?
> >
> >
> >
> > [MR: A reference to a partnerlink, yes.]
> >
> >
> >
> > A subissue (or perhaps a different issue) related to this
> is: we would
> >
> > need additional SCA BPEL extensions in section 3 to mark
> services and
> >
> > references (in addition to properties and multirefs). This
> would allow
> >
> > one to specify equivalent information in a side file or in the BPEL
> >
> > process itself (similar to what Java has done). I.e., side
> file would
> be
> >
> > optional as far as provided functionality goes.
> >
> >
> >
> > [MR: I agree]
> >
>
> [AK: ok, will raise a separate issue for this]
>
> >
> >
> > Yet another subissue is: if my BPEL process is SCA aware,
> for example
> it
> >
> > has sca:property or sca:multiReference in it (and potentially
> >
> > sca:service, sca:reference elements if we add it -- see subissue
> above),
> >
> > do the default rules still apply?
> >
> >
> >
> > [MR: I don't understand. The default rules would be for the
> > partnerlinks that are not so marked.]
> >
>
> [AK: if my process is sca-aware I can mark all the
> partnerlinks that I
> want to expose as services/references. I don't need
> defaulting. I want
> to have control. Default should apply when there is no SCA-specific
> mark-up and no side file. Otherwise I don't have a way to say
> -- don't
> expose this partner-link as an sca ref or service]
>
> -Anish
> --
>
> >
> >
> > Michael
> >
> >
> >
> > Comments?
> >
> >
> >
> > -Anish
> >
> > --
> >
> >
> >
> >>
> >
> >> Michael
> >
> >>
> >
> >> -----Original Message-----
> >
> >> From: Anish Karmarkar [mailto:]
> >
> >> Sent: Thursday, October 18, 2007 1:58 AM
> >
> >> To: OASIS BPEL
> >
> >> Subject: Re: [sca-bpel] Issue 2 - Does the spec allow a
> componentType
> >
> >> side file?
> >
> >>
> >
> >> Proposed resolution:
> >
> >>
> >
> >> In section 2, line 194 add --
> >
> >> It is also possible to have a component type file that is
> associated
> >
> >> with the BPEL component implementation. When such a component type
> file
> >
> >> is present, as specified in [SCA-Assembly], it provides component
> type
> >
> >> information in addition to what is found by introspection.
> >
> >>
> >
> >>
> >
> >> Do we need to define compatibility between what is found by
> >
> >> introspection and what is available in the side file?
> >
> >>
> >
> >> Comments?
> >
> >>
> >
> >> -Anish
> >
> >> --
> >
> >>
> >
> >> Alex Yiu wrote:
> >
> >> > Issue entered:
> >
> >> > http://www.osoa.org/jira/browse/BPEL-2
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >> > Anish Karmarkar wrote:
> >
> >> >> Title: Does the spec allow a componentType side file
> >
> >> >>
> >
> >> >> Target: BPEL C&I spec
> >
> >> >>
> >
> >> >> Description: The spec does not say whether a componentType side
> file
> >
> >> >> is allowed. If it is allowed then it should override the default
> >
> >> rules
> >
> >> >> specified in the spec.
> >
> >> >>
> >
> >> >> Proposal:
> >
> >> >> <none>
> >
> >> >
> >
>
> ---------------------------------------------------------------------
> 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_workgr
> oups.php
>
>
