|
Integrate SOA Portals With WSE
Use the ASP.NET 2.0 Web Parts framework and Web Services Enhancements (WSE) 3.0 to create a successful service-oriented architecture portal.
by Derek Harmon
October 28, 2005
Technology Toolbox: Visual Basic, C#, ASP.NET, XML, WS-Security, WS-Policy, Web Services Enhancements 3.0, Visual Studio .NET 2005
The service-oriented architecture (SOA) buzz around the industry comes from a groundswell of experience with enterprise application integration and the promise of Web services to fulfill the promise that SOM, COM, and CORBA never fully realized. Yet the advantages of using SOA aren't always plain to see until you need to pull together different services. I'll lead you through the design of a human-resources hiring portal that highlights patterns for successful SOA. I'll show you how to apply the portal integration pattern to aggregating Web services using the ASP.NET 2.0 Web Parts framework and Web Services Enhancements (WSE) 3.0.
Imagine a hypothetical staffing firm, ABC Staffing, responsible for placing educators in schools nationwide. After interviewing a promising candidate, an ABC employee must review that individual's references and licenses. This includes checking teaching credentials, university attendance and grades, and the existence of any criminal history. As you might imagine, this information comes in many formats and through many different providers.
Let's assume ABC Staffing achieved schema independence from the variety of record formats used by state agencies, universities, and law enforcement by selecting the HR-XML vocabulary to represent background reports in a single unified format. By choosing a widely adopted schema within your industry, the number of service providers you can build upon grows (see the sidebar, "Apply HR-XML," for more information on HR-XML applications). ABC Staffing has committed to a portal application for its hiring managers that pools together background reports received from several providers. As time goes by, new providers may replace old providers, so the solution needs to be easily reconfigurable.
The success of SOA relies upon a service-oriented marketplace, so let's focus on aggregating external services. In the ideal free market, countless providers sell interchangeable services, fair competition abounds, and there are no barriers to entry. Web services provide specifications regarding interoperability, identity, and policy for services based on industry experience.
Even without following these ideals, it's possible to aggregate a service building only upon services you have control over and that never leave the boundaries of your department. For instance, you can build internal services using domain accounts for authentication and Kerberos delegation to traverse intermediaries. However, this approach suffers from short-sightedness because it dresses Web services in many familiar trappings (and pitfalls) of Windows Distributed InterNet Architecture (DNA).
The reality is that all services evolve over time. You get greater flexibility over time by designing the solution to permit substitution of service providers. The service architectures you build with this flexibility in mind fit intranet or extranet situations equally well.
WS-Security: A Principle Cornerstone
Web Services Security (WS-Security) is one of the principle cornerstones of Web service specifications. The digital signature portion of WS-Security tells you that messages are from who they claim to be from (they are authentic). It also tells you messages have not been tampered with since they were signed (their integrity is assured). These two qualities indicate that the architects of Simple Object Access Protocol (SOAP) at the World Wide Web Consortium (W3C) and Organization for the Advancement of Structured Information Standards (OASIS) made security a fundamental value. Following the best security practices promoted by WS-Security helps you secure your applications more easily, although this doesn't mean security should slip your mind.
WS-Security includes encryption, which helps you keep the content of messages confidential and away from prying eyes. However, encrypting whole messages also defeats some benefits of service aggregation, so you should take this trade-off into consideration when you encrypt something.
Back to top
|