Achieving SOA made easy with

CeltiXfire

AgendaServices and SOA

CeltiXfire Project

Architecture

Components

Deployment Models

Building a Service with CeltiXfire

Q&A

From the OASIS SOA Reference Model:“Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.”“Services are the mechanism by which needs and capabilites are brought together.”

A Service includesRequesterProviderOne or more message exchange patterns

Services and SOA

Requester Provider

UDDIRegistry

SOAP

WSDL

Services and SOA

SOA is a technology independent style of design

Decoupled, coarse-grained components

Focus on reuse, granularity, modularity, composability, componentization, and interoperablity

Compliance to standards

Services identification and categorization, provisioning and delivery, and monitoring and tracking

Has been mapped successfully to CORBA, message oriented middleware, Web Services

Benefits of Service Oriented Design

More flexibility (“business agility”)Reduced cost of operation through consolidationHigher qualityReduced risk, cost and complexity for developmentLessen the dependencies on vendorsGood service design (partitioning) will outlive middleware or implementation technology

ESB for SOAEnterprise Service Bus (ESB)

Provides infrastructure that can be leveraged/used to implement SOA.

Characterics of an ESBUses XML as the standard communication language

Supports Web Services standards

Supports messaging (synchronous, asynchronous, point-to-point, publish-subscribe)

Includes standards-based adapters for integration with legacy systems

Includes support for service orchestration & choreography

Includes intelligent, content-based routing services

Provides tranformation services

Many more …

CeltiXfire Project History

Celtix project initiated as open-source project on Objectweb in June 2005 under the sponsorship of IONA Technologies

To provide a feature-rich, open source Java ESB runtime

Celtix 1.0 released in May 2006

XFire project initiated as open-source project on codehaus 2 ½ years ago

To build a next generation SOAP framework: easy-to-use, embeddable, high performance (StAX based).

CeltiXfire project accepted as incubating Apache project in August 2006

CeltiXfire Project Goals (1)

From our Apache proposal:“Project CeltiXfire is a SOA infrastructure framework focused on implementation of JCP and web service standards while also providing extensibility for legacy integration”

Key point is the focus on standards and extensibility

CeltiXfire Project Goals (2)Merge of Celtix and XFire resulting in a fast, flexible, easy-to-use and embeddable SOA and WS framework

Provide Enterprise QoS and features (security, management, reliability, routing, …)

Offer choice of application models, incl. native JAX-WS

Wider, more active, vendor-neutral communityDiverse set of developers (Envoi Solutions, IONA, LogicBlaze, BEA and Red Hat)

Apache License

Cooperation with other open source projectsSynapse, Tuscany, ServiceMix

CeltiXfire Project StatusInitial code drop in August 2006

Including history of both projects

Currently merging Celtix and XFire codebases

Adopting a more message centric approach and combining the best of both projects

Releasing Milestones while incubatingFirst milestone: core functionality with proven stability

First release: all features from original projects and more, migration support for existing Celtix and XFire customers

In the meantime:Celtix 1.0 still available on ObjectWeb, XFire on codehaus

ArchitectureExtensibility

Extensible bus

Pluggable bindings and transports

Interceptor-based QoSTransparently engage reliability by adding RM interceptors to the call chain

Service ModelAbstraction of underlying service contracts (WSDL 1.1, WSDL 2.0, Java interfaces)

Configuration-by-exceptionAll just works out-of-the-box, configuration only required to customize

Extensibility (1)

Bus is a provider of shared resources and services to the CeltiXfire runtime

Dynamic discovery of available services

Deferred loading/activation of services (when needed)

Examples:Binding Factory Manager, WSDL 1.1 Manager, …

<extension class="org.apache.cxf.bindings.BindingFactoryManagerImpl" interface="org.apache.cxf.bindings.BindingFactoryManager"/>

<extension class="org.apache.cxf.bindings.soap.SoapBindingFactory" deferred="true">

<namespace>http://schemas.xmlsoap.org/wsdl/soap/</namespace> <namespace>http://schemas.xmlsoap.org/wsdl/soap/http</namespace>

</extension>

Extensibility (2)

Pluggability at multiple levelsFrontends, transports, bindings

Component (service requestor/provider)

JAX-WS

XML SOAPCORBA

-----------------

IIOP

WS-RM, Routing, Security,

Transactions, Transformations

---

HTTP, JMS, FTP, …

Binding

QOS

Transport

Front-end

Network

CeltiXfire Bus

JavaScript/E4X

Extensibility Example: CORBA Binding

Developed by Yoko projectIncubating in Apache

Initial contributions from IONA & Trifork

Full IDL type support

CORBA binding use-casesExpose legacy CORBA backends as Web Services

Conversely, allow CORBA clients invoke WS endpoints

Leverage ORB QoS

Standards supportJava 5pervasive usage of annotations, generics

JAX-WS 2.0sucessor to JAX-RPC 1.0 - annotation-driven, optional Java-first approach

JAXB 2.0much better coverage than JAX-RPC data binding

SOAP 1.1XFire merge will also give us SOAP 1.2 & MTOM

WSDL 1.12.0 support upcoming (based on Woden)

Components - Transports

Transport APIsSymmetric concept of channels abandoned in favor of client/server specific model of conduits and destinations

Support for decoupled responses (only used in HTTP transport, by RM implementation)

HTTPJetty based, stand-alone HTTP server

Servlet support

