Re: [stp-newsgroup] Re: BPEL Compilation [message #576244] |
Mon, 24 April 2006 01:02 |
keanu Messages: 49 Registered: July 2009 |
Member |
|
|
This is a multipart message in MIME format.
--=_alternative 0005D53C4925715A_=
Content-Type: text/plain; charset="US-ASCII"
Thank you for your kind answer. I understand what is your point.
> One problem I hit upon while doing this is that I didn't want to make
> the engine's debug APIs public, which in turn meant that, following
> Eclipse conventions, I couldn't have the Debug UI in another plugin (as
> far as I understand it - I should clarify that actually). Anyway that's
> all internal code so it's something I hope to resolve at some point and
> move around to further reduce the core plugin size.
Your requirement would be pretty much solved just using "fragment bundle",
I believe.
Given that you seperate out debug related packages into a fragment bundle,
you don't need to externalize your apis to other plugins.
Fragment bundle is operated as one bundle combining with a master bundle
in runtime.
> You make an interesting point that the code could be further separated
> to run in more limited environments. It would be possible to separate
> out the BPEL compiler from the engine but it is important to realise
> that the BPEL compiler would be required by some part of the code to
> compile the BPEL into a program the engine can run.
I don't get it. Could you explain more about this?
> One could however
> conceive of a setup where a less limited client compiled the BPEL and
> ran it on a more limited device with just engine installed?
Hmmm. Yes. It's me. :-)
> I don't think the right way to separate the code is necessarily through
> extra plugins though. I think perhaps the simplest answer is for extra
> builds to be added to the core plugin to generate either
>
> A) the core plugin plus full B2J.jar (default)
> B) the core plugin plus BPEL compiler + engine only B2J.jar
> C) the core plugin plus engine only B2J.jar
>
> Then for anyone that had the requirement, they could build B2J and
> choose to build a second version of the plugin to deploy on more limited
> environments.
>
> Would this be good from your point of view?
Fine. Simplest is the best.
Right. Key challenge will be whether b2j runtime engine can be isolated
into a separate bundle without any dependency.
Thank you for your kind answer, again.
Best regards,
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+
Paik, YoungSang (Keanu)
Advanced Mobile Solution Technology Team in Ubiquitous Computing Lab (UCL)
IBM, Korea
Tel: (822)3781-7509, (8211)898-7509 Email: yspaik@kr.ibm.com
Address : The MMAA Bldg 467-12 Dogok-dong. Gangnam-gu, Seoul, Korea
--=_alternative 0005D53C4925715A_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="Tahoma">Thank you for your kind answer. I understand
what is your point.</font>
<br>
<br><font size=2 face="Tahoma">> One problem I hit upon while doing
this is that I didn't want to make <br>
> the engine's debug APIs public, which in turn meant that, following
<br>
> Eclipse conventions, I couldn't have the Debug UI in another plugin
(as <br>
> far as I understand it - I should clarify that actually). Anyway
that's <br>
> all internal code so it's something I hope to resolve at some point
and <br>
> move around to further reduce the core plugin size.<br>
</font>
<br><font size=2 face="Tahoma">Your requirement would be pretty much solved
just using "fragment bundle", I believe. </font>
<br><font size=2 face="Tahoma">Given that you seperate out debug related
packages into a fragment bundle,</font>
<br><font size=2 face="Tahoma">you don't need to externalize your apis
to other plugins. </font>
<br><font size=2 face="Tahoma">Fragment bundle is operated as one bundle
combining with a master bundle in runtime.</font>
<br>
<br>
<br><tt><font size=2>> You make an interesting point that the code could
be further separated <br>
> to run in more limited environments. It would be possible to
separate <br>
> out the BPEL compiler from the engine but <b>it is important to realise
<br>
> that the BPEL compiler would be required by some part of the code
to <br>
> compile the BPEL into a program the engine can run.</b> </font></tt>
<br>
<br><tt><font size=2>I don't get it. Could you explain more about this?</font></tt>
<br>
<br>
<br><tt><font size=2>> One could however <br>
> conceive of a setup where a less limited client compiled the BPEL
and <br>
> ran it on a more limited device with just engine installed?<br>
</font></tt>
<br><font size=2 face="Tahoma">Hmmm. Yes. It's me. :-)</font>
<br>
<br>
<br><tt><font size=2>> I don't think the right way to separate the code
is necessarily through <br>
> extra plugins though. I think perhaps the simplest answer is
for extra <br>
> builds to be added to the core plugin to generate either<br>
> <br>
> A) the core plugin plus full B2J.jar (default)<br>
> B) the core plugin plus BPEL compiler + engine only B2J.jar<br>
> C) the core plugin plus engine only B2J.jar<br>
> <br>
> Then for anyone that had the requirement, they could build B2J and
<br>
> choose to build a second version of the plugin to deploy on more limited
<br>
> environments.<br>
> <br>
> Would this be good from your point of view?<br>
</font></tt>
<br><font size=2 face="Tahoma">Fine. Simplest is the best. </font>
<br><font size=2 face="Tahoma">Right. Key challenge will be whether b2j
runtime engine can be isolated into a separate bundle without any dependency.</font>
<br>
<br><font size=2 face="Tahoma">Thank you for your kind answer, again.</font>
<br><font size=2 face="Tahoma"> </font>
<br><font size=2 face="Tahoma">Best regards,</font>
<br><font size=2 face="sans-serif">*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ <br>
Paik, YoungSang (Keanu)<br>
Advanced Mobile Solution Technology Team in Ubiquitous Computing Lab (UCL)<br>
IBM, Korea<br>
<br>
Tel: (822)3781-7509, (8211)898-7509 Email: yspaik@kr.ibm.com<br>
Address : The MMAA Bldg 467-12 Dogok-dong. Gangnam-gu, Seoul, Korea<br>
</font>
--=_alternative 0005D53C4925715A_=--
|
|
|
Powered by
FUDForum. Page generated in 0.04084 seconds