Working With BlazeDS Beta 1

Last week we successfully ported an AIR application from amfphp to BlazeDS. The code for this application was almost completely generated by a new generator we're working on (coming soon!). With the announcement of BlazeDS, we kinda shelved our php generator and redirected our efforts in doing the same thing for BlazeDS. In the process, we put together our own version of the blazeds.war file that ships with BlazeDS beta 1, which we use as the starting point for all our BlazeDS projects. Here's a list of the changes we've made:

• Modified the context.xml found in the META-INF folder - the packaged one was producing Valve Errors
• Added the missing my-streaming-amf channel to services-config.xml, which I found in the BlazeDS samples war's config file
  
• Incorporated the latest Flex 3 Compiler Module files to allow server-side compilation of mxml files
• Created a very simple java class and a corresponding destination which will verify Blaze backend functionality
• Created a very simple Flex application that calls the above java class function test(string)
• Added 2 jars to WEB-INF, one is crazedTemplate.jar, which our new codegenerator (coming soon) uses, the other is sharpertools.jar, which the jar requires.
  

You can choose to go ahead and just use the application as is. It's only been tested on Tomcat / Win / OSX 10.5.2. If you don't intend on using our generator (coming soon!) to generate your java and AS3 Classes then you can go ahead and delete the 2 jars mentioned above. I really like this separation of compiler and essentially what was FDS. When FDS was originally released, it did both runtime compiles as well as Remoting, Messaging, Proxy and Managed Data Services. In our case, we never deployed anything that required runtime compilation AND furthermore, with each subsequent Flex release (2.01, Hotfix 1, 2 and 3), converting FDS projects that were set to compile on the server wasn't trivial. So we stopped using it. If I was super Java savvy I might have been able to figure out what parts I could yank out of my FDS application, but generally it seemed better to just leave it alone.

Now, with Blaze and the compiler war being separate, I've gone through the web.xml in this project and put comments to show which pieces are required by the compiler module and which pieces are required by Blaze. To get this back to being a pure Blaze non-Flex 3 Compiler Module, you'd just need to remove the appropriately marked sections from the web.xml and then remove all folders and files from WEB-INF/flex with the exception of:

• services-config.xml
• remoting-config.xml
• proxy-config.xml
• messaging-config.xml
  

Some of our clients have asked what the differences exactly are between BlazeDS and LCDS (prev. known as FDS). If you do enough research on the web, you can find several answers. From what I've seen, here's some differences I've found so far:

• BlazeDS does not support the RTMP Channel typically used by LCDS for data push (RTMP typically means firewall port challenges all around anyway!)
• BlazeDS does support AMF Streaming which offers data push like RTMP, however not nearly as scalable (100's vs 10000's of concurrent users)
• BlazeDS does support proxy so you can bypass the all too familiar sandbox issues when accessing remote data where no crossdomain.xml is present
• BlazeDS does not come packaged with the Compiler Module
• BlazeDS does not have managed dataservices. This means that you don't need the fds.swc (DataService & [Managed]) in your flex projects.. you will use either Consumer, Producer or RemoteObject Classes
• BlazeDS does support AMF3, RemoteClasses & Messaging with a "lite" version of push via amf streaming
  

To download the blazeBlank application click here. (as new builds of Flex 3 and BlazeDS are released I'll try to keep this application updated). This application currently uses Flex 3 Beta 3 and BlazeDS Beta 1. Be sure to visit the url /{context}/TestApp/Main.mxml to ensure that the application is working properly. (i.e. http://localhost:8600/blazeBlank/TestApp/Main.mxml)

Bpel 4 people / Bpel 4 newbees

One of the main goals I'm trying to reach is to advise customers on how to start implementation of SOA in their organisation by using a coaching approach instead of implementor approach.

In other words, guide and coach the development teams of each customer in getting familiar with SOA concepts and getting their hands dirty ;o))
The developers themselves are tought BPEL, Web Services, XML and XSD through basic hands on session, workshops in a practical way and then they start designing bpel processes.

What's very important is this process is that each person needs to do the brainwork, in other words always start from scratch, don't define a synchronous or asynchronous process, no define an empty process and build it up yourself.

What’s very interesting when guiding and coaching people in becoming a SOA expert, is understanding the way they think and handle functional requests and problems in a SOA Technology. This gives me the opportunity and possibility to focus more on how to better advice and guide people in learning SOA, e.g. BPEL.

The most interesting points to consider and think about when being a teacher in SOA or being a student are the following:

Being a teacher:

• be passionate, patient, non technical, use metaphors and most don't use abbreviations or buzz words, this ain't cool ;o)

Basic knowledge before starting BPEL/ESB/OWSM/Mediators … Integration:

• Web services (synchronous versus asynchronous)


• Xml and xsd (how to define, how to work with xml data (xquery, xpath, …)

You need to be able to understand following principles:

• Fault handling


• Compensation handling


• Transaction handling

Following abbreviations mean something to you:

• JCA, JNDI, EDA, SOA, WSDL, WSIF, SOAP, JMS, RPC

How to get started when designing bpel processes:
One of the interesting tricks I’ve learned when guiding a customers’ developer in learning bpel was that he defined an empty bpel process where all needed activities where pseudo-coded.

In other words when you need to define your first bpel process using the use cases defined and described by your analysts, you just design the bpel process using empty activities which describe each needed task/action in your process.

This empty process is deployable and can then be iteratively implemented by the designer when the visual flow is checked upon with the functional developers. => THIS IS A GREAT INSIGHT and WAY OF THINKING and a very visual approach to enabling business processen (thanks to Yves for the tip !!!)

The most interesting part when starting with SOA development is that everyone that’s involved in this process is learning; it’s a learning organization where every person’s knowledge and expertise is augmented!

Working With BlazeDS Beta 1

Last week we successfully ported an AIR application from amfphp to BlazeDS. The code for this application was almost completely generated by a new generator we're working on (coming soon!). With the announcement of BlazeDS, we kinda shelved our php generator and redirected our efforts in doing the same thing for BlazeDS. In the process, we put together our own version of the blazeds.war file that ships with BlazeDS beta 1, which we use as the starting point for all our BlazeDS projects. Here's a list of the changes we've made:

• Modified the context.xml found in the META-INF folder - the packaged one was producing Valve Errors
• Added the missing my-streaming-amf channel to services-config.xml, which I found in the BlazeDS samples war's config file
  
• Incorporated the latest Flex 3 Compiler Module files to allow server-side compilation of mxml files
• Created a very simple java class and a corresponding destination which will verify Blaze backend functionality
• Created a very simple Flex application that calls the above java class function test(string)
• Added 2 jars to WEB-INF, one is crazedTemplate.jar, which our new codegenerator (coming soon) uses, the other is sharpertools.jar, which the jar requires.
  

You can choose to go ahead and just use the application as is. It's only been tested on Tomcat / Win / OSX 10.5.2. If you don't intend on using our generator (coming soon!) to generate your java and AS3 Classes then you can go ahead and delete the 2 jars mentioned above. I really like this separation of compiler and essentially what was FDS. When FDS was originally released, it did both runtime compiles as well as Remoting, Messaging, Proxy and Managed Data Services. In our case, we never deployed anything that required runtime compilation AND furthermore, with each subsequent Flex release (2.01, Hotfix 1, 2 and 3), converting FDS projects that were set to compile on the server wasn't trivial. So we stopped using it. If I was super Java savvy I might have been able to figure out what parts I could yank out of my FDS application, but generally it seemed better to just leave it alone.

Now, with Blaze and the compiler war being separate, I've gone through the web.xml in this project and put comments to show which pieces are required by the compiler module and which pieces are required by Blaze. To get this back to being a pure Blaze non-Flex 3 Compiler Module, you'd just need to remove the appropriately marked sections from the web.xml and then remove all folders and files from WEB-INF/flex with the exception of:

• services-config.xml
• remoting-config.xml
• proxy-config.xml
• messaging-config.xml
  

Some of our clients have asked what the differences exactly are between BlazeDS and LCDS (prev. known as FDS). If you do enough research on the web, you can find several answers. From what I've seen, here's some differences I've found so far:

• BlazeDS does not support the RTMP Channel typically used by LCDS for data push (RTMP typically means firewall port challenges all around anyway!)
• BlazeDS does support AMF Streaming which offers data push like RTMP, however not nearly as scalable (100's vs 10000's of concurrent users)
• BlazeDS does support proxy so you can bypass the all too familiar sandbox issues when accessing remote data where no crossdomain.xml is present
• BlazeDS does not come packaged with the Compiler Module
• BlazeDS does not have managed dataservices. This means that you don't need the fds.swc (DataService & [Managed]) in your flex projects.. you will use either Consumer, Producer or RemoteObject Classes
• BlazeDS does support AMF3, RemoteClasses & Messaging with a "lite" version of push via amf streaming
  

To download the blazeBlank application click here. (as new builds of Flex 3 and BlazeDS are released I'll try to keep this application updated). This application currently uses Flex 3 Beta 3 and BlazeDS Beta 1. Be sure to visit the url /{context}/TestApp/Main.mxml to ensure that the application is working properly. (i.e. http://localhost:8600/blazeBlank/TestApp/Main.mxml)

Bpel 4 people / Bpel 4 newbees

One of the main goals I'm trying to reach is to advise customers on how to start implementation of SOA in their organisation by using a coaching approach instead of implementor approach.

In other words, guide and coach the development teams of each customer in getting familiar with SOA concepts and getting their hands dirty ;o))
The developers themselves are tought BPEL, Web Services, XML and XSD through basic hands on session, workshops in a practical way and then they start designing bpel processes.

