Building Service Oriented Architectures with Java Technology
Sun Microsystems started a tour in the US to present a comprehensive view of the technologies and approaches it recommends to build Service-Oriented-Architecture with Java Technology. In Seattle, the presenter was Thomas Barrett, SOA Technical Specialist at Sun.
Sun's target architecture is a composite application platform which is using reusable services either provided by third parties or built from legacy systems. Sun introduces SOA as a:
Track-tested architectural style for building applications using services available in a network (“The Network is the Computer”)
The presentation explains that SOA is best implemented with an ESB that provides resource and channel adapters as well as a series of build-in capabilities such as transformation, security, logging, routing...
Sun introduces the four layers of a Service Oriented Architecture:
- access (delivery channels)
Sun sees Web Services and REST as equally important for implementing Service Oriented Architectures. It is investing significantly in REST with:
- JAX-RS: Java API for RESTful Web Services
- JSR 311 (Draft April 2007)
- Jersey is open source reference implementation
Sun also presents BPEL as a critical technology for SOA. The presenter demoed a graphical editor based on BPMN symbols and running in NetBeans 6.0.
The presentation went on to give an introduction to JBI, which is Sun's foundation to Service Oriented Achitectures. The presenter also demoed JBI's new assembly capability which is very similar to the one of SCA. Sun sees JBI as:
- Allowing developers to provide more sophisticated applications and achieve better integration with other Java platform technologies
- Standard “meta-container” for integrated services
The presentation gives some details about the upcoming JBI 2.0 specification:
- Clarify and enhance JBI's role in creation, deployment and runtime support of composite applications
- Support Web 2.0 technologies and usage models
- Facilitate performance optimizations by component and container implementers
- Improve alignment with Java EE (e.g. use of transactions)
- Align with the Service Component Architecture (SCA) specifications with the goal of making JBI 2.0 a standard Java runtime for SCA
- Provide full compatibility with OSGi Java-based service platform
The presentation includes a proposal for the alignment between SCA and JBI:
- SCA sees JBI as helpful in implementing SCA on the Java platform
- JBI appreciates SCA service metadata as helpful in standardizing service composition in general
- SCA and JBI are not competitors as they focus on different aspects of service composition
The last section of the presentation focuses on the OpenESB offering, its relationship to Java CAPS (Composite Application Platform Suite) and its roadmap.
REST and BPEL?
How is Sun combining their REST and BPEL stories? Obviously, with their emphasis on REST, they aren't supporting WSDL...
Re: REST and BPEL?
hi, this is a good question. First I want to emphasize that the presenter, Thomas Barrett was neutral with respect to Web Services vs REST. I know that he relayed some of the concerns Tim Bray has about Web Services, but I did not get the feeling that Sun was walking away from Web Services. Thomas presented Tim's quote as: "what people that use REST think about Web Services". I am not sure he used the quote to represent Sun's view in the REST vs Web Services debate. I think Thomas point was "if you are thinking about Web Services, take a look at REST too".
BPEL appears to be a key element of CAPS (based on the presentation) and Thomas did not talk at all about the relationship between BPEL and REST.
IMHO, (it would be best if someone from Sun would respond directly) it seems that REST plays at the "access" layer of Sun's architecture. Of course, REST has more architectural implications than this, but nothing really prevents you to use REST as some kind of "lipstick". As soon as you use annotations on an object model, I think it means that you are doing some form of remoting without profound architectural changes. Again, this is only my opinion, and I am not conveying by expressing it anything I learned from Sun.
Hope this helps,
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015