A Trenaman SOA

8/6/2019 A Trenaman SOA

1/42

1Open source software for SOA IONA Technologies 2005

Using Open Source Software for SOAAdrian Trenaman, Principal Consultant, IONA Technologies.

[email protected]


2/42

Open source software for SOA 2 IONA Technologies 2005

IntroductionThis presentation is about service-oriented architecture, andhow you can implement it using open-source softwareavailable 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


3/42


Service Oriented Architecture


4/42


The history of SOAThe term SOA was coined in a 1996 research paper byGartner analyst Yefim V. Natis.

- 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.

SOA principals arose out of work with distributed objects .

- Experience with distributed object technologies (for example, COM andCORBA) led to a set of design principals, guidelines and best practise.- It became popular to refer to these distributed objects as services.

SOA could be thought of as the application of object-oriented

principals to client-server architectures.


5/42


The history of SOA (cont)Despite its early appearance, the term SOA became moreprominent some years later around 2002/2003

Web services technologies provided a new interface definitionlanguage called WSDL that is suitable for use in a SOA.

- The term SOA was hijacked by marketers to lend credibility to their webservices products, with the message you need our web servicesproduct for SOA

SOA is not dependent on web services technologies- SOA predates them!

However, web services technologies are suitable for SOA.

Remember: SOA is an architectural style , not a product.


6/42


Understanding architecture stylesWhen discussing the architectural style of a cathedral youmight say that it is Gothic or Roman

There is no rigorous definition of the Gothic or Roman styles, just a collection of design characteristics.

- 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 distinctivedefining characteristics of the style that differentiate it fromothers.


7/42


Distinguishing features of a SOAService-oriented architecture is an architectural style forclient-server applications.

Distinguishing features:- 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 ofcommunication, and supports enterprise qualities of service like securityand transactions.

- Services are often reused by a number of applications.


8/42


SOA componentsDistributed architectures can be trivially separated into clients,servers and the communication infrastructure that liesbetween them.

ConsumerConsumerClient

ServiceServiceServer

Communication Infrastructure

Clients

Servers


9/42


SOA components (cont)The SOA literature gives us new names for thesecomponents: service consumers , service providers and aservice bus .

ConsumerConsumer

Consumer

ServiceServiceService

Service Bus

Service Consumers

Service Providers


10/42


SOAclients

andservices

SOA provides different terms for client and server - 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 Some people find this terminology useful.

- They prefer to use service , because server is ambiguous(server could mean a software application or a computer)

Many people find this terminology unnecessary and annoying.- 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 andservice interchangeably.


11/42


SOAclients

andservices

(cont)In a SOA services exhibit the following properties:

- Its interface is defined using a formal contract (for example, WSDL, orIDL)

- The service implementation details are unknown to the client; the onlyconnection (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 userscan browse.

Formal contracts, loose-coupling and abstraction ofimplementation details are key features of a SOA.

Note: the properties above are almost identical to theproperties of an object in object-oriented architecture.


12/42


SOAservice bus

The clients and servers in a SOA communicate via a commoncommunication framework called a service bus.

The term service bus is derived from computer bus (the wires that connect the CPU, RAM, I/O and so on)

- Each component provides an interface to the bus, which allows it tocommunicate indirectly with a large number of different kinds ofcomponents.

-A component X places a message on the bus, and component Y receives it.

The term service bus is used metaphorically to describe asubsystem that connects clients and servers using the same

underlying protocols and technologies.


13/42


Aside: the bus metaphorThe service bus is a single communication subsystem usedby all the clients and services in a SOA.

Client 2 Client N Client 1

Service Bus

Service 1 Service 2 Service N


14/42


Aside: the bus metaphor (cont)Some people mistakenly ( or purposely) interpret the servicebus to be a messaging hub.

Hub-spoke architectures are difficult to scale, because themessaging hub becomes a bottleneck.


Service Bus



15/42


Aside: the bus metaphor (cont)In reality, a service bus is a set of distributed libraries anddaemons that facilitate direct and indirect communicationbetween clients and services.

This approach scales well.


Service Bus


Messaging


16/42


SOA system servicesA service bus product usually includes system services thatprovide clients and servers with commonly requiredfunctionality, for example:

- 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 samecommunication infrastructure that clients and normal serversuse.


17/42


Theres nothingnew

about SOASOA associates new terminology with concepts that havebeen around for some time.

- The key idea of separating service semantics from serviceimplementation using well defined contracts was already used byCORBA, DCOM and DCE.

CORBA and DCOM where inherently object -oriented.- Over time a set of design guidelines and best-practices emerged that

focused on the design of services (otherwise known as distributedobjects).

SOA can be implemented using existing contract-based client-server technologies such as CORBA and DCOM.

At the same time, SOA has been used as the motivating forcebehind the development of new product categories such asthe Enterprise Service Bus (ESB) category.


18/42


Enterprise Service Bus


19/42


Enterprise Service BusThe term ESB (Enterprise Service Bus) lacks a formaldefinition.

- The term emerged around 2003 and has become synonymous withSOA.

- It has been hijacked by marketers and vendors and liberally redefinedto suit their product sets.

An ESB is a software product that provides underlyingcommunication infrastructure for software components.

- The enterprise in ESB stresses that the product has features likesecurity and transactions and is suitable for use in a large-scaleenterprise.

ESBs provide support for contract-based services using direct(synchronous point-to-point) and indirect (asynchronousmessaging) communication paradigms.


20/42


ESBs and XMLTechnologies such as CORBA and DCOM have providedservice-bus functionality for some time now.

- Surely we could argue that CORBA is an ESB?

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 thismeans 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 calledXML Services Bus, or Web Services Bus.


21/42


Features of an ESBIn the absence of a definition of an ESB, a good way tounderstand 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


22/42


Open Source SOA Software


23/42


What do you need for SOA?You need:

- 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, )


