As a quick start, for those that don’t know, SO-Aware is a service metadata repository, very similar to UDDI, except without the complexity, all based on a REST-ful architecture. If you do know you can skip to the explanation of how it works, or skip to the how to section. It supports registry of SOAP, REST, and OData based services, written using Microsoft’s WCF technology stack, as well and Java based web services. However, that’s not all. SO-Aware has five major capability buckets: Centralized Configuration, Service Testing, Dependency Modeling, Activity Monitoring and last but not least Service Cataloging.
Centralized Configuration allows you take full advantage of Microsoft’s WCF based services, by containing a central repository database for all WCF Configurations. This feature allows you to allows you to store and retrieve all information pertaining to WCF configurations. You can retrieve endpoints, bindings, behaviors, Url’s, security information, just to name a few. You can also dynamically change your bindings and configurations so that all you existing services can point to this central location for your configuration.
Service Testing allows you to test registered services. One derived idea about Service Cataloging and Centralized Configuration, is that if SO-Aware knows about your service and communication protocol, then testing becomes simple. It’s simple because if you registered any security, binding, message type format information about the service, then all SO-Aware needs to do is query this information and build the communication stack and messages to send to the service for testing. What better tool to test than the one that understands how to communicate with the Service.
Dependency Modeling allows you to build a diagram of service versions, and the dependencies of the service version. Thus if you needed to see which services depended each other, you have a view into this.
Activity Monitoring allows you see tracked events and aggregations about registered services, such which operations were invoked, and how many services were sent message over a period of time, and many other dimensions and measurements.
Service Cataloging allows you to store and retrieve custom metadata about Services, Service Versions, and environment details. Using these features, allow you to query the catalog for information about services, and service versions dynamically.
Which leads us into the primary discussion of this post, How to Use AJAX and JQuery with SO-Aware. SO-Aware provides many API’s for retrieving and updating the registered information. As a developer you can use SO-Aware’s OData API’s, .Net API’s, Microsoft’s Windows PowerShell, and lastly Javascript, AJAX and/or JQuery API calls.
Recently, a customer asked if SO-Aware can be used with a Javascript client application. The Client wanted to build a web site that could use AJAX, and JQuery to retrieve binding, uri, and service version information. So naturally, when asked, we responded with an explanation and a “How-To” on how to do it. Thus I figured I’d share it with you all.
Underneath the hood, SO-Aware utilizes WCF Data Services to expose various API support for querying and updating registered services inside SO-Aware’s repository. WCF Data Services are based on a REST-ful architecture that uses OData feeds, to as its message protocol format. As a developer the quickest and simplest way to access SO-Aware is to use the REST styled Uri’s for its data. For example, to see a listing of Services registered inside SO-Aware, you could use a uri similar to http://localhost:8088/SO-Aware/ServiceRepository.svc/Services, as this would return an OData ATOM feed of all registered Services.
WCF Data services support a number of optional query parameters, also termed “query options” that allow access to the queried data through different options hanging off the end of the uri as query parameters. One option such as filter allows an application to filter the results based off a string function, math function, logical operator, or expressions. For example if you wanted to look for all services registered in SO-Aware with the versions greater than 1.0 you could write a query option filter as such: http://localhost:8088/SO-Aware/ServiceRepository.svc/ServiceVersions?$filter=MajorVersion ge 1 and MinorVersion gt 0 I’ll discuss more query options in another post, however to read about all supported query options, read the SO-Aware documentation.
One of the interesting decisions that the WCF Data Services team decided was to not enable support for a specific query option by default. This option is the $format option. By Default WCF Data services does not allow you to use the $format query option. This option allows developers and applications to change the format of the return data coming from a WCF Data Service. The $format option supports three types of formats: JSON, XML and ATOM. Not to worry here, we enabled this option for the SO-Aware service repository, thus you can choose which format you want to use. The way we enabled this option is similar to various blogs and posts on the subject matter, although we used a custom WCF Behavior instead. We only support two of the three formats: JSON and ATOM. Which shouldn’t be that big a deal since ATOM is xml anyway… By enabling this option, you can use AJAX, and JQuery with javascript clients to retrieve JSON based queries.
One of the main challenges with using AJAX and JQuery with web services is the security model around accessing remote services. Most AJAX implementations, flat outright do not support it, while others use some sort of “policy access” security file to allow specific Url’s for AJAX/JQuery access. One of the easiest ways to bypass the policy access or non supported impelementations is to use a “Bridge” methodology. A Bridge methodology is a simple idea. Because of security restrictions accessing remote services, the idea entails building a local server side AJAX/JSON formated supported web service which forwards the calls to the SO-Aware repository. By building the “Bridge”, it bypasses the security restrictions, and allows for the AJAX/JQuery client side interactions. In our SO-Aware SDK Samples, we have build an example “Bridge” using Microsoft’s ASP.Net, however Java Server Pages will work just as well. The project in reference is the JQueryAjaxSolution project. It’s code is really simple and straight forward.
Build an ASP.NET Bridge to wrap the SO-Aware ServiceRepository service for use with AJAX/JQuery clients.
Steps:
1. For you existing ASP.NET web site, that wants to use the JQuery and AJAX, add a new Asp.Net Web form to your site.
2. Add a WCF Data Service reference to your project. You can use the DataSvcUtil program, and point your reference to your install of SO-Aware.
3. Inside the Page_Load method add the following code:
1: protected void Page_Load(object sender, EventArgs e)
2: {
3: Response.ContentType = "application/json";
4: SOAwareService.ResourceRepositoryContext ctxt = new ResourceRepositoryContext(new Uri( "http://localhost:8088/SO-Aware/ServiceRepository.svc"));
5:
6: ctxt.Credentials = System.Net.CredentialCache.DefaultCredentials;
7:
8: var serviceName = Request.QueryString["ServiceName"];
9: var serviceVersion = Request.QueryString["ServiceVersion"];
10: var category = Request.QueryString["Category"];
11:
12: var services = ctxt.ServiceVersions
13: .Expand("Service")
14: .Expand("Soap")
15: .Expand("OData")
16: .Expand("Rest")
17: .Expand("ServiceDependencies")
18: .Expand("DependantServices")
19: .Expand("TrackingProfile")
20: .Expand("ConfigurationCategory")
21: .Where(sv => sv.Name == string.Format("{0}({1})", serviceName, serviceVersion) && sv.ConfigurationCategory.Name == category);
22: var service = services.FirstOrDefault();
23: var serviceId = service.Id;
24:
25: HttpClient client = new HttpClient("http://localhost:8088");
26: client.TransportSettings.Credentials = CredentialCache.DefaultCredentials;
27: HttpRequestMessage req = new HttpRequestMessage("GET", string.Format("/SO-Aware/ServiceRepository.svc/ServiceVersions(guid'{0}')?$expand=Service,Soap,OData,Rest,ConfigurationCategory,ServiceDependencies,DependantServices,TrackingProfile&$format=json", serviceId));
28: var result = client.Send(req);
29: Response.Write(result.Content.ReadAsString() );
30:
31: }
32: }
4. At this point you have a “Bridge” based off an ASP.NET web page that supports JSON, AJAX and JQuery.
5. Now open up your web page that needs to use JQuery or AJAX, or create a new web page.
6. Include your JQuery and AJAX javascript files.
7. Type your JQuery code, here’s an example:
1: <script id="jquerySample" type="text/javascript" >2: function GetData() {3: jQuery.ajax(4: { url: String.format("webform1.aspx?Servicename={0}&ServiceVersion={1}&Category={2}",5: ServiceName.value, ServiceVersion.value, Category.value),6: type: "GET",7: dataType: "json",8: success: function (data, textStatus, XmlHttpRequest) {9: Details.innerHTML = "<p>JSON: " + JSON.stringify(data, null, '\t') +"</p>";10: }11: });12: }</script>
2: <h2><% ViewData["Message"]%></h2>3: <p>4: To learn more about ASP.NET MVC visit <a href="http://asp.net/mvc" title="ASP.NET MVC Website">http://asp.net/mvc</a>.5: </p>6: <p>SO-Aware AJAX Jquery Sample</p>7:8: <p>Type In SO-Aware URL:</p><input type="text" id="SOAwareUrl" />9: <p>ServiceName:</p><input type="text" id="ServiceName" />10: <p>ServiceVersion:</p><input type="text" id="ServiceVersion" />11: <p>Category:</p><input type="text" id="Category" />12: <p><input type="button" id="SendResults" value="Resolve Service Endpoint Information" onclick="GetData()"/></p>13: <p>Details:</p><span id="Details" style="background: azure; width=180px; height=120px" />
8. You’re done, You have a Bridge ASP.NET web page that supports JQuery and AJAX clients.
9. 
10. 
D Goins Insperience 