Integrate SOA Portals With WSE (Continued)

For these reasons, the client X.509 certificate identifying your user (for example, the hiring manager at ABC Staffing) is what you register with your service providers to prove you requested their service (for billing and privacy purposes, these are all of the claims the service providers are concerned about). Authenticating the partner with whom you're exchanging messages is greatly simplified whenever you can offload the burden of trust onto a third-party issuer that both consumers and service providers can count on. Your application sheds itself of the administrative overhead involved with maintaining private identity stores and dealing with trust boundaries in your architecture.

I've spoken a lot about security and by now, you're probably expecting to see a lot of code. This is where WS-Policy comes in. Authentication, encryption, and integrity of messages are design qualities SOA should have, but you don't have to pay for them with a lot of code. This is especially important because your requirements, and the service providers you choose, might change tomorrow.

WS-Policy makes these services configurable. This standard defines the structure of policy configuration files. Place a list of policy assertions about the messages being sent—such as whether they are secure, digitally signed, and/or encrypted—in these files. The client-side policy configuration file for your portal application ensures that every outgoing request message to a service provider includes your client X.509 certificate to identify the request as legitimately coming from you (see Figure 2).

The corresponding policy configuration on the service provider's side insists that all incoming requests have an authentic and valid X.509 certificate, and any that don't return a SOAP fault immediately. Add this capability to your Web service by checking the "Enable Web Services Extensions" from the WSE 3.0 Settings... dialog in Solution Explorer. This checkbox enables the scanning of incoming SOAP headers with extensions registered by WSE and adds this valuable and supportive substrate to a service provider application.

Don't worry if the XML in the policy configuration file appears overwhelmingly complex at first. WSE dialogs guide you through settings important to your client or service provider and produce a proper configuration. You need to know only the answers to the design questions relevant to your application, such as those regarding authentication, integrity, encryption, transport protocol, and so on.

Take a Bird's-Eye View of Your Portal
Your portal is designed to aggregate three background reporting agencies responsible for feeding it information on a candidate's criminal record, educational history, and teaching license status (see Figure 3). The URLs of these end points are set up in your Web services' configuration, so you can change them when business demands warrant. Right now, each provider is implemented as WSE-enabled ASMX Web services retrieving records based on the candidate's name, and each returns a canned HR-XML conformant response.

Between these three services and the hiring manager stands an ASP.NET portal application that integrates separate background reports into a single view. You accomplish portal integration through custom Web Parts (see the sidebar, "Portal Integration vs. Data Integration Pattern," for an explanation of why the portal integration pattern fits best, and when to consider alternative patterns).

Two types of user-interface elements fulfill a Model-View-Controller architecture for this portal. The custom SearchWebPart is the controller responsible for making Web service requests and presenting hiring managers with a list of candidates whose credentials are checked. A variety of specialized ContentWebParts specialize in presenting their view of a portion of HR-XML, which they're responsible for transforming into HTML. The model spans your aggregation of Web services from different providers.

Public methods exposed on the ContentWebParts can receive IXPathNavigable objects representing an HR-XML background report. The methods transform this report into HTML using an XslTransform from the SearchWebPart (controller). In the Web Parts architecture, you express your willingness to receive objects from other Web Parts by annotating a GetInterface method with the ConnectionConsumerAttribute that names the connection between the Web Parts your ContentWebPart wishes to consume. On the other end, your SearchWebPart exposes a ProvideInterface method marked with the ConnectionProviderAttribute that provides objects to the named connection.

Enterprises are turning increasingly to SOA, expecting to deliver greater flexibility and reduce costs. Hopefully I've introduced you to the architectural decisions that go into making a sound, reusable service-oriented architecture that tackles real business problems. Moreover, you have seen the value both WS-Security and WS-Policy provide service architects by securing information and relieving you from building the infrastructure so you can build solid services.

About the Author
Derek Harmon is an R&D engineer at Infragistics and is responsible for the design and development of grid-related ASP.NET presentation-layer elements. Derek is an IBM Certified Solutions Developer in XML & Related Technologies and has more than five years of experience in XML and .NET development.