ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matthieu.r...@gmail.com>
Subject Re: Late binding vs. early binding
Date Thu, 14 Jun 2007 18:41:35 GMT
I agree with the intent but it has non trivial implications. In the current
code base only the ILs now what a service really is, endpoints are
completely opaque to the server, which is good. And sometimes even the IL
doesn't know everything about an endpoint, only whatever we're hooked to
knows (think Axis2 or the JBI bus).

I guess we could have some sort of "best effort" tool that tries to guess
which IL you want to use, tries to understand the format of your endpoints
and all that stuff. But if we write it with only SOAP/HTTP in mind and
somebody configures Axis2 to use JMS, the tool will fail even if your
endpoint is fine.

On 6/14/07, Paul Brown <paulrbrown@gmail.com> wrote:
> On 6/14/07, Matthieu Riou <matthieu.riou@gmail.com> wrote:
> > Currently when you deploy a process, very little gets loaded to save
> memory
> > (some people deploy a lot of processes without using them all). This
> kind of
> > goes with the dehydration but it's just that the default for now is to
> never
> > fully load a process as long as it's not used.
> > However this has some side effects. Mostly you can never be sure after
> > deployment that your process is fully okay, including the services that
> it
> > should invoke. Because the messaging layer loads the WSDL only at first
> > invocation, you might get a nasty error there saying that the services
> > declared in your deploy.xml don't exist at all in your WSDL. Which is
> > usually true but it's the kind of things you'd rather find out at
> deployment
> > time.
> Hmmm.  Hmmmm.
> Well, this seems like functionality that should be part of the bpelc
> step in the toolchain and not part of deployment.  It's a usability
> nightmare to have to debug your process and accompanying metadata at
> deployment time only, and in a production/secure environment, getting
> access to logs may be inconvenient or impossible.  (This was part of
> the motivation for bpelc as a commandline tool in the first place...)
> How about a "deploycheck" commandline tool or other such that provides
> this functionality, either as an alternative to the less lazy loading
> or as an adjunct?  (Seems like we could just use the same code, more
> or less.)
> --
> paulrbrown@gmail.com
> http://mult.ifario.us/

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