JavaOne-TS-8897-Designing Service Collaborations-The Design of "Wire"-Centric Integration13 May 2007
Presentations, JavaOne, SOA-Tips, SOA-Blueprints, The-Web-of-Services
Presentation Slide Deck
Presented a technical session at JavaOne 2007 about designing Service Collaborations and an indepth discussion about The Design of “Wire”-Centric Integration.
|JavaOne 2007, Moscone Center, San Fransisco, CA.
|Date & Time
|Thursday, May 10, 2007, 10:55AM to 11:55AM
|Designing Service Collaborations: The Design of “Wire”-Centric Integration
|Integration design used to be focused on the design of middleware that connected applications. Today the “wire” design of the message exchanges between collaborating services is the core architectural element of integration. The Internet and the messaging standards it has driven allow integration wire design to be global, nonproprietary, and platform-independent. A service collaboration design formally captures the functional, infrastructure, and protocol layers of the message exchange wire that connects the services that implement one or more of the collaboration’s roles. This session presents an overview of collaboration wire design and walks through an example to illustrate how it is done in practice.
|Services and Integration
|Mark Hapner, Sun Microsystems, Inc.; Gopalan Suresh Raj, Sun Microsystems, Inc.
Presentation Slide Deck
How the session was presented
Mark Hapner went first and for the first half of the presentation talked about:
- Focus shifts to the ‘wire’
- What the ‘wire’ isn’t
- What the ‘wire’ is
- ‘Wire’ design
I did the second half with 15 ‘Wire’ design best practices.
We had so many ‘Wire’ design best practices, but in a session that is limited to an hour, there are only as many that you can talk about. I hope to talk about so many other best practices through my blog here and various articles and white-papers that I plan to write.
More about the Session
As noted in the abstract, the focus of integration design is shifting to design of the ‘wire’. Just as in other areas of software design, it is a combination of technology and art. When we, as developers and architects, were learning how to design software with OO languages, many overly complex designs were created as designers used every bell and whistle in the OO kit in their designs. The same thing is beginning to happen with our ‘wire’ designs.
The art of ‘wire’ design is to simplify the design at each level to the minimum needed to support the function of the collaboration. The less protocol, infrastructure and functional complexity a collaboration requires – the easier it is to bring it to life.
A ‘wire’ design is meaningless if it doesn’t result in actual service collaboration occurring. A collaboration may span companies in a vertical market; companies participating in a particular supply chain; users of a particular SaaS provider; or, simply an internal set of collaborating services. Once it has been brought to life, the hope is that its community of users will grow and that it will evolve to meet the changing needs of this community. The design of the ‘wire’ must take this requirement for growth and evolution into account. It must also take into account the day-to-day requirement for reliability – it is impossible to guarantee collaboration ‘consistency’ so the design must include basic support for ‘recovery’.
The shift to ‘wire’ design goes hand-in-hand with the recognition that most integrations today can’t rely on a central broker to establish the collaboration in the sense that EAI middleware did for IT and VANs did for EDI. The only infrastructure most ‘wire’ collaborations share is the Internet TCP-IP infrastructure. The rest is implemented at each endpoint and these endpoints are increasing operating as peers as they weave their function out of functions they supply and functions they access via ‘wire’ collaboration.
This session will help developers and designers understand how to begin reasoning about integration from a ‘wire’ perspective. It will help them decide how to decompose an integration design into its ‘wire’ and ‘endpoint’ parts. It will help them recognize that they ‘own’ the task of ‘wire’ design – that they must define service collaborations down to the bits-on-the-wire if they are to successfully deploy them. That there are many choices at each level – to use/not-use the SOAP envelope; what message elements should function as correlation values; how to design duplicate-insensitive message exchanges; etc.
About the introduction of this new ‘Services and Integration’ Track to JavaOne 2007
SOA architectures are being realized in implementations of high-value connections between enterprises. These e-business collaborations present a challenge not typically considered when SOA is discussed. Developers must start creating global applications. In addition, the delta between external collaboration and internal integration is disappearing. In effect, developers are beginning to converge on a single global application development model.
This track’s sessions address the developer community’s need for creating pragmatic e-business services with Java technology. Among the topics covered in this track are the following:
- Best practices for implementing composite applications conforming to service-oriented architecture principles
- Securing global collaboration
- The design of message-based collaborations independent of platform and service implementation
- Best practices in policy enforcement
- Tools and technologies for implementing e-business services for functions such as orchestration, routing, rules, validation, and data access
- The use of REST and Web 2.0 techniques to solve e-collaboration problems
- What facilities provided by web services and SOA have been found to be of the most value in solving e-collaboration problems
- New approaches and technologies such as Java Business Integration (JBI) and SCA Interoperability