Archive for March, 2009
Governing Anonymous Service Consumers
On Friday, the SOA Chief (Tim Vibbert), Brenda Michelson, and I had a conversation on Twitter regarding SOA governance and anonymous service consumers. Specifically, how do you provide run-time governance for a service that is accessed anonymously?
If you’ve read this blog or my book, you’ll know that my take on run-time SOA governance is the enforcement and/or monitoring of compliance with the policies contained within the service contract. Therein lies the biggest problem: if the service consumer is anonymous, is there a contract? There’s certainly the functional interface, which is part of the contract, but there isn’t any agreement on the allowed request rates, hours of usage, etc. So what do we do?
The first thing to recognize is that while there may not be a formal contract that all consumers have agreed to, there should always be an implied contract. When two parties come to the table to establish an agreement, it’s likely that both sides comes with a contract proposal, and the final contract is a negotiation between the two. The same thing must be considered here. If someone starts using a service, they have some implicit level of service that they expect to receive. Likewise, the service provider knows both the capacity they currently can handle as well as what how they think a typical consumer will use the service. Unfortunately, these implied contracts can frequently be wrong. The advice here is that even if you are trying to lower the barrier for entry by having anonymous access, you still need to think about service contracts and design to meet some base level of availability.
The second thing to do, which may seem obvious, is to avoid anonymous access in the first place. It’s very hard to enforce anything when you don’t know where it’s coming from. Your authorization policy can simply be that you must be an authenticated user to use the service. Even in an internal setting, having some form of identity on the message, even if there are no authentication or authorization policies, becomes critical when you’re trying to understand how the systems are interacting, perform capacity planning, and especially in a troubleshooting scenario. Even services with low barriers to entry, like the Twitter API, often require identity.
The next thing you should do is leverage a platform with elasticity. That is, the available capacity should grow and shrink with the demand. If it’s anonymous, and new consumers can start using it simply by getting the URLs from someone else, you have no control over the rate at which usage will scale. If the implied level of availability is that the service is always available, you’ll need on-demand resources.
Finally, you still need to protect your systems. No request is completely anonymous, and there are things you can do to ensure the availability of your service against rogue consumers. Requests will have source IP addresses on them, so you can look for bad behavior at that level. You can still do schema validation, look for SQL injection, etc. In other words, you still need to do DoS protection. You also should be looking at the usage metrics on a frequent basis to understand the demand curve, and making decisions accordingly.
The Role of the Service Manager
Tony Baer joined the SOA Consortium on one of its working group conference calls this week to discuss his research on connections between ITIL and SOA. Both he and Beth Gold-Bernstein have blogged about the call, Beth focusing on the broader topic of SOA and ITIL, and Tony talking about the topic of service ownership, as these topics were the meat of the conversation between Beth, Tony, and myself.
I’ve spent the past few years thinking about all things SOA, and recently, I completed the ITIL v3 Foundations certification and have been doing a lot of work in the ITIL/ITSM space. When you move away from the technology-side of the discussion and actually talk about the people and process side of the discussion, you’ll find that there are significant similarities between ITIL/ITSM adoption and SOA adoption. Tony had a diagram in his presentation that illustrated this that Beth reproduced on her blog. Having looked at this from both the SOA world of the application developer and the ITIL/ITSM world of IT operations, there’s a lot that we can learn from ITIL in our SOA adoption efforts. Foremost, ITIL defines a role of Service Manager. Anyone who’s listened to my panel discussions and heard my answer to the question, “What’s the one piece of advice you have for companies adopting SOA?” you’ll know that I always answer, “Make sure all your services have owners.” I’ve decided I like the term “Service Manager” better than “Service Owner” at this point, but if you refer to past posts of mine, you can think of these two terms synonymously.
So what does a service manager do? Let’s handle the easy one. Clearly, service management begins with the initial release of the service. The service manager is accountable for defining this release and putting the project in motion to get it out the door. This involves working with the initial service consumer(s) to go over requirements, get the interface defined, build, test, deploy, etc. Clearly, there’s probably a project manager, developers, etc. helping in the effort, but in a RACI model, it’s the service manager who has accountability. The work doesn’t end there, however. Once the service is in production, the service manager must be receiving reports on the service utilization, availability, etc. and always making sure it meets the needs of the consumer(s). In other words, they must ensure that “service” is being provided.
They must also be defining the next release of the service. How does this happen? Well, part of it comes from analysis of current usage, part of it comes from external events, such as a merger, acquisition, or new regulations, and part of it comes from seeking out new customers. Some consumers may come along on their own with new requests. Reading between the lines, however, it is very unlikely that a service manager manages only one service. It is more likely that they manage multiple services within a common domain. Even if it is one service, it’s likely that the service has multiple operations. The service manager is the one responsible for the portfolio of services and their operations, and trying to find the right balance between meeting consumer needs and keeping a maintainable code base. If there’s redundancy, the service manager is the one accountable for managing it and getting rid of it where it makes sense. This doesn’t negate the need for enterprise service portfolio management, because sometimes the redundancy may be spread across multiple service managers.
So what’s the list? Here’s a start. Add other responsibilities via comments.
- Release Management (a.k.a. Service Lifecycle Management)
- Production Monitoring
- Customer (Consumer) Management
- Service Management
- Marketing
- Domain Research: Trends associated with the service domain
- Domain-Specific Service Portfolio Management
Think hard about this, as it’s a big shift from many IT organizations today. How many organizations have their roles strictly structured around project lifecycle activities, rather than service lifecycle activities? How many organizations perform these activities even at an application level? It’s a definition change to the culture of many organizations.
SOI versus SOA
Anne Thomas Manes’ “SOA is dead” post back at the beginning of the year sparked quite a debate, which is still going strong. On the Yahoo SOA group, the question was asked on exactly what Anne meant by SOI, or Service-Oriented Integration. Here’s my response:
SOI, service oriented integration, is probably best stated as WSOI- Web Services Oriented Integration. It’s simply the act of taking the same integration points that arise in a project and using web services or some other XML over HTTP approach to integrate the systems. Could this constitute a service-oriented application architecture? Absolutely, but in my mind, there is at best incremental benefits in this approach versus some other integration technology.
Because the scope is a single application, it’s unlikely that any ownership domains beyond the application itself were identified, so there won’t be anyone responsible for looking for and removing other redundant service implementations. Because the scope of the services involved didn’t change, only the technologies used, it’s unlikely that the services will have any greater potential for reuse than they would with another integration technology except that XML/HTTP will be more interoperable, than say, Java RMI, if that’s even a concern. To me, SOA must be applied at something larger than a single application to get anything better than these incremental gains. Services should be defined along ownership domains that create accountability for driving the redundancy out of the enterprise where appropriate.
This is why an application rationalization effort or application/service portfolio management is a critical piece of being successful. If it’s just a “gut feel” that there is a lot of waste in the IT systems, arbitrary use of a different integration technology won’t make that go away. Only working to identify the areas of redundancy/waste, defining appropriate ownership domains, and then driving out the redundancy through the use of services will make a significant difference.
Kindle 1 vs. Kindle 2
Those of you that follow me on Twitter know that my Kindle 1 recently suffered an untimely demise. I had the option of purchasing a refurbished Kindle 1, or getting the new Kindle 2, and I opted for the latter. I thought I’d highlight some of the differences that I’ve noticed for those of you that are considering upgrading and giving your Kindle 1 to another family member or friend.
Ergonomics. Like many Kindle 1 owners, I frequently would pick the device up and hit the next page button, or have it in its case and open it up to find that I had pressed the menu button a few times. That same feature, however, was a plus when I was actually using it. You can hit those buttons just about anywhere and they will respond. In addition to those buttons, the power switch and wireless switch on the back of the device were simply inconvenient. Outside of the buttons, the device had a bit of a flimsy feel to it. While I never had any problems with it, durable would not be the word that would come to your mind. At the same time, the actual shape of the device and its weight was very book-like, which was appealing.
The Kindle 2 is very different. It is much thinner and feels much sturdier. At the same time, there’s a lot more “whitespace” around the screen, which is essentially wasted space. I would have preferred to add thickness rather than width. There’s no problems with accidentally hitting the next page buttons, and the power switch was moved to the top of the device, making it accessible when the device is in its case. The wireless switch was removed entirely and must now be controlled through a menu (I preferred having the physical switch). On the downside, the buttons aren’t as easy to press as on Kindle 1. I was accustomed to hitting the outside edge of the button, which works very well when on an elliptical trainer in the gym, and that won’t work with Kindle 2. You have to press the face of the button. Second, the changes in shape do make the device less book-like, especially when it’s not in its case. With the case on (the Amazon one, which must now be purchased separately), it was less of an issue. Finally, while it is an extra purchase, the latching mechanism for hooking it into the new case is much better. I have not had any issues with it falling out of the case.
Usability/Performance. I really didn’t have any issues with the performance of my Kindle 1. Yes, there’s the flash associated with page turns, but that’s an artifact on any e-reader that uses the eInk technology. Some people felt that there would be too much page flipping, but it didn’t bother me at all. The Kindle 2 performance is noticeably faster, but as I often tell people when discussing performance, the Kindle 1 was already good enough, so this wasn’t a big deal. The second improvement on the Kindle 2 is better grayscale support. If you’re using the Kindle to read technical documents, which I do, then I think this is something that you might find important. The Kindle 1 could only do 4 shades of gray, the Kindle 2 can do 16, and this does make a different. For reading fiction, this is less of an issue. Finally, the Kindle 1 had a mirrored scrollbar that ran parallel to the vertical axis of the screen. You used a scroll-wheel to position it, and clicked it to select. The Kindle 2 replaced the scroll-wheel with a joystick, and did away with the mirrored scrollbar. I assume it’s because the performance of the screen improved, so they felt the scrollbar wasn’t needed. Personally, I liked the scrollbar better. Again, it’s not a huge deal though.
Overall, the Kindle 2 verified my initial thoughts from the original announcement. It’s definitely an incremental improvement, but I don’t think the feature set associated with it is compelling enough for someone to ditch/sell their Kindle 1. There are still some things to work out, such as getting the ergonomics around those page buttons a bit better so they’re still very convenient, but not easily clicked by mistake. If you’re considering a Kindle 2 as your first e-reader, I absolutely recommend it. I love the reading experience on it, I love being able to manage my documents via Amazon, I like that it syncs up where you are within a book if you also have the iPhone Kindle app, and the convenience of the wireless modem for purchasing new content whenever and wherever (if you’re in the US) is great.
Is Twitter the Cloud Bus?
Courtesy of Michael Coté, I received a
Speaking of the RIA Weekly podcast, thanks to Ryan Stewart and Coté for the shout-out in episode #46 about my post on RIAs and Portals that was inspired by a past RIA Weekly podcast. More important than the shout-out, however, was the discussion they had with Jeff Haynie of Appcelerator. The three of them got into a conversation about the role of SOA on the desktop, which was very interesting. It was nice to hear someone thinking about things like inter-application communication on the desktop, since the integration has been so focused on the server side for many years. What really got me thinking was Coté’s comment that you can’t build an RIA these days without including a Twitter client inside of it. At first, I was thinking about the need for a standard way for inter-application communication in the RIA world. Way back when, Microsoft and Apple were duking it out over competing ways of getting desktop apps to communicate with each other (remember OpenDoc and OLE?). Now that the pendulum is swinging back toward the world of rich UI’s, it won’t surprise me at all if the conversation around inter-application communication for desktop apps comes up again. What’s needed? Just a simple message bus to create a communication pathway.
In reality, it’s actually several message buses. An application can leverage an internal bus for communication with its own components, a desktop/VM-based bus for communication with other apps on the same host, another bus for communication within a local networking domain, and then possibly a bus in the clouds for communication across domains. Combining this with Coté’s comment made me think, “Why not Twitter?” As Coté suggested, many applications are embedding Twitter clients in them. The direct messaging capability allows point-to-point communication, and the public tweets can act as a general pub-sub event bus. In fact, this is already occurring today. Today, Andrew McAfee tweeted about productivity tools on the iPhone (and elsewhere), and a suggestion was made about Remember The Milk, a web-based GTD program with an iPhone client, and a very open integration model which includes the ability to listen to tweets on Twitter that allow you to add new tasks. There’s a lightweight protocol to follow within the tweet, but for basic stuff, it’s as simple as “d rtm buy tickets in 2 days”. Therefore, if someone is using RTM for task management, some other system can send a tweet to RTM to assign a talk to a Twitter user. The friend/follower structure of Twitter provides a rudimentary security model, but all-in-all, it seems to work with a very low barrier to entry. That’s just cool. Based on this example, I think it’s entirely possible that we’ll start seeing cloud-based applications that rely on Twitter as the messaging bus for communication.
