Eclipse Community Forums: Service Oriented Architecture Tools Platform (STP)

Help

Home

Home » Archived » Service Oriented Architecture Tools Platform (STP) » Re: [stp-newsgroup] Re: BPEL Compilation

Show: Today's Messages :: Show Polls :: Message Navigator

Re: [stp-newsgroup] Re: BPEL Compilation [message #576184]

Wed, 19 April 2006 10:40

keanu

Messages: 49
Registered: July 2009

Member

This is a multipart message in MIME format.
--=_alternative 003A9CE585257155_=
Content-Type: text/plain; charset="ISO-2022-KR"

$)CThank you for your kind answer. Now many things are clear.
So, the reason why in b2j BPEL is compiled first rather than is
interpreted is
- 1. Faster performance concern
- 2. distributed engine support or multiple engine support
to my understanding.

Actually, I am currently interested in small footprint, lightweight bpel
engine.
As for this reason, I am interested in the b2j bpel server.
The whole size of the core packcage does not excess 1M.
It includes small size web server.
It runs on the eclipse rcp, not the server side big fat enterprise server.
It is very impressive to me. Gorgeous.

Hmmm, I have one curious point here.
Do you think it is good or useless if the b2j core, one big plugin, is
separated into several plugins such as "deploy related" and "really
runtime related" and "UI or debug related", etc.
So the separated runtime can be even smaller than as is, having a small
foot print.
Also if somebody just want "runtime engine only", then the micro-engine
only can be run standalone, while compiler or other stuff are deactivated
or even are not installed.

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+
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

stp-newsgroup-bounces@eclipse.org wrote on 2006-04-18 ?@@| 05:40:03:

> Hi Keanu,
>
> I'll keep this short but a bit of history is useful here.
>
> B2J started out as the Choreography component in the Test and
> Performance Tools Platform (TPTP) as a runtime to link together various
> aspects of the project and to serve as generic test behaviour engine.
>
> These behaviours had certain requirements on the runtime and, in
> particular, load testing behaviours had important requirements regarding

> scalability and performance.
>
> As such, the runtime grew up not as an interpreter of BPEL XML documents

> but with a compilation step that converted the BPEL to Java programs.
> These pure Java programs could run much faster than a Java program
> interpreting a BPEL document.
>
> In addition, the Java programs ran using a framework which could either
> be implemented locally or as distributed nodes (e.g. for large load
> tests involving multiple machines).
>
> This division of the running Java program and the server/runtime
> framework implementation it used was picked up on as a worthwhile
> framework to base runtimes or implementations with other requirements
> around and B2J was born.
>
> The plan now is to solicit requirements from other vendors who wish to
> make use of the B2J code and create or integrate their own runtimes so
> we can evolve the framework to suit.
>
> cheers
>
> Antony
>
> Keanu, Paik wrote:
> > The main feature of B2J is BPEL to java translation and compilation,
> > which is not common for other bpel engine.
> > What is the main reason, or main advantage for compiling bpel into
java?
> >
> _______________________________________________
> stp-newsgroup mailing list
> stp-newsgroup@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/stp-newsgroup

--=_alternative 003A9CE585257155_=
Content-Type: text/html; charset="ISO-2022-KR"

$)C
 Thank you for your kind answer. Now
many things are clear.
 So, the reason why in b2j BPEL is compiled
first rather than is interpreted is
 - 1. Faster performance concern
 - 2. distributed engine support or multiple
engine support
 to my understanding.
 
 Actually, I am currently interested
in small footprint, lightweight bpel engine.
 As for this reason, I am interested
in the b2j bpel server.
 The whole size of the core packcage
does not excess 1M.
 It includes small size web server.
 It runs on the eclipse rcp, not the
server side big fat enterprise server.
 It is very impressive to me. Gorgeous.
 
 Hmmm, I have one curious point here.
 Do you think it is good or useless if
the b2j core, one big plugin, is separated into several plugins such as
"deploy related" and "really runtime related" and "UI
or debug related", etc.
 So the separated runtime can be even
