I'm proud to announce the release of jUDDI-3.0.0.beta. Since the alpha release the implementation has shown stability and performance, and it implements the final two UDDI API implementations targeted for the 3.0.0 release; "Subscription" and "Custody transfer". Subscriptions allow you to register for updates in the Registry. The registry will send out the notification by calling an endpoint defined at registration time. The generic UDDI client now supports InVM transport to allow jUDDI to run in embedded mode. For a complete overview of what went into this release see the release notes:
http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10401&styleName=Html&version=12313630
Finally, we also started work on the console.
The console is Pluto portal which plugs in uddi-portlets. The portlets are GWT based. We'd have one to Publish, Search, Browse, Subscribe etc.. Right now you can see a tree of services under the publisher you log in as. You can download the portal-bundle from the following url if you want to see it all in action.
http://www.apache.org/dist/ws/juddi/3_0/juddi-portal-bundle-3.0.0.beta.zip
--Kurt
Friday, June 5, 2009
Synergy rocks (for once)
Whenever companies merge great "Synergies" are promised by upper-management. I hate that word. It's a red flag for me. So for that reason alone I had not tried out Synergy until yesterday. However I really like working on the mac, and this way I can; I can simply move my mouse across to the other machines. This is really pretty sweet. Finally a good use of the word synergy! Great work guys. Thx.
--Kurt
--Kurt
Wednesday, June 3, 2009
Setup of a Wireless Connection on a Lenovo T400 running centos 5.3
I recently installed Centos 5.3 on my Lenovo T400, and everything pretty much worked except for the wireless connection. I had a hard time finding instructions on how to get it working but this blog entry was most helpful.
First make sure the RPMForge repo is installed
rpm -Uhv http://apt.sw.be/redhat/el5/en/x86_64/rpmforge/RPMS/rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm
yum clean all
yum update
Next install the driver for the PRO/Wireless 5100 AGN[Shiloh] card from Intel
yum install iwl5000-firmware
The wireless device should now be working, and you can enable the NetworkManager to start using it
chkconfig NetworkManager on
service NetworkManager start
and you may want to save yourself some wait time at boottime by disabling the network since you don't need that anymore
chkconfig network off
Next you need to configure your wireless connection settings by going to System > Preferences > More Preferences > Network Connections
Select the Wireless tab and click on Add, and fill out your connection settings.
First make sure the RPMForge repo is installed
rpm -Uhv http://apt.sw.be/redhat/el5/en/x86_64/rpmforge/RPMS/rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm
yum clean all
yum update
Next install the driver for the PRO/Wireless 5100 AGN[Shiloh] card from Intel
yum install iwl5000-firmware
The wireless device should now be working, and you can enable the NetworkManager to start using it
chkconfig NetworkManager on
service NetworkManager start
and you may want to save yourself some wait time at boottime by disabling the network since you don't need that anymore
chkconfig network off
Next you need to configure your wireless connection settings by going to System > Preferences > More Preferences > Network Connections
Select the Wireless tab and click on Add, and fill out your connection settings.
Saturday, May 23, 2009
jUDDI v3.0.0 SNAPSHOT
The jUDDI project has seen a lot of activity lately in the ramp up for the jUDDIv3 beta release. The biggest change with the alpha release is that for beta the Subscription API will be fully implemented. One of the missing features of jUDDI has always been a good console. After the beta release we will work hard to get that work completed. However it is very exciting that we already have the beginnings of the console.
You can download a ready to go bundle (3.0.0.SNAPSHOT) from the repos.
--Kurt
You can download a ready to go bundle (3.0.0.SNAPSHOT) from the repos.
--Kurt
Friday, April 3, 2009
Switch JBossESB-4.5.GA from HSQL to MSSQL
To switch JBossESB from the default HSQL embedded database to a "real" database like MSSQL, the persistence configuration of JMS, jUDDI, ESB MessageStore and jBPM needs updating.
1. JMS
rm server/default/deploy/jms/hsqldb-jdbc2-service.xml
cp docs/examples/jms/mssql-jdbc2-service.xml server/default/deploy/jms
cp docs/examples/jca/mssql-ds.xml server/default/deploy/jms
mv server/default/deploy/jms/hsql-jdbc-state-service.xml server/default/deploy/jms/mssql-jdbc-state-service.xml
update the mssql-jdbc-state-service.xml to point to the MSSQLDS datasource
update the "Security domain for JBossMQ" in the server/default/conf/login-config.xml to java:/MSSQLDS
2. jUDDI
cp docs/examples/jca/mssql-ds.xml server/default/deploy/jbossesb.sar/juddi-ds.xml
update the juddi-ds.xml, make sure the <jndi-name>juddiDB</jndi-name>
update the server/default/deploy/jbossesb.sar/esb.juddi.xml to make sure the mssql sql is used to create the jUDDI tables
3. JBossESB MessageStore
rm server/default/deploy/jbossesb.esb/hsql-ds.xml
cp docs/examples/jca/mssql-ds.xml server/default/deploy/jbossesb.esb
update the mssql-ds.xml, make sure the <jndi-name>JBossESBDS</jndi-name>
update the server/default/deploy/jbossesb.esb/jbossesb-service.xml to point to the mssql sql for creating the message table
4. jBPM
rm server/default/deploy/jbpm.esb/hsql-ds.xml
cp docs/examples/jca/mssql-ds.xml server/default/deploy/jbpm.esb/
update the mssql-ds.xml, make sure the <jndi-name>JbpmDS</jndi-name>
update the server/default/deploy/jbpm.esb/hibernate.cfg.xml to make sure the SQLServerDialect is used
update the server/default/deploy/jbpm.esb/jbpm-service.xml so it points to the mssql sql file
Not that the import.sql tries to set the primary key, which is an autoincrement column. MSSQL does not like this. Simply setting this column from this script will get you going.
5. Finishing up
To Finish up, make sure you add the mssql database driver jar to the server/default/lib directory, and make sure you added your credentials to the various mssql-ds.xml files.
Make sure this user has table create rights, so that when you start up JBossESB it can create the tables.
1. JMS
rm server/default/deploy/jms/hsqldb-jdbc2-service.xml
cp docs/examples/jms/mssql-jdbc2-service.xml server/default/deploy/jms
cp docs/examples/jca/mssql-ds.xml server/default/deploy/jms
mv server/default/deploy/jms/hsql-jdbc-state-service.xml server/default/deploy/jms/mssql-jdbc-state-service.xml
update the mssql-jdbc-state-service.xml to point to the MSSQLDS datasource
<depends optional-attribute-name="ConnectionManager">jboss.jca:service=DataSourceBinding,name=MSSQLDS</depends>
update the "Security domain for JBossMQ" in the server/default/conf/login-config.xml to java:/MSSQLDS
2. jUDDI
cp docs/examples/jca/mssql-ds.xml server/default/deploy/jbossesb.sar/juddi-ds.xml
update the juddi-ds.xml, make sure the <jndi-name>juddiDB</jndi-name>
update the server/default/deploy/jbossesb.sar/esb.juddi.xml to make sure the mssql sql is used to create the jUDDI tables
<entry key="juddi.sqlFiles">juddi-sql/mssql/create_database.sql,juddi-sql/mssql/import.sql</entry>
3. JBossESB MessageStore
rm server/default/deploy/jbossesb.esb/hsql-ds.xml
cp docs/examples/jca/mssql-ds.xml server/default/deploy/jbossesb.esb
update the mssql-ds.xml, make sure the <jndi-name>JBossESBDS</jndi-name>
update the server/default/deploy/jbossesb.esb/jbossesb-service.xml to point to the mssql sql for creating the message table
<attribute name="SqlFiles">
message-store-sql/mssql/create_database.sql
</attribute>
4. jBPM
rm server/default/deploy/jbpm.esb/hsql-ds.xml
cp docs/examples/jca/mssql-ds.xml server/default/deploy/jbpm.esb/
update the mssql-ds.xml, make sure the <jndi-name>JbpmDS</jndi-name>
update the server/default/deploy/jbpm.esb/hibernate.cfg.xml to make sure the SQLServerDialect is used
<!-- hibernate dialect -->
<property name="hibernate.dialect">org.hibernate.dialect.SQLServerDialect</property>
update the server/default/deploy/jbpm.esb/jbpm-service.xml so it points to the mssql sql file
<attribute name="SqlFiles">
jbpm-sql/jbpm.jpdl.mssql.sql,
jbpm-sql/import.sql
</attribute>
Not that the import.sql tries to set the primary key, which is an autoincrement column. MSSQL does not like this. Simply setting this column from this script will get you going.
5. Finishing up
To Finish up, make sure you add the mssql database driver jar to the server/default/lib directory, and make sure you added your credentials to the various mssql-ds.xml files.
<datasources>
<local-tx-datasource>
<jndi-name>JbpmDS</jndi-name>
<connection-url>jdbc:jtds:sqlserver://192.168.1.2:1433/jbossesb</connection-url>
<driver-class>net.sourceforge.jtds.jdbc.Driver</driver-class>
<user-name>jbossesb_admin</user-name>
<password>admin</password>
<!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
<metadata>
<type-mapping>MS SQLSERVER2000</type-mapping>
</metadata>
</local-tx-datasource>
Make sure this user has table create rights, so that when you start up JBossESB it can create the tables.
MSSQL Drop all constraints from the database
Recently I had to drop all tables from a MSSQL Server Database, and this proved to be harder than expected because of foreign key contraints in the database. I found a post on how do disable them but that turned out to be not enough to allow to drop the tables. Instead I had to drop all the constraints from the database. The few lines below generate the commands to do this.
select
'ALTER TABLE ' + so.table_name + ' DROP CONSTRAINT ' + so.constraint_name
from INFORMATION_SCHEMA.TABLE_CONSTRAINTS so
Wednesday, March 25, 2009
Smooks XML2Java Transformation
Previously I wrote about using Smooks for XML2XML transformations. Today I worked on an XML2Java transformation. It so happens that my incoming XML is completely flat, and looks like
Which lends itself really well to be stuffed into a Map, with the key being the name of the element. This is where a really handy Smooks trick comes in handy
Now when running the following code:
It prints out:
The Smooks User Guide talks about something similar when your XML uses property elements.
By the way if you like mapping out your transformation graphically you should check out the new Smooks Graphical Editor.
The Eclipse plugin can be downloaded from http://www.smooks.org/news/eclipseeditorforsmooksinjbosstools.
<my-example-data>
<id>1234</id>
<fname>First Name</fname>
<mname>Middle Name</mname>
<lname>Last Name</lname>
<jobTitle>Job Title</jobTitle>
</my-example-data>
Which lends itself really well to be stuffed into a Map, with the key being the name of the element. This is where a really handy Smooks trick comes in handy
<?xml version="1.0"?>
<smooks-resource-list xmlns="http://www.milyn.org/xsd/smooks-1.1.xsd"
xmlns:jb="http://www.milyn.org/xsd/smooks/javabean-1.1.xsd">
<jb:bindings beanId="inquiryMap" class="java.util.HashMap" createOnElement="$document">
<jb:value data="inquiry-email-data/*"/>
</jb:bindings>
</smooks-resource-list>
Now when running the following code:
Smooks smooks = new Smooks("smooks-config.xml");
JavaResult javaResult = new JavaResult();
smooks.filter(new StreamSource(new StringReader(xml)), javaResult);
Map results = (Map<String,String>) javaResult.getBean("inquiryMap");
System.out.println("result=" + results);
It prints out:
results={lname=Last Name, mname=Middle Name, fname=First Name, id=1234, jobTitle=Job Title}
The Smooks User Guide talks about something similar when your XML uses property elements.
By the way if you like mapping out your transformation graphically you should check out the new Smooks Graphical Editor.
The Eclipse plugin can be downloaded from http://www.smooks.org/news/eclipseeditorforsmooksinjbosstools.
Thursday, March 12, 2009
JBoss Deployment Dependencies of a War
When your war file depends on another service to deploy first you can add a depends element in the WEF-INF/jboss-web.xml. This will guaranty the deployment order, and the war file will not be deployed until the PluginManager Service is deployed first.
I know I looked for this before and was not able to find it. Now I won't forget.
--Kurt
jboss.admin:service=PluginManager
I know I looked for this before and was not able to find it. Now I won't forget.
--Kurt
Tuesday, February 17, 2009
Using Regexp in Drools 5
I've spend waaay too much time on this, so I need to scribble this 'note to self'. I'm working with JBossESB and I have a piece of text in the body of the message. Now if a certain word is found in this text I want to route the message a certain way. This example is based on the simple_cbr quickstart.
1. So let's first take a look how to match a word in a string. To demonstrate how to do this I created this logging rule:
This rule will print out the incoming string if both the words 'Order' and 'EST' are matched.
The (?i) means 'ignore case', .*Order*. means the word 'Order' or 'order' anywhere in the string will be matched, but this will still not work if the string is multi-line (The '.' character does not match the newline character). So to fix that we need to make it .*Order(.|\n)*. Same story for the '\r'. This is the first word match which we can combine with '&&' or '||' with other matches like I did here looking for 'EST'.
2. Finally to push the String from the default place in the ESB message into the rules engine you need to use an object path of "body.'org.jboss.soa.esb.message.defaultEntry'" as shown in the XML fragment taking from a jboss-esb.xml.
alternatively you can use a path of esb="BODY_CONTENT".
1. So let's first take a look how to match a word in a string. To demonstrate how to do this I created this logging rule:
rule "Logging"
when
b: String(this matches "(?i).*Order(.|\n|\r)*" && this matches ".*EST(.|\n|\r)*")
then
System.out.println("b=|" + b + "|");
end
This rule will print out the incoming string if both the words 'Order' and 'EST' are matched.
The (?i) means 'ignore case', .*Order*. means the word 'Order' or 'order' anywhere in the string will be matched, but this will still not work if the string is multi-line (The '.' character does not match the newline character). So to fix that we need to make it .*Order(.|\n)*. Same story for the '\r'. This is the first word match which we can combine with '&&' or '||' with other matches like I did here looking for 'EST'.
2. Finally to push the String from the default place in the ESB message into the rules engine you need to use an object path of "body.'org.jboss.soa.esb.message.defaultEntry'" as shown in the XML fragment taking from a jboss-esb.xml.
<action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter">
<property name="ruleSet" value="ShippingRules.drl"/>
<property name="ruleReload" value="true"/>
<property name="object-paths">
<object-path esb="body.'org.jboss.soa.esb.message.defaultEntry'" />
</property>
<property name="destinations">
<route-to destination-name="express" service-category="ExpressShipping" service-name="ExpressShippingService"/>
<route-to destination-name="normal" service-category="NormalShipping" service-name="NormalShippingService"/>
</property>
</action>
alternatively you can use a path of esb="BODY_CONTENT".
jUDDI-3.0.0.alpha released
For details see the jUDDI website or the TSS announcement. This release duplicates the functionality that is available in jUDDIv2.x and we'll be working on the newly added UDDI v3 APIs (such as the Subscription, Replication and Custody transfer) going forward. To get started we created a ready-to-go UDDI v3 server in one download: juddi-tomcat.zip (based on jUDDI-3.0.0.alpha, Tomcat and Derby). Please contact us if you want to help out. Now that the jUDDI-v3.x code base is functional it is relativity easy to contribute.
--Kurt
--Kurt
Friday, February 13, 2009
Java Architecture Management
Yesterday I attended a NEJUG meeting presented by Alexander von Zitzewitz called "Java Architecture Management or how to avoid the structural erosion of your code base". It was a pretty entertaining talk where he reviewed a number of scenarios that lead to the creation of unmaintainable complexity. He confirmed a lot of what I already knew, but nicely formulated and explained. He argued that no documentation is going to help you, it's prohibitively expensive to create and always outdated by the latest code. A general theme was that you need to have an architecture that slices horizontally (architectural layers) as well as vertically (functional slices). Think of vertical slices as your java package naming and how packages end up in a jar. This way you end up with a grid of subsystems. Next you can start analyzing the dependencies between the subsystems. He described a number of code metrics that can be used to quantify the number of architecture violations in the code. He came up with a list of 6 rules that one should follow to write maintainable code:
Rule 1: Define a cycle free logical architecture down to the level of subsystems and a strict and consistent package naming convention
Rule 2: Do not allow cyclic dependencies between different packages
Rule 3: Keep the relative ACD low (< 7% for 500 compilation units, NCCD < 6)
Rule 4: Limit the size of Java files (700 LOC is a reasonable value)
Rule 5: Limit the cyclomatic complexity of methods (e.g. 15)
Rule 6: Limit the size of a Java package (e.g. less than 50 types)
To break a dependency cycle you can should introduce an interface; this reverses the dependency. It is that simple. This leads to the observation that "good code" can be recognized using certain metrics (see also a white paper by Robert Martin. Good code should have a certain ration of abstractness (classes vs interfaces), and if more code depends on your code, you will likely need more interfaces. The two extremes of this "metric distance" from the optimal ratio, are:
zone of uselessness which means a high number of interfaces and few things depending on you. This happens when coders plan for complexity that never happened.
zone of pain which means very few interfaces and lots of code depends on you. So each change in your class can break lots of other things elsewhere. This usually happens when people cut corners to make a deadline.
To monitor this adherence to the rules you need a tool. Commercially he listed three; Lattix here in Massachusetts, Structure101 and SonarJ, which is his product and which was later demoed. I was actually involved in a case study with Lattix a few years ago, which was interesting but felt like moving the chair on the deck of the Titanic. The case study only took into account the Java side and our major issue was the duplication of code on the server (Java) and the client side (Javascript). Code duplication is something that is not easily picked up and certainly not when it appears in the different Languages. We were simply to deep into our own poo to fix things. I think a rewrite was the only option for that product. Anyway I still learned a lot from it. For one that it is never too early to hook up a static code analyzer to the nightly build. If you register with hello2morrow you can download a free version of SonarJ meant for projects with fewer then 500 Java classes. If you want to go Open Source then you can try: PMD, jDepend (dependencies only) and Architecture Rules (on top of jDepend).
The meeting really confirmed my own experiences, that the process of creating good code is simple. You just have to follow it *all the f***ing time* (much like Bryan Liles' TATFT framework). Bad code is like a black hole attracting other bad code. So simply don't put black holes in your code! If your system gets large, make sure you use tools to monitor that none of these simple rules are broken. Hook them up to the nightly build and have any violations be fixed the very next day. Note that you need an architecture before you can use any of these tools!
--Kurt
Rule 1: Define a cycle free logical architecture down to the level of subsystems and a strict and consistent package naming convention
Rule 2: Do not allow cyclic dependencies between different packages
Rule 3: Keep the relative ACD low (< 7% for 500 compilation units, NCCD < 6)
Rule 4: Limit the size of Java files (700 LOC is a reasonable value)
Rule 5: Limit the cyclomatic complexity of methods (e.g. 15)
Rule 6: Limit the size of a Java package (e.g. less than 50 types)
To break a dependency cycle you can should introduce an interface; this reverses the dependency. It is that simple. This leads to the observation that "good code" can be recognized using certain metrics (see also a white paper by Robert Martin. Good code should have a certain ration of abstractness (classes vs interfaces), and if more code depends on your code, you will likely need more interfaces. The two extremes of this "metric distance" from the optimal ratio, are:
zone of uselessness which means a high number of interfaces and few things depending on you. This happens when coders plan for complexity that never happened.
zone of pain which means very few interfaces and lots of code depends on you. So each change in your class can break lots of other things elsewhere. This usually happens when people cut corners to make a deadline.
To monitor this adherence to the rules you need a tool. Commercially he listed three; Lattix here in Massachusetts, Structure101 and SonarJ, which is his product and which was later demoed. I was actually involved in a case study with Lattix a few years ago, which was interesting but felt like moving the chair on the deck of the Titanic. The case study only took into account the Java side and our major issue was the duplication of code on the server (Java) and the client side (Javascript). Code duplication is something that is not easily picked up and certainly not when it appears in the different Languages. We were simply to deep into our own poo to fix things. I think a rewrite was the only option for that product. Anyway I still learned a lot from it. For one that it is never too early to hook up a static code analyzer to the nightly build. If you register with hello2morrow you can download a free version of SonarJ meant for projects with fewer then 500 Java classes. If you want to go Open Source then you can try: PMD, jDepend (dependencies only) and Architecture Rules (on top of jDepend).
The meeting really confirmed my own experiences, that the process of creating good code is simple. You just have to follow it *all the f***ing time* (much like Bryan Liles' TATFT framework). Bad code is like a black hole attracting other bad code. So simply don't put black holes in your code! If your system gets large, make sure you use tools to monitor that none of these simple rules are broken. Hook them up to the nightly build and have any violations be fixed the very next day. Note that you need an architecture before you can use any of these tools!
--Kurt
Tuesday, February 10, 2009
jUDDI 2.0rc6 released
Today the jUDDI team released the -hopefully final- release candidate for of jUDDI-2.0. One of the major new release artifacts is a jUDDI-tomcat bundle which is a jUDDI server bundled with Tomcat and an embedded Derby database. This means that users can start using their UDDI server instantly. It is expected that the jUDDI-2.0 release will follow shortly, as well as a jUDDI-3.0alpha release. The full release notes can be found here. jUDDI-3.0 implements the UDDI v3.0.2 spec, while jUDDI-2.0 implements the UDDI v2 spec.
--Kurt
--Kurt
Monday, February 9, 2009
Code Listings on Blogger
I finally found a great post about inserting code listings on Blogger. They use a javascript library called syntax-highlighter.
Let's see if it works:
Note that for Java code you would use the class="Java" and name="code" attributes on the pre element, like
I love it! Here is a cup of goodness for you Mr Alex Gorbatchev :)
Let's see if it works:
package freshespresso.listing;
public class List {
public static void main(String[] args) {
System.out.println("That's some high octane cup!");
}
}
Note that for Java code you would use the class="Java" and name="code" attributes on the pre element, like
<pre class="Java" name="code">
java code here...
</pre>
I love it! Here is a cup of goodness for you Mr Alex Gorbatchev :)
Thursday, January 29, 2009
Maven: The Definitive Guide
I'm trying to get a jUDDI release out the door, threw a fit with maven and finally picked up a copy of the book "Maven: The Defintive Guide". This book is pretty good and a free online version of it can be found at the Sonatype website.
I love the standardization of Maven, but as the number of plugin grow it is sometimes hard to figure out which plugin to use, and how the configuration works. This book is certainly a help.
--Kurt
I love the standardization of Maven, but as the number of plugin grow it is sometimes hard to figure out which plugin to use, and how the configuration works. This book is certainly a help.
--Kurt
Monday, January 19, 2009
JOSSO 1.8 Released
JOSSO 1.8 was released last week and in my opinion the 5 minute setup is a key feature. Using the deployment console getting started with JOSSO will now be that much easier.
Subscribe to:
Posts (Atom)