May | 2006 | Gopalan Suresh Raj's Web Cornucopia

Implementing Service-Oriented Architectures (SOA) with the Java EE 5 SDK

Posted in JBI and SOA by gsraj on May 30, 2006

Implementing Service-Oriented Architectures (SOA) with the Java EE 5 SDK
This article presents concepts and language constructs needed to
develop a Service-Oriented Architecture composite application in Java
EE 5. It then describes an example application designed to solve a
business problem.

Service-oriented architecture (SOA) describes a category of composite
applications composed of service provider and service consumer
components. SOA segregates business logic and offers location
transparency for the service providers and consumers.

The SOA approach lets you replace or upgrade individual components
in the application without affecting other components or the process as
a whole. Moreover, you can independently specify alternative paths
through which the components in the application exchange messages.

This article presents architectural concepts and language constructs
necessary to developing a SOA composite application in Java EE 5. It
then presents an example application, deployed in the Java Business
Integration (JBI) environment. The example uses HTTP/SOAP binding
components and WS-BPEL and Java EE service engines, illustrating how
these components can be orchestrated to solve a business problem.

Read the full article here.

Linux version: Download the project artifacts from here: LoanProcessing.jar (152 kb)

Windows version: Download the project artifacts from here: loanProcessing.zip (179 kb)

Download the Java EE 5 Tools Bundle Beta from http://java.sun.com/javaee/downloads/index.jsp for FREE, and provide us feedback on the improvements you’d like to see. It combines the new Java EE 5 SDK with NetBeans IDE 5.5 Beta,
NetBeans Enterprise Pack 5.5 Early Access, and Sun Java System
Application Server Platform Edition 9. This bundle also contains
Project Open ESB Starter Kit Beta, Java EE 5 samples, Java BluePrints,
and API docs (Javadoc).

_uacct = “UA-464833-1”;urchinTracker();

leave a comment

The JBI/SOA Composite Application Unit Test Driver Framework

Posted in JBI and SOA by gsraj on May 29, 2006

The JBI unit test driver framework is a NetBeans plug-in module
that helps in creating and executing unit and driver tests for a JBI/SOA Composite Application project module. It is assumed that the JBI/SOA Composite Application project module is created and deployed
prior to testing.

Unit and Driver test framework features:

Add/Delete test cases
Each test case could test one or more operations from the WSDL
Semi-automatic generation of test inputs
Manual creation of test outputs (as this needs human supervision)
Automatic comparison of expected output with actual output
Display test results

User Interaction

Create a new test case, enter name for test case
Choose a WSDL document from the project
Choose the operation to be tested from the WSDL
Edit input.xml and output.xml
Test the project

From your JBI/SOA Composite Application project in the NetBeans IDE, right click on test and choose “Add Testcase” to create a new test case.

Enter a name for the test case

Choose a WSDL document from the project

Choose the operation to be tested

The above steps result in an input.xml and an output.xml file created in the project tree.
Manually edit the input.xml file to your satisfaction. Choose “Test project”
from the project node. The first time the test is run, outputs are
created and these ouputs will be assumed to be the expected output for
the tests. It is always possible to edit the output.xml to change
the expected output if you so desire.

All subsequent test runs will compare actual output with the expected output and report either a success or failure status.

_uacct = “UA-464833-1”;urchinTracker();

leave a comment

The WS-BPEL Debugger

Posted in BPEL by gsraj on May 29, 2006

The
WS-BPEL Debugger is a NetBeans Plug-in module that lets you debug your
WS-BPEL code.Before using it, you should have started the BPEL Service
Engine component in debug mode using the JBI Manager accessible from the NetBeans IDE Runtime tab.

The WS-BPEL Debugger supports the following features and a lot more:

Attach/detach and breakpoint stop
Breakpoint Stepping
Basic Variables (global)
Multi-threaded support
Pause
Run to Cursor
XPath Breakpoints

Read each image and then scroll down to the next image. This is a visual tutorial.

_uacct = “UA-464833-1”;urchinTracker();

leave a comment

The WS-BPEL XPath Assignment Editor (a.k.a., The BPEL Mapper)

Posted in BPEL by gsraj on May 29, 2006

The
WS-BPEL XPath Expression Editor is a NetBeans plug-in editor for building XPath expressions
which are used in various WS-BPEL elements. The WS-BPEL XPath Expression Editor
allows the user to build XPath expressions in a WYSWYG way. It works on XML
Schema (XSD) trees to generator XPath expressions.

Acronyms	Explanation
WS-BPEL	Web Service-Business Process Execution Language
XPath	XML Path Language

WS-BPEL
2.0 Language Background

The WS-BPEL
2.0 language supports XPath 1.0 for defining expressions in various WS-BPEL
constructs. WS-BPEL uses several types of expressions. The kinds of expressions
used are as follows (relevant usage contexts are listed in parentheses):

Boolean-valued expressions
(transition conditions, join conditions, while conditions, and if
conditions)
Deadline-valued expressions
(“until” expression of onAlarm and wait)
Duration-valued expressions
(“for” expression of onAlarm and wait, “repeatEvery”
expression of onAlarm)
General expressions
(assignment)

WS-BPEL
2.0 Language Supported Elements

The
following WS-BPEL 2.0 language elements are supported by the WS-BPEL XPath
Expression Editor:

Boolean Expressions

<conditon> element of <while>
<condition> element of <if> and <elseif>
<condition> element of <repeatUntil>
<joinCondition> element of <targets>
<transitionCondition> element of <source>

Deadline Expressions

<for> element of <onAlarm>
<for> element of <wait>
<for> element of <repeatEvery>

Duration Expressions

<until> element of <onAlarm>
<until> element of <wait>

General Expressions

Inside <from> element of <copy>
Inside <to> element of <copy>

XPath
1.0 Support

The
WS-BPEL XPath Expression Editor supports the XPath 1.0 specification. (See
Xpath specification for more information of how operators are evaluated)

Usage Scenarios

The following details some use-case scenarios in which the WS-BPEL
XPath Expression Editor can help:

1. Creating a variable to
variable assignment expression

The user can create variable to variable
assignments which will generate a <copy> with XPath expressions under the
selected assign activity.

e.g.,

<copy>

<from variable="sayHello_Input"/>

<to variable="sayHello_Output"/>

</copy>

2. Create a part to part assignment expression

The user can create part to part assignments which will generate a <copy> with XPath expressions under selected assign activity.

e.g.,

<copy>

<from variable="sayHello_Input" part="result"/>

<to variable="sayHello_Output" part="body"/>

</copy>

3. Create an XSD element-to-element assignment expression

The user can create an XSD element to XSD element assignment which will generate a <copy> with XPath expressions under the selected assign activity.

e.g.,

<copy>

<from>$sayHello_Input.result/long</from>

<to>$sayHello_Input.result/long</to>

</copy>

4. Create an XSD attribute-to-attribute assignment expression

The user can create an XSD attribute to XSD attribute assignment which will generate a <copy> with XPath expressions under the selected assign activity.

e.g.,

<copy>

<from>$sayHello_Input.result/shiporder/@orderid</from>

<to>$sayHello_Output.body/shiporder/@orderid</to>

</copy>

5. Create an expression using an XPath operator

The user can use any XPath 1.0 supported operator in the XPath expression editor.

e.g.,

<copy>

<from>($sayHello_Input.result/int + $sayHello_Input.result/long) </from>

<to>$sayHello_Output.body/double</to>

</copy>

6. Create an expression using any XPath core function

The user can use any XPath 1.0 supported core function in the XPath expression editor.

e.g.,

<copy>

<from>concat($sayHello_Input.result/shiporder/shipto/name, $sayHello_Input.result/shiporder/shipto/address)</from>

<to>$sayHello_Output.body/shiporder/shipto/name</to>

</copy>

7. Create an expression using literal

The user can define expressions using string literals, number literals and duration literals.

e.g.,

<copy>

<from>'Menlo Park'</from>

<to>$sayHello_Output.body/shiporder[1]/shipto/city</to>

</copy>

<copy>

<from>1234</from>

