Michael Pelletier

Subscribe to Michael Pelletier: eMailAlertsEmail Alerts
Get Michael Pelletier: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Apache Web Server Journal, SOA & WOA Magazine

Article

2005 Will Be the Year of SOA — Are You Ready?

So what's this SOA stuff all about anyway?

You might have been asking yourself for a while now what this Service Oriented Architecture (SOA) thing is and why it should matter to you. If you're a developer you've probably been wondering what you'll need to learn to avoid being left behind. You'd probably also like to know what steps you can take to position your development team and your organization for the future. If you're like me when I first started hearing about SOA, you've done some Web searches and read a few articles, but haven't fully grasped:

  • the difference between SOA and Web Services;
  • what's required to actually implement an SOA;
  • how Indigo fits into the picture;
  • and whether SOA is an all or nothing proposition;
  • what your role is in developing an application.
These are just a few of the questions that typically come up and this article will guide you through the answers.

What is SOA?
Let's start with a basic definition of SOA. One of the things you'll recognize as you learn more about SOA is that there isn't just one definition. Depending on whether you are a developer, architect, IT manager, LOB director or even a CXO, SOA will mean different things to you. For example, as a CIO, you'd be interested in how adopting an SOA approach would allow your organization to deliver new applications more quickly to address changing business needs. As a developer you might be interested in how SOA allows applications to be sensitive to the content and context of a specific business process, and to incorporate new capabilities incrementally over time. See, SOA is not just a services architecture seen from a technology perspective; it's the policies, practices and frameworks by which we ensure the right services are provided and consumed to provide business value.

Rather than hewing to a set definition, there are four tenets of SOA that have been generally accepted by the developer community. While there's always going to be some disagreement over whether supporting all these principles is presrequisite to SOA, they do provide a basis on which we can build an understanding.

  • Boundaries are explicit;
  • Services are autonomous;
  • Services share schema and contract, not class;
  • Compatibility is based on policy.
While the principles are important, you shouldn't focus only on developing your technical skills. You should build up your business acumen too. The promise of SOA lies not just in the technology, but in its ability to deliver business processes as services. While those from the business world will need to continue to learn more about the technology and related disciplines, it's incumbent on developers to learn more about their particular industry and cross-pollinate business and technology. That said, let's dive into some of the enabling technologies for creating an SOA.

Enabling Technologies
The notion of a services-based architecture isn't new. In fact, many of the concepts and principles have been around for several years in technologies like CORBA, DCOM and MSMQ. However, while these technologies are useful in creating distributed systems, they're not particularly well suited for creating a service-oriented architecture. For example, one of the important aspects of an SOA is interoperability (compatibility based on policy). CORBA, DCOM and MSMQ aren't as interoperable as, say, XML, SOAP, WSDL and HTTP, which provide the basis on which Web Services are created. Additionally, standards bodies, like the WS-Interoperability Organization (WS-I) are helping to ensure, through their Profile specifications, that Web Services implementations from different vendors (Microsoft, BEA, IBM, Sun, Apache) can interoperate when each subscribes to a given Profile.

Web Services are currently the most effective way to implement a Service Oriented Architecture since they involve technologies that most of us are familiar with, like XML and HTTP. Web Services in and of themselves, however, are not an SOA. To create a basic web service you need the following mechanisms:

  • A network transport - HTTP;
  • A common data markup language - XML;
  • A standard way for interpreting endpoints and requesting remote procedure invocation - SOAP;
  • A language that describes the services being offered - WSDL;
  • A means of finding services that are available for consumption - UDDI.
While the tools available today in Visual Studio.NET let you create and consume Web Services without needing to do things like manually modify the XML in a WSDL document, it's important to understand each of these technologies so that when you do have to edit the WSDL manually you will be able to. One of the principles to subscribe to when creating Web Services is to create the WSDL first to allow for the definition of the most important piece of the SOA puzzle - the creation of a well-defined interoperable interface. This is just one example of an architectural issue developers should be aware.

Architectural Challenges
As a developer it's important to understand some of the architectural issues at hand when creating an SOA. While the architects of your applications should be responsible for defining the overall interaction mechanism, it's incumbent on the developer to be proactive in identifying some of the challenges to SOA and addressing them through development techniques.

One thing that developers need to be aware of is the granularity of services. There's no fixed answer to how granular a service should be, but it's something that needs to be evaluated when creating services. Granularity refers to how responsible a particular service is in the context of the overall activity to be performed and that correlates to how many cross-boundary calls are made.

See Figure 1 for a diagram illustrating a client application calling coarse grained services

Imagine if you were writing an application that involved managing rooms in a hotel. Assuming you've used many of the object-oriented principles that have been espoused over the past 10 years you've probably defined a Room class, a Guest class and a Reservation class among others. Typically, in a non-services-based application the user interface might have pulled up a list of rooms that were available and then, when it came time to book a reservation, the instance of a particular room and a particular guest were used to create a reservation class. This might have involved two or three calls from the user interface to these business entities.

In a services-based design there might be a room availability service that provides information about the rooms, their availability and their rates. There might be a guest management service that provides information about the guests, their room preferences and preferred method of payment. While each of these services may be implemented using OO principles with Room classes and Guest classes, to book a room we wouldn't want to have to call each of them to create instances of a guest and a room in order to call yet-another service to book the reservation. Instead, we should design our reservation service so that we can pass it all the data we need to book the room with one request. The creation of a Guest, Room and Reservation class could occur as part of the Reservation Service, but would isolate the UI from needing to know that these objects were created to avoid making several cross-boundary calls.