smaller than as is, having a small foot print.
 Also if somebody just want "runtime
engine only", then the micro-engine only can be run standalone, while
compiler or other stuff are deactivated or even are not installed.
 
 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ 
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 

 
 <tt>stp-newsgroup-bounces@eclipse.org wrote on 2006-04-18
?@@| 05:40:03: 
 
> Hi Keanu, 
> 
> I'll keep this short but a bit of history is useful here. 
> 
> B2J started out as the Choreography component in the Test and 
> Performance Tools Platform (TPTP) as a runtime to link together various
 
> aspects of the project and to serve as generic test behaviour engine. 
> 
> These behaviours had certain requirements on the runtime and, in 
> particular, load testing behaviours had important requirements regarding
 
> scalability and performance. 
> 
> As such, the runtime grew up not as an interpreter of BPEL XML documents
 
> but with a compilation step that converted the BPEL to Java programs.
 
> These pure Java programs could run much faster than a Java program
 
> interpreting a BPEL document. 
> 
> In addition, the Java programs ran using a framework which could either
 
> be implemented locally or as distributed nodes (e.g. for large load
 
> tests involving multiple machines). 
> 
> This division of the running Java program and the server/runtime 
> framework implementation it used was picked up on as a worthwhile
 
> framework to base runtimes or implementations with other requirements
 
> around and B2J was born. 
> 
> The plan now is to solicit requirements from other vendors who wish
to 
> make use of the B2J code and create or integrate their own runtimes
so 
> we can evolve the framework to suit. 
> 
> cheers 
> 
> Antony 
> 
> Keanu, Paik wrote: 
> > The main feature of B2J is BPEL to java translation and compilation,
 
> > which is not common for other bpel engine. 
> > What is the main reason, or main advantage for compiling bpel
into java? 
> > 
> _______________________________________________ 
> stp-newsgroup mailing list 
> stp-newsgroup@eclipse.org 
> https://dev.eclipse.org/mailman/listinfo/stp-newsgroup 
</tt>
--=_alternative 003A9CE585257155_=--

Report message to a moderator