<to>$sayHello_Output.body/shiporder[1]/@orderid</to>

</copy>

<copy>

<from>'P2006Y5M10DT4H9M7S'</from>

<to>$sayHello_Output.body/dateTime</to>

</copy>

8. Create an XPath predicate

The user can define XPath predicate expressions.

e.g.,

$sayHello_Input.result/shiporder[5]

9. Use a predicate in assignment

The user can use a predicate in assignment.

e.g.,

<copy>

<from>$sayHello_Input.result/shiporder[5]</from>

<to>$sayHello_Output.body/shiporder</to>

</copy>

10. Create a Boolean expression

The user can create a Boolean expression used in various WS-BPEL elements which require Boolean conditional expressions. (for e.g., <while>)

e.g.,

<condition> $sayHello_Input.result/shiporder/shipto/country = 'US' </condition>

11. Create a Duration expression

The user can create a Duration expression used in various WS-BPEL elements which require Duration expressions. (e.g., <wait>)

e.g.,

<for>'P2006Y1M30DT3M13S'</for>

12. Create a Deadline expression

The user can create a Deadline expression used in various WS-BPEL elements which require Deadline expressions. (e.g., <wait> )

e.g.,

<until>$sayHello_Input.result/dateTime</until>

User Interface Interactions

The WS-BPEL XPath Expression Editor is launched based on the current selected WS-BPEL element in WS-BPEL editor. If there is currently a selected WS-BPEL element which requires the WS-BPEL XPath Expression Editor, then the editor is shown in the NetBeans IDE in the bottom pane.

_uacct = “UA-464833-1”;urchinTracker();

leave a comment

The WS-BPEL JBI Service Engine

Posted in JBI and SOA by gsraj on May 28, 2006

The WS-BPEL Serivce Engine (BPELSE) is a JBI
engine component that provides services for executing business
processes

Figure 1: WS-BPEL Service Engine Architecture

It
is a standard JBI 1.0 service engine component. The BPEL Serice Engine
supports business processes that conform to Web Services Business
Process Execution Language (WS-BPEL) 2.0 specification. It provisions
and consumes web services described in WSDL1.1. It exchanges messages
in JBI-defined XML document format for wrapped WSDL 1.1 message parts.
The BPEL Service Engine can be configured in one of the following three
modes: static, deployment, or runtime:

Static: Parameter values,
once loaded, can only be modified by re-installing the engine.
Deployment: Parameter
values can be changed without re-installation, but only until the
engine is started/restarted; they remain in effect throughout
business process execution.
Runtime: Parameter values
can be changed even while business processes are running.

The
BPEL Service Engine supports request/reply, asynchronous one-way
invokes, and direct invocation between two business processes. It
supports monitoring of endpoint status. In addition, it also offers a
command line facility to build the service assembly and test the
deployed service.

WS-BPEL Engine Runtime Configuration
To support component configuration at installation and run-time our
components follow the following conventions not covered by the JBI
spec:

Component configuration defaults are present in the JBI descriptor of the component
These
defaults can be overridden via JBI installation configuration
parameters at installation time. This is how our web GUI allows these
to be changed
At run-time, a custom JMX MBean exposes the configuration and allows relevant settings to be changed on-the-fly

Figure 2: WS-BPEL Service Engine Configuration

