Tuesday, June 28, 2005

JavaOne: Enterprise Service Bus and Java Business Integration: Infrastructure for Enterprise SOA

Notes from JavaOne 2005...

Dave Chappell, Sonic Software.

Nobody gets SOA right the first time, so you have to take a flexible approach that can be refined as you go.

SOA infrastructure requirements: Extracting business value: enterprises need business agility to meet ever-changing requirements, implement new programs to attract & retain customers. Streamline, refine, and measure business processes. IT infrastructure flexibility, freedom of choice, adaptable to change.

Processes are fragmented - apps deployted in different departments and business units become silos of knowledge and data.

Enterprise SOA vision is an idealized world where disparate systems come together to provide services. Gartner predicts SOA to be a prevailing software engineering practice by 2008. SOA foundation is all about the cloud in the middle. Connect / mediate /control is important.

Scope drives architectural considerations. Heterogeneity - Span new service-enabled apps as well as existing apps. Scalability - provide the performance expected while accomodating changes in demands. Availability - isolate applications from faults arising from server and communication failures. Also distribution, flexibility, visibility, and control

ESB overview: ESB combines reliable communications (message-oriented middleware, reliable web services), service hosting, services, and service mediation in order to construct the SOA infrastructure. Maps and binds services, processes, and IT assets. ESB makes it easy to connect, mediate, and control services and their interactions.

Global reach - global deployment and process, local autonomy. (Graphic: multiple service buses joined together across the globe.)

ESB interfaces are not just web services. SOA principles can apply independently of WS. Examples: Web services, Application, database, and protocol adapters, http, JCA, J2EE Appservers, .NET, C++, C#, Rosettanet, ebXML, JMS, WebSphereMQ, TIBCO, SMTP, FTP, JBI

JBI (JSR208): Standard component model for integration. Loosely-coupled, event-driven integration with pluggable components (routing engines, data transformation engines, choreography, BPEL, etc.) Not really intended for end users to code to, it's more for software vendors to provide standardized interfaces in their products so you can plug them together however you want. JBI will help drive the shape of integration and ESB much like the EJB spec did for business logic and appservers in the late 90s.

JSR208 provides pluggable integration components, protocol independent (HTTP, SOAP, JMS, EDI, ASN.1). Loosely coupled, SOA-based integration model closely matches core architecture concepts of ESB container model. Standards-based interfaces (e.g., WSDL).

JBI provides a way to standardize the ESB container model. (It's not the only way to do it, though.)

JBI is intended to be an SPI, not API. Allow for proprietary black boxes as integration services. Enables a third-party vendor ecosystem to expand the reach and adoption beyond the realm of J2EE appserver vendors, including middleware, EAI, and ESB.

JBI services include: Normalized message router (NMR) - core component of JBI. XML-based messages include data and metadata. Service is described using WSDL, and provides transaction context, security context, and MEP. Specifics of services, contexts, etc. are not fully specified, some common use cases were used when creating the specification. Also deployment and packaging, and management interfaces (JMX).

JBI container includes: protocol binding component (BC), service engine (SE), NMR, service instance. Has WSDL interface for communications with container, JMX interface for installation, deployment, control, monitoring.

JBI enables multiple services to plug together through the normalized message router without having to translate all the way back out to the main interface protocol.

ESB characteristics: Distributed services architecture. Enterprise-grate communications backbone for reliable messaging (proprietary MOM, JMS, WS-RM, etc). Intelligent routing and content-based routing. Process coordination. Flexible security framework. XML transformation. Management.

Enterprise-grade messaging backbone provides a way to reliably connect services across domains. Need to have scalability at both services and messaging layers. Example of multiple business units with clusters of messaging brokers, interconnected as needed via secured links (at the message level).

Each cluster of messaging turns into a segment of the service bus. Service bus in turn is used to reliably connect service containers.

Services containers support parallel processing and load balancing. Each service can be independently scaled - the number of services and containers is configurable. Location transparency - single namespace allows named addressing. Physical location of services is configurable. Lightweight service containers provide a way to host and control services across platforms. Containers expose abstract endpoints. The actual services are behind the abstraction.

ESB endpoint is event-driven. Behavior is controlled through configuration, not code. Configurable endpoints through Workflow Supported Exception Processing (WSEP).

Multiple, configurable interaction models: publish/subscribe, broadcast, synchronous, asynchronous, etc. Services are assembled into processes. Intermediaries provide routing, transformation, custom processing.

Multiple ways to provide process orchestration. Itineraries can be used for statless processes - message carries its process information along with it, each step passes along to the next. Orchestration services provide stateful processes, where there is an orchestrator that coordinates activity (messages don't need to know where they go next).

JBI + ESB: JBI architecture can support both bus-oriented and mesh-oriented architectures. ESB, as its name implies, is bus-oriented. As with data networks, bus scales better than mesh. In reality, the "bus" winds up looking more like a star (because of the message routing) than an actual bus.

Summary: Loosely coupled, event-driven SOA. Highly distributed integration services container model with selective deployment where and when you need it. Configuration rather than coding. Will foster 3rd-party ecosystem for integration components. Pluggable into ESB backbone.

No comments: