Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Service Oriented Architecture Tools Platform (STP) » Re: [stp-newsgroup] Re: BPEL Compilation
Re: [stp-newsgroup] Re: BPEL Compilation [message #576244] Mon, 24 April 2006 01:02
keanu is currently offline keanuFriend
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">&gt; One problem I hit upon while doing
this is that I didn't want to make <br>
&gt; the engine's debug APIs public, which in turn meant that, following
<br>
&gt; Eclipse conventions, I couldn't have the Debug UI in another plugin
(as <br>
&gt; far as I understand it - I should clarify that actually). &nbsp;Anyway
that's <br>
&gt; all internal code so it's something I hope to resolve at some point
and <br>
&gt; 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 &quot;fragment bundle&quot;, 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>&gt; You make an interesting point that the code could
be further separated <br>
&gt; to run in more limited environments. &nbsp;It would be possible to
separate <br>
&gt; out the BPEL compiler from the engine but <b>it is important to realise
<br>
&gt; that the BPEL compiler would be required by some part of the code
to <br>
&gt; compile the BPEL into a program the engine can run.</b> &nbsp;</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>&gt; One could however <br>
&gt; conceive of a setup where a less limited client compiled the BPEL
and <br>
&gt; 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>&gt; I don't think the right way to separate the code
is necessarily through <br>
&gt; extra plugins though. &nbsp;I think perhaps the simplest answer is
for extra <br>
&gt; builds to be added to the core plugin to generate either<br>
&gt; <br>
&gt; A) the core plugin plus full B2J.jar (default)<br>
&gt; B) the core plugin plus BPEL compiler + engine only B2J.jar<br>
&gt; C) the core plugin plus engine only B2J.jar<br>
&gt; <br>
&gt; Then for anyone that had the requirement, they could build B2J and
<br>
&gt; choose to build a second version of the plugin to deploy on more limited
<br>
&gt; environments.<br>
&gt; <br>
&gt; 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">&nbsp;</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 &nbsp;Email: yspaik@kr.ibm.com<br>
Address : The MMAA Bldg 467-12 Dogok-dong. Gangnam-gu, Seoul, Korea<br>
</font>
--=_alternative 0005D53C4925715A_=--
Previous Topic:BPEL Compilation
Next Topic:Re: [stp-newsgroup] Re: BPEL Compilation
Goto Forum:
  


Current Time: Fri Mar 29 09:53:29 GMT 2024

Powered by FUDForum. Page generated in 0.04084 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top