Giovani Salvador: Java, SOA and XML

Java, SOA and XML

Posted by giovanisalvador on July 27, 2008 at 3:32 PM PDT

I have been involved in SOA (Service Oriented Architecture) projects and also studying a lot all the aspects of the SOA world. It is interesting that I thought that I knew SOA before working effectively with SOA. More specifically, I thought my knowledge on XML parsing (of course, using a JAXP implementation) would be sufficient to say that I really know XML.

For example, when we think of an XML document we usually think of something like this:

<customer>        <address>                <zipcode>123</zipcode>                …        </address>        <address>                <zipcode>321</zipcode>                …        </address></customer>

and not this:

<?xml version="1.0" encoding="UTF-8"?><definitions xmlns=""         xmlns:wsdl=""        xmlns:soap=""        xmlns:tns=""        xmlns:xsd="" name="SyncBusiness"        targetNamespace="">        <types>                <xsd:schema targetNamespace=""                         xmlns:xs=""                        xmlns:order="">                        <xs:import namespace="" schemaLocation="./order.xsd" />                        <xsd:element name="submitOrderResponse" type="order:Order" />                        <xsd:element name="submitOrder" type="order:Order" />                </xsd:schema>        </types>        <message name="submitOrderResponse">        ...        </message>        <portType name="SyncBusiness">        ...        </portType>        <binding name="SyncBusinessSOAP" type="tns:SyncBusiness">                <soap:binding style="document"                        transport="" />                <operation name="submitOrder">                ...                </operation>        </binding>        <service name="SyncBusiness">                <port binding="tns:SyncBusinessSOAP"                        name="SyncBusinessSOAP">                        ....                </port>        </service></definitions>

But when you get involved with SOA using an ESB (Enterprise Service Bus) implementation you start to deal with a world you typically have not any involvement.



Tagged with: , , , , , , ,
Posted in Java Platform

IBM: Model and build ESB SOA frameworks

Summary:  Application integration is the biggest challenge today for many enterprises. Building an Enterprise Service Bus (ESB) is probably the quickest and most cost-effective way to address this challenge. In this article, you gain insight on ESBs, and how to model and construct ESB service-oriented architecture frameworks.

Capabilities of the Enterprise Service Bus

An Enterprise Service Bus exhibits these minimum, or mandatory, capabilities:

  • Communication
    Supports routing and addressing for at least one messaging style (such as request/response, or publish/subscribe), and at least one transport protocol that is or can be made widely available. This enables location transparency and service substitution, which enables the decoupling of the consumer view of services from their implementation.
  • Integration
    Supports several integration styles or adapters. It enables the provision of services based on these integration capabilities, and decouples technical aspects of service interactions and the integration of services in the enterprise.
  • Service interaction
    Supports an interface definition format and associated messaging model (such as WSDL and SOAP) to allow the decoupling of technical aspects of service interactions.
  • Management and autonomic
    Provides a consistent administration model across a potentially distributed infrastructure, including control over naming, routing, addressing, and transformation capabilities. This enables the management of services in the enterprise.


More advanced ESBs typically offer a number of additional value-added features, including:

  • Adapters, to enable connectivity to packaged and custom enterprise applications, as well as to leading technologies.
  • Service orchestration engines, to support both long-running (stateful) and short-running (stateless) processes.
  • Quality of service and service-level capabilities.
  • Presentation services, to enable the creation of personalized portals that aggregate services from multiple sources.

Typical architecture of an Enterprise Service Bus

The architecture of an ESB is centered on a bus. The bus provides message delivery services based on standards such as SOAP, HTTP, and Java™ Messaging Service (JMS). It is typically designed for high-throughput, guaranteed message delivery to a variety of service producers and consumers. The ESB enables the use of multiple protocols (such as synchronous and asynchronous) and performs transformation and routing of service requests. The ESB enables services to interact with each other based on the quality of service requirements of the individual transactions. It also supports different standards such as SOAP, XML, WSDL, JMS, J2EE, JAX-RPC, and so on.