What's very important is this process is that each person needs to do the brainwork, in other words always start from scratch, don't define a synchronous or asynchronous process, no define an empty process and build it up yourself.

What’s very interesting when guiding and coaching people in becoming a SOA expert, is understanding the way they think and handle functional requests and problems in a SOA Technology. This gives me the opportunity and possibility to focus more on how to better advice and guide people in learning SOA, e.g. BPEL.

The most interesting points to consider and think about when being a teacher in SOA or being a student are the following:

Being a teacher:

• be passionate, patient, non technical, use metaphors and most don't use abbreviations or buzz words, this ain't cool ;o)

Basic knowledge before starting BPEL/ESB/OWSM/Mediators … Integration:

• Web services (synchronous versus asynchronous)


• Xml and xsd (how to define, how to work with xml data (xquery, xpath, …)

You need to be able to understand following principles:

• Fault handling


• Compensation handling


• Transaction handling

Following abbreviations mean something to you:

• JCA, JNDI, EDA, SOA, WSDL, WSIF, SOAP, JMS, RPC

How to get started when designing bpel processes:
One of the interesting tricks I’ve learned when guiding a customers’ developer in learning bpel was that he defined an empty bpel process where all needed activities where pseudo-coded.

In other words when you need to define your first bpel process using the use cases defined and described by your analysts, you just design the bpel process using empty activities which describe each needed task/action in your process.

This empty process is deployable and can then be iteratively implemented by the designer when the visual flow is checked upon with the functional developers. => THIS IS A GREAT INSIGHT and WAY OF THINKING and a very visual approach to enabling business processen (thanks to Yves for the tip !!!)

The most interesting part when starting with SOA development is that everyone that’s involved in this process is learning; it’s a learning organization where every person’s knowledge and expertise is augmented!

BPEL Process Invocation from different UI's - Best Practices

In my previous thread I've talked about different tips & tricks when working with ESB, BPEL, ODI, Flex, etc.

One of these tips was tips & tricks on invocation of BPEL Processes when using different UI approaches.

A very understable explanation given by 'Hajo Normann' about this:

It is best practice to use the default ways to invoke a BPEL process –
create a WSDL that maps to WSIF binding in a controlled environment and to a
SOAP/HTTP binding in a more B2B type of scenario. A call to the BPEL API would
be a “custom” solution that needs way more governance to communicate with fellow
developers and to maintain properly, when compared to the straightforward
standard way.

So, I suggest to use the API only if you desperately need
to optimize and found the default implementations violating your SLAs.

Let’s have a look at the technical implications:

If you run your presentation logic in the same Java VM as your BPEL process, you would use the default mechanism of invoking the process with the default WSDL. Under the hood, the middleware creates WSIF bindings that
- are extremely memory friendly, because no redundant memory is allocated (the middleware passes a reference to the Java object)
- share transactions

In this scenario I see no advantage of calling the API.

If you run your presentation logic in an other Java VM as your BPEL process in a controlled environment, you would still benefit from using the default mechanism of invoking the process with his default WSDL. Under the hood, the middleware creates WSIF bindings that

- serialize the passed Java objects and, on the BPEL side, create the BPEL DOM
implementations that make up the BPEL instance variables. This causes a performance and memory penalty you have to pay
- share transactions

I haven't seen any benchmarks regarding this or haven't received more information of the Oracle Development Team so hopefully this will start up a big discussion ;o)

Going Underground

I’ve started a very large project that will keep me occupied 7 days as week for quite some time. Just a quick note to inform everyone that blog posts will be very sparse for quite a while. Thanks.

Working With BlazeDS Beta 1

Last week we successfully ported an AIR application from amfphp to BlazeDS. The code for this application was almost completely generated by a new generator we're working on (coming soon!). With the announcement of BlazeDS, we kinda shelved our php generator and redirected our efforts in doing the same thing for BlazeDS. In the process, we put together our own version of the blazeds.war file that ships with BlazeDS beta 1, which we use as the starting point for all our BlazeDS projects. Here's a list of the changes we've made:

• Modified the context.xml found in the META-INF folder - the packaged one was producing Valve Errors
• Added the missing my-streaming-amf channel to services-config.xml, which I found in the BlazeDS samples war's config file
  
• Incorporated the latest Flex 3 Compiler Module files to allow server-side compilation of mxml files
• Created a very simple java class and a corresponding destination which will verify Blaze backend functionality
• Created a very simple Flex application that calls the above java class function test(string)
• Added 2 jars to WEB-INF, one is crazedTemplate.jar, which our new codegenerator (coming soon) uses, the other is sharpertools.jar, which the jar requires.
  

You can choose to go ahead and just use the application as is. It's only been tested on Tomcat / Win / OSX 10.5.2. If you don't intend on using our generator (coming soon!) to generate your java and AS3 Classes then you can go ahead and delete the 2 jars mentioned above. I really like this separation of compiler and essentially what was FDS. When FDS was originally released, it did both runtime compiles as well as Remoting, Messaging, Proxy and Managed Data Services. In our case, we never deployed anything that required runtime compilation AND furthermore, with each subsequent Flex release (2.01, Hotfix 1, 2 and 3), converting FDS projects that were set to compile on the server wasn't trivial. So we stopped using it. If I was super Java savvy I might have been able to figure out what parts I could yank out of my FDS application, but generally it seemed better to just leave it alone.

Now, with Blaze and the compiler war being separate, I've gone through the web.xml in this project and put comments to show which pieces are required by the compiler module and which pieces are required by Blaze. To get this back to being a pure Blaze non-Flex 3 Compiler Module, you'd just need to remove the appropriately marked sections from the web.xml and then remove all folders and files from WEB-INF/flex with the exception of:

• services-config.xml
• remoting-config.xml
• proxy-config.xml
• messaging-config.xml
  

Some of our clients have asked what the differences exactly are between BlazeDS and LCDS (prev. known as FDS). If you do enough research on the web, you can find several answers. From what I've seen, here's some differences I've found so far:

• BlazeDS does not support the RTMP Channel typically used by LCDS for data push (RTMP typically means firewall port challenges all around anyway!)
• BlazeDS does support AMF Streaming which offers data push like RTMP, however not nearly as scalable (100's vs 10000's of concurrent users)
• BlazeDS does support proxy so you can bypass the all too familiar sandbox issues when accessing remote data where no crossdomain.xml is present
• BlazeDS does not come packaged with the Compiler Module
• BlazeDS does not have managed dataservices. This means that you don't need the fds.swc (DataService & [Managed]) in your flex projects.. you will use either Consumer, Producer or RemoteObject Classes
• BlazeDS does support AMF3, RemoteClasses & Messaging with a "lite" version of push via amf streaming
  

To download the blazeBlank application click here. (as new builds of Flex 3 and BlazeDS are released I'll try to keep this application updated). This application currently uses Flex 3 Beta 3 and BlazeDS Beta 1. Be sure to visit the url /{context}/TestApp/Main.mxml to ensure that the application is working properly. (i.e. http://localhost:8600/blazeBlank/TestApp/Main.mxml)

BPEL Process Invocation from different UI's - Best Practices

In my previous thread I've talked about different tips & tricks when working with ESB, BPEL, ODI, Flex, etc.

One of these tips was tips & tricks on invocation of BPEL Processes when using different UI approaches.

A very understable explanation given by 'Hajo Normann' about this:

It is best practice to use the default ways to invoke a BPEL process –
create a WSDL that maps to WSIF binding in a controlled environment and to a
SOAP/HTTP binding in a more B2B type of scenario. A call to the BPEL API would
be a “custom” solution that needs way more governance to communicate with fellow
developers and to maintain properly, when compared to the straightforward
standard way.

So, I suggest to use the API only if you desperately need
to optimize and found the default implementations violating your SLAs.

Let’s have a look at the technical implications:

If you run your presentation logic in the same Java VM as your BPEL process, you would use the default mechanism of invoking the process with the default WSDL. Under the hood, the middleware creates WSIF bindings that
- are extremely memory friendly, because no redundant memory is allocated (the middleware passes a reference to the Java object)
- share transactions

In this scenario I see no advantage of calling the API.

If you run your presentation logic in an other Java VM as your BPEL process in a controlled environment, you would still benefit from using the default mechanism of invoking the process with his default WSDL. Under the hood, the middleware creates WSIF bindings that

- serialize the passed Java objects and, on the BPEL side, create the BPEL DOM
implementations that make up the BPEL instance variables. This causes a performance and memory penalty you have to pay
- share transactions

I haven't seen any benchmarks regarding this or haven't received more information of the Oracle Development Team so hopefully this will start up a big discussion ;o)

Working With BlazeDS Beta 1

Last week we successfully ported an AIR application from amfphp to BlazeDS. The code for this application was almost completely generated by a new generator we're working on (coming soon!). With the announcement of BlazeDS, we kinda shelved our php generator and redirected our efforts in doing the same thing for BlazeDS. In the process, we put together our own version of the blazeds.war file that ships with BlazeDS beta 1, which we use as the starting point for all our BlazeDS projects. Here's a list of the changes we've made:

• Modified the context.xml found in the META-INF folder - the packaged one was producing Valve Errors
• Added the missing my-streaming-amf channel to services-config.xml, which I found in the BlazeDS samples war's config file
  
• Incorporated the latest Flex 3 Compiler Module files to allow server-side compilation of mxml files
• Created a very simple java class and a corresponding destination which will verify Blaze backend functionality
• Created a very simple Flex application that calls the above java class function test(string)
• Added 2 jars to WEB-INF, one is crazedTemplate.jar, which our new codegenerator (coming soon) uses, the other is sharpertools.jar, which the jar requires.
  

You can choose to go ahead and just use the application as is. It's only been tested on Tomcat / Win / OSX 10.5.2. If you don't intend on using our generator (coming soon!) to generate your java and AS3 Classes then you can go ahead and delete the 2 jars mentioned above. I really like this separation of compiler and essentially what was FDS. When FDS was originally released, it did both runtime compiles as well as Remoting, Messaging, Proxy and Managed Data Services. In our case, we never deployed anything that required runtime compilation AND furthermore, with each subsequent Flex release (2.01, Hotfix 1, 2 and 3), converting FDS projects that were set to compile on the server wasn't trivial. So we stopped using it. If I was super Java savvy I might have been able to figure out what parts I could yank out of my FDS application, but generally it seemed better to just leave it alone.

Now, with Blaze and the compiler war being separate, I've gone through the web.xml in this project and put comments to show which pieces are required by the compiler module and which pieces are required by Blaze. To get this back to being a pure Blaze non-Flex 3 Compiler Module, you'd just need to remove the appropriately marked sections from the web.xml and then remove all folders and files from WEB-INF/flex with the exception of:

• services-config.xml
• remoting-config.xml
• proxy-config.xml
• messaging-config.xml
  

Some of our clients have asked what the differences exactly are between BlazeDS and LCDS (prev. known as FDS). If you do enough research on the web, you can find several answers. From what I've seen, here's some differences I've found so far:

• BlazeDS does not support the RTMP Channel typically used by LCDS for data push (RTMP typically means firewall port challenges all around anyway!)
• BlazeDS does support AMF Streaming which offers data push like RTMP, however not nearly as scalable (100's vs 10000's of concurrent users)
• BlazeDS does support proxy so you can bypass the all too familiar sandbox issues when accessing remote data where no crossdomain.xml is present
• BlazeDS does not come packaged with the Compiler Module
• BlazeDS does not have managed dataservices. This means that you don't need the fds.swc (DataService & [Managed]) in your flex projects.. you will use either Consumer, Producer or RemoteObject Classes
• BlazeDS does support AMF3, RemoteClasses & Messaging with a "lite" version of push via amf streaming
  

To download the blazeBlank application click here. (as new builds of Flex 3 and BlazeDS are released I'll try to keep this application updated). This application currently uses Flex 3 Beta 3 and BlazeDS Beta 1. Be sure to visit the url /{context}/TestApp/Main.mxml to ensure that the application is working properly. (i.e. http://localhost:8600/blazeBlank/TestApp/Main.mxml)

BPEL Process Invocation from different UI's - Best Practices

In my previous thread I've talked about different tips & tricks when working with ESB, BPEL, ODI, Flex, etc.

One of these tips was tips & tricks on invocation of BPEL Processes when using different UI approaches.

A very understable explanation given by 'Hajo Normann' about this:

It is best practice to use the default ways to invoke a BPEL process –
create a WSDL that maps to WSIF binding in a controlled environment and to a
SOAP/HTTP binding in a more B2B type of scenario. A call to the BPEL API would
be a “custom” solution that needs way more governance to communicate with fellow
developers and to maintain properly, when compared to the straightforward
standard way.

So, I suggest to use the API only if you desperately need
to optimize and found the default implementations violating your SLAs.

Let’s have a look at the technical implications:

If you run your presentation logic in the same Java VM as your BPEL process, you would use the default mechanism of invoking the process with the default WSDL. Under the hood, the middleware creates WSIF bindings that
- are extremely memory friendly, because no redundant memory is allocated (the middleware passes a reference to the Java object)
- share transactions

In this scenario I see no advantage of calling the API.

If you run your presentation logic in an other Java VM as your BPEL process in a controlled environment, you would still benefit from using the default mechanism of invoking the process with his default WSDL. Under the hood, the middleware creates WSIF bindings that

- serialize the passed Java objects and, on the BPEL side, create the BPEL DOM
implementations that make up the BPEL instance variables. This causes a performance and memory penalty you have to pay
- share transactions

I haven't seen any benchmarks regarding this or haven't received more information of the Oracle Development Team so hopefully this will start up a big discussion ;o)

Working With BlazeDS Beta 1

Last week we successfully ported an AIR application from amfphp to BlazeDS. The code for this application was almost completely generated by a new generator we're working on (coming soon!). With the announcement of BlazeDS, we kinda shelved our php generator and redirected our efforts in doing the same thing for BlazeDS. In the process, we put together our own version of the blazeds.war file that ships with BlazeDS beta 1, which we use as the starting point for all our BlazeDS projects. Here's a list of the changes we've made:

• Modified the context.xml found in the META-INF folder - the packaged one was producing Valve Errors
• Added the missing my-streaming-amf channel to services-config.xml, which I found in the BlazeDS samples war's config file
  
• Incorporated the latest Flex 3 Compiler Module files to allow server-side compilation of mxml files
• Created a very simple java class and a corresponding destination which will verify Blaze backend functionality
• Created a very simple Flex application that calls the above java class function test(string)
• Added 2 jars to WEB-INF, one is crazedTemplate.jar, which our new codegenerator (coming soon) uses, the other is sharpertools.jar, which the jar requires.
  

You can choose to go ahead and just use the application as is. It's only been tested on Tomcat / Win / OSX 10.5.2. If you don't intend on using our generator (coming soon!) to generate your java and AS3 Classes then you can go ahead and delete the 2 jars mentioned above. I really like this separation of compiler and essentially what was FDS. When FDS was originally released, it did both runtime compiles as well as Remoting, Messaging, Proxy and Managed Data Services. In our case, we never deployed anything that required runtime compilation AND furthermore, with each subsequent Flex release (2.01, Hotfix 1, 2 and 3), converting FDS projects that were set to compile on the server wasn't trivial. So we stopped using it. If I was super Java savvy I might have been able to figure out what parts I could yank out of my FDS application, but generally it seemed better to just leave it alone.

Now, with Blaze and the compiler war being separate, I've gone through the web.xml in this project and put comments to show which pieces are required by the compiler module and which pieces are required by Blaze. To get this back to being a pure Blaze non-Flex 3 Compiler Module, you'd just need to remove the appropriately marked sections from the web.xml and then remove all folders and files from WEB-INF/flex with the exception of:

• services-config.xml
• remoting-config.xml
• proxy-config.xml
• messaging-config.xml
  

Some of our clients have asked what the differences exactly are between BlazeDS and LCDS (prev. known as FDS). If you do enough research on the web, you can find several answers. From what I've seen, here's some differences I've found so far:

• BlazeDS does not support the RTMP Channel typically used by LCDS for data push (RTMP typically means firewall port challenges all around anyway!)
• BlazeDS does support AMF Streaming which offers data push like RTMP, however not nearly as scalable (100's vs 10000's of concurrent users)
• BlazeDS does support proxy so you can bypass the all too familiar sandbox issues when accessing remote data where no crossdomain.xml is present
• BlazeDS does not come packaged with the Compiler Module
• BlazeDS does not have managed dataservices. This means that you don't need the fds.swc (DataService & [Managed]) in your flex projects.. you will use either Consumer, Producer or RemoteObject Classes
• BlazeDS does support AMF3, RemoteClasses & Messaging with a "lite" version of push via amf streaming
  

To download the blazeBlank application click here. (as new builds of Flex 3 and BlazeDS are released I'll try to keep this application updated). This application currently uses Flex 3 Beta 3 and BlazeDS Beta 1. Be sure to visit the url /{context}/TestApp/Main.mxml to ensure that the application is working properly. (i.e. http://localhost:8600/blazeBlank/TestApp/Main.mxml)

BPEL Process Invocation from different UI's - Best Practices

In my previous thread I've talked about different tips & tricks when working with ESB, BPEL, ODI, Flex, etc.

One of these tips was tips & tricks on invocation of BPEL Processes when using different UI approaches.

A very understable explanation given by 'Hajo Normann' about this:

It is best practice to use the default ways to invoke a BPEL process –
create a WSDL that maps to WSIF binding in a controlled environment and to a
SOAP/HTTP binding in a more B2B type of scenario. A call to the BPEL API would
be a “custom” solution that needs way more governance to communicate with fellow
developers and to maintain properly, when compared to the straightforward
standard way.

So, I suggest to use the API only if you desperately need
to optimize and found the default implementations violating your SLAs.

Let’s have a look at the technical implications:

If you run your presentation logic in the same Java VM as your BPEL process, you would use the default mechanism of invoking the process with the default WSDL. Under the hood, the middleware creates WSIF bindings that
- are extremely memory friendly, because no redundant memory is allocated (the middleware passes a reference to the Java object)
- share transactions

In this scenario I see no advantage of calling the API.

If you run your presentation logic in an other Java VM as your BPEL process in a controlled environment, you would still benefit from using the default mechanism of invoking the process with his default WSDL. Under the hood, the middleware creates WSIF bindings that

- serialize the passed Java objects and, on the BPEL side, create the BPEL DOM
implementations that make up the BPEL instance variables. This causes a performance and memory penalty you have to pay
- share transactions

I haven't seen any benchmarks regarding this or haven't received more information of the Oracle Development Team so hopefully this will start up a big discussion ;o)

Working With BlazeDS Beta 1

