Compartir a través de

Composite Applications and Distributed "Service Networks"

  • Artículo

For those that have managed to avoid the pitfall of SOA for SOA’s sake, composite applications are one of the biggest driving forces behind deployments. The reason for service enablement in the first place is so that you can compose them into new applications more easily and richly. As a byproduct, you tend to get more abstraction, and therefore control, over the application logic. Yet, there are some dirty-little secrets about composite apps – compared with your old-fashioned “monolithic app” they introduce some new challenges:

 

1.       Composite apps are more complex for IT to deploy, manage and evolve. The fact that pieces of the composite app may be distributed across servers, platforms and possibly organizational boundaries creates a need for more sophisticated management solutions than exist today.

2.       Composite apps present new challenges around scalability, performance and reliability. With classic monolith apps there are tried-and-true strategies for optimizing apps to scale in demanding environments. But how can you predict the way that a composite app will perform, when the underlying services may have been built for much different levels of scale? How can you make a composite app resilient to failure, so that if one service stops working it doesn’t bring the whole app down?

3.       Composite apps often require much greater cross-vendor interoperability. The benefits of reusing services for new apps can’t be limited to services you’ve created on a single vendor platform, since most enterprises live in a fundamentally heterogeneous world. Therefore composite apps need to be able to easily interop across.NET, Java and legacy mainframe environments.

Despite what some vendors might tell you (which tend to be driven by their monetization goals), solutions to the above problems are challenging. Customers often avoid these issues with initial SOA deployments, but as they start to pursue enterprise-wide initiatives and develop numerous new composite apps these challenges become more apparent.

 

However, there are existing architectural patterns for addressing these concerns. Think about how the world’s largest distributed, service-oriented application - the Internet - addresses the above challenges. Every second of the day the Internet gains more scale and power as new nodes are added to the fabric of the internet. All nodes on the Internet are virtualized – I don’t need to know machine addresses, or know how many boxes any website is running on. You can dynamically add new computing resources without having to take down the Internet, and if any failure occurs the Internet is resilient enough to route traffic around individual points of failure. The Internet is also fundamentally interoperable – you can add computing nodes of any vendor platform as long as you adhere to standards-based protocols.

 

I’ll apply these characteristics of the Internet to the world of SOA, and describe something that I’ll call a distributed “Service Network” . The Service Network should be able to automatically detect when you’ve added new computing nodes to the network and take advantage of scaling out with greater power (without requiring complex setup or configuration – it should auto-detect that more resources are available for use). A Service Network should allow you to add new services without having to worry about physically deploying bits on servers or taking down machines – it should dynamically be “virtualized” against the underlying physical resources. The Service Network should also let you mix/match services across vendors, as long as you stick to open standards. And most importantly, the Service Network should keep the composite application from knowing about failure of hardware, automatically redirecting access to new services somewhere on the network without the app ever skipping a beat.

 

Last week I wrote about how Greg Leake was going on tour to talk about his latest work on both StockTrader and the new Configuration Service. Greg’s configuration service is one of the first examples of a general purpose Service Network built using .NET managed code. These code libraries can be leveraged as part of your SOA projects to develop new composite application that mix/match services across both .NET and Java. And you can take advantage of the Config Service with your existing services and apps, requiring only 20 lines of code to reap all of the advantages of the Service Network concept.

 

For more on this, check out a recent article by Redmond Magazine that describes how Greg’s efforts are helping shape the future of SOA and composite applications. We’ll be using the feedback we get from this initial work to drive requirements and patterns into our on-going product development efforts.

 

And remember, if a vendor tells you that you have to open a PO to “do SOA” and the money isn’t for training, start asking hard questions.

Comments