ServiceBus


Messaging

ContractRegistry

Security

Transaction


24/42


SOA with CORBAIf using CORBA, the ORB you choose will typically provide allthe components you need.


ORB


Events/ Notification

InterfaceRespository

Security

Transaction

NamingService


25/42


Open Source ORBs

Choices for open source ORB:- 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-the-wire, you can mix and match different ORB implementations.


26/42


SOA with ESB

The ESB provides core infrastructure and tools.- 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.


ESB


JMS

UDDI/ ebXML

Security

Transaction


27/42


Open Source ESBs

There are a number of open source ESBs available.

Choices:- Celtix : hosted on ObjectWeb, supported commercially by IONA

Technologies- OpenESB : hosted on java.net- Mule : hosted on codehaus.org- ServiceMix : hosted by LogicBlaze

Each of these ESBs typically provides a default JMSmessaging provider

- But you can easily change to a alternative provider.- A list of open-source JMS providers follows.


28/42


Open Source JMS Providers

There are many open-source JMS providers.

Choices:- 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,

Note: JMS providers are not one-the-wire compatible!- If JMS is used, then both client and server must use the same JMS

implementation.


29/42


Open Source Contract Registries

The UDDI standard defines a registry system for WSDLcontracts.

A number of open-source implementations exist:- 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

The ebXML registry is an evolution of UDDI.- Sun Service Registry: http://www.sun.com/products/soa/registry/ - FreebXML: http://ebxmlrr.sourceforge.net/


30/42


Comparison: ESB vs. CORBA for SOA


31/42


32/42


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.

CORBA uses IDL for interface definition- Easy to learn and use (syntactically similar to Java, C++, C#)- Location information is not specified in the contract.


33/42


34/42


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)

CORBA also supports all of these messaging styles.- One-way (using IIOP or event service)- Request-response (using IIOP )- Document-oriented (using IIOP or event service)- Publish-subscribe (using event service)


35/42


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)

Interface design using IDL (in CORBA) is easy .- You can easily write your own IDL with Notepad!- CORBA boasts a powerful yet complex server-side programming

model.


36/42


Technology Adoption

ESB technologies (WSDL, SOAP, JMS) have enormousadoption.

- Huge technology support from J2EE, .Net,

CORBA adoption is leveling out.- However, there is some growth in high-performance areas such as

manufacturing.


37/42


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 Orbacusfor 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.


38/42


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: [email protected]|

|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

|+----------------------------------------------------------------

+-------------------------------------------------------------------


39/42


Results

The following table shows timings for the ESB vs. CORBAapproach.

- Note: client, server and JMS on same machine.

CORBA clearly outperforms the ESB.- Is XML a good fit for SOA?

findInvoicesForCustomer()sendInvoice()SOA

2.3 ms1.2 msOrbacus ORB: IIOP

326.57 ms53.88 msCeltix ESB: SOAP/JMS(ActiveMQ)

123.6 ms19.9 msCeltix ESB: SOAP/HTTP


40/42


Aside: is XML really a good fit for SOA?

XML has widespread support as a markup language.- XML documents are self describing and can be easily validated and

parsed.- XML tools are available for almost all programming languages

However, XML is often criticized for its size and performance:- 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.

- The performance cost can only really be estimated on a per-applicationbasis.

There is a strong argument that ESBs should provide supportfor compact binary protocols as well as XML-based protocols.


41/42


Summary


42/42


Conclusion

When it comes to open source SOA you have lots of choice.

We reviewed and compared two different SOA technologysets: ESB and CORBA

ESB offers great advantages in terms of technology adoptionand 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.

A Trenaman SOA

Documents

Transcript of A Trenaman SOA