IEP/cql Personal Discoveries...

Well, I can't really call this FAQ since I'm finding these mostly on my own... There is not much for now, but I'm hoping to add as I go along the learning path...

Q. What can be connected to what ? So many choices and not much to help with deciding...

1. To help you with that, create a process with the candidate elements you would think of using. Then start to draw a line from the source element. You'll see "X"s appear on the ports of elements you can't use. This will help greatly on knowing what can be used together.
2. Colours highlight types of connections. Green to green, grey to grey, etc. Some blocks have two colours so it can be called/can call multiple types of operators. (Jason)

Q. Which output to use?

1. See here for this.

Q. Which input to use?

1. There are only two inputs. Streams and tables. Well, scratch that. There are two sources of data, but only the streams are inputs.
2. Unless I could simply not find it, there are no triggers on the tables to get an event when a new row is added or a row is deleted.

Q. Why do I always loose my WSDL customizations?

1. The WSDL is generated by the interface on the iep process. So if you change the external aspect of the iep process (like the output) then the WSDL will get changed. Make a backup copy of your modifications to avoid entering them all the time...

Q. Should I use the WSDL that is generated from the build?

1. While this is a good one to use, I perfer using the one that is returned from the deployed URL:
1. http://<hostname>:<port>/service/<iepProcessName>?WSDL
2. I use it with soap ui or with the web tester in Netbeans. Doing so allow me to just have to refresh directly from the application server and not the development environment. I think this is a good practice, since we are sure we're using the description that is actually deployed...
   

Q. So, what is so special about IEP that I can't do with a SQL server?

1. Well, give me enough time, and I can do about any system in assembler. But would I want to? IEP is based on CQL, which has two aspects that makes is very attractive to use, instead of simply using a SQL system:
1. Time sensitive. Think of IEP as a database where the data can change with time. And time is actually a major factor in the relevance of the data you are dealing with. Is the quality data of last year as relevant to your business as the quality data of last week? A SQL server wouldn't see any difference. IEP processes can.
2. IEP constructs are seen as sets, just like SQL, and as data flow (this is different). So when constructing the processing model for IEP, you do it using flowing constructs, going from one operator (or data source), to another operator. This can lead you to create complex event processing model, that would require you to break them down in multiple steps, if you were to process them in SQL statements.
2. Think of it as layers. SQL is the basic layer used by IEP to store the sets of data. You can then use IEP as a time sensitive parlance, to handle the events in a more natural way that always has the flowing nature of events in mind.
   

Q. Have any other questions?

1. If you are in a time crunch, use supported channels or go through your local Sun sales representatives.
2. In a slower mode, but don't want to rely on a single person, use the open-esb mailing lists or forum.
3. Don't mind being answered whenever I have time for it, post your question as a comment here....

Thanks

Posted at 10:30AM Mar 05, 2008 by sergeblais in OpenESB  |  Comments[1]