Last week we successfully ported an AIR application from amfphp to BlazeDS. The code for this application was almost completely generated by a new generator we're working on (coming soon!). With the announcement of BlazeDS, we kinda shelved our php generator and redirected our efforts in doing the same thing for BlazeDS. In the process, we put together our own version of the blazeds.war file that ships with BlazeDS beta 1, which we use as the starting point for all our BlazeDS projects. Here's a list of the changes we've made:

• Modified the context.xml found in the META-INF folder - the packaged one was producing Valve Errors
• Added the missing my-streaming-amf channel to services-config.xml, which I found in the BlazeDS samples war's config file
  
• Incorporated the latest Flex 3 Compiler Module files to allow server-side compilation of mxml files
• Created a very simple java class and a corresponding destination which will verify Blaze backend functionality
• Created a very simple Flex application that calls the above java class function test(string)
• Added 2 jars to WEB-INF, one is crazedTemplate.jar, which our new codegenerator (coming soon) uses, the other is sharpertools.jar, which the jar requires.
  

You can choose to go ahead and just use the application as is. It's only been tested on Tomcat / Win / OSX 10.5.2. If you don't intend on using our generator (coming soon!) to generate your java and AS3 Classes then you can go ahead and delete the 2 jars mentioned above. I really like this separation of compiler and essentially what was FDS. When FDS was originally released, it did both runtime compiles as well as Remoting, Messaging, Proxy and Managed Data Services. In our case, we never deployed anything that required runtime compilation AND furthermore, with each subsequent Flex release (2.01, Hotfix 1, 2 and 3), converting FDS projects that were set to compile on the server wasn't trivial. So we stopped using it. If I was super Java savvy I might have been able to figure out what parts I could yank out of my FDS application, but generally it seemed better to just leave it alone.

Now, with Blaze and the compiler war being separate, I've gone through the web.xml in this project and put comments to show which pieces are required by the compiler module and which pieces are required by Blaze. To get this back to being a pure Blaze non-Flex 3 Compiler Module, you'd just need to remove the appropriately marked sections from the web.xml and then remove all folders and files from WEB-INF/flex with the exception of:

• services-config.xml
• remoting-config.xml
• proxy-config.xml
• messaging-config.xml
  

Some of our clients have asked what the differences exactly are between BlazeDS and LCDS (prev. known as FDS). If you do enough research on the web, you can find several answers. From what I've seen, here's some differences I've found so far:

• BlazeDS does not support the RTMP Channel typically used by LCDS for data push (RTMP typically means firewall port challenges all around anyway!)
• BlazeDS does support AMF Streaming which offers data push like RTMP, however not nearly as scalable (100's vs 10000's of concurrent users)
• BlazeDS does support proxy so you can bypass the all too familiar sandbox issues when accessing remote data where no crossdomain.xml is present
• BlazeDS does not come packaged with the Compiler Module
• BlazeDS does not have managed dataservices. This means that you don't need the fds.swc (DataService & [Managed]) in your flex projects.. you will use either Consumer, Producer or RemoteObject Classes
• BlazeDS does support AMF3, RemoteClasses & Messaging with a "lite" version of push via amf streaming
  

To download the blazeBlank application click here. (as new builds of Flex 3 and BlazeDS are released I'll try to keep this application updated). This application currently uses Flex 3 Beta 3 and BlazeDS Beta 1. Be sure to visit the url /{context}/TestApp/Main.mxml to ensure that the application is working properly. (i.e. http://localhost:8600/blazeBlank/TestApp/Main.mxml)

BPEL Process Invocation from different UI's - Best Practices

In my previous thread I've talked about different tips & tricks when working with ESB, BPEL, ODI, Flex, etc.

One of these tips was tips & tricks on invocation of BPEL Processes when using different UI approaches.

A very understable explanation given by 'Hajo Normann' about this:

It is best practice to use the default ways to invoke a BPEL process –
create a WSDL that maps to WSIF binding in a controlled environment and to a
SOAP/HTTP binding in a more B2B type of scenario. A call to the BPEL API would
be a “custom” solution that needs way more governance to communicate with fellow
developers and to maintain properly, when compared to the straightforward
standard way.

So, I suggest to use the API only if you desperately need
to optimize and found the default implementations violating your SLAs.

Let’s have a look at the technical implications:

If you run your presentation logic in the same Java VM as your BPEL process, you would use the default mechanism of invoking the process with the default WSDL. Under the hood, the middleware creates WSIF bindings that
- are extremely memory friendly, because no redundant memory is allocated (the middleware passes a reference to the Java object)
- share transactions

In this scenario I see no advantage of calling the API.

If you run your presentation logic in an other Java VM as your BPEL process in a controlled environment, you would still benefit from using the default mechanism of invoking the process with his default WSDL. Under the hood, the middleware creates WSIF bindings that

- serialize the passed Java objects and, on the BPEL side, create the BPEL DOM
implementations that make up the BPEL instance variables. This causes a performance and memory penalty you have to pay
- share transactions

I haven't seen any benchmarks regarding this or haven't received more information of the Oracle Development Team so hopefully this will start up a big discussion ;o)

Working With BlazeDS Beta 1

Last week we successfully ported an AIR application from amfphp to BlazeDS. The code for this application was almost completely generated by a new generator we're working on (coming soon!). With the announcement of BlazeDS, we kinda shelved our php generator and redirected our efforts in doing the same thing for BlazeDS. In the process, we put together our own version of the blazeds.war file that ships with BlazeDS beta 1, which we use as the starting point for all our BlazeDS projects. Here's a list of the changes we've made:

• Modified the context.xml found in the META-INF folder - the packaged one was producing Valve Errors
• Added the missing my-streaming-amf channel to services-config.xml, which I found in the BlazeDS samples war's config file
  
• Incorporated the latest Flex 3 Compiler Module files to allow server-side compilation of mxml files
• Created a very simple java class and a corresponding destination which will verify Blaze backend functionality
• Created a very simple Flex application that calls the above java class function test(string)
• Added 2 jars to WEB-INF, one is crazedTemplate.jar, which our new codegenerator (coming soon) uses, the other is sharpertools.jar, which the jar requires.
  

You can choose to go ahead and just use the application as is. It's only been tested on Tomcat / Win / OSX 10.5.2. If you don't intend on using our generator (coming soon!) to generate your java and AS3 Classes then you can go ahead and delete the 2 jars mentioned above. I really like this separation of compiler and essentially what was FDS. When FDS was originally released, it did both runtime compiles as well as Remoting, Messaging, Proxy and Managed Data Services. In our case, we never deployed anything that required runtime compilation AND furthermore, with each subsequent Flex release (2.01, Hotfix 1, 2 and 3), converting FDS projects that were set to compile on the server wasn't trivial. So we stopped using it. If I was super Java savvy I might have been able to figure out what parts I could yank out of my FDS application, but generally it seemed better to just leave it alone.

Now, with Blaze and the compiler war being separate, I've gone through the web.xml in this project and put comments to show which pieces are required by the compiler module and which pieces are required by Blaze. To get this back to being a pure Blaze non-Flex 3 Compiler Module, you'd just need to remove the appropriately marked sections from the web.xml and then remove all folders and files from WEB-INF/flex with the exception of:

• services-config.xml
• remoting-config.xml
• proxy-config.xml
• messaging-config.xml
  

Some of our clients have asked what the differences exactly are between BlazeDS and LCDS (prev. known as FDS). If you do enough research on the web, you can find several answers. From what I've seen, here's some differences I've found so far:

• BlazeDS does not support the RTMP Channel typically used by LCDS for data push (RTMP typically means firewall port challenges all around anyway!)
• BlazeDS does support AMF Streaming which offers data push like RTMP, however not nearly as scalable (100's vs 10000's of concurrent users)
• BlazeDS does support proxy so you can bypass the all too familiar sandbox issues when accessing remote data where no crossdomain.xml is present
• BlazeDS does not come packaged with the Compiler Module
• BlazeDS does not have managed dataservices. This means that you don't need the fds.swc (DataService & [Managed]) in your flex projects.. you will use either Consumer, Producer or RemoteObject Classes
• BlazeDS does support AMF3, RemoteClasses & Messaging with a "lite" version of push via amf streaming
  

To download the blazeBlank application click here. (as new builds of Flex 3 and BlazeDS are released I'll try to keep this application updated). This application currently uses Flex 3 Beta 3 and BlazeDS Beta 1. Be sure to visit the url /{context}/TestApp/Main.mxml to ensure that the application is working properly. (i.e. http://localhost:8600/blazeBlank/TestApp/Main.mxml)

BPEL Process Invocation from different UI's - Best Practices

In my previous thread I've talked about different tips & tricks when working with ESB, BPEL, ODI, Flex, etc.

One of these tips was tips & tricks on invocation of BPEL Processes when using different UI approaches.

A very understable explanation given by 'Hajo Normann' about this:

It is best practice to use the default ways to invoke a BPEL process –
create a WSDL that maps to WSIF binding in a controlled environment and to a
SOAP/HTTP binding in a more B2B type of scenario. A call to the BPEL API would
be a “custom” solution that needs way more governance to communicate with fellow
developers and to maintain properly, when compared to the straightforward
standard way.

So, I suggest to use the API only if you desperately need
to optimize and found the default implementations violating your SLAs.

Let’s have a look at the technical implications:

If you run your presentation logic in the same Java VM as your BPEL process, you would use the default mechanism of invoking the process with the default WSDL. Under the hood, the middleware creates WSIF bindings that
- are extremely memory friendly, because no redundant memory is allocated (the middleware passes a reference to the Java object)
- share transactions

In this scenario I see no advantage of calling the API.

If you run your presentation logic in an other Java VM as your BPEL process in a controlled environment, you would still benefit from using the default mechanism of invoking the process with his default WSDL. Under the hood, the middleware creates WSIF bindings that

- serialize the passed Java objects and, on the BPEL side, create the BPEL DOM
implementations that make up the BPEL instance variables. This causes a performance and memory penalty you have to pay
- share transactions

I haven't seen any benchmarks regarding this or haven't received more information of the Oracle Development Team so hopefully this will start up a big discussion ;o)

Working With BlazeDS Beta 1

Last week we successfully ported an AIR application from amfphp to BlazeDS. The code for this application was almost completely generated by a new generator we're working on (coming soon!). With the announcement of BlazeDS, we kinda shelved our php generator and redirected our efforts in doing the same thing for BlazeDS. In the process, we put together our own version of the blazeds.war file that ships with BlazeDS beta 1, which we use as the starting point for all our BlazeDS projects. Here's a list of the changes we've made:

• Modified the context.xml found in the META-INF folder - the packaged one was producing Valve Errors
• Added the missing my-streaming-amf channel to services-config.xml, which I found in the BlazeDS samples war's config file
  
• Incorporated the latest Flex 3 Compiler Module files to allow server-side compilation of mxml files
• Created a very simple java class and a corresponding destination which will verify Blaze backend functionality
• Created a very simple Flex application that calls the above java class function test(string)
• Added 2 jars to WEB-INF, one is crazedTemplate.jar, which our new codegenerator (coming soon) uses, the other is sharpertools.jar, which the jar requires.
  

You can choose to go ahead and just use the application as is. It's only been tested on Tomcat / Win / OSX 10.5.2. If you don't intend on using our generator (coming soon!) to generate your java and AS3 Classes then you can go ahead and delete the 2 jars mentioned above. I really like this separation of compiler and essentially what was FDS. When FDS was originally released, it did both runtime compiles as well as Remoting, Messaging, Proxy and Managed Data Services. In our case, we never deployed anything that required runtime compilation AND furthermore, with each subsequent Flex release (2.01, Hotfix 1, 2 and 3), converting FDS projects that were set to compile on the server wasn't trivial. So we stopped using it. If I was super Java savvy I might have been able to figure out what parts I could yank out of my FDS application, but generally it seemed better to just leave it alone.

Now, with Blaze and the compiler war being separate, I've gone through the web.xml in this project and put comments to show which pieces are required by the compiler module and which pieces are required by Blaze. To get this back to being a pure Blaze non-Flex 3 Compiler Module, you'd just need to remove the appropriately marked sections from the web.xml and then remove all folders and files from WEB-INF/flex with the exception of:

• services-config.xml
• remoting-config.xml
• proxy-config.xml
• messaging-config.xml
  

Some of our clients have asked what the differences exactly are between BlazeDS and LCDS (prev. known as FDS). If you do enough research on the web, you can find several answers. From what I've seen, here's some differences I've found so far:

• BlazeDS does not support the RTMP Channel typically used by LCDS for data push (RTMP typically means firewall port challenges all around anyway!)
• BlazeDS does support AMF Streaming which offers data push like RTMP, however not nearly as scalable (100's vs 10000's of concurrent users)
• BlazeDS does support proxy so you can bypass the all too familiar sandbox issues when accessing remote data where no crossdomain.xml is present
• BlazeDS does not come packaged with the Compiler Module
• BlazeDS does not have managed dataservices. This means that you don't need the fds.swc (DataService & [Managed]) in your flex projects.. you will use either Consumer, Producer or RemoteObject Classes
• BlazeDS does support AMF3, RemoteClasses & Messaging with a "lite" version of push via amf streaming
  

To download the blazeBlank application click here. (as new builds of Flex 3 and BlazeDS are released I'll try to keep this application updated). This application currently uses Flex 3 Beta 3 and BlazeDS Beta 1. Be sure to visit the url /{context}/TestApp/Main.mxml to ensure that the application is working properly. (i.e. http://localhost:8600/blazeBlank/TestApp/Main.mxml)

BPEL Process Invocation from different UI's - Best Practices

In my previous thread I've talked about different tips & tricks when working with ESB, BPEL, ODI, Flex, etc.

One of these tips was tips & tricks on invocation of BPEL Processes when using different UI approaches.

A very understable explanation given by 'Hajo Normann' about this:

It is best practice to use the default ways to invoke a BPEL process –
create a WSDL that maps to WSIF binding in a controlled environment and to a
SOAP/HTTP binding in a more B2B type of scenario. A call to the BPEL API would
be a “custom” solution that needs way more governance to communicate with fellow
developers and to maintain properly, when compared to the straightforward
standard way.

So, I suggest to use the API only if you desperately need
to optimize and found the default implementations violating your SLAs.

Let’s have a look at the technical implications:

If you run your presentation logic in the same Java VM as your BPEL process, you would use the default mechanism of invoking the process with the default WSDL. Under the hood, the middleware creates WSIF bindings that
- are extremely memory friendly, because no redundant memory is allocated (the middleware passes a reference to the Java object)
- share transactions

In this scenario I see no advantage of calling the API.

If you run your presentation logic in an other Java VM as your BPEL process in a controlled environment, you would still benefit from using the default mechanism of invoking the process with his default WSDL. Under the hood, the middleware creates WSIF bindings that

- serialize the passed Java objects and, on the BPEL side, create the BPEL DOM
implementations that make up the BPEL instance variables. This causes a performance and memory penalty you have to pay
- share transactions

I haven't seen any benchmarks regarding this or haven't received more information of the Oracle Development Team so hopefully this will start up a big discussion ;o)

Working With BlazeDS Beta 1

Last week we successfully ported an AIR application from amfphp to BlazeDS. The code for this application was almost completely generated by a new generator we're working on (coming soon!). With the announcement of BlazeDS, we kinda shelved our php generator and redirected our efforts in doing the same thing for BlazeDS. In the process, we put together our own version of the blazeds.war file that ships with BlazeDS beta 1, which we use as the starting point for all our BlazeDS projects. Here's a list of the changes we've made:

• Modified the context.xml found in the META-INF folder - the packaged one was producing Valve Errors
• Added the missing my-streaming-amf channel to services-config.xml, which I found in the BlazeDS samples war's config file
  
• Incorporated the latest Flex 3 Compiler Module files to allow server-side compilation of mxml files
• Created a very simple java class and a corresponding destination which will verify Blaze backend functionality
• Created a very simple Flex application that calls the above java class function test(string)
• Added 2 jars to WEB-INF, one is crazedTemplate.jar, which our new codegenerator (coming soon) uses, the other is sharpertools.jar, which the jar requires.
  

You can choose to go ahead and just use the application as is. It's only been tested on Tomcat / Win / OSX 10.5.2. If you don't intend on using our generator (coming soon!) to generate your java and AS3 Classes then you can go ahead and delete the 2 jars mentioned above. I really like this separation of compiler and essentially what was FDS. When FDS was originally released, it did both runtime compiles as well as Remoting, Messaging, Proxy and Managed Data Services. In our case, we never deployed anything that required runtime compilation AND furthermore, with each subsequent Flex release (2.01, Hotfix 1, 2 and 3), converting FDS projects that were set to compile on the server wasn't trivial. So we stopped using it. If I was super Java savvy I might have been able to figure out what parts I could yank out of my FDS application, but generally it seemed better to just leave it alone.

Now, with Blaze and the compiler war being separate, I've gone through the web.xml in this project and put comments to show which pieces are required by the compiler module and which pieces are required by Blaze. To get this back to being a pure Blaze non-Flex 3 Compiler Module, you'd just need to remove the appropriately marked sections from the web.xml and then remove all folders and files from WEB-INF/flex with the exception of:

• services-config.xml
• remoting-config.xml
• proxy-config.xml
• messaging-config.xml
  

Some of our clients have asked what the differences exactly are between BlazeDS and LCDS (prev. known as FDS). If you do enough research on the web, you can find several answers. From what I've seen, here's some differences I've found so far:

• BlazeDS does not support the RTMP Channel typically used by LCDS for data push (RTMP typically means firewall port challenges all around anyway!)
• BlazeDS does support AMF Streaming which offers data push like RTMP, however not nearly as scalable (100's vs 10000's of concurrent users)
• BlazeDS does support proxy so you can bypass the all too familiar sandbox issues when accessing remote data where no crossdomain.xml is present
• BlazeDS does not come packaged with the Compiler Module
• BlazeDS does not have managed dataservices. This means that you don't need the fds.swc (DataService & [Managed]) in your flex projects.. you will use either Consumer, Producer or RemoteObject Classes
• BlazeDS does support AMF3, RemoteClasses & Messaging with a "lite" version of push via amf streaming
  

