simplifying service oriented applications with the apache tuscany project n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Simplifying Service Oriented Applications with The Apache Tuscany project PowerPoint Presentation
Download Presentation
Simplifying Service Oriented Applications with The Apache Tuscany project

Loading in 2 Seconds...

play fullscreen
1 / 15

Simplifying Service Oriented Applications with The Apache Tuscany project - PowerPoint PPT Presentation


  • 67 Views
  • Uploaded on

Simplifying Service Oriented Applications with The Apache Tuscany project. Jeremy Boynes 27 July 2006. Consumer. Provider. SOA - What is it?. Architecture for building loosely-coupled applications Characteristics Applications provide and consume services

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Simplifying Service Oriented Applications with The Apache Tuscany project' - becka


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
simplifying service oriented applications with the apache tuscany project

Simplifying Service Oriented ApplicationswithThe Apache Tuscany project

Jeremy Boynes

27 July 2006

soa what is it

Consumer

Provider

SOA - What is it?
  • Architecture for building loosely-coupled applications
  • Characteristics
    • Applications provide and consume services
    • Services have clearly defined contract separate from their implementation
    • Operations exchange information between consumer and provider
    • Implementations can be be built up from smaller ones
  • Connections are as important as applications
  • There are a lot of both
beyond web services
Beyond Web Services
  • Web Services have been critical to SOA evolution
    • Provided a clear need for some form of solution
    • Stimulated evaluation and implementation of SOA
    • Exposed many of the challenges of loosely-coupled solutions
    • Provided clarity into the issues
    • Help specification of solutions
  • But they have also …
    • Contributed a lot of complexity
    • Contributed a lot of overhead
beyond integration
Beyond Integration
  • Organizations faced with challenges connecting applications
    • Users demanding more complex applications
    • “Legacy” applications not open to integration
    • Exceeded capabilities of tape, file exchange, carrier pigeon
  • Web Services presented as a solution
    • But bitten by complexity
    • Double whammy: web services + J2EE
sca approach
SCA Approach
  • There are just two things that are important:
    • What resources you have
    • How they are connected
  • Create an assembly model to represent this
    • Applications become components in the assembly
    • Components provide and consume services
    • Components connect to each other with wires
    • Configuration information outside the implementations
  • Let programmers write applications they way they want to
    • Just let the assembly handle the connections
assembly
Assembly
  • Logical System made up of Components and Wires
  • Components provide and reference Services
  • A Component may be implemented in some language
  • Or it can be implemented as a Composite of other Components
programming models
Programming Models
  • Let a programmer pick the right language for the problem
    • Based on technical applicability
    • Or just familiarity
  • Define a way in which components implemented in that language can be used in an assembly
  • Languages include Java, C++, PHP, BPEL, JavaScript, Groovy
  • Model can also include programming frameworks
    • Specification for Spring applications
    • Support for J2EE applications such as EJBs
simple java implementation
Simple Java Implementation
  • Provides a service an delegates to another
  • IoC pattern allows code to move around an assembly
    • No dependency on SCA APIs e.g. for locating services
    • Can be wired and re-wired by an SCA runtime

public class SourceImpl implements Source {

private Target target;

public SourceImpl(Target target) {

this.target = target;

}

public String echo(String msg) {

return target.echo(msg);

}

}

Service

Provided

Referenceto Service

Use of Service

xml assembly
XML Assembly
  • Defines a single composite containing two components with a wired reference between them

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"

name="LocalWireComposite">

<!-- the component that is the source end of the wire -->

<component name="SourceComponent">

<implementation.java class="localwire.cdi.SourceImpl"/>

<references>

<reference name="target" target="TargetComponent"/>

</references>

</component>

<!-- the component that is the target of the wire -->

<component name="TargetComponent">

<implementation.java class="localwire.cdi.TargetImpl"/>

</component>

</composite>

going global
Going global
  • Exposing as a web service

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"

name="LocalWireComposite">

<service name="MyService">

<interface.wsdl wsdl=”http://www.example.com/myservice"/>

<binding.ws uri=”http://localhost/services/MyService”/>

<reference target=“SourceComponent”/>

</service>

<!-- the component that is the source end of the wire -->

<component name="SourceComponent">

<implementation.java class="localwire.cdi.SourceImpl"/>

<references>

<reference name="target" target="TargetComponent"/>

</references>

</component>

multiple bindings
Multiple bindings
  • Add exposure as a Java RMI service

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"

name="LocalWireComposite">

<service name="MyService">

<interface.wsdl wsdl=”http://www.example.com/myservice"/>

<binding.ws uri=”http://localhost/services/MyService”/>

<binding.rmi uri=”//localhost/MyService”/>

<reference target=“SourceComponent”/>

</service>

<!-- the component that is the source end of the wire -->

<component name="SourceComponent">

<implementation.java class="localwire.cdi.SourceImpl"/>

<references>

<reference name="target" target="TargetComponent"/>

</references>

</component>

how apache tuscany can help
How Apache Tuscany can help…
  • Project under incubation to implement this technology
    • Not an RI for the spec but something actually useful
  • 2 SCA Runtime environments
    • C++ runtime for general integration
    • Java runtime for bytecode based applications
    • Both (will) support implementations in multiple languages
  • There’s also a PHP based runtime at PECL
  • Related technology sub-projects
    • SDO in Java and C++ to represent data
    • Data Access Service for storing state
tuscany futures
Tuscany Futures
  • Support for fine-grained services
    • E.g. expose server-side Ajax handlers
  • Asynchronous connections
    • Automatically queue and process requests
    • Callbacks on completion
  • Conversational Services
    • Application controlled conversations
    • Automatic control e.g. for life of HTTP session
  • Support for Policy and Quality of Service
    • Reliable services, security, integrity
  • Dynamic self-configuring assemblies
    • Automatic location of services based on application criteria
    • Automatic wiring of assemblies based on rules
    • Rewiring and rerouting around disruptions
resources
Resources
  • Tuscany Project
    • http://incubator.apache.org/tuscany
    • mailto:tuscany-dev@ws.apache.org
  • Specifications
    • http://www.osoa.org
  • Contact
    • Jeremy Boynes
    • jboynes@apache.org