Figure 2 illustrates component types that can connect to an ESB:

  • Custom applications, based on standards like J2EE and Struts, which plug into the ESB to provide a user interface to enterprise services.
  • Service orchestration engine, which hosts long running business processes, based on standards like Business Process Execution Language (BPEL).
  • Adapters, typically built to the Java Connector Architecture (JCA) specification, enable integration with a wide variety of enterprise applications.
  • Presentation and portals enable the creation of personalized portals that aggregate services from multiple sources.
  • Data services which provides real time view of data from heterogeneous data sources.
  • Web services provides a standard means of connectivity to legacy and proprietary integration technologies.

Figure 2. ESB architecture
ESB architecture


Tagged with: , , , , , , ,
Posted in ESB, General SOA

Oracle: Enterprise Service Bus

Defining the ESB

An accepted definition for this term has yet to be firmly established that is most likely caused by a lack of industry standards, whereas standards like BPEL and BPMN 2.0 exist for process engines and other components. The term “Enterprise Service Bus” was coined by Gartner in 2002, and further introduced by the analyst Roy Schulte to describe a category of software products that he observed were available on the market at that time. Ten years later, there is still very little agreement on what exactly an ESB is or what it should deliver. There are different definitions depending on the manufacturer or source. Among other things, an ESB is defined as:

“A style of integration architecture that allows communication via a common communication bus that consists of a variety of point-to-point connections between providers and users of services.”

“An infrastructure that a company uses for integrating services in the application landscape.”

“An architecture pattern that enables interoperability between heterogeneous environments, using service orientation.” (Figure 1)

Figure 1: The ESB architecture pattern is divided into these main system architectures

The ESBs that are available in today’s market essentially differ in terms of the architecture of their systems. As shown in the preceding figure, they are mostly based on the following architectures:

Extended Message-Oriented Middleware (MOM)

These systems correspond to the original definition of ESB and typically distribute multiple nodes across the network, using a MOM infrastructure to support reliable messaging and event-driven processing among the nodes. Although the ESB nodes communicate using a proprietary protocol, service endpoints don’t need to be aware of the MOM. Services can be exposed using a WSDL or other protocols.

Extended Integration Brokers

Over the last five years, traditional integration broker vendors have been adding support for Web services and repositioning their products as ESBs. These systems are more standards-compliant than they once were but still tend to be more proprietary than most ESBs. They also tend to provide a very centralized solution in which all messages pass through a centralized broker.

Extended Application Servers

A number of ESB vendors use a Java EE application server as the basis for their ESB products. These products are typically stronger in terms of service creation and composition than they are in legacy integration. They tend to be rather centralized, although they do support distributed nodes.

Endpoint-Based Plug-In Channels

A few ESB vendors support an extremely distributed model that implements service mediation at the service endpoint, and supports heterogeneous communications using a channel plug-in architecture

Mediation Agents

Although these products don’t technically qualify as ESBs because a service platform is provided, more than one vendor has been known to label this type of product as such. Mediation agents can be centralized or distributed and support service mediation. There are also related product categories that implement parts of ESBs but are not officially marketed as ESBs by manufacturers [REF-1]:

XML Gateway

XML gateways are hardware appliances that primarily support service mediation, which is one of the key features of ESBs. In fact, XML gateways often support service mediation capabilities that ESBs do not or cannot support, such as transformation acceleration and the decryption and encryption of XML documents. However, XML gateways do not provide a service platform, a feature that is typically associated with ESBs.

Tagged with: , , , , , , ,
Posted in Java Platform

Working With Open Source Enterprise Service Bus in Java

Open Source Enterprise Service Bus in Java




Apache ServiceMix is an open source distributed Enterprise Service Bus (ESB) and SOA toolkit built from the ground up on the semantics and APIs of the Java Business Integration (JBI) specification JSR 208 and released under the Apache license. ServiceMix is lightweight and easily embeddable, has integrated Spring support and can be run at the edge of the network (inside a client or server), as a standalone ESB provider or as a service within another ESB. You can use ServiceMix in Java SE or a Java EE application server. ServiceMix uses ActiveMQ to provide remoting, clustering, reliability and distributed failover.  

Go To ServiceMix


Mule is a light-weight messaging framework. It is a highly distributable object broker that can seamlessly handle interactions with other applications using disparate technologies, transports and protocols. The Mule framework provides a highly scalable environment in which you can deploy your business components. Mule manages all the interactions between components transparently whether they exist in the same VM or over the internet and regardless of the underlying transport used. Mule was designed around the Enterprise Service Bus architecture, which stipulates that different components or applications communicate through a common messaging bus, usually implemented using Jms or some other messaging server. Mule goes a lot further by abstracting Jms and any other transport technology away from the business objects used to receive messages from the bus.