JMSBased on ActiveMQ

Future: FTP, Colocated, …?

Components - Bindings

Message Bindings:Realised as a set of interceptors (MustUnderstandInterceptor, ReadHeadersInterceptor, SoapInInterceptor, …) associated with phases (receive, read, protocol, …)

Currently supported: SOAP 1.1, XML

In work: SOAP 1.2, MTOM

Future: Fixed, tagged, …?

Data BindingsRealised as implementations of DataReader/DataWriter interfaces.

Currently supported: JAXB 2.0, XMLBeans, JiBX, Castor

Components - Frontends

JAX-WS 2.0JAX-WS components (Endpoint, Service, BindingProvider) built on top of/wrapping generic components

JAX-WS handlers executing in CeltiXfire interceptors

Wrapping of CeltiXfire Message into LogicalMessageContext, SOAPMessageContext

JavaScript 1, ECMAScript for XML (E4X) 2Service implementation is ‘annotated’ with JavaScript WebServiceProvider variable

Script is run in Provider type Endpoint – metadata and properties obtained from WebServiceProvider variable

Components – WS-*

WS-AddressingMulti-version support - natively 2005/08, also 2004/08 for RM

WS-RMFully-fledged implementation with message persistence

Transparently enabled with zero application impact

Keeping an eye on WS-RX group in OASIS

WS-I Basic Profile 1.1

Components – Configuration

Metadata model defines a component's configurable properties

Name, type, value space restrictions, default values

Consumers obtain values through Configuration interface

Configuration backed by ProvidersHide details of underlying source/format

Can be chained - consumers are unaware of which source provided the data (WSDL or Spring)

Built-in support for dynamic configuration updates using e.g. JMX

Components - ToolingCode generators

wsdl2java, java2wsdl, xsd2wsdl, wsdl2service, wsdl2soap, wsdl2xml

WSDL validator

Command line based tools provided OOTB

Graphical tools will be based on results from the Eclipse STP

Aims to provide tools, frameworks for SOA construction in 5 subprojects (Service Creation, SCA Assembly Model, SOA System, BPEL 2 Java, BPMN)

An opportunity for Open Source tooling for SOA/ESB related tools to be gathered in one place

Deployment Models

Support for deploying into Servlet EnginesTomcat

Support for deploying into J2EE AppserversGeronimo, JOnAS

Support for deploying into JBI containerServiceMix, OpenESB

(JBI-)internal/external consumer/provider

Support for running CeltiXfire inside Apache Tuscany

EnablesTuscany runtime to act as standalone web service

Building a Service with CeltiXfire

Starting from WSDL:Use wsdl2java to generate Service endpoint interface and Service class.

Server side: Implement servant (inherit from generated interface and/or use annotations only), create and publish endpoint.

Client side: Create service and proxy, invoke on proxy.

Server SideObject obj = new HelloWorldImpl(); Endpoint.publish(ADDRESS, obj);

@WebService(serviceName="HelloWorldService")public class HelloWorldImpl implements HelloWorld { public String sayHello(String message) { return "Hello to you too!";

}}

Server mainlineImplementation

Generated SEI

WSDL

@WebService(wsdlLocation = …, targetNamespace = …,…)public interface HelloWorld {

@ResponseWrapper(…)@RequestWrapper(…)@WebResult(…)@WebMethod(operationName = "sayHello")public String sayHello(String message) {

@WebParam(…) return "Hello to you too!";

}}

<xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" …<binding name="HelloWorldBinding“ type="tns:HelloWorld">

<soap:binding … >…

</binding>…<service name="HelloWorldService">

<port binding="tns:HelloWorldBinding" name="HelloWorldPort"> <soap:address location="http://localhost:9090/helloworld"/> </port></service>

Namepace of first element in binding determines binding id/factory

Namepace of first element in port determines transport id/factory

Client SideHelloWorldService service = new HelloWorldService();HelloWorld proxy = Service.getHelloWorldPort(); System.out.println(proxy.sayHello("JavaZone"));

• using generated service and SEI

Generated Service

@WebServiceClient(name = "HelloWorldService", targetNamespace=…)public class HelloWorldService extends Service {

private final static URL WSDL_LOCATION; private final static QName SERVICE = … private final static QName PORT = …

public HelloWorldService() { super(WSDL_LOCATION, SERVICE); }

@WebEndpoint(name = "HelloWorldPort") public HelloWorld getHelloWorldPort() { return (HelloWorld)super.getPort(PORT, HelloWorld.class); }}

URL url = Client2.class.getResource("/HelloWorld.wsdl");String ns = "http://cxf.apache.org/samples/HelloWorld";QName serviceName = new QName(ns, "HelloWorldService");QName portName = new QName(ns, "HelloWorldPort");Service service = Service.create(url, serviceName);HelloWorld proxy = service.getPort(portName, HelloWorld.class);System.out.println(proxy.sayHello("JavaZone"));

• or using generated SEI only

Getting InvolvedCeltiXFire

Mailing lists: cxf-dev@incubator.apache.org

IRC: #cxf on irc.codehaus.org

CeltixWeb: http://celtix.objectweb.org/

Mailing lists: celtix-dev, celtix @objectweb.org

IRC: #celtix on irc.freenode.net

XFireWeb: http://xfire.codehaus.org

Mailing lists: dev, announce, scm, user @xfire.codehaus.org

IRC: #xfire on irc.codehaus.org

Questions & Answers