ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Waterman" <lance.water...@gmail.com>
Subject Re: Issue 10 / Versioning
Date Wed, 09 Aug 2006 00:05:05 GMT
Alex,

inline ...

On 8/8/06, Alex Boisvert <boisvert@intalio.com > wrote:
>
>
> What is the benefit of forcing the service signature to be the same for
> a given process name?   Is there a complexity aspect that I am
> missing?   It seems like the engine is trying to enforce a specific
> policy instead of providing a flexible deployment mechanism.


I think what I hear you saying is that you want to be able to aggregate
several versions of a BPEL process into a single service interface. Such
that this aggregated service interface can serve as the interface for
several BPEL process versions. I understand this however, what do you
propose when the operation+endpoint are identical between process versions?
How does the engine know which one to route to ( and I don't want to require
a change to the client )?

Say I change the signature of a Java class, do I need to change its name?


Alex, I think using Java as an analogy is a good way to convey
patterns/concepts however, when it's posted as a rhetorical question like
this I think it comes across a bit condescending. I'm sure that wasn't your
intent but none the less it doesn't work for me. Now, to move forward with
your analogy, if I were able to deprecate ( i.e. retire ) specific
operations - is that where you are going? Is this something that shows up in
the service interface? Does the operation just stop working for deprecated
operations?


alex
>
> Lance Waterman wrote:
> > I think if P(v1) and P(v2) have different operation+endpoint then P(v2)
> > should be a new process definition ( name/namespace ) and not a new
> > version.
> > It seems like P(v2) is trying to define a new interface for P(v1). What
> > happens if P(v1) and P(v2) do have the same operations and both are
> > active?
> > I think in the typical use case we are trying to solve ( i.e. the
> > client app
> > is not required to change )..
> >
> > Lance
> >
> >
> > On 8/8/06, Alex Boisvert <boisvert@intalio.com> wrote:
> >>
> >> Maciej Szefler wrote:
> >> > I think that clarifies it, and also suggests that our terminology
> >> is not
> >> > the best. The things that is confusing is that the retired
> >> processes are
> >> > not "inactive". Lance's 'current' is better in this respect, but
> >> has no
> >> > good opposite (perhaps "legacy").
> >> >
> >>
> >> Retired only means that you cannot create new instances -- existing
> >> instances remain active and are allowed to complete normally.  This
> >> terminology is already used in other widely available process engines
> >> and that's why I've been using it.
> >>
> >> Again, I don't understand why we need the concept of "current" since
> you
> >> only need to define which process is logically hooked to a given
> >> operation+endpoint for routing purposes.
> >>
> >> Or said another way, I don't understand why you could not have P (v1)
> >> and P (v2) both activated at the same time if they do not share the
> same
> >> operation+endpoints.
> >>
> >> alex
> >>
> >>
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message