Re: [stp-newsgroup] Re: BPEL Compilation [message #576201 is a reply to message #576184]

Thu, 20 April 2006 09:38

Antony Miguel

Messages: 49
Registered: July 2009

Member

The reasons you mention for the java compilation are correct. It is
mainly about performance which came from requirements in TPTP.

Previously B2J was all in one plugin but I realised that as you say
there was a lot of code which was not relevant to the runtime but which
was being distributed with the runtime nonetheless. To that end I
separated out much of the UI and Eclipse-dependant code into B2J.UI and
left the runtime in B2J.CORE.

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.

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. 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?

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?

thanks

Antony

YoungSang Paik wrote:
>
> Thank you for your kind answer. Now many things are clear.
> So, the reason why in b2j BPEL is compiled first rather than is
> interpreted is
> - 1. Faster performance concern
> - 2. distributed engine support or multiple engine support
> to my understanding.
>
> Actually, I am currently interested in small footprint, lightweight bpel
> engine.
> As for this reason, I am interested in the b2j bpel server.
> The whole size of the core packcage does not excess 1M.
> It includes small size web server.
> It runs on the eclipse rcp, not the server side big fat enterprise server.
> It is very impressive to me. Gorgeous.
>
> Hmmm, I have one curious point here.
> Do you think it is good or useless if the b2j core, one big plugin, is
> separated into several plugins such as "deploy related" and "really
> runtime related" and "UI or debug related", etc.
> So the separated runtime can be even smaller than as is, having a small
> foot print.
> Also if somebody just want "runtime engine only", then the micro-engine
> only can be run standalone, while compiler or other stuff are
> deactivated or even are not installed.
>
> *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+
> 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
>
>
> stp-newsgroup-bounces@eclipse.org wrote on 2006-04-18 오전 05:40:03:
>
> > Hi Keanu,
> >
> > I'll keep this short but a bit of history is useful here.
> >
> > B2J started out as the Choreography component in the Test and
> > Performance Tools Platform (TPTP) as a runtime to link together various
> > aspects of the project and to serve as generic test behaviour engine.
> >
> > These behaviours had certain requirements on the runtime and, in
> > particular, load testing behaviours had important requirements regarding
> > scalability and performance.
> >
> > As such, the runtime grew up not as an interpreter of BPEL XML documents
> > but with a compilation step that converted the BPEL to Java programs.
> > These pure Java programs could run much faster than a Java program
> > interpreting a BPEL document.
> >
> > In addition, the Java programs ran using a framework which could either
> > be implemented locally or as distributed nodes (e.g. for large load
> > tests involving multiple machines).
> >
> > This division of the running Java program and the server/runtime
> > framework implementation it used was picked up on as a worthwhile
> > framework to base runtimes or implementations with other requirements
> > around and B2J was born.
> >
> > The plan now is to solicit requirements from other vendors who wish to
> > make use of the B2J code and create or integrate their own runtimes so
> > we can evolve the framework to suit.
> >
> > cheers
> >
> > Antony
> >
> > Keanu, Paik wrote:
> > > The main feature of B2J is BPEL to java translation and compilation,
> > > which is not common for other bpel engine.
> > > What is the main reason, or main advantage for compiling bpel into
> java?
> > >
> > _______________________________________________
> > stp-newsgroup mailing list
> > stp-newsgroup@eclipse.org
> > https://dev.eclipse.org/mailman/listinfo/stp-newsgroup

Report message to a moderator

Re: [stp-newsgroup] Re: BPEL Compilation [message #576219 is a reply to message #576201]

Mon, 24 April 2006 04:26

keanu

Messages: 49
Registered: July 2009

Member

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 concern would be pretty much solved using "fragment bundle" to my
best knowledge.
If 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 your meaning from the sentence "but ~~". 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.
Key point will be whether b2j runtime engine itself can be isolated from
other packages into a separate bundle without any dependency with compiler
or UI.
Then the rest of the module would be combined with the runtime engine to
become a full version, or managed as different version. It actually
doesn't matter, I think.

Report message to a moderator

Re: [stp-newsgroup] Re: BPEL Compilation [message #576226 is a reply to message #576219]

Mon, 24 April 2006 09:31

Antony Miguel

Messages: 49
Registered: July 2009

Member

Hi Keanu,

> Your concern would be pretty much solved using "fragment bundle" to my
> best knowledge. If 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.

This sounds good, I'll look into it.

>> 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 your meaning from the sentence "but ~~". Could you explain
> more about this?

The basic way B2J works is as follows:

1. Take some BPEL and generate Java source code from it.
2. Compile the Java source code into Java classes
3. Run the Java classes inside a runtime framework which provides
certain commonly required functions

So to take some BPEL and run it with B2J you do require a Java compiler
(note that you don't have to use Sun Javac, you could use a much smaller
compiler such as Jikes or Janino).

However. It is possible to have a split between the host that does the
compilation and the host that runs the BPEL process by using the
distributed engine. In this case the host that compiles the BPEL would
require a Java compiler but the host(s) that actually run the BPEL would
not.

You could therefore have a standard PC that compiled the BPEL into Java
classes and connected to a B2J distributed engine daemon on a less
powerful host which would then run the BPEL program sent from the more
powerful host. The host running the B2J engine daemon would not (does
not) depend on any UI or compiler.

In addition, if you didn't want to use the distributed engine and run a
daemon on the limited device you could also just somehow save the
compiled engine program onto the device and run it with the single-host
mini engine.

>> 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. :-)
>

The scene I described above would be just this.

Is this the case that you have? Where you could compile the BPEL on a
standard host and then send it to a limited device to run?

thanks

Antony

Report message to a moderator

Re: [stp-newsgroup] Re: BPEL Compilation [message #576259 is a reply to message #576226]

Mon, 24 April 2006 20:10

keanu

Messages: 49
Registered: July 2009

Member

Hi, Antony

>However. It is possible to have a split between the host that does the
>compilation and the host that runs the BPEL process by using the distributed
>engine. In this case the host that compiles the BPEL would require a Java
>compiler but the host(s) that actually run the BPEL would not.

>You could therefore have a standard PC that compiled the BPEL into Java
>classes and connected to a B2J distributed engine daemon on a less powerful
>host which would then run the BPEL program sent from the more powerful host.

The distributed engine scenario sounds interesting. I thought all (any)
bpel script must be compiled first in the machine that the script will be
running on. But your saying reads to me that a distributed engine can pass
all the compiled classes (or part of the classes) into a target machine.
Sounds amazing. BPEL script itself does not know that the script itself is
compiled. So additional settings might be given to the each distributed
BPEL engine, I guess. Right? I've already read the documents available in
the web pages but I didn't get the information about this. All I got is
from the distribution tutorial, so...
Could you give me some detail document about distributed engine if
publicly okay and available?

>The host running the B2J engine daemon would not (does not) depend on any UI
>or compiler.

Right. You are telling me. That's what I am talking to you. :-) If it does
not depend on any UI or compiler, then could the engine part be seperated
easily out as a different plugin from the whole rest? Couldn't it? The
advantage is the footprint and the scalability. The runtime engine itself
can be run alone, and also can be run with other stuffs. In the standard
PC, the features are not important, but in the embedded device, they are
crucial.

Given that b2j whole plugins are separated into compiler plugin(s),
mini-engine plugin(s), distributed engine plugin(s), debug plugin(s) and
misc plugin(s), then the target host can put the plugins that are really
needed selectively, not the whole fat engine.

>In addition, if you didn't want to use the distributed engine and run a
daemon >on the limited device you could also just somehow save the compiled
engine >program onto the device and run it with the single-host mini engine.

Yes. Exactly. We need the "somehow", though. That's what I am interested.
I am willing to build the "somehow" on top of the b2j.

>Is this the case that you have? Where you could compile the BPEL on a
>standard host and then send it to a limited device to run?

Right. As you use BPEL script in the testing and profiling, rather than in
the business process and workflow that BPEL is commonly used, I will use
BPEL script in the embedded area. So that's why I am interested in this
engine, as I told you. I want to set all things up in the development
phase, and deploy the whatever result to the target machine, keeping the
needed resources of the target platform as small as possible. In my point
of view, mini-engine alone, or distributed engine alone exclusively, is
enough in the target platform. Compiler, other engine that is not used,
and debug or UI stuff can be optional. I mean those can be addable, if
needed, and removable if not needed.

I hope my suggestion is clear to you.
Thank you so much for your interest and kind answer.

Report message to a moderator

Re: [stp-newsgroup] Re: BPEL Compilation [message #576288 is a reply to message #576259]

Tue, 25 April 2006 10:22

Antony Miguel

Messages: 49
Registered: July 2009

Member

Hi Keanu,

>> The host running the B2J engine daemon would not (does not) depend on
>> any UI or compiler.
>
> Right. You are telling me. That's what I am talking to you. :-) If it
> does not depend on any UI or compiler, then could the engine part be
> seperated easily out as a different plugin from the whole rest? Couldn't
> it? The advantage is the footprint and the scalability. The runtime
> engine itself can be run alone, and also can be run with other stuffs.
> In the standard PC, the features are not important, but in the embedded
> device, they are crucial.

Yes the engine could certainly be separated out into a runtime-only JAR.

>> In addition, if you didn't want to use the distributed engine and run a
>
> daemon >on the limited device you could also just somehow save the
> compiled engine >program onto the device and run it with the
> single-host mini engine.
>
> Yes. Exactly. We need the "somehow", though. That's what I am
> interested. I am willing to build the "somehow" on top of the b2j.
>

If the device can support a TCP/IP server then B2J can do this already
via the distributed engine. The distributed engine daemon could sit on
the limited device and the B2J client (workbench) can connect to the
daemon and send it a program to run. The program specifies what hosts to
include but if it only specified one host then the engine would be
constrained to the limited device only quite happily.

The other somehow I was talking about was if the device could not
already support TCP/IP server and the engine program would have to be
saved to the device maybe over some kind of serial connection and then
launched on the device through some other method (which would still be
possible).

>> Is this the case that you have? Where you could compile the BPEL on a
>> standard host and then send it to a limited device to run?
>
> Right. As you use BPEL script in the testing and profiling, rather than
> in the business process and workflow that BPEL is commonly used, I will
> use BPEL script in the embedded area. So that's why I am interested in
> this engine, as I told you. I want to set all things up in the
> development phase, and deploy the whatever result to the target machine,
> keeping the needed resources of the target platform as small as
> possible. In my point of view, mini-engine alone, or distributed engine
> alone exclusively, is enough in the target platform. Compiler, other
> engine that is not used, and debug or UI stuff can be optional. I mean
> those can be addable, if needed, and removable if not needed.

I think generally speaking it only really makes sense to make a split
between the runtime engine and the runtime + rest of core. The rest of
the core is almost entirely taken up by the compiler so if the limited
device wanted to use the compiler and the engine it would pretty much
have to have the entire plugin anyway.

May I ask what type of devices you are looking to run on and what
version of Java they support / what storage space and memory
restrictions they are likely to have?

Assuming the device supports TCP/IP and is accessible from the
development workspace via TCP/IP, the easiest option is:

1. Create a JAR containing only the B2J distributed engine
2. Run the distributed engine daemon on the limited device
3. Connect to it from the workspace and send it BPEL to run.

This is doable today. I have written a preliminary build.xml file to
create a JAR with only the distributed engine in and it gets down to
about 420KB. I haven't tested it to see if it runs yet but I expect it
will be roughly that size.

A further possibility would be to use the single host engine
(mini-engine) and find some way to get the program to it.

The easiest way would be to keep using the distributed engine daemon but
have it run the mini engine. Going via this route you could chop out
unused bits of the distributed engine and I think it would bring the JAR
down to roughly 300KB.

Do either of the options above sound suitable?

thanks

Antony

Report message to a moderator

Re: [stp-newsgroup] Re: BPEL Compilation [message #576294 is a reply to message #576288]

Tue, 25 April 2006 12:17

Antony Miguel

Messages: 49
Registered: July 2009

Member

As a quick follow up to this I have a build.xml file generating a
workbing but cut down version of the B2J jar. The jar is 422KB and
contains the distributed engine, daemon and mini-engine (so everything
required for the runtime). I've tried it with a few of the standard B2J
example BPEL files and everything works fine.

thanks

Antony

Antony Miguel wrote:
> Hi Keanu,
>
>>> The host running the B2J engine daemon would not (does not) depend on
>>> any UI or compiler.
>>
>>
>> Right. You are telling me. That's what I am talking to you. :-) If it
>> does not depend on any UI or compiler, then could the engine part be
>> seperated easily out as a different plugin from the whole rest?
>> Couldn't it? The advantage is the footprint and the scalability. The
>> runtime engine itself can be run alone, and also can be run with other
>> stuffs. In the standard PC, the features are not important, but in the
>> embedded device, they are crucial.
>
>
> Yes the engine could certainly be separated out into a runtime-only JAR.
>
>>> In addition, if you didn't want to use the distributed engine and run a
>>
>>
>> daemon >on the limited device you could also just somehow save the
>> compiled engine >program onto the device and run it with the
>> single-host mini engine.
>
> >
> > Yes. Exactly. We need the "somehow", though. That's what I am
> > interested. I am willing to build the "somehow" on top of the b2j.
> >
>
> If the device can support a TCP/IP server then B2J can do this already
> via the distributed engine. The distributed engine daemon could sit on
> the limited device and the B2J client (workbench) can connect to the
> daemon and send it a program to run. The program specifies what hosts to
> include but if it only specified one host then the engine would be
> constrained to the limited device only quite happily.
>
> The other somehow I was talking about was if the device could not
> already support TCP/IP server and the engine program would have to be
> saved to the device maybe over some kind of serial connection and then
> launched on the device through some other method (which would still be
> possible).
>
>>> Is this the case that you have? Where you could compile the BPEL on
>>> a standard host and then send it to a limited device to run?
>>
>>
>> Right. As you use BPEL script in the testing and profiling, rather
>> than in the business process and workflow that BPEL is commonly used,
>> I will use BPEL script in the embedded area. So that's why I am
>> interested in this engine, as I told you. I want to set all things up
>> in the development phase, and deploy the whatever result to the target
>> machine, keeping the needed resources of the target platform as small
>> as possible. In my point of view, mini-engine alone, or distributed
>> engine alone exclusively, is enough in the target platform. Compiler,
>> other engine that is not used, and debug or UI stuff can be optional.
>> I mean those can be addable, if needed, and removable if not needed.
>
>
> I think generally speaking it only really makes sense to make a split
> between the runtime engine and the runtime + rest of core. The rest of
> the core is almost entirely taken up by the compiler so if the limited
> device wanted to use the compiler and the engine it would pretty much
> have to have the entire plugin anyway.
>
> May I ask what type of devices you are looking to run on and what
> version of Java they support / what storage space and memory
> restrictions they are likely to have?
>
> Assuming the device supports TCP/IP and is accessible from the
> development workspace via TCP/IP, the easiest option is:
>
> 1. Create a JAR containing only the B2J distributed engine
> 2. Run the distributed engine daemon on the limited device
> 3. Connect to it from the workspace and send it BPEL to run.
>
> This is doable today. I have written a preliminary build.xml file to
> create a JAR with only the distributed engine in and it gets down to
> about 420KB. I haven't tested it to see if it runs yet but I expect it
> will be roughly that size.
>
> A further possibility would be to use the single host engine
> (mini-engine) and find some way to get the program to it.
>
> The easiest way would be to keep using the distributed engine daemon but
> have it run the mini engine. Going via this route you could chop out
> unused bits of the distributed engine and I think it would bring the JAR
> down to roughly 300KB.
>
> Do either of the options above sound suitable?
>
> thanks
>
> Antony

Report message to a moderator

Re: [stp-newsgroup] Re: BPEL Compilation [message #580388 is a reply to message #576294]

Tue, 25 April 2006 15:34

keanu

Messages: 49
Registered: July 2009

Member

Hi, Antony

> As a quick follow up to this I have a build.xml file generating a
> workbing but cut down version of the B2J jar. The jar is 422KB and
> contains the distributed engine, daemon and mini-engine (so everything
> required for the runtime). I've tried it with a few of the standard B2J
> example BPEL files and everything works fine.
>
This is great. I want to try it and set things up in my PC. When can I
share this?
You are so diligent, anyway.

Regardless of embedded things, I think the runtime separation would be
good for b2j itself, because the separation would be more natural to the
eclipse "plugin" concept to my understanding. "If they can be separated,
let them separated."
I know this is a quick follow. The big b2j can be separated more to be
"more pluggable."

> >
> > The other somehow I was talking about was if the device could not
> > already support TCP/IP server and the engine program would have to be
> > saved to the device maybe over some kind of serial connection and then
> > launched on the device through some other method (which would still be
> > possible).
> >

Right. That is I am thinking about. I expect so if b2j runtime only
version is still big.

> > A further possibility would be to use the single host engine
> > (mini-engine) and find some way to get the program to it.
> > The easiest way would be to keep using the distributed engine daemon but
> > have it run the mini engine. Going via this route you could chop out
> > unused bits of the distributed engine and I think it would bring the JAR
> > down to roughly 300KB.
> >
> > Do either of the options above sound suitable?
This is just great.

Thank you for your effort and kind answer. It will be extremely valuable.

Best regards,
Keanu,

Report message to a moderator

Previous Topic:	Re: [stp-newsgroup] Re: BPEL Compilation
Next Topic:	STP Service Creation (SC) Sub-project page published

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 08:18:40 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter