Service-Oriented Architecture and Phoenix

Sun, 10 Feb 2008 12:27:00 GMT

Since I asked readers about the types of processing deemed essential for us to expose via Web Services, the thought occurs to me that it would be a good thing to discuss Web Services and the importance of Service-Oriented Architecture (SOA).

Service-Oriented Architecture covers a lot of ground, so I’ll delve into that first. In general terms, software architecture concerns itself with the design and structure of a software system. Software systems are compartmentalized into layers, subsystems, and components (and objects, methods, and so on). Software architecture defines these entities and the communication interfaces that will be used for all of the parts to converse with one another.

Service-Oriented Architecture focuses on business-level processing. Software is still constructed in a layered, modular fashion, but with each software service providing a defined, related set of business functions and capable of operating as an independent entity. Our PremiumBill product is an example of this. It has one job (service): insurance billing. It operates as an independent entity with its own business logic and database, a design that in turn allows PremiumBill to support Phoenix as well as any other policy processing system.

The communication interfaces of SOA-compliant systems are likewise focused on business processing. XML and Web Services (covered in a moment) are commonly used to implement these interfaces, resulting in a significant benefit: one application doesn't have to know the technical details of another application in order to communicate with it. This eliminates the embedding of inter-application calls in the applications themselves, something that becomes a maintenance headache over time as well as making it significantly more difficult to replace applications down the road.

The final step with Service-Oriented Architecture is to tie the various (business) services together to provide a complete, end-to-end business solution. To sum it all up in one sentence: Service-Oriented Architecture is also about modeling the enterprise as a collection of services, with these services geared towards business functions.

Since I mentioned Web Services and XML I’ll close the loop on those here. Web Services are used to implement business-level communication interfaces in an SOA world. They are the mechanism that allows applications to communicate regardless of the language they were written in or the platform that they execute on. Windows and Linux-based applications – whether they are written in .NET or Java – can communicate and interoperate through the magic of Web Services.

XML is also an important piece of the puzzle. As we continually expose Phoenix processing via Web Services, we’ve been making use of XML quite heavily. XML – or Extensible Markup Language – is an open standard used for structuring and sharing of data with applications or services. An XML document contains both data and descriptions about the data, making XML “self-describing.” XML is also extensible – meaning new data elements can be defined.

We’re generating XML definitions (called schemas) as part of our Phoenix XML Web Services. These are based on policy configurations within Phoenix, and are designed so that we can work with and use policy data provided in an XML document. When you call a Web Service to rate a policy, you hand that interface an XML document that contains the policy data (in reality, a program will do this on your behalf), and a rate is returned by the software service updating the XML document.

As you can see, we’re sold on SOA here at AMS Carrier Services, and we see numerous advantages to SOA for our customers. Some immediate thoughts that come to mind: a) The fact that business-level interfaces are exposed opens the door to workflow automation; b) Applications can be more readily maintained and improved; c) New software can be introduced far easier.

It’s easy to see how all of this relates to newly-designed systems like PremiumBill. But how does all of this relate to a legacy system like Phoenix? Based on understanding what SOA, XML, and Web Services are, and the fact that Phoenix was not designed to operate in this universe, I hope that you can see that we’re in difficult, but not unmanageable waters.

We’re building out interfaces into the product, using SOA design principles and leveraging the technologies of XML, Web Services, and .NET languages. We’re essentially building new business processing logic that accesses key Phoenix capabilities – like ART rating – and interacts with the Phoenix database. In essence, we’re leveraging and protecting our mutual investment.

This provides you the best of both worlds. Your existing business processing can continue, and we can meet new needs through exposing the necessary business processing via XML and Web Services. In order for us to do this, however, we will need to re-architect and re-write portions of our product.

This is where you come in. It is an expensive proposition to completely re-write Phoenix, and it is not something that can be done all at once. We want to focus on the areas you need us to focus on. I’ll close this blog with the same questions I asked in the last blog: What are your key challenges with Phoenix? What processing do you deem essential for us to expose via Web Services?

Some Web Services seems like a slam-dunk to us: Inquiry capability for policy, billing, and claims, and First Notice of Loss. Others that involve change processing open up a much broader spectrum of processing. What type of change processing do you really need exposed via the Web? Since we can’t build everything overnight, what would be the priority?

I look forward to your input and discussions on this topic.

Dave Moran's Software Development Blog

Service-Oriented Architecture and Phoenix