To download the blazeBlank application click here. (as new builds of Flex 3 and BlazeDS are released I'll try to keep this application updated). This application currently uses Flex 3 Beta 3 and BlazeDS Beta 1. Be sure to visit the url /{context}/TestApp/Main.mxml to ensure that the application is working properly. (i.e. http://localhost:8600/blazeBlank/TestApp/Main.mxml)

Soa Suite 10.1.3.3 - ESB, BPEL - Nice-to-knows, pitfalls

I've been checking out the different capabilities and new features of the Adapter-framework in ESB and BPEL for some weeks now and came across some nasty pitfalls, nice-to-knows, ... which I would like to share with you.

Of course I would like to share thoughts, opinions and start discussions on these topics.

ESB:

• How to define xsd-validation on file-adapter (validate payload at runtime-option isn't available in file adapter) : In the ESB console, select the routing service which is invoked after the inbound file adapter. See the "Definition" tab. The validation option is in the "Operation Details" section. (with thanks to Ronald)

• Define error-handling on file-adapter for erroneous files: use the 'rejectedMessageHandlers' endpoint property which you need to define manually in the esb-file (for more information have a look at the technical note about error handling http://www.oracle.com/technology/products/integration/adapters/pdf/Adapter_TN_004_Adapter_ErrorManagement.pdf
  

BPEL:

• Inserting master-detail data using DB Adapter functionality : Referring to my experiences so far it's best best way to make use of stored procedures instead of the toplink mappings file. I am mainly using the stored procedures because the tooling support in Jdeveloper (wizards, toplink ui), I still miss a good ui for the toplink support. Also it is easy to give the task to create an PL/SQL api to the PL/SQL developers that are working on a certain application. (with thanks to Orjan)

• [Error ORABPEL-10007]: unresolved messageType for "{http://schemas.oracle.com/bpel/extension}RuntimeFaultMessage": When you've defined an empty bpel process (which is best practice to do the brain-work) you will face this issue when defining fault-handling inside your bpel-process. To solve this error you need to import the RuntimeFault.wsdl inside the adapter you're using. Following import statement needs to be added:

• Best practices when invoking Bpel Processes from different UI's (Flex, JSF, ...) : Many thanks to Hajo for his explanation: It is best practice to use the default ways to invoke a BPEL process – create a WSDL that maps to WSIF binding in a controlled environment and to a SOAP/HTTP binding in a more B2B type of scenario. A call to the BPEL API would be a “custom” solution that needs way more governance to communicate with fellow developers and to maintain properly, when compared to the straightforward standard way. . For more details see OTN Thread: http://forums.oracle.com/forums/thread.jspa?messageID=2329384&#2329384

• Use multiple sources in transform-activity: In 11g a new feature has been added to be able to use multiple sources using bpel 2.0 (bpel:doXslTransform(string, node-set, (string, object)*)). The workaround in 10.1.3.3 is by using the params-approach => http://blogs.oracle.com/rammenon/2007/05/07. Or by using an assign-activity with append-functionality to add the variable inside your source-target and in the same assign-activity add the process-xslt functionality to call your xsl to populate the source with the target-information.

Invoking Web Services from Database:

• Call an esb service using the UTL_HTTP package => ORA-29266: end-of-body reached => make sure to pass variables using String-notation instead of Character-notation

Interesting New Features in 10.1.3.3 :

• Controlling the Size of a Rejected Message (10133technotes.pdf):
  You can now control the size of a rejected message by specifying the following
  endpoint property for the inbound File/FTP adapter partner link.
  In this example, you reject 100 lines from the file since the actual file is too large.
  oracle.tip.adapter.file.debatching.rejection.quantum=”100”

• ESB Endpoint Properties : e.g. ability to add RejectedMessageHandler to file adapter services

Enhancement Requests:

• Ability to validate xml payload at runtime on Adapter-level instead of on domain level or routing service level
• Ability to add xsi:nil attribute using xsl-functionality in transform-activity
• File-adapter: Ability to skip columns besides skipping rows + ability to use special characters in column headers

Well that's it for now ... feel free to share thoughts, comments, etc.

Working With BlazeDS Beta 1

Last week we successfully ported an AIR application from amfphp to BlazeDS. The code for this application was almost completely generated by a new generator we're working on (coming soon!). With the announcement of BlazeDS, we kinda shelved our php generator and redirected our efforts in doing the same thing for BlazeDS. In the process, we put together our own version of the blazeds.war file that ships with BlazeDS beta 1, which we use as the starting point for all our BlazeDS projects. Here's a list of the changes we've made:

• Modified the context.xml found in the META-INF folder - the packaged one was producing Valve Errors
• Added the missing my-streaming-amf channel to services-config.xml, which I found in the BlazeDS samples war's config file
  
• Incorporated the latest Flex 3 Compiler Module files to allow server-side compilation of mxml files
• Created a very simple java class and a corresponding destination which will verify Blaze backend functionality
• Created a very simple Flex application that calls the above java class function test(string)
• Added 2 jars to WEB-INF, one is crazedTemplate.jar, which our new codegenerator (coming soon) uses, the other is sharpertools.jar, which the jar requires.
  

You can choose to go ahead and just use the application as is. It's only been tested on Tomcat / Win / OSX 10.5.2. If you don't intend on using our generator (coming soon!) to generate your java and AS3 Classes then you can go ahead and delete the 2 jars mentioned above. I really like this separation of compiler and essentially what was FDS. When FDS was originally released, it did both runtime compiles as well as Remoting, Messaging, Proxy and Managed Data Services. In our case, we never deployed anything that required runtime compilation AND furthermore, with each subsequent Flex release (2.01, Hotfix 1, 2 and 3), converting FDS projects that were set to compile on the server wasn't trivial. So we stopped using it. If I was super Java savvy I might have been able to figure out what parts I could yank out of my FDS application, but generally it seemed better to just leave it alone.

Now, with Blaze and the compiler war being separate, I've gone through the web.xml in this project and put comments to show which pieces are required by the compiler module and which pieces are required by Blaze. To get this back to being a pure Blaze non-Flex 3 Compiler Module, you'd just need to remove the appropriately marked sections from the web.xml and then remove all folders and files from WEB-INF/flex with the exception of:

• services-config.xml
• remoting-config.xml
• proxy-config.xml
• messaging-config.xml
  

Some of our clients have asked what the differences exactly are between BlazeDS and LCDS (prev. known as FDS). If you do enough research on the web, you can find several answers. From what I've seen, here's some differences I've found so far:

• BlazeDS does not support the RTMP Channel typically used by LCDS for data push (RTMP typically means firewall port challenges all around anyway!)
• BlazeDS does support AMF Streaming which offers data push like RTMP, however not nearly as scalable (100's vs 10000's of concurrent users)
• BlazeDS does support proxy so you can bypass the all too familiar sandbox issues when accessing remote data where no crossdomain.xml is present
• BlazeDS does not come packaged with the Compiler Module
• BlazeDS does not have managed dataservices. This means that you don't need the fds.swc (DataService & [Managed]) in your flex projects.. you will use either Consumer, Producer or RemoteObject Classes
• BlazeDS does support AMF3, RemoteClasses & Messaging with a "lite" version of push via amf streaming
  

To download the blazeBlank application click here. (as new builds of Flex 3 and BlazeDS are released I'll try to keep this application updated). This application currently uses Flex 3 Beta 3 and BlazeDS Beta 1. Be sure to visit the url /{context}/TestApp/Main.mxml to ensure that the application is working properly. (i.e. http://localhost:8600/blazeBlank/TestApp/Main.mxml)

Soa Suite 10.1.3.3 - ESB, BPEL - Nice-to-knows, pitfalls

I've been checking out the different capabilities and new features of the Adapter-framework in ESB and BPEL for some weeks now and came across some nasty pitfalls, nice-to-knows, ... which I would like to share with you.

Of course I would like to share thoughts, opinions and start discussions on these topics.

ESB:

• How to define xsd-validation on file-adapter (validate payload at runtime-option isn't available in file adapter) : In the ESB console, select the routing service which is invoked after the inbound file adapter. See the "Definition" tab. The validation option is in the "Operation Details" section. (with thanks to Ronald)

• Define error-handling on file-adapter for erroneous files: use the 'rejectedMessageHandlers' endpoint property which you need to define manually in the esb-file (for more information have a look at the technical note about error handling http://www.oracle.com/technology/products/integration/adapters/pdf/Adapter_TN_004_Adapter_ErrorManagement.pdf
  

BPEL:

• Inserting master-detail data using DB Adapter functionality : Referring to my experiences so far it's best best way to make use of stored procedures instead of the toplink mappings file. I am mainly using the stored procedures because the tooling support in Jdeveloper (wizards, toplink ui), I still miss a good ui for the toplink support. Also it is easy to give the task to create an PL/SQL api to the PL/SQL developers that are working on a certain application. (with thanks to Orjan)

• [Error ORABPEL-10007]: unresolved messageType for "{http://schemas.oracle.com/bpel/extension}RuntimeFaultMessage": When you've defined an empty bpel process (which is best practice to do the brain-work) you will face this issue when defining fault-handling inside your bpel-process. To solve this error you need to import the RuntimeFault.wsdl inside the adapter you're using. Following import statement needs to be added:

• Best practices when invoking Bpel Processes from different UI's (Flex, JSF, ...) : Many thanks to Hajo for his explanation: It is best practice to use the default ways to invoke a BPEL process – create a WSDL that maps to WSIF binding in a controlled environment and to a SOAP/HTTP binding in a more B2B type of scenario. A call to the BPEL API would be a “custom” solution that needs way more governance to communicate with fellow developers and to maintain properly, when compared to the straightforward standard way. . For more details see OTN Thread: http://forums.oracle.com/forums/thread.jspa?messageID=2329384&#2329384

• Use multiple sources in transform-activity: In 11g a new feature has been added to be able to use multiple sources using bpel 2.0 (bpel:doXslTransform(string, node-set, (string, object)*)). The workaround in 10.1.3.3 is by using the params-approach => http://blogs.oracle.com/rammenon/2007/05/07. Or by using an assign-activity with append-functionality to add the variable inside your source-target and in the same assign-activity add the process-xslt functionality to call your xsl to populate the source with the target-information.

Invoking Web Services from Database:

• Call an esb service using the UTL_HTTP package => ORA-29266: end-of-body reached => make sure to pass variables using String-notation instead of Character-notation

Interesting New Features in 10.1.3.3 :

• Controlling the Size of a Rejected Message (10133technotes.pdf):
  You can now control the size of a rejected message by specifying the following
  endpoint property for the inbound File/FTP adapter partner link.
  In this example, you reject 100 lines from the file since the actual file is too large.
  oracle.tip.adapter.file.debatching.rejection.quantum=”100”

• ESB Endpoint Properties : e.g. ability to add RejectedMessageHandler to file adapter services

Enhancement Requests:

• Ability to validate xml payload at runtime on Adapter-level instead of on domain level or routing service level
• Ability to add xsi:nil attribute using xsl-functionality in transform-activity
• File-adapter: Ability to skip columns besides skipping rows + ability to use special characters in column headers

Well that's it for now ... feel free to share thoughts, comments, etc.

Working With BlazeDS Beta 1

Last week we successfully ported an AIR application from amfphp to BlazeDS. The code for this application was almost completely generated by a new generator we're working on (coming soon!). With the announcement of BlazeDS, we kinda shelved our php generator and redirected our efforts in doing the same thing for BlazeDS. In the process, we put together our own version of the blazeds.war file that ships with BlazeDS beta 1, which we use as the starting point for all our BlazeDS projects. Here's a list of the changes we've made:

• Modified the context.xml found in the META-INF folder - the packaged one was producing Valve Errors
• Added the missing my-streaming-amf channel to services-config.xml, which I found in the BlazeDS samples war's config file
  
• Incorporated the latest Flex 3 Compiler Module files to allow server-side compilation of mxml files
• Created a very simple java class and a corresponding destination which will verify Blaze backend functionality
• Created a very simple Flex application that calls the above java class function test(string)
• Added 2 jars to WEB-INF, one is crazedTemplate.jar, which our new codegenerator (coming soon) uses, the other is sharpertools.jar, which the jar requires.
  

You can choose to go ahead and just use the application as is. It's only been tested on Tomcat / Win / OSX 10.5.2. If you don't intend on using our generator (coming soon!) to generate your java and AS3 Classes then you can go ahead and delete the 2 jars mentioned above. I really like this separation of compiler and essentially what was FDS. When FDS was originally released, it did both runtime compiles as well as Remoting, Messaging, Proxy and Managed Data Services. In our case, we never deployed anything that required runtime compilation AND furthermore, with each subsequent Flex release (2.01, Hotfix 1, 2 and 3), converting FDS projects that were set to compile on the server wasn't trivial. So we stopped using it. If I was super Java savvy I might have been able to figure out what parts I could yank out of my FDS application, but generally it seemed better to just leave it alone.

Now, with Blaze and the compiler war being separate, I've gone through the web.xml in this project and put comments to show which pieces are required by the compiler module and which pieces are required by Blaze. To get this back to being a pure Blaze non-Flex 3 Compiler Module, you'd just need to remove the appropriately marked sections from the web.xml and then remove all folders and files from WEB-INF/flex with the exception of:

• services-config.xml
• remoting-config.xml
• proxy-config.xml
• messaging-config.xml
  

Some of our clients have asked what the differences exactly are between BlazeDS and LCDS (prev. known as FDS). If you do enough research on the web, you can find several answers. From what I've seen, here's some differences I've found so far:

• BlazeDS does not support the RTMP Channel typically used by LCDS for data push (RTMP typically means firewall port challenges all around anyway!)
• BlazeDS does support AMF Streaming which offers data push like RTMP, however not nearly as scalable (100's vs 10000's of concurrent users)
• BlazeDS does support proxy so you can bypass the all too familiar sandbox issues when accessing remote data where no crossdomain.xml is present
• BlazeDS does not come packaged with the Compiler Module
• BlazeDS does not have managed dataservices. This means that you don't need the fds.swc (DataService & [Managed]) in your flex projects.. you will use either Consumer, Producer or RemoteObject Classes
• BlazeDS does support AMF3, RemoteClasses & Messaging with a "lite" version of push via amf streaming
  

To download the blazeBlank application click here. (as new builds of Flex 3 and BlazeDS are released I'll try to keep this application updated). This application currently uses Flex 3 Beta 3 and BlazeDS Beta 1. Be sure to visit the url /{context}/TestApp/Main.mxml to ensure that the application is working properly. (i.e. http://localhost:8600/blazeBlank/TestApp/Main.mxml)

Soa Suite 10.1.3.3 - ESB, BPEL - Nice-to-knows, pitfalls

I've been checking out the different capabilities and new features of the Adapter-framework in ESB and BPEL for some weeks now and came across some nasty pitfalls, nice-to-knows, ... which I would like to share with you.

Of course I would like to share thoughts, opinions and start discussions on these topics.

ESB:

• How to define xsd-validation on file-adapter (validate payload at runtime-option isn't available in file adapter) : In the ESB console, select the routing service which is invoked after the inbound file adapter. See the "Definition" tab. The validation option is in the "Operation Details" section. (with thanks to Ronald)

• Define error-handling on file-adapter for erroneous files: use the 'rejectedMessageHandlers' endpoint property which you need to define manually in the esb-file (for more information have a look at the technical note about error handling http://www.oracle.com/technology/products/integration/adapters/pdf/Adapter_TN_004_Adapter_ErrorManagement.pdf
  

BPEL:

• Inserting master-detail data using DB Adapter functionality : Referring to my experiences so far it's best best way to make use of stored procedures instead of the toplink mappings file. I am mainly using the stored procedures because the tooling support in Jdeveloper (wizards, toplink ui), I still miss a good ui for the toplink support. Also it is easy to give the task to create an PL/SQL api to the PL/SQL developers that are working on a certain application. (with thanks to Orjan)

• [Error ORABPEL-10007]: unresolved messageType for "{http://schemas.oracle.com/bpel/extension}RuntimeFaultMessage": When you've defined an empty bpel process (which is best practice to do the brain-work) you will face this issue when defining fault-handling inside your bpel-process. To solve this error you need to import the RuntimeFault.wsdl inside the adapter you're using. Following import statement needs to be added:

• Best practices when invoking Bpel Processes from different UI's (Flex, JSF, ...) : Many thanks to Hajo for his explanation: It is best practice to use the default ways to invoke a BPEL process – create a WSDL that maps to WSIF binding in a controlled environment and to a SOAP/HTTP binding in a more B2B type of scenario. A call to the BPEL API would be a “custom” solution that needs way more governance to communicate with fellow developers and to maintain properly, when compared to the straightforward standard way. . For more details see OTN Thread: http://forums.oracle.com/forums/thread.jspa?messageID=2329384&#2329384

• Use multiple sources in transform-activity: In 11g a new feature has been added to be able to use multiple sources using bpel 2.0 (bpel:doXslTransform(string, node-set, (string, object)*)). The workaround in 10.1.3.3 is by using the params-approach => http://blogs.oracle.com/rammenon/2007/05/07. Or by using an assign-activity with append-functionality to add the variable inside your source-target and in the same assign-activity add the process-xslt functionality to call your xsl to populate the source with the target-information.

Invoking Web Services from Database:

• Call an esb service using the UTL_HTTP package => ORA-29266: end-of-body reached => make sure to pass variables using String-notation instead of Character-notation

Interesting New Features in 10.1.3.3 :

• Controlling the Size of a Rejected Message (10133technotes.pdf):
  You can now control the size of a rejected message by specifying the following
  endpoint property for the inbound File/FTP adapter partner link.
  In this example, you reject 100 lines from the file since the actual file is too large.
  oracle.tip.adapter.file.debatching.rejection.quantum=”100”

• ESB Endpoint Properties : e.g. ability to add RejectedMessageHandler to file adapter services

Enhancement Requests:

• Ability to validate xml payload at runtime on Adapter-level instead of on domain level or routing service level
• Ability to add xsi:nil attribute using xsl-functionality in transform-activity
• File-adapter: Ability to skip columns besides skipping rows + ability to use special characters in column headers

Well that's it for now ... feel free to share thoughts, comments, etc.

Working With BlazeDS Beta 1

Last week we successfully ported an AIR application from amfphp to BlazeDS. The code for this application was almost completely generated by a new generator we're working on (coming soon!). With the announcement of BlazeDS, we kinda shelved our php generator and redirected our efforts in doing the same thing for BlazeDS. In the process, we put together our own version of the blazeds.war file that ships with BlazeDS beta 1, which we use as the starting point for all our BlazeDS projects. Here's a list of the changes we've made:

• Modified the context.xml found in the META-INF folder - the packaged one was producing Valve Errors
• Added the missing my-streaming-amf channel to services-config.xml, which I found in the BlazeDS samples war's config file
  
• Incorporated the latest Flex 3 Compiler Module files to allow server-side compilation of mxml files
• Created a very simple java class and a corresponding destination which will verify Blaze backend functionality
• Created a very simple Flex application that calls the above java class function test(string)
• Added 2 jars to WEB-INF, one is crazedTemplate.jar, which our new codegenerator (coming soon) uses, the other is sharpertools.jar, which the jar requires.
  

You can choose to go ahead and just use the application as is. It's only been tested on Tomcat / Win / OSX 10.5.2. If you don't intend on using our generator (coming soon!) to generate your java and AS3 Classes then you can go ahead and delete the 2 jars mentioned above. I really like this separation of compiler and essentially what was FDS. When FDS was originally released, it did both runtime compiles as well as Remoting, Messaging, Proxy and Managed Data Services. In our case, we never deployed anything that required runtime compilation AND furthermore, with each subsequent Flex release (2.01, Hotfix 1, 2 and 3), converting FDS projects that were set to compile on the server wasn't trivial. So we stopped using it. If I was super Java savvy I might have been able to figure out what parts I could yank out of my FDS application, but generally it seemed better to just leave it alone.

Now, with Blaze and the compiler war being separate, I've gone through the web.xml in this project and put comments to show which pieces are required by the compiler module and which pieces are required by Blaze. To get this back to being a pure Blaze non-Flex 3 Compiler Module, you'd just need to remove the appropriately marked sections from the web.xml and then remove all folders and files from WEB-INF/flex with the exception of:

• services-config.xml
• remoting-config.xml
• proxy-config.xml
• messaging-config.xml
  

Some of our clients have asked what the differences exactly are between BlazeDS and LCDS (prev. known as FDS). If you do enough research on the web, you can find several answers. From what I've seen, here's some differences I've found so far:

• BlazeDS does not support the RTMP Channel typically used by LCDS for data push (RTMP typically means firewall port challenges all around anyway!)
• BlazeDS does support AMF Streaming which offers data push like RTMP, however not nearly as scalable (100's vs 10000's of concurrent users)
• BlazeDS does support proxy so you can bypass the all too familiar sandbox issues when accessing remote data where no crossdomain.xml is present
• BlazeDS does not come packaged with the Compiler Module
• BlazeDS does not have managed dataservices. This means that you don't need the fds.swc (DataService & [Managed]) in your flex projects.. you will use either Consumer, Producer or RemoteObject Classes
• BlazeDS does support AMF3, RemoteClasses & Messaging with a "lite" version of push via amf streaming
  

To download the blazeBlank application click here. (as new builds of Flex 3 and BlazeDS are released I'll try to keep this application updated). This application currently uses Flex 3 Beta 3 and BlazeDS Beta 1. Be sure to visit the url /{context}/TestApp/Main.mxml to ensure that the application is working properly. (i.e. http://localhost:8600/blazeBlank/TestApp/Main.mxml)

Soa Suite 10.1.3.3 - ESB, BPEL - Nice-to-knows, pitfalls

I've been checking out the different capabilities and new features of the Adapter-framework in ESB and BPEL for some weeks now and came across some nasty pitfalls, nice-to-knows, ... which I would like to share with you.

Of course I would like to share thoughts, opinions and start discussions on these topics.

ESB:

• How to define xsd-validation on file-adapter (validate payload at runtime-option isn't available in file adapter) : In the ESB console, select the routing service which is invoked after the inbound file adapter. See the "Definition" tab. The validation option is in the "Operation Details" section. (with thanks to Ronald)

• Define error-handling on file-adapter for erroneous files: use the 'rejectedMessageHandlers' endpoint property which you need to define manually in the esb-file (for more information have a look at the technical note about error handling http://www.oracle.com/technology/products/integration/adapters/pdf/Adapter_TN_004_Adapter_ErrorManagement.pdf
  

BPEL:

• Inserting master-detail data using DB Adapter functionality : Referring to my experiences so far it's best best way to make use of stored procedures instead of the toplink mappings file. I am mainly using the stored procedures because the tooling support in Jdeveloper (wizards, toplink ui), I still miss a good ui for the toplink support. Also it is easy to give the task to create an PL/SQL api to the PL/SQL developers that are working on a certain application. (with thanks to Orjan)

• [Error ORABPEL-10007]: unresolved messageType for "{http://schemas.oracle.com/bpel/extension}RuntimeFaultMessage": When you've defined an empty bpel process (which is best practice to do the brain-work) you will face this issue when defining fault-handling inside your bpel-process. To solve this error you need to import the RuntimeFault.wsdl inside the adapter you're using. Following import statement needs to be added:

• Best practices when invoking Bpel Processes from different UI's (Flex, JSF, ...) : Many thanks to Hajo for his explanation: It is best practice to use the default ways to invoke a BPEL process – create a WSDL that maps to WSIF binding in a controlled environment and to a SOAP/HTTP binding in a more B2B type of scenario. A call to the BPEL API would be a “custom” solution that needs way more governance to communicate with fellow developers and to maintain properly, when compared to the straightforward standard way. . For more details see OTN Thread: http://forums.oracle.com/forums/thread.jspa?messageID=2329384&#2329384

• Use multiple sources in transform-activity: In 11g a new feature has been added to be able to use multiple sources using bpel 2.0 (bpel:doXslTransform(string, node-set, (string, object)*)). The workaround in 10.1.3.3 is by using the params-approach => http://blogs.oracle.com/rammenon/2007/05/07. Or by using an assign-activity with append-functionality to add the variable inside your source-target and in the same assign-activity add the process-xslt functionality to call your xsl to populate the source with the target-information.

Invoking Web Services from Database:

• Call an esb service using the UTL_HTTP package => ORA-29266: end-of-body reached => make sure to pass variables using String-notation instead of Character-notation

Interesting New Features in 10.1.3.3 :

• Controlling the Size of a Rejected Message (10133technotes.pdf):
  You can now control the size of a rejected message by specifying the following
  endpoint property for the inbound File/FTP adapter partner link.
  In this example, you reject 100 lines from the file since the actual file is too large.
  oracle.tip.adapter.file.debatching.rejection.quantum=”100”

• ESB Endpoint Properties : e.g. ability to add RejectedMessageHandler to file adapter services

Enhancement Requests:

• Ability to validate xml payload at runtime on Adapter-level instead of on domain level or routing service level
• Ability to add xsi:nil attribute using xsl-functionality in transform-activity
• File-adapter: Ability to skip columns besides skipping rows + ability to use special characters in column headers

Well that's it for now ... feel free to share thoughts, comments, etc.

Working With BlazeDS Beta 1

Last week we successfully ported an AIR application from amfphp to BlazeDS. The code for this application was almost completely generated by a new generator we're working on (coming soon!). With the announcement of BlazeDS, we kinda shelved our php generator and redirected our efforts in doing the same thing for BlazeDS. In the process, we put together our own version of the blazeds.war file that ships with BlazeDS beta 1, which we use as the starting point for all our BlazeDS projects. Here's a list of the changes we've made:

• Modified the context.xml found in the META-INF folder - the packaged one was producing Valve Errors
• Added the missing my-streaming-amf channel to services-config.xml, which I found in the BlazeDS samples war's config file
  
• Incorporated the latest Flex 3 Compiler Module files to allow server-side compilation of mxml files
• Created a very simple java class and a corresponding destination which will verify Blaze backend functionality
• Created a very simple Flex application that calls the above java class function test(string)
• Added 2 jars to WEB-INF, one is crazedTemplate.jar, which our new codegenerator (coming soon) uses, the other is sharpertools.jar, which the jar requires.
  

You can choose to go ahead and just use the application as is. It's only been tested on Tomcat / Win / OSX 10.5.2. If you don't intend on using our generator (coming soon!) to generate your java and AS3 Classes then you can go ahead and delete the 2 jars mentioned above. I really like this separation of compiler and essentially what was FDS. When FDS was originally released, it did both runtime compiles as well as Remoting, Messaging, Proxy and Managed Data Services. In our case, we never deployed anything that required runtime compilation AND furthermore, with each subsequent Flex release (2.01, Hotfix 1, 2 and 3), converting FDS projects that were set to compile on the server wasn't trivial. So we stopped using it. If I was super Java savvy I might have been able to figure out what parts I could yank out of my FDS application, but generally it seemed better to just leave it alone.

Now, with Blaze and the compiler war being separate, I've gone through the web.xml in this project and put comments to show which pieces are required by the compiler module and which pieces are required by Blaze. To get this back to being a pure Blaze non-Flex 3 Compiler Module, you'd just need to remove the appropriately marked sections from the web.xml and then remove all folders and files from WEB-INF/flex with the exception of:

• services-config.xml
• remoting-config.xml
• proxy-config.xml
• messaging-config.xml
  

Some of our clients have asked what the differences exactly are between BlazeDS and LCDS (prev. known as FDS). If you do enough research on the web, you can find several answers. From what I've seen, here's some differences I've found so far:

• BlazeDS does not support the RTMP Channel typically used by LCDS for data push (RTMP typically means firewall port challenges all around anyway!)
• BlazeDS does support AMF Streaming which offers data push like RTMP, however not nearly as scalable (100's vs 10000's of concurrent users)
• BlazeDS does support proxy so you can bypass the all too familiar sandbox issues when accessing remote data where no crossdomain.xml is present
• BlazeDS does not come packaged with the Compiler Module
• BlazeDS does not have managed dataservices. This means that you don't need the fds.swc (DataService & [Managed]) in your flex projects.. you will use either Consumer, Producer or RemoteObject Classes
• BlazeDS does support AMF3, RemoteClasses & Messaging with a "lite" version of push via amf streaming
  

To download the blazeBlank application click here. (as new builds of Flex 3 and BlazeDS are released I'll try to keep this application updated). This application currently uses Flex 3 Beta 3 and BlazeDS Beta 1. Be sure to visit the url /{context}/TestApp/Main.mxml to ensure that the application is working properly. (i.e. http://localhost:8600/blazeBlank/TestApp/Main.mxml)