The birds-of-a-feather presentation “Designing and Building a Real-World Service-Oriented Architecture” was presented by Eben Hewitt of Discount Tire.

In my opinion, this was the best session that I have attended yet. The purpose of this presentation was to show how a service-oriented architecture (SOA) was implemented at Discount Tire.

Hewitt’s first slide simply said “SOA != SOD”. In other words, Service-Oriented Architecture is not the same thing as Service-Oriented Development.

Hewitt indicated that SOA is a kind of architecture that uses services as building blocks to facilitate enterprise integration and component reuse through loose-coupling. His company’s goals for SOA was to leverage existing code, reduce time to market, reduce complexity, and clarify maintainability.

The approach to SOA that Hewitt and his team took was to start with well-defined business initiatives and outcomes, deliver architecture and pilot services concurrently, and integrate, communicate, and educate developers every step of the way.

Their strategy was to create a central team that represented their “center of excellence”. This team would be fully responsible for the initial pilot, but they would educate and evangelize to the rest of the community through a reference architecture web site and a blog.

They had a three-year plan involving services, infrastructure, and governance. The services came first ignoring infrastructure and governance for the time being. The services encompassed the platform, tools, the bus, services, and data services. Once the services were established and functional, the infrastructure was defined that allowed for a repository of services, composites, and business process modeling. Finally, the governance piece was considered, which would determine real-time monitoring and change control.

Hewitt talked next about pilot selection. He recommended thinking about the following questions when deciding upon what to pilot:

• Does it create business value?
• Is it limited in scope?
• Would it be a good service?
• Would it be useful, but not mission critical?

Next, Hewitt talked about the toolset used for the SOA implementation. They chose Java SE 6 and Java EE 5 because it had JAX-WS 2.1 built-in. They also selected Glassfish, Open ESB, NetBeans 6 and Eclipse. All of these tools are free and provided an easy exit strategy, if things “went south”.

The team chose to use SOAP and WSDL instead of REST because it had wide industry support, free add-ons, a strong interface, and it was simplified with JAX-WS.

Open ESB was chosen because it was based on JBI. It had support for BPEL, and it was free.

Hewitt and his team decided that they wanted the architecture to be schema-based meaning that all communication mechanisms would be via XML. They introduced BPEL early, and it was used to totally decouple the business process from the code.

The team toyed with the idea of using UDDI for discovery of services, but that idea was “deferred to never”, because there is no one using UDDI. Even SUN couldn’t give them the name of anyone using UDDI. They realized they needed a repository of services so others would know what was available, but UDDI was definitely NOT the answer.

Only after they had a working model and design, did they even start talking about governance. The governance group was responsible for enforcing organizational policies and standards about services. It was very important to maintain a strategy with the business areas.