I’ve been working on integrating social media into my service composition work. My advisor suggested it as a way to add a little more kick to the work. I’m sure the fact that he’s teaching a class on social networks this semester has a little something to do with it as well.

The concept is pretty easy — find the pages for service providers on a social network, mine the information available to make a judgment about how that provider compares to others. I expected the hard part to be learning the APIs well enough to retrieve the information from the networks. Oddly enough, it seems that’s the easy part. The hard part is finding APIs for the various networks.

I decided to start with the 800 pound gorilla of social networking, Facebook. There’s an excellent and dead-simple API called RestFB that does everything I need and is easy to use. But because I”m (nominally) working with business services, I thought that looking to sites devoted to business reviews would be a good next step. Yelp was not a disappointment; they also have an easy-to-use search API. (These are both REST APIs, but are easy to use with thick clients as well.)

But that’s about it. Angie’s List doesn’t have a public API available, and don’t get me started on trying to learn anything from the Service Magic site — don’t waste your time on it. I still need to look at other organizations like the Better Business Bureau, but it looks like there’s not much out there for my purposes beyond Facebook and Yelp (I don’t want to get into trying to divine emotions from Twitter — that’s someone else’s dissertation.)

At the same time, I’m learning the Manchester OWL API so I can query an ontology to find potential service providers and read in their social network IDs. Luckily, the OWL API is also proving pretty easy to use.

But for now, I’ve managed to figure out how to find the service providers in an ontology, read in their Facebook ID, and get the number of “Likes” for that business from Facebook. Not too bad for a week’s work, given that I’m not a real programmer and I’m holding down a full time job.

I met with my advisor about 10 days ago as the new semester started, and we discussed adding social network aspects to the paper I’m working on for the SRII Conference. So I’ve spent some time learning the APIs for Yelp and Facebook (as a start).

The good news is that the APIs don’t seem all that complex. Well, the Yelp API isn’t that complex; I haven’t worked with the Facebook API enough to make a judgment. Complicating the fact is that I’m writing thick client Java code, and these apps are both built on the assumption that it is other web sites that will be using their applications. The practical effect is that the responses I get are JSON objects that I’ll need to parse if I want to get at the information of interest to me. Not necessarily a difficult task, just a pain.

But I am making progress, so that’s a good thing.

A little over a week ago I received notification that my paper was accepted for the 28th International Conference on Data Engineering Workshop on Data-Driven Decision Support and Guidance Systems (hereinafter referred to as DGSS). The notification was a couple of days late, but the comments weren’t too bad, so I updated my paper and sent them the camera-ready copy this past Monday.

Another one down, two or three more to go! (I’m trying to make sure I’ve got plenty of padding in the publications department.)

But now the semester is over, and I still need to update my committee members on my progress. I supposed I’ll have to type something u pto send them, but I really need to sit down with them in the spring.

In the meantime, it’s back to work on defining a service description specification.

I spent the weekend working on my prototype implementation using some service agents I had kicking around from previous work. I added a “graph agent” that collects information from the various service agents and assembles them into a directed graph for further analysis. Building the initial graph turned out to be pretty easy. There’s a very easy-to-use directed graph library called JGraphT that made the task pretty simple.

Now comes the hard part: verifying that the graph is correct. The easiest way to do that is to see it, so I followed the recommendation on the JGraphT site and downloaded the JGraph library. It’s a commercial product, but it does have a free license for non-commercial use.Unfortunately, the latest version (called JGraphX) doesn’t have a simple importer for the latest version of JGraphT, but the previous version, JGraph v5, still works pretty seamlessly wiht JGraphT. It wasn’t too hard to get the graph to display in a window, but figuring out how to do it with a reasonably useful layout is proving tricky. By default, it lays out with all of the vertices stacked on top of each other. But it is a start.

Now I need to troubleshoot why the edges aren’t behaving the way I expect them to; only some of them are correct. I think I’ve got an idea, but it will take a little time to code up and check. But in the meantime, I am making progress.

I survived the mad rush to complete that paper in 96 hours. I successfully submitted it and now I’m waiting to hear whether it was accepted or not. My advisor told me it was a good job and he liked the final product, so that was good news. There were 14 papers submitted for that particular workshop. It’s a one-day event, so I expect there will be about 7 papers selected. Those aren’t bad odds.

I spoke to my advisor this past Friday and he told me again that he thought it was a good paper, so I’m cautiously optimistic about my chances of being accepted. In the meantime, I have begun some implementation work to try and show the work i described in the paper. I’m successfully parsing a BPMN model and launching individual agents for each task in the model, so I’m off to a decent start. Now I am trying to figure out how to assemble the discovered services into a connected graph. I’ve got a couple of ideas, but I need to mull them over a little more.

In the meantime, I still have a fighting chance of completing my research by the end of the spring semester.

I told my advisor I’d have him a draft of a paper within 48 hours. I think that was pretty reasonable given that he decided we should submit only 96 hours before the deadline.

I just mailed him a solid first draft. It’s reasonably smooth, although I’m not completely happy with it. I haven’t gotten a good night’s sleep in a couple of days, but I think I can relax this evening and try to get caught up on my rest. I’m going to need to get back at it early tomorrow, so I’ll need my rest.

