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 #373983]

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

Re: [stp-newsgroup] Re: BPEL Compilation [message #373984 is a reply to message #373983]

Wed, 26 April 2006 10:27

Antony Miguel

Messages: 49
Registered: July 2009

Member

Hi Keanu,

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

I've checked in some code changes and a build.xml file with two targets
into CVS HEAD. You should be able to download both B2J plugins
anonymously from CVS and compile them.

Once you have them compiling OK you can right-click on the build.xml
file and select 'Run As ...' -> 'Ant Build...'. You should see a window
pop up where you can either check 'b2j_full' or 'b2j_runtimeOnly'. Both
of these build the B2J jar file but the 'b2j_runtimeOnly' target builds
the JAR with only the runtime components.

Note that if you build the JAR with only the runtime components then you
can't use that JAR as part of the Eclipse plugin because it doesn't
include important essential classes.

Instead you should right-click the core plugin, select:

-> Export
-> Deployable Plug-ins and Fragments
-> check org.eclipse.stp.b2j.core
-> (IMPORTANT) UN-check 'Package plug-ins as individual JAR archives'

and then deploy just the B2J core plugin to some directory. You can
then run the build.xml and copy the smaller B2J JAR file into this
directory, overwriting the deployed B2J JAR.

When you've done that you should have a reduced size, ready to run B2J
runtime (run the .bat file to give it a try). This is what you will
need to have on the limited device.

Some extra things to note:

- If you run Eclipse with B2J and start a BPEL process without running
the engine manually in another process an engine daemon will be started
inside the Eclipse JVM which will prevent you from running an engine
manually.

- The distributed B2J engine currently automatically self-updates all
nodes by sending the current JAR across if the client version does not
match the daemon version. If you have limited space on the device then
you may not wish B2J to do self-updating and you may wish to manage the
versioning yourself. In this case I can add a switch to the default
conf.xml file for you to turn off this behaviour.

- The B2J engine program also contains and passes around dependancy JARs
where necessary (see
http://www.eclipse.org/stp/b2j/docs/tutorials/deployment/dep loyment_tut.php).
These JARs need to be written to some temporary space on the device
before the program can run. By default there are no extra JARs but if
you use some 3rd party endpoints or create your own Java endpoints then
this is how they will be distributed and the device will need some
temporary space to hold the JARs.

- B2J generally requires a 1.4 JVM. It is possible to run it on a 1.3
JVM but you need some extra JARs for things like XML DOM support. If
you need to run it on a 1.3 JVM let me know and I'll tell you what extra
JARs you need etc.

- The B2J distributed engine forks the JVM when a new engine is started
and uses the topology shown in

http://www.eclipse.org/stp/b2j/docs/architecture/architectur e.php

(3rd figure, under B2J Distributed Engine Implementation)

This is mainly for robustness so that the daemon is never brought down
or damaged by any running engine. If your device won't support so many
JVMs you can edit the Default/conf.xml file and change

<JvmFork>
<Fork>true</Fork>

to

<JvmFork>
<Fork>false</Fork>

Whereupon the daemon will launch all new engine components in the same
JVM rather than in a new one (it's been a while since I tested this so
you may encounter issues when running in this mode).

>> > 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,

Let me know how you get on and if you have any trouble building / running.

If you need the jar to be smaller you will either want to use the
distributed engine daemon to run the mini engine (which is an option I
can add) or you will need to copy across the program yourself and launch
it yourself in the mini-engine. In this case I can produce another
build.xml target containing just the mini-engine.

Thanks

Antony

Report message to a moderator

Re: [stp-newsgroup] Re: BPEL Compilation [message #373985 is a reply to message #373984]

Wed, 26 April 2006 14:51

Antony Miguel

Messages: 49
Registered: July 2009

Member

Hi Keanu,

Since it's generally useful information and since STP isn't doing builds
yet I've written a quick tutorial on how to build B2J from CVS. It's
linked from the main B2J page under 'B2J for Developers' or you can go
to it direct at:

http://www.eclipse.org/stp/b2j/docs/development/buildfromsrc .php

Theres a section at the bottom that describes the 'runtime only' case.

thanks

Antony

Antony Miguel wrote:
> Hi Keanu,
>
>>> 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.
>
>
> I've checked in some code changes and a build.xml file with two targets
> into CVS HEAD. You should be able to download both B2J plugins
> anonymously from CVS and compile them.
>
> Once you have them compiling OK you can right-click on the build.xml
> file and select 'Run As ...' -> 'Ant Build...'. You should see a window
> pop up where you can either check 'b2j_full' or 'b2j_runtimeOnly'. Both
> of these build the B2J jar file but the 'b2j_runtimeOnly' target builds
> the JAR with only the runtime components.
>
> Note that if you build the JAR with only the runtime components then you
> can't use that JAR as part of the Eclipse plugin because it doesn't
> include important essential classes.
>
> Instead you should right-click the core plugin, select:
>
> -> Export
> -> Deployable Plug-ins and Fragments
> -> check org.eclipse.stp.b2j.core
> -> (IMPORTANT) UN-check 'Package plug-ins as individual JAR archives'
>
> and then deploy just the B2J core plugin to some directory. You can
> then run the build.xml and copy the smaller B2J JAR file into this
> directory, overwriting the deployed B2J JAR.
>
> When you've done that you should have a reduced size, ready to run B2J
> runtime (run the .bat file to give it a try). This is what you will
> need to have on the limited device.
>
> Some extra things to note:
>
> - If you run Eclipse with B2J and start a BPEL process without running
> the engine manually in another process an engine daemon will be started
> inside the Eclipse JVM which will prevent you from running an engine
> manually.
>
> - The distributed B2J engine currently automatically self-updates all
> nodes by sending the current JAR across if the client version does not
> match the daemon version. If you have limited space on the device then
> you may not wish B2J to do self-updating and you may wish to manage the
> versioning yourself. In this case I can add a switch to the default
> conf.xml file for you to turn off this behaviour.
>
> - The B2J engine program also contains and passes around dependancy JARs
> where necessary (see
> http://www.eclipse.org/stp/b2j/docs/tutorials/deployment/dep loyment_tut.php).
> These JARs need to be written to some temporary space on the device
> before the program can run. By default there are no extra JARs but if
> you use some 3rd party endpoints or create your own Java endpoints then
> this is how they will be distributed and the device will need some
> temporary space to hold the JARs.
>
> - B2J generally requires a 1.4 JVM. It is possible to run it on a 1.3
> JVM but you need some extra JARs for things like XML DOM support. If
> you need to run it on a 1.3 JVM let me know and I'll tell you what extra
> JARs you need etc.
>
> - The B2J distributed engine forks the JVM when a new engine is started
> and uses the topology shown in
>
> http://www.eclipse.org/stp/b2j/docs/architecture/architectur e.php
>
> (3rd figure, under B2J Distributed Engine Implementation)
>
> This is mainly for robustness so that the daemon is never brought down
> or damaged by any running engine. If your device won't support so many
> JVMs you can edit the Default/conf.xml file and change
>
> <JvmFork>
> <Fork>true</Fork>
>
> to
>
> <JvmFork>
> <Fork>false</Fork>
>
> Whereupon the daemon will launch all new engine components in the same
> JVM rather than in a new one (it's been a while since I tested this so
> you may encounter issues when running in this mode).
>
>>> > 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,
>
>
> Let me know how you get on and if you have any trouble building / running.
>
> If you need the jar to be smaller you will either want to use the
> distributed engine daemon to run the mini engine (which is an option I
> can add) or you will need to copy across the program yourself and launch
> it yourself in the mini-engine. In this case I can produce another
> build.xml target containing just the mini-engine.
>
> Thanks
>
> Antony

Report message to a moderator

Re: [stp-newsgroup] Re: BPEL Compilation [message #373986 is a reply to message #373985]

Thu, 27 April 2006 02:41

keanu

Messages: 49
Registered: July 2009

Member

Hi, Antony,

Great. I am very thankful to see this. I'll try tomorrow and give you
feedback.
If I have some questions during test according to your script, I'll ask
you then.

> Some extra things to note:
>
> - The distributed B2J engine currently automatically self-updates all
> nodes by sending the current JAR across if the client version does not
> match the daemon version. If you have limited space on the device then
> you may not wish B2J to do self-updating and you may wish to manage the
> versioning yourself. In this case I can add a switch to the default
> conf.xml file for you to turn off this behaviour.

Oh, I see. So, should I run the same version of b2j both on the server
side and also on the branch (client) side,
otherwise the server will overwrite the client version? right?
I didn't know that. Yes, please. I think the manual function is important
to be defined in conf.xml to turn off the behaviour.
There could be many cases for the developers not to delete the engine
without any notice.

>Note that if you build the JAR with only the runtime components then you
>can't use that JAR as part of the Eclipse plugin because it doesn't
>include important essential classes.
I am not sure I am following you in this part. Generally if any java
program can be a eclipse plugin.
If I import the jar file onto the eclipse plugin and then set some
information on the MENIFEST.MF file,
then it is a plugin, actually. Right? I think I don't get sufficiently
what you mean.

> - B2J generally requires a 1.4 JVM. It is possible to run it on a 1.3
> JVM but you need some extra JARs for things like XML DOM support. If
> you need to run it on a 1.3 JVM let me know and I'll tell you what extra
> JARs you need etc.
>
Adding a library to the 1.3 is one way. Or downgrade of the class
implementation compliant to java 1.3 could be another thing.
For example, w3c DOM is a kind of expensive class. Generic XML parser such
as Xerces will exceed 1M,
so limited device usually use SAX parser only or use micro DOM.
I looked through bj2 and they were not many, but some classes uses w3c DOM
related classes.
So, downgrade the classes is a kind of interest to me.
Is there any way for me to contribute my implementation, or commit mine
branching in CVS from a certain b2j version?

> Let me know how you get on and if you have any trouble building / running.
I will.

>
> If you need the jar to be smaller you will either want to use the
> distributed engine daemon to run the mini engine (which is an option I
> can add) or you will need to copy across the program yourself and launch
> it yourself in the mini-engine. In this case I can produce another
> build.xml target containing just the mini-engine.
Now, I'll start to try with the settings you are currently suggesting.
But, the mini-engine only version seems eventually to be needed, though.

Thank you for your kindness.
I really appreciate you.

Best Regards,
Keanu

Report message to a moderator

Re: [stp-newsgroup] Re: BPEL Compilation [message #373987 is a reply to message #373985]

Thu, 27 April 2006 13:33

Eclipse User

Originally posted by: ohurley.iona.com

> Since it's generally useful information and since STP isn't doing
> builds yet I've written a quick tutorial on how to build B2J from CVS.

The good news is that we are very very close to having those builds
happening!
Watch this space :)

--oh

Report message to a moderator

Re: [stp-newsgroup] Re: BPEL Compilation [message #373989 is a reply to message #373986]

Mon, 01 May 2006 10:07

Antony Miguel

Messages: 49
Registered: July 2009

Member

Hi Keanu,

>> - The distributed B2J engine currently automatically self-updates all
>> nodes by sending the current JAR across if the client version does not
>> match the daemon version. If you have limited space on the device
>> then you may not wish B2J to do self-updating and you may wish to
>> manage the versioning yourself. In this case I can add a switch to
>> the default conf.xml file for you to turn off this behaviour.
>
>
> Oh, I see. So, should I run the same version of b2j both on the server
> side and also on the branch (client) side, otherwise the server will
> overwrite the client version? right?
> I didn't know that. Yes, please. I think the manual function is
> important to be defined in conf.xml to turn off the behaviour.
> There could be many cases for the developers not to delete the engine
> without any notice.

What actually happens is that the server daemon remains exactly the
same, but if the client and server don't match, the client sends it's
JAR file across to the server. The server isn't overwritten but it
stores the JAR file and uses it for that BPEL process run. It keeps the
JAR file around in case it's asked to do more runs of the same version
but the daemon retains it's original version and the b2j.jar file isn't
overwritten (the new JAR file is written into a 'versions' directory).
This means that multiple clients of different versions can connect to a
single daemon and run engines in any number of machines using the
version of the engine they expect to see.

The only problem would be if you didn't have space on the daemon machine
for the alternate-version JARs.

>> Note that if you build the JAR with only the runtime components then
>> you can't use that JAR as part of the Eclipse plugin because it
>> doesn't include important essential classes.
>
> I am not sure I am following you in this part. Generally if any java
> program can be a eclipse plugin.
> If I import the jar file onto the eclipse plugin and then set some
> information on the MENIFEST.MF file,
> then it is a plugin, actually. Right? I think I don't get sufficiently
> what you mean.

I mean if you deploy the b2j core eclipse plugin, the MANIFEST.MF will
point to various classes like org.eclipse.stp.b2j.core.B2jPlugin, which
it will expect to find in the JAR file. If you then use the build.xml
to generate a b2j.jar file with only the runtime components then it
won't contain classes like B2jPlugin so although the engine will work OK
the plugin won't work in Eclipse.

>> - B2J generally requires a 1.4 JVM. It is possible to run it on a 1.3
>> JVM but you need some extra JARs for things like XML DOM support. If
>> you need to run it on a 1.3 JVM let me know and I'll tell you what
>> extra JARs you need etc.
>>
>
> Adding a library to the 1.3 is one way. Or downgrade of the class
> implementation compliant to java 1.3 could be another thing.
> For example, w3c DOM is a kind of expensive class. Generic XML parser
> such as Xerces will exceed 1M, so limited device usually use SAX parser
> only or use micro DOM.
> I looked through bj2 and they were not many, but some classes uses w3c
> DOM related classes. So, downgrade the classes is a kind of interest to me.
> Is there any way for me to contribute my implementation, or commit mine
> branching in CVS from a certain b2j version?

If this is a requirement then I'd prefer to solve this for the main
stream of B2J rather than branch.

Of the extra JARs B2J needs, the bulk of the size comes from XML and
JSSE. B2J uses JSSE to implement HTTPS in the HTTP client and HTTP
server. Since it's usage is restricted to just those classes it's
probably possible to have B2J use them via reflection and not require
the classes to be present all the time.

For the XML stuff, I have an XML parser that implements the most
important bits of DOM but is only about 32K in size (which would
compress to much less in a JAR). I think it would stand a good chance of
working in B2J, I could give it a try. I'm not sure how much work would
be required to chop out DOM altogether but if that were too much then I
have the w3c classes in a JAR about 130KB in size.

If I made both these conversions then I *think* B2J wouldn't need any
extra JARs to run in a 1.3 JVM.

Is running on a 1.3 JVM a concrete requirement for you or just a nice to
have?

cheers

Antony

Report message to a moderator

Re: [stp-newsgroup] Re: BPEL Compilation [message #373990 is a reply to message #373989]

Wed, 03 May 2006 19:16

keanu

Messages: 49
Registered: July 2009

Member

Hi, Antony

I can't begin to tell you how grateful I am.
I always thank you for your kindness.

> I mean if you deploy the b2j core eclipse plugin, the MANIFEST.MF will
> point to various classes like org.eclipse.stp.b2j.core.B2jPlugin, which
> it will expect to find in the JAR file. If you then use the build.xml
> to generate a b2j.jar file with only the runtime components then it
> won't contain classes like B2jPlugin so although the engine will work OK
> the plugin won't work in Eclipse.

Now, I understand what you mean. You are right. It is a plain jar, not a
plugin. Or just add a class implementing org.osgi.service.BundleActivator
to make b2j an osgi bundle, which is totally same as eclipse plugin
excepting eclipse UI related functions.

> If I made both these conversions then I *think* B2J wouldn't need any
> extra JARs to run in a 1.3 JVM.
I found 3 methods compile erorrs about this in Eclipse problems panel.

> If this is a requirement then I'd prefer to solve this for the main
> stream of B2J rather than branch.

In my project? yes, it is. If you can care about it, I'll be very happy
with it. I've sent you a mail about my environment things. may be useful.
This is only for runtime, though. The rest of the classes is fine on PC or
Workstation.
As eclipse supports to apply different JRE for each plugin, it might be
more comfortable for you to separate out runtime bundle. In this case,
OSGi bundle instead of eclipse plugin can be applied because runtime does
not depend on UI. Eclipse 3.2 start supporting to create bundle...so..
Just. my opinion.

> For the XML stuff, I have an XML parser that implements the most
> important bits of DOM but is only about 32K in size (which would
> compress to much less in a JAR). I think it would stand a good chance of
> working in B2J, I could give it a try. I'm not sure how much work would
> be required to chop out DOM altogether but if that were too much then I
> have the w3c classes in a JAR about 130KB in size.

sounds terrific! 32K for DOM parser? Awesome!

Best regards,
Keanu

Report message to a moderator

Re: [stp-newsgroup] Re: BPEL Compilation [message #580408 is a reply to message #373983]

Wed, 26 April 2006 10:27

Antony Miguel

Messages: 49
Registered: July 2009

Member

Report message to a moderator

Re: [stp-newsgroup] Re: BPEL Compilation [message #580428 is a reply to message #373984]

Wed, 26 April 2006 14:51

Antony Miguel

Messages: 49
Registered: July 2009

Member

Report message to a moderator

Re: [stp-newsgroup] Re: BPEL Compilation [message #580450 is a reply to message #373985]

Thu, 27 April 2006 02:41

keanu

Messages: 49
Registered: July 2009

Member

Report message to a moderator

Re: [stp-newsgroup] Re: BPEL Compilation [message #580478 is a reply to message #373985]

Thu, 27 April 2006 13:33

Oisin Hurley

Messages: 204
Registered: July 2009

Senior Member

> Since it's generally useful information and since STP isn't doing
> builds yet I've written a quick tutorial on how to build B2J from CVS.

The good news is that we are very very close to having those builds
happening!
Watch this space :)

--oh

Report message to a moderator