Instrumentation and Management
JBI 1.0 does not directly define many
component-specific run-time monitoring and management capabilities
(with some exceptions, e.g. lifecycle extensions. It does however
provide access to the java management extensions (JMX)
infrastructure; our components therefore use the following
additional conventions to support enhanced management:

For monitoring purposes, the component
directly creates and manipulates a monitoring object and registers
it as an MBean.
Standard interfaces allow the GUI to
understand the capabilities provided by the monitoring MBean.
For management purposes, a MBean is
registered that exposes the configuration properties as MBean
attributes and advanced management functionality as MBean methods.

Why do I need to know this?
The good news is that you don’t need to know any of this to use Java
Business Integration(JBI). Perhaps the even better news is that JBI is
tightly, seamlessly, and transparently integrated with the GlassFish Application
Server. However, we thought some people might be interested in learning how
this actually works behind the scenes.

SOA developers who are the users of the Java EE Tools Bundle therefore
only need to use domain concepts and technologies related to the
business problem they are addressing because JBI and the GlassFish
Application Server provide that Invisible Plumbing
that makes it easy for the SOA developer. This allows the composite
application developer to concentrate exclusively in domains he is
expert in, and leaves the business of weaving the services he writes
into the overall SOA fabric to the Java EE tools bundle.

_uacct = “UA-464833-1”;urchinTracker();

4 comments

The HTTP/SOAP JBI Binding Component

Posted in JBI and SOA by gsraj on May 28, 2006

The HTTP/SOAP binding component (BC) provides external
connectivity for SOAP over HTTP in a JBI 1.0 compliant environment. It
supports the WSDL 1.1 and SOAP 1.1 specs (the RI example uses WSDL 2.0,
SOAP 1.2). Message exchanges to and from this BC make use of the JBI
WSDL 1.1 wrapper for the normalized message. It implements the SOAP
binding from the WSDL 1.1 spec (not HTTP Get/Post or Mime bindings). It
follows WS-I 1.0 conventions and adds additional support for
non-conforming components. It supports Document and RPC style web
services. The HTTP/SOAP binding component supports literal use and
currently only some very limited “Section 5” SOAP encoding such as
simple arrays. It supports the common convention of WSDL retrieval via
<service uri>?wsdl. It uses XML Catalogs following the OASIS
Committee Specification – these allow the component to resolve schemas
locally without resorting to network access. It Packages an embedded
HTTP server (Grizzly). It uses asynchronous I/O (NIO) to service 1000s
of concurrent incoming requests. Outbound requests are currently
handled through SAAJ 1.2. To service requests directed at a port
serviced by an application server instance, a Servlet can be deployed
to handle these requests in the HTTP/SOAP BC. It supports JBI service
unit deployments to define the web services to provision or consume. It
makes use of the WSDL extensibility (standard SOAP extensions) to
define external communication details for the web services to provision
or consume.

Figure 1: HTTP/SOAP Binding Component Architecture

Component Configuration
To
support component configuration at installation and run-time our
components follow the following conventions not covered by the JBI
spec:

Component configuration defaults are present in the JBI descriptor of the component
These
defaults can be overridden via JBI installation configuration
parameters at installation time. This is how our web GUI allows these
to be changed
At run-time, a custom JMX MBean exposes the configuration and allows relevant settings to be changed on-the-fly

For monitoring purposes, the component
directly creates and manipulates a monitoring object and registers
it as an MBean.
Standard interfaces allow the GUI to
understand the capabilities provided by the monitoring MBean.
For management purposes, a MBean is
registered that exposes the configuration properties as MBean
attributes and advanced management functionality as MBean methods.

Figure 2: HTTP/SOAP Binding Component Configuration

Frequently Asked Questions

Is this equipped to support faults defined on operation both
directions (our application calling external web service and external client
calling our web service? What is the support for fault not defined
(server/client) on WSDL operation?
Yes, it will handle faults for webservices for both inbound and outbound invocatoins.
- For faults defined in the WSDL, the fault is converted to/from the
  standard normalized message format using the WSDL 1.1 wrapper defined
  in the JBI spec.
- If the fault is not defined in the WSDL, the fault is sent
  internally as a normalized message without the WSDL 1.1 wrapper – because
  we wouldn’t have a valid value for the mandatory type setting on the
  wrapper..
How does the BC handle services on different ports?
For
services defined on ports that are not served by the application
server, it contains an embedded server that will listen on those ports.
For services defined on an application server port, a servlet needs to
be deployed to handle the “services” context
When there are multiple operations defined in a
porttype/’interface’ bound to the same soap address URI, how does it
know which one to invoke?
It uses either the soapAction or the
message signature to distinguish requests, depending on which one is
unique within the WSDL definition (and present in the request). If
neither is unique or present in the request, a fault will be returned
indicating the ambiguity.

SOA developers who are the users of the Java EE Tools Bundle therefore
only need to use domain concepts and technologies related to the
business problem they are addressing because JBI and the GlassFish
Application Server provide that Invisible Plumbing
that makes it easy for the SOA developer. This allows the composite
application developer to concentrate exclusively in domains he is
expert in, and leaves the business of weaving the services he writes
into the overall SOA fabric to the Java EE tools bundle.

Download the Java EE 5 Tools Bundle Beta from http://java.sun.com/javaee/downloads/index.jsp for FREE, and provide us feedback on the improvements you’d like to see. It combines the new Java EE 5 SDK with NetBeans IDE 5.5 Beta,
NetBeans Enterprise Pack 5.5 Early Access, and Sun Java System
Application Server Platform Edition 9. This bundle also contains
Project Open ESB Starter Kit Beta, Java EE 5 samples, Java BluePrints,
and API docs (Javadoc).

_uacct = “UA-464833-1”;urchinTracker();

leave a comment

The JBI Composite Application Project System

Posted in JBI and SOA by gsraj on May 26, 2006

The
JBI Composite Application (CA) project system, sometimes called the
“JBI project system,” allows users to create instances of SOA composite
application projects within the NetBeans IDE.

Acronyms	Explanation
CA	Composite Application
BPEL	Business Process Execution Language
JBI	Java Business Integration
SU	Service Unit. A Service Unit is a jar file which can be deployed into a JBI service engine or binding component.
SA	Service Assembly. A service assembly is jar file which is a collection of service unit jars. A service assembly jar packages different service unit jars which then can be deployed to various JBI components (service engines or binding components).

Each composite application
project instance is a container holding the deployment configuration
for a collection of JBI component subprojects, e.g., BPEL Module
projects, XSLT projects, etc. It also maintains deployment specific
data objects, such as WSDL, XSD, and JBI deployment descriptor files.
The JBI Composite
Application (CA) project system allows the user to create a Service
Assembly (SA) artifact that contains all the subprojects as Service
Units (SUs). The SA can then be deployed to the JBI component
containers on the JBI Meta-container.

It
provides a project folder with subfolders on the local file system for
storing project specific design and configuration data. Key project
actions are implemented as ant scripts providing support for standard
actions such as: Configure, Clean, Build, and Deploy. Most of the ant
action scripts can be invoked outside of Netbeans IDE when supplied
with proper property files.

The main objective of the project
system is to provide a deployment container for various types of JBI
component projects. It provides support for users to selectively
include JBI component projects and deployment data. This allows one to
reuse JBI component projects for different deployment scenarios.

An architectural overview of the JBI Composite Application Project system is shown in Figure 1 below.

Figure 1: JBI Composite Application Project system

To
provide accurate target deployment information, the project system
accesses active JBI servers to retrieve information on deployed JBI
components, e.g., id and state. This information will allow users to
update the deployment configuration to match that of the target JBI
server. This feature utilizes services provided by the JBI Manager discussed in an earlier blog entry.

The
project system provides support allowing user to customize the
deployment configuration for different usage scenarios. This service is
provided by tools, that allows one to add/modify
deployment specific data within a composite application project, so
that JBI component projects can be designed to be more generic and be
reusable in multiple deployment scenarios.

The
project system performs validation of SU deployment descriptor
generated by JBI component projects. If needed, new deployment
descriptors are generated with modifications or additions based on the
deployment configuration specified by the composite application project.

The
project system generates the SA deployment package according to the JBI
spec that packages SU deployment jars from JBI component projects with
updated deployment configuration as specified by the composite
application project.

The SA deployment package can be deployed to the target JBI Meta-container on the server for execution.

Create A New Composite Application Project
The
user can create a new JBI composite application project. This works in
conjunction with standard netbeans new project action which can be
launched from File->New Project.

Figure 1: Create a New Composite Application Project

Add Component Subprojects
Users
can add component subprojects into the composite application. On the
project explorer, the user can right click on the newly created project
to bring up the context action menu as shown below:

Figure 2:

The
“Add JBI Module” opens the Select Project dialog. The user can select
component subprojects to add into the composite application.

The JBI Composite Application Project System allows the user to add and remove component subprojects.

Figure 3: Add/Remove component subprojects

Once
a project has been created and configured, the user can build the
project to create JBI service assembly deployment artifacts. Select the
“Build Project” item on the context menu to start the build action.

A successful build will create the SA deployment zip file for the project. After
the build is successful, the user should be able to deploy the service
assembly to the target JBI meta-container on the application server and start the services.
Select the “Deploy Project” item on the context menu to start the
deployment action. A successful deployment will start the service assembly on the target server.

[Listen to this article]

_uacct = “UA-464833-1”;urchinTracker();

1 comment

The BPEL Module JBI Project System

Posted in JBI and SOA by gsraj on May 26, 2006

The
BPEL Module project system is a NetBeans plug-in module that allows
users to create instances of BPEL projects within the NetBeans
IDE. Each BPEL
project instance maintains data objects, such as BPEL, WSDL, and XSD
files, representing the business logic specific to the project.

Acronyms	Explanation
BPEL	Business Process Execution Language
JBI	Java Business Integration
SU	Service Unit. A Service Unit is a jar file which can be deployed onto a JBI service engine or binding component.
SA	Service Assembly. A service assembly is jar file which is a collection of service unit jars. A service assembly jar packages different service unit jars which then can be deployed to various JBI components (service engines or bindings components).

The BPEL Module project
system allows the user to package the business data objects that can be
packaged into a JBI Service Unit (SU). One or more SUs are packaged
into a Service Assembly (SA) that can be deployed to a BPEL service
engine on an active JBI server.

It
provides the user a project folder with subfolders, on a local
filesystem, for storing project specific design and configuration data.
The BPEL Module project system provides ant scripts to implement standard actions such as Clean and Build. It generates JBI-compliant SU packages. For each BPEL Module project, the project system generates an SU deployment package according to the JBI specification. The BPEL Module project system implements the component project provider interface of the JBI Composite Application project system. This enables the SU generated from BPEL projects to be included in the SA deployment package generated by the
JBI Composite Application project.

Create A New BPEL Module Project
It
allows the user to create a new bpel module project. This works in
conjunction with standard netbeans new project action which can be
launched from File->New Project as shown in the figure below.

Figure 1: Create a New BPEL Module Project

Once a project has been created a user can build the project to create a JBI deployment service unit jar file. The BPEL Module project
supports build time compilation/validation of bpel/wsdl/xsd files used
in the project. This ensures any errors in the bpel/wsdl/xsd files are
caught at design time.

Figure 2: Performing Standard actions at project node menu

The user can perform the following standard actions at the project node context menu:

Build Project
Clean & Build Project
Clean Project
Set Main Project
Close Project
Find…
Properties

_uacct = “UA-464833-1”;urchinTracker();

1 comment

The JBI Manager

Posted in JBI and SOA by gsraj on May 26, 2006

The JBI
Manager is a NetBeans plug-in module that extends the NetBeans IDE to
manage and monitor JBI components and assemblies, such as Service
Engines, Binding Components, Shared Libraries, Service Assemblies, and
Service Units.

Figure 1: The JBI Manager NetBeans Plug-in in action

How it Works

The JBI Manager talks to the Sun Java Application Server and figures out if there is a Lifecycle Module by the name JBIFramework enabled.

If there is a Lifecycle module named JBIFramework available on the Application Server, it will add the JBI node to the Sun Java System Application Server node.

If there are JBI Components or Service Assemblies already deployed
on the JBI Meta-Container, the JBI tree will also display all the JBI
components that are currently installed and all the Service Assemblies
that are currently deployed on the JBI Meta-Container.

New JBI Component Installation
When a user wants to install a new JBI Component, he can right-click the mouse on the component node, and select the Install New JBI Component. This action will pop-up a file selection dialog that will enable the
user to select the artifact from the file system and install it onto
the JBI Meta-Container on the server.

Figure 2: Install new JBI Component

New Service Assembly Deployment
When a user wants to deploy a new Service Assembly, he can right-click the mouse on the Service Assembly node, and select the Deploy New Service Assembly.
This action will pop-up a file selection dialog that will enable the
user to select the artifact from the file system and deploy it onto the
JBI component container on the Appliaction server.

Figure 3: Deploy new Service Assembly

Manage installed JBI Components
The user can control the life-cycle of a JBI component to either
Start/Stop, Shutdown or Uninstall a Service Engine/Binding
Component/Shared Library.

Manage deployed Service Assemblies
The user can control the life-cycle of a Service Assembly to either Start/Stop, Shutdown or Undeploy a Service Assembly.

Runtime Configuration of JBI Components
If a Service Engine or Binding Component or Shared Library exposes a Runtime Configuration JMX MBean, the JBI Manager allows the relevant settings of the component to be changed on-the-fly during runtime.

Change the Default Log Level for the JBI/SOA Meta-Container

It is also possible to change the default Log Level of the JBI/SOA Meta-Container by selecting the JBI node as shown in the figure. Please note that you may have to restart the Application Server for this change to take effect since you are changing the setting of the Lifecycle-Module instance on the Sun Java System Application Server.

Figure 4: Changing the default Log Level

Download the Java EE 5 Tools Bundle Beta from http://java.sun.com/javaee/downloads/index.jsp for FREE, and provide us feedback on the improvements you’d like to see. It combines the new Java EE 5 SDK with NetBeans IDE 5.5 Beta,
NetBeans Enterprise Pack 5.5 Early Access, and Sun Java System
Application Server Platform Edition 9. This bundle also contains
Project Open ESB Starter Kit Beta, Java EE 5 samples, Java BluePrints,
and API docs (Javadoc).

_uacct = “UA-464833-1”;urchinTracker();

leave a comment

TS-3175: Building a Service With BPEL and the Java™ EE Platform: How Composite Applications and JBI Simplify SOA Development

Posted in JavaOne by gsraj on May 13, 2006

I have a technical session for JavaOne 2006 where we will demonstrate
how to build a SOA Composite Application using JBI, the Java EE
Platform, and WS-BPEL.

Please pre-register if you are coming, since the seats are going really fast.

Venue:
JavaOne 2006
Moscone Center
Room: Hall E 134
Capacity: accomodates 1020 people
Date & Time: Thursday, May 18, ’06, 1:30pm to 2:30pm

Details:

Session ID	TS-3175
Session Title	Building a Service With BPEL and the Java™ EE Platform: How Composite Applications and JBI Simplify SOA Development
Session Abstract:	Companies are using SOA to offer services that simplify and accelerate doing business with them. These services are typically implemented as a collaboration of new functionality with the functions of existing enterprise apps. The combination of BPEL to deal with asynchronous collaboration and Java™ Platform, Enterprise Edition (Java EE) components to implement the new business logic implements these services effectively. This session describes how Java EE platform developers can create composite applications of this form by using existing Java EE platform tools and app servers that support Java Business Integration (JBI).
Session Topic:	Core Enterprise ,JAVA EE
Session Type:	Leading Edge
Speaker/s & Speaker/s Company:	Gopalan Suresh Raj, Sun Microsystems Inc; Ron Ten-Hove, Sun Microsystems Inc; Peter Walker, Sun Microsystems Inc

Read the details in this blog entry titled JBI/SOA Blueprints: Insurance Claim Scenario

_uacct = “UA-464833-1”;urchinTracker();

leave a comment

Gopalan Suresh Raj's Web Cornucopia

Implementing Service-Oriented Architectures (SOA) with the Java EE 5 SDK

The JBI/SOA Composite Application Unit Test Driver Framework

Unit and Driver test framework features:

User Interaction

The WS-BPEL Debugger

The WS-BPEL XPath Assignment Editor (a.k.a., The BPEL Mapper)

The WS-BPEL JBI Service Engine

The HTTP/SOAP JBI Binding Component

Frequently Asked Questions

The JBI Composite Application Project System

The BPEL Module JBI Project System

The JBI Manager

How it Works

TS-3175: Building a Service With BPEL and the Java™ EE Platform: How Composite Applications and JBI Simplify SOA Development

The Author

The Pages

The Search

The Associates

The Archives

The Categories

The Meta