Tagged with: , , , , , , ,
Posted in Uncategorized

Windows Azure: REST service using ASP.NET Web API and SQL Database

This tutorial assumes that you have no prior experience using Windows Azure. On completing this tutorial, you’ll have a data-driven web application up and running in the cloud and using a cloud database.

You’ll learn:

  • How to enable your machine for Windows Azure development by installing the Windows Azure SDK.
  • How to create a Visual Studio ASP.NET MVC 4 project and publish it to a Windows Azure Web Site.
  • How to use the ASP.NET Web API to enable Restful API calls.
  • How to use a SQL database to store data in Windows Azure.
  • How to publish application updates to Windows Azure.

Tagged with: , , , , , , ,
Posted in .Net Platform

SOA World Magazein: ESB Integration Patterns

Configuration, Not Coding
The mantra of the ESB is “configuration rather than coding.” In an ESB, abstract endpoints, which are accessible through application adapters, message queues, Web services invocations, and a variety of other protocols, are configured through a tool interface rather than coded into applications. It’s not that there’s anything wrong with writing code, but there’s plenty of code to be written elsewhere that doesn’t have to do with hard-wiring interdependencies between applications and services.

With its distributed deployment infrastructure, an ESB can efficiently provide central configuration, deployment, and management of services that are distributed across the extended enterprise. Artifacts that affect the behavior of an integration service, such as an XSLT stylesheet that can be used by a data transformation service, are also configurable in an ESB.

The ESB Service Container
The highly distributed nature, and the ESB mantra of “configuration rather than coding” is largely due to traits of the ESB service container. A service container is the physical manifestation of the abstract endpoint, and provides the implementation of the service interface. A service container is a remote process that can host software components.

A service container is simple and lightweight, but it can have many discrete functions. As shown in Figure 2, service containers take on different roles as they are deployed across an ESB.

In its simplest form, a service container is an operating system process that can be managed by the ESB’s invocation and management framework. A service container provides a number of facilities for the service implementation such as event dispatch, thread management, security (encryption, authentication, and access control), and QoS via reliable message delivery. Unlike its distant cousins, the J2EE application server container and the EAI broker, the ESB service container allows the selective deployment of integration functionality exactly when and where you need it, and nothing more than what you need.

A service container can host a single service, or can combine multiple services in a single container environment (see Figure 3).

An ESB service is also scalable in a fashion that is independent of all other ESB services. A service container may manage multiple instances of a service within a container. Several containers may also be distributed across multiple machines for the purposes of scaling up to handle increased message volume (see Figure 4).

The ESB Service Interface
The ESB container provides the message flow in and out of a service. It also handles a number of facilities, such as service life cycle and itinerary management. As shown in Figure 5, the container manages an entry endpoint and an exit endpoint, which are used by the container to dispatch a message to and from the service.

Messages are received by the service from a configurable entry endpoint. Upon completion of its task, the service implementation simply places its output message in the exit endpoint to be carried to its next destination. The next destination may be a reply to the original sender of the message, or more often may be sent along to the next leg of its journey using a forwarding address. The output message may be the same message that it received. The service may modify the message before sending it to the exit endpoint. Or, in the service may create a completely new message to serve as a “response” to the incoming message and send the new message in the exit endpoint.

Posted in Uncategorized
Curve Monsters

Don't fear the curve, embrace it!

Soltis Consulting, Inc.

Business Concepts, Ideas, and Information

Ebonair Lifestyles

Accommodating the debonair lifestyles of ebony professionals everywhere

Affluent Blacks of Dallas

An online society for established and upwardly mobile black professionals, and those who aspire to be


Technology news, trends and analysis covering mobile, big data, cloud, science, energy and media

Thought Catalog

Thought Catalog is a digital youth culture magazine dedicated to your stories and ideas.

Trade News in Brief

International Economic Affairs & Relations / Regional & International Organizations / Global Commerce & Business

Software Bodyguard Blog for IT Security Protection

Info to Help You Protect Your Digital Assets and Identity

SOA Developers Blog

Helpful tidbits for service-oriented software developers

Samsona Corporation

If you can dream it, we can software it