Microsoft PowerPoint

1Open source software for SOA © IONA Technologies 2005

Using Open Source Software for SOA

Adrian Trenaman, Principal Consultant, IONA Technologies.

adrian.trenaman@iona.com

Open source software for SOA 2© IONA Technologies 2005

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

- There’s a lot of open-source “competition” out there.

- Comparison: ESB vs. CORBA for SOA

- Conclusions

Service Oriented Architecture

The history of SOA

� The term “SOA” was coined in a 1996 research paper by Gartner 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 and

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

The history of SOA (cont’)

� Despite its early appearance, the term SOA became more prominent some years later around 2002/2003

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

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

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

Understanding architecture styles

� When discussing the architectural style of a cathedral you might 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 distinctive

defining characteristics of the style that differentiate it from

others.

Distinguishing features of a SOA

� Service-oriented architecture is an architectural style for client-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 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.

ConsumerConsumerClient

ServiceService

Server

Communication Infrastructure

Clients

Servers

SOA components (cont’)

� The SOA literature gives us new names for these components: service consumers, service providers and a

service bus.

ConsumerConsumer

Consumer

ServiceService

Service

Service Bus

Service Consumers

Service Providers

SOA clients and services

� 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 and

service interchangeably.

SOA clients and services (cont’)

� In a SOA services exhibit the following properties:

- It’s interface is defined using a formal contract (for example, WSDL, or

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

SOA service bus

� The clients and servers in a SOA communicate via a common communication 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 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.

Aside: the “bus” metaphor

� The “service bus” is a single communication subsystem used by all the clients and services in a SOA.

Client 2 Client NClient 1

Service Bus

Service 1 Service 2 Service N

Aside: the “bus” metaphor (cont’)

� Some people mistakenly (or purposely) interpret the “service bus” to be a messaging hub.

� Hub-spoke architectures are difficult to scale, because the messaging hub becomes a bottleneck.

Service Bus

Aside: the “bus” metaphor (cont’)

� In reality, a “service bus” is a set of distributed libraries and daemons that facilitate direct and indirect communication

between clients and services.

� This approach scales well.

Service Bus

Messaging

SOA system services

� A service bus product usually includes system services that provide clients and servers with commonly required

functionality, 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 same

communication infrastructure that clients and normal servers use.

There’s nothing new about SOA

� SOA associates new terminology with concepts that have been around for some time.

- The key idea of separating service semantics from service

implementation using well defined contracts was already used by

CORBA, 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 distributed

objects).

� 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 force

behind the development of new product categories such as

the Enterprise Service Bus (ESB) category.

Enterprise Service Bus

� The term “ESB” (Enterprise Service Bus) lacks a formal definition.

- The term emerged around 2003 and has become synonymous with

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

ESBs and XML

� Technologies such as CORBA and DCOM have provided service-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

doesn’t use XML, then it’s 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.

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

Open Source SOA Software

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

SOA with CORBA

� If using CORBA, the ORB you choose will typically provide all the components you need.

Events/ Notification

InterfaceRespository

Security

Transaction

NamingService

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.

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.

UDDI/ebXML

Security

Transaction

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 JMS messaging provider

- But you can easily change to a alternative provider.

- A list of open-source JMS providers follows.

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.

Open Source Contract Registries

� The UDDI standard defines a registry system for WSDL contracts.

� 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/

Comparison: ESB vs. CORBA for SOA

� Recap: SOA requires an interface definition language and communication infrastructure.

� You can use an ESB to implement a SOA

- Or use a more traditional alternative, like CORBA.

� The next slides compare ESB and CORBA with respect to the

following:

- Communication infrastructure

- Interface Definition

- Messaging styles

- Complexity

- Technology Adoption

- Performance

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,

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

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. IONA’s 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.

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)

Complexity

� Interface design using WSDL (in an ESB) is complex.

- Requires specialist knowledge / experience / tools.

- Client and server implementation are straight-forward (particularly using

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

Technology Adoption

� ESB technologies (WSDL, SOAP, JMS) have enormous adoption.

- Huge technology support from J2EE, .Net, …

� CORBA adoption is leveling out.

- However, there is some growth in high-performance areas such as

manufacturing.

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.

Invoice

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

| I N V O I C E

|Customer: null

|Name: null null

|Address: 4 Shelbourne Road

| Ballsbridge

| Dublin

| null

| 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

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

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

Results

� The following table shows timings for the ESB vs. CORBA approach.

- 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

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

basis.

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

Summary

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.

Microsoft PowerPoint - A-Trenaman

Documents

Transcript of Microsoft PowerPoint - A-Trenaman

PowerPoint Lesson 1 Microsoft PowerPoint Basicsts091.k12.sd.us/Multimedia_power_points/PowerPoint Lesson 01.pdf · 1 PowerPoint Lesson 1 Microsoft Word Basics Microsoft Office 2010

Microsoft PowerPoint 2013 Fundamentals Manualtechnology.pitt.edu/sites/default/files/documents/migrated/Training... · Microsoft PowerPoint 2013 Fundamentals ... Microsoft PowerPoint

Microsoft PowerPoint 2013 Fundamentals Manual Microsoft PowerPoint 2010 Fundamentals Page 1 of 43 October 10, 2013 Welcome Microsoft PowerPoint 2013 Fundamentals ... File: Microsoft

Lesson 1: Understanding Microsoft Office PowerPoint 2010 Microsoft PowerPoint 2010.

MICROSOFT POWERPOINT Y MICROSOFT PUBLISHER

New Microsoft PowerPoint Presentationflarc.net/For_Sale/190726_KM2C_ForSale.pdfTitle: Microsoft PowerPoint - New Microsoft PowerPoint Presentation Author: LTE Created Date: 7/26/2019

POWERPOINT BASICS: MICROSOFT OFFICE 2013 Office/Powerpoint Basics... · Click Start Programs Microsoft PowerPoint* *Occasionally, Microsoft PowerPoint will be in a folder called "Microsoft

11040 Microsoft PowerPoint - 11040 Microsoft PowerPoint - Securtization [Compatibility Mode](1)

A Trenaman SOA

Презентация Microsoft PowerPointarmanenshaft.narod.ru/download/blender/Property_about.pdf · Title: Microsoft PowerPoint - Презентация Microsoft PowerPoint Author:

Lucene revolution 2013 adrian trenaman

Microsoft PowerPoint ...

New Microsoft PowerPoint Presentationkofraj.com/download/Geotube_offers_pdf/Snimki kofaj.pdfTitle Microsoft PowerPoint - New Microsoft PowerPoint Presentation Author Tedi Created Date

22 New Microsoft Office PowerPoint Presentation [Autosaved]metnet.imd.gov.in/imdrajbhasha/sangoshthi_2016/4500216.pdf · Microsoft PowerPoint - 22 New Microsoft Office PowerPoint

20100907 fuse-community-evening-adrian-trenaman-no-logo

Microsoft PowerPoint 2013 Tutorial · Microsoft PowerPoint 2013 Tutorial Basic Features of Microsoft PowerPoint Microsoft PowerPoint is a presentation program. It is used for making

Microsoft PowerPoint -

Microsoft Office PowerPoint 2010: Advanced …Microsoft Office PowerPoint 2010: Advanced Course 01 - Customizing PowerPoint

New Microsoft Office PowerPoint Presentationagritech.tnau.ac.in/agriculture/PGRs in Crop plants.pdf · Microsoft PowerPoint - New Microsoft Office PowerPoint Presentation Author: