Soa

You are currently browsing the archive for the Soa category.

IBM acquires Webify

Today, IBM announced that they are acquiring Webify:

ARMONK, NY - 02 Aug 2006: IBM (NYSE: IBM) today announced it acquired Webify Solutions, an Austin, Texas-based, privately held provider of industry-specific software and services for building service oriented architectures (SOA).

Webify provides what they call Industry Fabrics :

The Webify Industry Fabric is an integrated environment for policy driven sourcing, assembly, delivery and governance of business services and composite business services. It consists of six complementary modules that allows companies to source, provision, deliver, and govern industry-specific business services, processes, content, and events from a variety of internal and external sources.

They have fabrics for the following industries:

  • Healthcare
  • Banking
  • Telecom
  • Insurance

You might have read about the tentative to create a new version of the Service Oriented Architecture dubbed SOA 2.0.

You might also have seen the rise of opposition to this new term on some blogs like Elemental Links or even an online petition to oppose this term.

The main rational for creating a new version of SOA seems to be :

With SOA 2.0, an event-driven architecture is deployed in which software modules are related to business components, and alerts and event notifications are featured. The initial SOA concept has not been event-driven but instead has featured direct calls from one piece of software to another in a client-server process, Natis said.

Well, that doesn’t fly. What events are we talking about here ? In which way these events are different from asynchronous service invocations ? What about messages sent on an ESB like Mule or openESB ? Are they events ?

I would point to this article for a good example on how EDA and SOA can come together, without releasing a new architecture version.

The next step after playing with the openESB platform in a previous blog entry, more as a user, and look at what it takes to develop a service engine.
I found on the web a tutorial on writing a service engine for ObjectWeb’s Petals.
They give a pre-packaged Hello World service engine.
I tried to install it on top of the openESB starter kit.
It’s quite simple :

  • in the Runtime panel, expand the Sun Java System Application Server node, then the JBI node.
  • right click on the Service Engines node, select Install “New Service Engine”
  • point to the .zip file, and you are done.

Here is the result :

esb-petal

Next step is to understand how to activate the Service Engine, and extend it.

The goal was to put together the following technology components :

  • Java EE 5
  • Netbeans 5.5
  • Open ESB starter Kit Beta

The first step is to acquire the bundle here and follow the instructions on this tutorial to create a web service.

The code for my web service is:

/*
 * passThrough.java
 *
 * Created on May 24, 2006, 8:49 AM
 *
 * To change this template, choose Tools | Template Manager
 * and open the template in the editor.
 */
 
package org.me.nullOpe;
 
import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.WebParam;
 
/**
 *
 * @author jc
 */
@WebService()
public class passThrough {
 
    /**
     * Web service operation
     */
    @WebMethod
    public String echo(@WebParam(name = "input") String input) {
        // TODO implement operation
        System.out.println("---"+input+"+++");
        return input;
    }
}

When this is done, and the service is deployed, right click on the Web Services node in your project to access the menu option “Test Web Service”. The Tester page should open. Note the link to the WSDL file on that page.
(If you are lost, see the Deploying and Testing the Web Service in the above mentioned tutorial

Now, lets create a BPEL workflow to invoke this service. More information on the JBI/Open ESB component of the tool bundle can be found on the Java Technology and Business Integration Services page

The first step is to create an SOA project:

  • File -> New Project
  • Choose Project->Samples->Service Oriented Architecture->Synchronous BPEL Process
  • Next->Give a name to your project -> Finish

At this point, you should have two new nodes created in your Projects navigation panel. One for the BPEL Module, and one for the Composite Application. In order to continue, you have to add the BPEL Module to the composite application by right clicking on your Composite Application node, select “Add JBI Module”, and navigate to your BPEL module jar file. You should now have a BPEL process that you can deploy and test.

More information can be found in the Netbeans Enterprise Pack 5.5 tutorial : A Simple Synchronous BPEL Process

Below are steps that are not found in the previous tutorials, and are the basic steps required to invoke web services from the BPEL process. This might not be the best way to do it, I tried to figure this by myself, and it seems to work in this simple case

The first set of steps is to import the WSDL document in the BPEL project :

  • right click on the Source Package node of your BPEL application
  • New -> Retrieve Schema and WSDL documents
  • Select URL resource in the Location Type
  • in the URL file, paste the WSDL link from your Tester session in the development of the web service, and finish

At this point, you should have two new nodes added under Source Packages . One for the WSDL, and one for the Schema. These documents were generated by JAX-WS when the service was deployed.

The next set of steps are adding a PartnerLinkType to the wsdl document. This is required by the BPEL specification, and will allow you to use this wsdl in the BPEL process as a partnerLink:

  • double click on the wsdl document imported during the last step. you should see a design window allowing you to edit the wsdl document
  • right click on the top level object and select “Add Extension Element” -> “BPEL
    “. You should have a new node created with this label {http://schemas.xmlsoap.org/ws/2004/03/partner-link}partnerLinkType
  • expand this node and edit the name (you need to have the property palette displayed to see on the right side the attribute to change
  • expand the contained node with the label {http://schemas.xmlsoap.org/ws/2004/03/partner-link}role
  • select the portType and enter a name for the provider role in the properties panel.

At this point, if you switch to the source view, you should have something like this added to your wsdl document :

    <plink:partnerLinkType name="nullOpe">
        <plink:role name="nullOpeProvider" portType="tns:passThrough"/>
    </plink:partnerLinkType>

The next set of steps is adding this partnerLink to the process, and invoke it :

  • double click on your bpel file in your Source Packages in order to use the BPEL designer
  • delete the original assign from the SynchronousSample flow
  • select the wsdl file you edited previously in the Projects navigation, and drag ad drop that file in the BPEL designer. Select the Partner Role to be your provider role, click ok.This will create the partnerLink in the designer
  • drag and drop the invoke icon from the palette between the start and end in your flow (in one of the appearing target).
  • right click on the just created invoke object, and select Edit. Select your newly added partnerLink, the operation should be filled, create variables for input and output by accepting the defaults. Click OK. You should now see that your invloke method is connected to the method exposed by your web service.

The next set of steps will connect the input of the BPEL process to the invoke step, and the output of the invoke step to the output of the process:

  • drag and drop an assign step from the basic activities on the target just above your invoke.
  • select the assign step, and you should see a mapper panel below the BPEL designer. (see the BPEL tutorial above for how to use it) connect the inputVar/inputType/paramA to the parameter in your web service input message
  • drag and drop an assign step from the basic activities on the target just below your invoke.
  • connect the parameter in your web service output message to the outputVar/inputType/paramA

The source view of the BPEL process should look like:

<?xml version="1.0" encoding="UTF-8"?>
<process 
    name="SynchronousSample" 
    targetNamespace="http://www.mycomp.org/SynchronousSample"
    xmlns="http://schemas.xmlsoap.org/ws/2004/03/business-process/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:bpws="http://schemas.xmlsoap.org/ws/2004/03/business-process/"
    xmlns:wsdlNS="http://www.mycomp.org/SynchronousSample"
    xmlns:xs="http://www.mycomp.org/SynchronousSampleSchemaNamespace" xmlns:ns1="http://nullOpe.me.org/">
 
  <import namespace="http://www.mycomp.org/SynchronousSample" location="SynchronousSample.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"/>
    <import namespace="http://nullOpe.me.org/" location="localhost_8080/nullOpe/passThroughService.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"/>
    <partnerLinks>
        <partnerLink name="passThroughService" partnerLinkType="ns1:nullOpe" partnerRole="nullOpeProvider"/>
        <partnerLink name="partnerLinkA" 
         partnerLinkType="wsdlNS:SynchronousSamplePartnerLinkType" 
         myRole="SynchronousSampleProvider" />
   </partnerLinks>
   <variables>
      <variable name="EchoOut1" messageType="ns1:echoResponse"/>
      <variable name="EchoIn1" messageType="ns1:echo"/>
      <variable name="inputVar" messageType="wsdlNS:requestMessage"/>
     <variable name="outputVar" messageType="wsdlNS:responseMessage"/>
   </variables>
   <receive
          name="start"
          partnerLink="partnerLinkA"
          portType="wsdlNS:MyPortType"
          operation="operationA"
          variable="inputVar"
          createInstance="yes"/>
      <assign name="Assign1">
         <copy>
         <from>$inputVar.inputType/paramA</from><to>$EchoIn1.parameters/input</to>
         </copy>
      </assign>
      <invoke name="Invoke1" partnerLink="passThroughService" operation="echo" portType="ns1:passThrough" inputVariable="EchoIn1" outputVariable="EchoOut1"/>
      <assign name="Assign2">
         <copy>
         <from>$EchoOut1.parameters/return</from><to>$outputVar.resultType/paramA</to>
         </copy>
      </assign>
      <reply name="end"  
              partnerLink="partnerLinkA"
              portType="wsdlNS:MyPortType" 
              operation="operationA"
              variable="outputVar"/>
   </sequence>
</process>
 
 
   <sequence>

the resulting workflow would look like this :

bpel

 

This is it. You should be able to deploy the updated project, and test it (remove the content of the output.xml to check the output).

Portals and SOA

I recently saw a blog entry mentioning an article relating SOA with the portal technology. It’s not clear to me that this is really related. Yes, there are services, which can expose portlets, but are we saying that the composition of portlets inside a portal is identical to the composition of services by a composite application platform like Sun’s CAPS ?

Here is the pointer to the document: A Service Oriented Architecture for Portals Using Portlets