Showing posts with label SOA. Show all posts
Showing posts with label SOA. Show all posts

Friday, June 5, 2009

jUDDI Release-3.0.0.beta

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

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

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:

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

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

Saturday, September 27, 2008

Transformation using Smooks, part 1: XML2XML

Part 1 is sort of the Hello World on Smooks, and how it is better then using plain XSLT.

Smooks is fragment based data transformation framework. It can handle many different data formats and is the default transformation engine of three open source ESBs: (JBossESB, Synapse and Mule ESB). In this case I needed an XML2XML transformation. I'm used to using XSLT for that, but I had some date formatting to do, so I figured I would use Smooks. Currently the latest release is v1.0.1, so this is what I used. Note that some of the documentation on the Smooks website already referring the v1.1.x version (you can tell by the xsd reference, smooks-1.1.xsd), so watch out for that since that will not work using 1.0.x. However you can still use v1.0.x notation in v1.1. x

So how to go get started?

1. First you will need to download the Smooks Libraries, but if you're like me and use JBossESB, then you can skip this step. Note that Smooks is very modular, so if you don't need all the features you'll only need a subset of the jars provided by Smooks.

2. Create a transformation unittest, like the one below to test your transformation. I based this one on the one given in the Smook User Guide, the one at the very end of the document).

package com.sermo.services.foley.transform;

import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileWriter;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.StringReader;
import java.io.StringWriter;
import java.io.Writer;

import javax.xml.transform.stream.StreamResult;
import javax.xml.transform.stream.StreamSource;

import org.custommonkey.xmlunit.XMLAssert;
import org.custommonkey.xmlunit.XMLUnit;
import org.junit.BeforeClass;
import org.junit.Test;
import org.milyn.Smooks;
import org.milyn.container.ExecutionContext;
import org.milyn.event.report.HtmlReportGenerator;
import org.milyn.payload.JavaSource;
import org.xml.sax.SAXException;

/**
* Unit test for Smooks transformation.
*
* Smooks configuration file is located in src/main/resources/smooks-config.xml
* Input file for transformation is located in src/test/resouces/input.xml
* Expected file from trasformation is located in src/test/resouces/expected.xml
* Smooks execution report will be created in target/smooks-report.html
*/
public class SmooksTest {

public static Smooks smooks = null;

@BeforeClass
public static void setupSmooks() throws SAXException, IOException
{
smooks = new Smooks( "smooks-res.xml");
}
@Test
public void testTransformation()
throws FileNotFoundException, IOException, SAXException
{
InputStream in = this.getClass().getResourceAsStream("/input.xml");
System.out.println(new InputStreamReader(in).toString());
StreamSource source = new StreamSource(this.getClass().getResourceAsStream("/input.xml"));
ExecutionContext executionContext = smooks.createExecutionContext();
//create smooks report
Writer reportWriter = new FileWriter( "smooks-report.html" );
executionContext.setEventListener( new HtmlReportGenerator( reportWriter ) );
StreamResult result = new StreamResult( new StringWriter() );
smooks.filter( source, result, executionContext );
System.out.println("Smooks output:" + result.getWriter().toString());
InputStream is = this.getClass().getResourceAsStream("/expected.xml");
//compare the expected xml (src/test/resources/expected.xml) with the transformation result.
XMLUnit.setIgnoreWhitespace( true );
XMLAssert.assertXMLEqual(new InputStreamReader(is), new StringReader(result.getWriter().toString()));
}
}

In this case it transforms the XML in the input.xml file into a format that should correspond to the XML in the expected.xml file. The actual transformation happens at line 55 (smooks.filter), and the result can be accessed using a StreamResult called result. XMLAssert is used to check that the output corresponds to our expectation.

3. Smooks has one configuration file, the smooks-res.xml file, in which you define the smooks-resource-list, and any entry in this list is a resource-config entry. This file contains the definition of the transformation:

<?xml version='1.0' encoding='UTF-8'?>
<smooks-resource-list xmlns="http://www.milyn.org/xsd/smooks-1.0.xsd" >

<resource-config selector="global-parameters">
<param name="default.serialization.on">false</param>
<param name="stream.filter.type">SAX</param>
</resource-config>

<!-- Date Parser used by all the bean populators -->
<resource-config selector="decoder:UTCDateTime">
<resource>org.milyn.javabean.decoders.DateDecoder</resource>
<param name="format">yyyy-MM-dd HH:mm:ss</param>
</resource-config>

<resource-config selector="hibernate-event">
<resource>org.milyn.javabean.BeanPopulator</resource>
<param name="beanId">eventType</param>
<param name="beanClass">java.util.HashMap</param>
<param name="bindings">
<binding property="type" selector="hibernate-event/@eventType" />
</param>
</resource-config>

<resource-config selector="category">
<resource>org.milyn.javabean.BeanPopulator</resource>
<param name="beanId">category</param>
<param name="beanClass">java.util.HashMap</param>
<param name="bindings">
<binding property="name" selector="category/name" />
<binding property="type" selector="category/type" />
<binding property="id" selector="category/id" />
<binding property="createDate" selector="category/createDate" type="UTCDateTime" />
</param>
</resource-config>

<resource-config selector="category">
<resource type="ftl">
<![CDATA[<caffeine-event type="${eventType.type}">
<category>
<cat-name>${category.name}</cat-name>
<cat-type>${category.type}</cat-type>
<id type="integer">${category.id}</id>
<utc-date><#if category.createDate?exists>${category.createDate?string("yyyy-MM-dd'T'HH:mm:ss'Z'")}</#if></utc-date>
</category>
</caffeine-event>]]>
</resource>
</resource-config>

</smooks-resource-list>

Note that the first sections sets up some global parameters like which parser it should be using under the hood (SAX in this case). Next I defined a date parser called 'decoder:UTCDateTime' which can parse the date format in the input.xml, so that it can be transformed into another date format later. The next two sections set up two Java beans (using a HashMap actually), so we can add name, value pairs. The first bean selects data on the 'hibernate-event' tag, setting the type, by selecting the value of eventType attribute. The second section populates another HashMap by looking at the data in the category element. This is what Smooks means with being fragment based. You can use different types of technologies to parse your incoming message (XML in this case). Finally in the last section it builds the output message. Here I chose to use FreeMarker (ftl), which is very nice templating language.

4. input.xml

<hibernate-event eventType="create">
<category>
<name>Sumatra</name>
<type>Coffee Bean</type>
<id type="integer">5000</id>
<createDate>2009-02-09 21:00:01</createDate>
</category>
</hibernate-event>

This is the incoming XML message.

5. expected.xml

<caffeine-event type="create">
<category>
<cat-name>Sumatra</cat-name>
<cat-type>Coffee Bean</cat-type>
<id type="integer">5000</id>
<utc-date>2009-02-09T21:00:01Z</utc-date>
</category>
</caffeine-event>

This is the XML we want to transform the input.xml to. So this file is the expected output, so we can use XMLUnit to assert that we got what we were expecting.

6. Smooks Execution Report

When you are in the middle of building your smooks-res.xml, the Smooks Execution Report can come in very handy for debugging purposes. The lines

//create smooks report
Writer reportWriter = new FileWriter( "smooks-report.html" );
executionContext.setEventListener( new HtmlReportGenerator( reportWriter ) );

create an HTML based report called 'smooks-report.html', which you can simply open in your favorite browser.


Conclusion

Fragment based transformation rocks, have you ever tried to do any date manipulation or working on a highly normalized XML in XSLT? By the way you can still use XSLT instead of a BeanPopulator; mix and match. I also like having a real templating language to create my outgoing message. By picking the tool for the task you can expect high transformation performance. There was nice thread on theServerSide on that here.

Part 2, will be about how a Java2XML transformation and how you'd deploy the transformation as a service to JBossESB.

Monday, March 17, 2008

Using an EJB3 Interceptor in Seam

For one of the demos for the NEJUG presentation we integrated the JPetStore (Spring based) and the DVDStore (Seam based) with JBossESB. The idea is that when orders are placed in either store the orders are processed in some ESB based Order Processing Service, using jBPM for the Orchestration. Here I want to show what you need to do to intercept a the order when the user hits the 'confirm' button in the Seam based DVD Store. For this we use an EJB3 interceptor. The beauty of this solution is that no code changes are needed in the DVD Store itself.

1. Modify the ejb-jar.xml
First we need to add some configuration to the ejb-jar.xml, as shown in Figure 1.


Figure 1. Add the interceptor to the ejb-jar.xml


So first we define the interceptor class by referencing
com.jboss.dvd.seam.CheckoutInterceptor
, next we need to specify when this class should be called, which is done by adding the second piece of xml which specifies the bean name for which the interceptor should fire. Here we want it to fire when the
CheckoutAction
is called.

2. Add the interceptor class

The interceptor class itself looks like

package com.jboss.dvd.seam;

import javax.interceptor.AroundInvoke;
import javax.interceptor.InvocationContext;

public class CheckoutInterceptor {

@AroundInvoke
public Object sendOrderToESB(InvocationContext ctx) throws Exception {

System.out.println("*** Entering CheckoutInterceptor");
Object target = ctx.getTarget();
//Just making sure
if (target instanceof CheckoutAction) {
if (ctx.getMethod().getName().equals("submitOrder")) {
System.out
.println("We will send the following completedOrder object to ESB");
Order completedOrder = ((CheckoutAction) target).currentOrder;
Customer customer = ((CheckoutAction) target).customer;
completedOrder.setCustomer(customer);
System.out.println("Completed Order= " + completedOrder);
}
}
try {
return ctx.proceed();
} finally {
System.out.println("*** Exiting CheckoutInterceptor");
}
}
}

Figure 2. The CheckoutInterceptor Code

And that is all there is to it. In the interceptor we check which method is called, and if it is the
submitOrder
method we print out the order. In the demo we added code to serialize the order to XML, and then dropped in onto a gateway Queue, on its way to the ESB.

NEJUG on SOA - The SOA-P Store: Bed, Bath and Beyond (II)

I'm happy to say that the presentation went over well. We got some great questions and in general I think people really got it. Tom Cunningham compiled a list of the questions we got:

Is the registry different than UDDI?
Is there portability across ESB implementations (Mule / Service Mix / JBoss)?
Is there portability across different BPEL providers?
When you are talking about components for ESB, are you talking about adapters?
How gunshy should I be using JBoss ESB (are people using it in production)?
What strategies can I use for portability between ESB providers?
Is there any inherent security in the content based routing? Are there plans on adding something in this area (ACEGI/Spring Security in particular)?
What would you typically see in an actions block?
Would an example of an action be something execuing a rule?
When do you use a J2EE Servlet Filter approach and when would you use ESB?
How would you roll back a transaction?
How do you integrate with RESTful services?
How tightly couple is the rules engine with the ESB?
What monitoring tools exist to see what is going on inside the ESB?
Is there a way inside the ESB to log payload in and out of the ESB?
Is the ESB's state recoverable? Will it maintain state?
How do you track long transactions?
What's the connection between Rules and the ESB?
Will hot deploy consume all current requests before redeploying?
Is load balancing simple round robin?
Does JBPM compete with BPEL?
Is there interactive debugging so that you can step through the JPDL flow?
Are the enterprise design patterns (wiretap, splitter, aggregatore) available inside of a visual designer in JBDS?
Is the JBPM plugin going to be available for NetBeans?
Who is the jbpm-console intended for?
What's the difference between SOA and ESB?
How do you migrate to ESB?

The most humorous question had to be the last one, where someone wanted to know if content based routing could be used as a method of escaping hardware licenses.


Sorry, you had to be there for the answers, but maybe it can be a start for a JBossESB FAQ page.

Monday, March 10, 2008

NEJUG on SOA - The SOA-P Store: Bed, Bath and Beyond

This Thursday (March 13th) Burr Sutter and I will speak at the NEJUG on SOA "The SOA-P Store: Bed, Bath and Beyond".

This will be a dynamic session focused on the demonstration of the customary capabilities and best practices associated with an Enterprise Service Bus for SOA-focused deployment.

We will get people involved and empowered with real boots-on-the-ground knowledge of how to do SOA and not just pontificate on abstract theory and marketing-speak. The live demonstrations will illustrate how typical Struts+Spring+Hibernate web applications can be liberated as services and enter the world of ESB & SOA.

See you there.

JBoss SOA Platform (SOA-P) Documentation

The SOA-P team incorporates a team of technical writers who take the project specific documentation and turn it into documentation for the SOA Platform, which is the supported 'RHEL' version of JBossESB (where JBossESB would be Fedora). In the true spirit of Open Source, this documentation is available for free, under the support/documentation tab of the Red Hat homepage, or you can go directly to the SOA-P 4.2 docs. I was quite impressed with what they did to some of the docs I wrote! Thanks guys.

Service Orchestration using jBPM

I recently wrote up am entry in the JBossESB blog. This code is now available in the SOA Platform as well as on the trunk of the JBossESB project. For the full documentation in pdf format see the jBPMIntegrationGuide.


Figure 1. Service Integration using jBPM.