Beruflich Dokumente
Kultur Dokumente
Introduction
This presentation is about service-oriented architecture, and how you can implement it using open-source software available today. Roadmap:
-
What is SOA? - A little historical reference - Distinguishing features of service-oriented architectures The (Enterprise) Service Bus concept Open-source software choices for SOA - Theres a lot of open-source competition out there. Comparison: ESB vs. CORBA for SOA Conclusions
SOA is a software architecture that starts with an interface definition and builds the entire application topology as a topology of interfaces, interface implementations and interface calls SOA would be better-named interface-oriented architecture.
Experience with distributed object technologies (for example, COM and CORBA) led to a set of design principals, guidelines and best practise. It became popular to refer to these distributed objects as services.
The term SOA was hijacked by marketers to lend credibility to their web services products, with the message you need our web services product for SOA
However, web services technologies are suitable for SOA. Remember: SOA is an architectural style, not a product.
Gothic arches are pointy; Roman arches are rounded Gothic walls should be embellished with statues and fine detail; Roman walls are plain and simple. If a cathedral has rounded arches and plain walls then it is Roman style.
To understand a style you need to focus on the distinctive defining characteristics of the style that differentiate it from others.
A SOA consists of clients and servers (services) connected by a communication subsystem known as a service bus. Services are defined using formal interfaces (contracts) that hide away implementation details from the client. The bus supports both point-to-point and messaging styles of communication, and supports enterprise qualities of service like security and transactions. Services are often reused by a number of applications.
SOA components
Distributed architectures can be trivially separated into clients, servers and the communication infrastructure that lies between them.
Clients Client Consumer Consumer
Communication Infrastructure
Server Service Service Servers Open source software for SOA IONA Technologies 2005 8
Service Bus
Service Service Service Service Providers Open source software for SOA IONA Technologies 2005 9
In SOA terminology, a client is a service consumer, or simply a consumer. Likewise, a server is known as a service provider, or simply a service
They prefer to use service, because server is ambiguous (server could mean a software application or a computer)
They are cynical of any attempt to recast well-known concepts as something new and innovative by simply giving them a new name.
In practice, most people still use client, and use server and service interchangeably.
10
Its interface is defined using a formal contract (for example, WSDL, or IDL) The service implementation details are unknown to the client; the only connection (or coupling) between the client and server is the contract. The service is self-contained, and can be run with or without other services present. Services may be used by other services The interface is stored in a well-known repository that prospective users can browse.
Formal contracts, loose-coupling and abstraction of implementation details are key features of a SOA. Note: the properties above are almost identical to the properties of an object in object-oriented architecture.
Open source software for SOA IONA Technologies 2005 11
Each component provides an interface to the bus, which allows it to communicate indirectly with a large number of different kinds of components. A component X places a message on the bus, and component Y receives it.
The term service bus is used metaphorically to describe a subsystem that connects clients and servers using the same underlying protocols and technologies.
12
Client 1
Client 2
Client N
Service Bus
Service 1
Service 2
Service N
13
Service Bus
Service 1
Service 2
Service N
14
Client 1
Client 2
Client N
Service Bus
Messaging
Service 1
Service 2
Service N
15
Service naming and lookup for finding services at runtime Service registry for storing service contracts Security Transactions Service management Messaging
Typically the services are implemented using the same communication infrastructure that clients and normal servers use.
16
The key idea of separating service semantics from service implementation using well defined contracts was already used by CORBA, DCOM and DCE.
Over time a set of design guidelines and best-practices emerged that focused on the design of services (otherwise known as distributed objects).
SOA can be implemented using existing contract-based clientserver technologies such as CORBA and DCOM. At the same time, SOA has been used as the motivating force behind the development of new product categories such as the Enterprise Service Bus (ESB) category.
Open source software for SOA IONA Technologies 2005 17
18
The term emerged around 2003 and has become synonymous with SOA. It has been hijacked by marketers and vendors and liberally redefined to suit their product sets.
An ESB is a software product that provides underlying communication infrastructure for software components.
-
The enterprise in ESB stresses that the product has features like security and transactions and is suitable for use in a large-scale enterprise.
ESBs provide support for contract-based services using direct (synchronous point-to-point) and indirect (asynchronous messaging) communication paradigms.
Open source software for SOA IONA Technologies 2005 19
The industry has settled on the following rule-of-thumb if it doesnt use XML, then its not an ESB. To qualify as an ESB, a product must use XML; typically this means the web services technologies:
-
XSD and WSDL for contract definition SOAP and XML for protocol payload UDDI for service registry
Aside: perhaps ESB is a misnomer; it should have been called XML Services Bus, or Web Services Bus.
Open source software for SOA IONA Technologies 2005 20
Features of an ESB
In the absence of a definition of an ESB, a good way to understand ESB to look at the features provided. An ESB typically provides the following functionality:
-
Data modeling with XML Schema; Interface modeling with WSDL; Client and server development tools (code generation from WSDL, libraries, IDE support, etc.) Synchronous point-to-point communication using SOAP/HTTP Asynchronous messaging using SOAP as a payload over a messaging protocol that supports persistence of messages. Message payload transformation using XSLT
21
22
A service bus providing point to point messaging A compatible messaging service (if not provided by the bus) Other services: registry, security, transactions Developer tools (design contracts, develop and deploy services, )
Client 1 Client 2 Client N
Contract Registry
Service Bus
Messaging
Security
23
ORB
Events/ Notification
Security
24
Orbacus (Java and C++ ORB): www.orbacus.com, commercially supported by IONA. TAO (C++ ORB) http://www.cs.wustl.edu/~schmidt/TAO.html, commercially supported by Prismtech, Huihoo, and OCI among others JacORB (Java ORB) http://jacorb.org. MICO (C++ ORB) http://www.mico.org, commercially supported by Object Security
Because ORBs use the standardized IIOP protocol on-thewire, you can mix and match different ORB implementations.
25
Many ESB components (eg. Registry, JMS) are pluggable! Expect a LAMP-like SOA stack to emerge, where a SOA ESB solution will comprise a number of open-source projects.
Client 1
Client 2
Client N
UDDI/ ebXML
ESB
JMS
Security
26
Celtix: hosted on ObjectWeb, supported commercially by IONA Technologies OpenESB: hosted on java.net Mule: hosted on codehaus.org ServiceMix: hosted by LogicBlaze
But you can easily change to a alternative provider. A list of open-source JMS providers follows.
27
JORAM: hosted by ObjectWeb Active MQ: hosted by Logic Blaze SwiftMQ: hosted by swiftmq MantaRay: hosted on SourceFourge.net JBossMQ: hosted by jboss.org Others: OpenJMS, UberMQ, ActiveJMS,
If JMS is used, then both client and server must use the same JMS implementation.
28
jUDDI: hosted by Apache - http://ws.apache.org/juddi Ruddi: hosted by InspireIT - http://www.inspireit.biz Nsure UDDI Server: hosted by Novell - http://developer.novell.com/uddi
29
30
The next slides compare ESB and CORBA with respect to the following:
-
Communication infrastructure Interface Definition Messaging styles Complexity Technology Adoption Performance
31
Interface Definition
ESB uses WSDL for interface definition
-
Can be quite complex, even for simple Hello, World example. Provides a clean separation of interface vs. location (host name, port, etc.) Interfaces are defined using WSDL, data-types are defined using XSD.
Easy to learn and use (syntactically similar to Java, C++, C#) Location information is not specified in the contract.
32
Communication Infrastructure
ESB typically uses SOAP as a messaging payload.
-
SOAP wraps XML messages in an XML wrapper; as a result SOAP messages are self describing. Messages are transmitted as plain text. Payload transmitted over HTTP or JMS
Some ESBs (e.g. IONAs Artix) allow other payload/transport combinations. CORBA uses a binary message payload, Common Data Representation (CDR).
-
Messages are not self describing. Payload transmitted over IIOP (Internet Inter-Orb Protocol) Asynchronous messaging provided by an event or notification service.
33
Messaging Styles
ESB can support the following messaging styles:
-
One-way (using SOAP/HTTP or SOAP/JMS) Request-response (using SOAP/HTTP or SOAP/JMS) Document-oriented (using SOAP/HTTP or SOAP/JMS) Publish-subscribe (using SOAP/JMS)
One-way (using IIOP or event service) Request-response (using IIOP ) Document-oriented (using IIOP or event service) Publish-subscribe (using event service)
34
Complexity
Interface design using WSDL (in an ESB) is complex.
-
Requires specialist knowledge / experience / tools. Client and server implementation are straight-forward (particularly using Java)
You can easily write your own IDL with Notepad! CORBA boasts a powerful yet complex server-side programming model.
35
Technology Adoption
ESB technologies (WSDL, SOAP, JMS) have enormous adoption.
-
36
Performance
Is ESB faster/slower than CORBA? As an illustration, timings were gathered for an Invoice Server
-
The invoice data structure is sufficiently complex to be interesting, involving enumerations, lists, nested data-types, etc. Sample invoice provided on next slide.
The server was implemented using Celtix ESB and Orbacus for Java. Two business operations were measured:
-
Transmitting a single invoice - sendInvoice() - Client sends an invoice - Server returns void. Transmitting a batch of invoices - getInvoicesForCustomer(): - Client sends first name, last name - Server returns a list of 100 invoices.
IONA Technologies 2005 37
Invoice
+------------------------------------------------------------------| I N V O I C E | |Customer: null |Name: null null |Address: 4 Shelbourne Road | Ballsbridge | Dublin | null | D4 | Ireland | |Phone: +353-1-6372000 |Email: customer@iona.com | |Shipping Date: 2005-11-30 |Payment Date: 2005-12-25 | |+---------------------------------------------------------------||Items: || 1000 x Widget (Code: 123) Unit cost: 20.0, Total cost: 20000.0 || 1000 x Doo-Lally (Code: 321) Unit cost: 30.0, Total cost: 30000.0 |+---------------------------------------------------------------+-------------------------------------------------------------------
38
Results
The following table shows timings for the ESB vs. CORBA approach.
-
SOA Celtix ESB: SOAP/HTTP Celtix ESB: SOAP/JMS (ActiveMQ) Orbacus ORB: IIOP
39
XML documents are self describing and can be easily validated and parsed. XML tools are available for almost all programming languages
XML documents can be bloated with markup tags. Validation and parsing of XML can be costly in time and memory.
There may be applications where XML (and by consequence, ESB) is simply too slow.
-
There is a strong argument that ESBs should provide support for compact binary protocols as well as XML-based protocols.
Open source software for SOA IONA Technologies 2005 40
Summary
41
Conclusion
When it comes to open source SOA you have lots of choice. We reviewed and compared two different SOA technology sets: ESB and CORBA ESB offers great advantages in terms of technology adoption and acceptance of the underlying XML core. This flexibility may cost you in terms of performance.
-
ESB performance will be acceptable for many business applications! If not, then the open-source ESB community will have to provide support for fast non-XML protocols.
42