Still, I feel like I’ve done a pretty good couple of days’ work.

I missed my weekly meeting with my advisor last week because of meetings at work that ran late. I didn’t mind much, because I hadn’t made a lot of progress on the task he set me the previous week. He asked me to look into devising a protocol that service agents could use to negotiate among themselves to offer better deals to potential users.

After looking into possible agent communication protocols, it was obvious that the Contract Net Protocol and Iterated  Contract Net Protocol published by Foundation for Intelligent Physical Agents (FIPA) met the needs of the mechanics of the communication if not the content. All of the work I could find that related to contract negotiation among agents used one of these protocols as the basis for their negotiation. So I turned my attention to the content of the communications, but I wasn’t making much progress.

Missing the meeting worked out well; I had a flash of inspiration earlier this week. I can use the Contract Net protocols for the mechanics of the communication, and on top of that I can layer a means for agents to know what other agents are in their potential workflow with them, then adjust their initial offer up or down based on their affinity for each of their neighbors.

I explained my idea to my advisor during out meeting this week, which went very well. In fact, it went a little too well. He liked the idea enough that he thought we could put together a paper for a conference whose deadline is “at the end of the month.” That’s the good news. The bad news is that deadline isn’t really the end of the month. It’s actually October 24. As in Monday; as in four days from our meeting yesterday.

So I spent a fair bit of last night writing furiously, and I’ll do the same tonight. I let my advisor know that unless the deadline has been moved the paper is due Monday, but I’d have him something within 48 hours.

It’s going to be a long night.

It has been way too long since I’ve updated this. I will be more diligent about it.

I’ve been meeting with my advisor weekly for most of this semester so far. Each time, I’ve fleshed out more and more of the details of how I’d like my research topic to shape up. At this point, I think I’m close to having a complete architecture that I can start working toward implementing to prove my ideas will work.

So far, I’ve laid out several items. First, a high-level architecture describing the main components needed to construct an automated workflow composition capability. Along with that, I’ve laid out the sequence of steps that those components need to execute to correctly parse through a BPMN model and pick out services needed to execute that workflow.

I’ve also specified some basic definitions and equations to capture the formal definitions and relations needed to compose services into workflows. And as of this week, I’ve detailed the major decision points necessary to compose services. This includes mapping services to individual activities in the process model, deciding which services can be composed together, how to analyze the quality of service attributes and recommend a choice of service compositions, and the factors to be considered when evaluating quality of service across complex workflows.

Now I need to specify the metadata that needs to be attached to a process model, plus an overall detailed architecture for the system. Luckily I did a fair bit of that work over the summer and I just need to formalize it.

One of the issues with earlier versions of BPMN is that they do not include a specific XML schema for describing a process. Version 2 resolves this with the inclusion of an XML schema as part of the standard. So I was really looking forward to BPMN 2, as it would make automated parsing and analysis of a BPMN model much easier and more predictable.

Unfortunately, the tools available for creating BPMN models don’t generally implement that specification just yet. Most BPMN tools claim to implement the BPMN 2 standard, but for the most part they implement the BPMN 2 graphical notation and not much else. Several of them include some variation of the XML standard with tool-specific extensions, which is of no particular help to me — I want to parse the standard to enable maximum portability. A fair number of tools save their models in XML Process Definition Language (XPDL); others use XML Metadata Interchange (XMI). While both of those are good standards for particular uses, neither one is ideal for my purposes. I would really like a design language that is accessible to business analysts, and that generally means a graphical notation.

The one bright spot on the scene is Sparx Enterprise Architect. I’ve used this tool in the past for various projects at work. It is an outstanding tool; unfailingly standards-compliant in my experience. And this time I was not disappointed — not only does the tool create BPMN 2.0 models, but it can actually save them in BPMN 2 XML. And the icing on the cake is that the price is dirt cheap. These days its running about $135 for a personal license; the “all you can eat” version tops out at just over $300. Compared to the thousands the competition charges, it just can’t be beat.

And most importantly (to me), the output is easy to parse. Now I just need to figure out how to add some extensions that will show up in the XML.

I have developed an initial service description ontology based on OWL-S. It is an initial version partly because it will doubtless evolve as I learn more from my research, but also because there are some missing pieces. Perhaps the most obvious of these, as I discussed in my presentation last week, is Quality of Service. Part of the reason QoS is missing is because it’s going to be complex to define and I’m not quite sure how to go about it.

I had planned to tackle QoS as the next part of my research; thinking that if I got something in there, no matter how basic, it would be progress. But the other day a thought occurred to me: Measuring and accounting for QoS in service selection is an optimization step — it is not fundamental to being able to compose services together.

So after thinking it over, I decided to take a more logical progression:

1. Determine how to relate a process model to a service description
2. Build a capability to do the service selection & matching and then execute the process
3. Define how to capture quality of service in the service description
4. Figure out how to optimize service selection with QoS as a factor in the selection

This will give me a chance to get some code running to prove that the basic idea is possible, and it will give me a chance to start generating some results I can use for comparison as I progress.

Now I just need to figure out how to relate a process description to service descriptions. I think I’ll be helped in this by the fact that OWL-S represents a service as a process. This might allow me to assert a certain equivalence between the idea of a service and the idea of a process. I’ll need to work on that.