As you work towards designing your services interface more coarsely it becomes evident that your services are representative of your business processes. That's why having a good understanding of what your business does and how it does it is so important.

Other challenges emerge when you move beyond creating a simple Web Service to, say, crafting a secure Web Service. One of the things that became apparent from the outset with Web Services was that the technologies and specifications had to prove the concept. As more and more companies began working with the tools deficiencies became apparent. One that was always topped the list was security.

Fortunately progress has been made in addressing this and other shortcomings in the standards surrounding Web Services. You can learn more about several of the initiatives underway by visiting the Web Services Specifications section of the MSDN Web Services Developer Center at (http://msdn.microsoft.com/webservices/understanding/specs/default.aspx).

Web Services Enhancements 2.0
One of the first things that developers using some of the new WS-* standards realized was that managing the creation of a policy file for WS-Policy and setting up the security for WS-SecureConversation was difficult to do without some tools. Microsoft subsequently released Web Services Enhancements (WSE) to address these issues. WSE 2.0 simplifies the development and deployment of secure Web Services by enabling developers using Visual Studio.NET and the .NET Framework to apply security policy more easily and establish long-running secure conversations and retrieve and validate security tokens.

See Listing 1 for an example of the XML used to indicate the use of an encrypted UsernameToken

One of the things you'll discover, however, is that while WSE automates a lot of the grunt work involved with creating secure Web Services, interoperability issues are going to have to be addressed manually. For example, the current version of BEA WebLogic doesn't support using a HashedPassword as an option for passing the password portion of a UsernameToken. While this can be overcome by encrypting the UsernameToken portion of the SOAP request, that predicate isn't included by default as a data element that the automated tools in WSE will encrypt. Adjusting this requires understanding where that information exists in the WSDL document and how to alter it, which is why understanding the specific technologies that make Web Services work is so important.

See Listing 2 for an example of the section of the policy file that needs to be updated to indicate that the UsernameToken should be encrypted.

The Future of SOA
While the tools and technologies we have today for developing Web Services are certainly capable of building and delivering the services necessary to implement SOA applications, there are exciting features in store from Microsoft in Indigo, the culmination of Microsoft's investments in interoperable messaging:

  • It will be Microsoft's implementation of advanced Web Services (the WS-* specifications).
  • It will be Microsoft's unified messaging stack for distributed computing from inter-process communications to cross-organization Web Service invocation.
  • It will be Microsoft's model and framework for developing service-oriented business applications.
Indigo is Microsoft's next-generation code base for developing services. It will deliver a programming model and messaging implementation based on the service-oriented concept of contracts, messages, channels and services. It will support more secure, reliable, transacted information exchange and capability invocation, compliant with the declared exchange policies of the participating organizations.

Parting Thoughts
As a developer it's your responsibility to build the next generation of applications and, if industry predictions are correct, these will be built on Service Oriented Architectures. To prepare yourself for your next application development effort start:

  • becoming more familiar with the underlying specifications and technologies that make Web Services work;
  • learning more about the business and industry you work in;
  • developing secure Web Services by downloading the WSE 2.0 bits from Microsoft's web site;
  • understanding some of the architectural issues that need to be addressed to make the services you create more consumable and efficient.
Start by identifying some simple points of integration in your organization that could benefit from lightweight interoperable connectivity and create a Web Service that exposes some aspect of the system. Then, start layering on things like security and transactions. By taking small, incremental steps you'll be able to begin to develop the skills required to implement more robust and purposeful services as your organization's architecture moves toward SOA.

Hopefully you now have a clearer understanding of the relationship between SOA and Web Services as well as what you need to do to be productive when developing services-based applications!

More Stories By Michael Pelletier

Michael Pelletier is a
consultant with Pinnacle Decision Systems (www.pinndec.com), a
privately held professional services and software development company in Middletown, Connecticut. The company helps design and develop
Internet-based business intelligence systems
incorporating client/server and data warehousing applications.

Comments (5) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
cobol guy 04/12/05 12:11:41 PM EDT

stop with this SOA b.s. I'm still coding in COBOL

Anti-SOA 04/12/05 11:48:42 AM EDT

Joe, don't sweat it, there is no such thing as SOA, it will die, just let it be ...

jesse 03/25/05 12:52:20 PM EST

"Seriously, though, if you don't understand the article, chances are you are not the intended audience."

Why? It reads like the typical MS advertisement. Complete
with all the MS product URLs...

Jeff 03/25/05 12:42:17 PM EST

Joe commented on 23 March 2005:
Oh my god, this soup of buzzwords, platitudes and fuzziness is called an article??? If so, than I don't care being left behind. Just wonder who is the targeted audience for this?

Sorry, Joe, but I believe the article is targeted at people that can speak english. Seriously, though, if you don't understand the article, chances are you are not the intended audience.

Joe 03/23/05 04:46:05 AM EST

Oh my god, this soup of buzzwords, platitudes and fuzziness is called an article??? If so, than I don't care being left behind. Just wonder who is the targeted audience for this?