 |
|
Is this the year of Policy?
I'm off to IMPACT,[http://www-306.ibm.com/software/websphere/events/impact2008/] IBM's conference and there seems to be a lot of buzz.
Policy holds a lot of promise for SOA realizations....two great things. Policy. SOA.
Policy - statements of requirements.
SOA - service artifacts to improve efficiency and reuse.
Here are some observations: there are still active debates on what constitutes a "service". We all have an intuitive reaction to the word, service, but how do we get past intuition into something that is more commonly understood? There are many actions that an individual can do and anyone can write stand-alone code. But an individual can't do everything. Likewise individual pieces of code can implement actions, but it's sometimes a better "value" to encapsulate a set or already defined actions into a service...the SOA food chain. Oh yeah, and standards, because if we're going to have services depend on each other, its good to have some understanding of the contract.
So, OK, services are a good thing, what does it mean to be "service oriented"? The intuitive response to "oriented", is to get directions or to steer. And in the services jungle, it means getting bearings, or making a decision. This is a big feature of SOA, the ability to make different choices. To do this, its important to know the decision criteria. Enter policy. There's a whole world of services out there in the big bad internet. So how do I orient myself to pick the service that meets my requirements and doesn't expose me to undue risk?
Thinking "architecturally" about making a service generally available, has to include explaining what the service is, and explaining under what conditions the service can be engaged. One of the fascinating aspects of communication between service components in SOA, to me is the level of abstraction. Is this communication expected to happen at the business level ?( in which case we need natural languages for policy expressions) or is this expected to happen at a detailed code level ( in which case we might need more structured languages for policy expressions). Most likely its a combination of both. So we will need to define ways to translate between business requirements and IT requirements. Looks to be a good conversation.
Some questions: What does a policy expression need in order to provide guidance in SOA decision making? Can one form of policy expression communicate information critical to business and IT? If I expect to use a service often, under varying conditions, can policy create predictive routes for business services? What is the level of trust that I'm expecting in this guidance?
Should be an interesting adventure. I'll try to do a daily post.
Categories
: [ IMPACT | Policy | SOA ]
Apr 04 2008, 04:47:19 PM EDT
Permalink
|
|
Diving in to the blogosphere
The difficult thing about blogging, is knowing when and where to dive in. So, I'm going to start with a little career background and then try to pick up a thread or two in future entries. I saw the potential benefit of Web Services and I was involved in many of the standards as early as 2000 to make sure it aligned with IBM long term business strategy, it is very heart warming to see how it is being adopted today in SOA. Having worked on security in operating systems (UNIX at Bell Labs) and distributed computing (DCE at HP) I started in Lotus working on Java client security. I went to work in Emerging Technologies under Rod Smith initially participating in some of the early browser security investigations, working with Tony Nadalin and Larry Koved. With colleagues in Raleigh, I began prototyping the "publish, find, bind" pattern for services and it led to the UDDI Universal Business Registry, and on into the UDDI speicifcations. Throughout, I was on point for working with research folks in the security area, and worked closely with Hiroshi Maruyama and Michiahru Kudoh in XML security which led me to be involved with Web Services.
Hiroshi, Tony and I began discussions with colleagues at Microsoft, when we realized that we each had thought about adding security to SOAP messaging models but in a slightly different way. The result was the Web Services Security Roadmap and a set of specifications; WS-Security, WS-Policy, WS-Federation, WS-Trust, WS-Secure Conversation. After working toward reference implementations and beginning the standardization process for the various proposed specifications in the W3C and OASIS, I went into the Enterprise Integration Services group under Ed Kahan. There I had the experience of working with customers on the early days of SOA which was enlightening. While in the field I started collecting security patterns and worked with a team of security folks and Jonathan Adams on trying to integrate security into the E-business patterns. Unfortunately, this never saw the light of day and I hope to add to the blog about some of this going forward. With the acquisition of Data Power, I thought it would be exciting to see many of these initiatives come together in an appliance form.
Now I'm trying to build a community around SOA policy, using the new work in DP, Tivoli and WS-RR as an illustration of pragmatic SOA policy. I'll use this blog to explore policy topics and I'm hoping that my colleagues will join in because policy is really the representation of a set of shared requirements. It should be fun.
Categories
: [ Policy | SOA | Security | Services | WS-Policy | WS-Security | Web ]
Mar 25 2008, 01:45:01 PM EDT
Permalink
|
|
|
| S | M | T | W | T | F | S | | | | 1 | 2 | 3 | 4 | 5 | | 6 | 7 | 8 | 9 | 10 | 11 | 12 | | 13 | 14 | 15 | 16 | 17 | 18 | 19 | | 20 | 21 | 22 | 23 | 24 | 25 | 26 | | 27 | 28 | 29 | 30 | | | | | | | | | | | | | Today |
|
Policy, WS-Policy, SOA Policy
