Here's a sketch for my sessions on day two of our upcoming SOA Executive Forum. As always, I'm eager for input. You can blog something that links back here, or use the email link on this blog. Something I forgot to mention in the day one writeup: if you email me questions or comments, please indicate whether it's OK for me to add them to these writeups.
In this session we'll hear from two developers who've built SOA-style: Furrukh Khan and Scott Hanselman. You can read a bit about both of them in our recent cover story on SOA. They'll drill down in a pair of presentations, and then we'll follow up with Q and A.
In principle SOA enables a flexible, consistent, and policy-driven security strategy. In practice there are a lot of pieces in that puzzle. We'll try to fit them together.
Externalizing security code. We know that security code should be factored out of applications and placed into declarative policies. But how do you accomplish that refactoring? And where do the policies live? In your repository? Your gateway? Your ESB, web-services management system, or "fabric"? j
Role of gateways and appliances. What are the current tradeoffs between software and hardware techniques? Do you need deep XML packet inspection? How do you detect and react to not merely individual events, but correlated clusters of events? How can policy-driven inspection adapt dynamically to changing circumstances?
The role of WS-* standards. As Mark Vordel's blog points out, WS-Security as used for message authentication plays a very different role than WS-Security for integration among security products. How do you navigate the sea of SOA security standards?
Sub-document security. SOA's coarse-grained messaging style anticipates workflows that expose different pieces of payloads to different people. WS-Encryption and WS-Digital Signatures supply the means to do that. But the problems cited in the famous paper Why Johnny Can't Encrypt still persist. Are we getting any closer to making sub-document security a practical reality?
From William Henry: Cross-platform security:
Modern SOA implementations in large organizations are likely to include multiple platforms: mainframes, Java, CORBA, .NET, COM, MOM, EAI, etc. With even a small mix of the above technologies a SOA may have to facilitate the propagation of security contexts/credentials from one technology/platform to another. It would be useful if your talk discussed this topic, perhaps by use of a scenario where a .Net client signs on and needs to be authenticated and authorized right through a J2EE based servlet or bean and on to a backend mainframe based CICS transaction.
See also additional comments from panelist Mark O'Neill.
In this session I'll review and exand on the themes covered in our recent cover story on SOA, and address follow-up questions to a panel of industry experts. Topics will include:
WS-* standards and user requirements. Some say the WS-* cart got ahead of its horse. Others argue things couldn't have unfolded any other way. Is this just water under the bridge, or will the growing demand for business-aligned SOA rekindle the debate?(1)
Blueprints and frameworks. SOA is both a way of thinking and a way of doing. Blueprints and patterns can help us understand best practices for SOA design; tools and frameworks can encapsulate those best practices and make them readily usable. How can these approaches work together?
WS-Heavy, WS-Lite, and WS-Just-Right. WS-Heavy is the formal WS-* stack. WS-Lite refers to such technologies as AJAX, REST, and POX (plain old XML). WS-Just-Right means using the right tool for the job, and we'll explore some examples.
The RSS data web. Your business's core services are supported by SOA infrastructure, but they are contextualized by vast flows of semi-structured and unstructured documents. How can your SOA infrastructure integrate with and help you manage those information flows?
From Neil Ward-Dutton: Developers and operations staff:
There's a real need to look beyond the development perspective of SOA to consider the operational/management side of the idea. SOA is all about services, right...? And in the world of IT management automation, people are talking about IT Service Management, Service Level Management etc, aren't they? So the killer question is - how do these views come together? Are the developer-focused and ops-focused industry communities talking about the same kinds of services when they use these phrases - and if not, how do their concepts map together?From (name withheld by request): Big companies, small companies:
What about SOA migration practices and paths? Re-architecting to a WS + SOA is a big undertaking. How is all this justified? How many companies have even done first-gen WS effectively, or I'm wondering, are there a lot small efforts "their way" (POX, REST-like, a couple try and see internally used WS's)? And now we have coming out next gen WS, WFC, SOA architecture projects, etc., all sounding more complex to me.
My situation is how do we move to something like this, with limited resources allocated to these efforts. I'm in a small company as a single .NET/SQL developer with SQL DBA coworker. There are other developers here still devoted to our CICS/COBOL legacy system. We've done some HTTP based REST-like integration .NET->mainframe, and are in an industry that looks to move forward and do some SOA/WS type stuff, but it's not happening over night.
Maybe I'm coming from the small shop that tries to play with and be like the boys perspective, and your audience is big shopper IT with more resources.
People are the exception handlers of last resort in all SOA workflows. So we need to connect services not merely to one another, but also to people at their desks and on the move. Our panel of experts represents a variety of approaches. Topics will include:
Binary XML for small-memory devices. Infoset-preserving binary XML isn't only a way to cut down on XML's bandwidth. It also helps your applications run on PDAs.
The AJAX-style browser-based SOA client. How capably can the modern browser perform as an autonomous services client?
The role of "rich Internet application" runtimes: Flash, Java, Dot-NET. When the browser won't cut it, how do these alternatives stack up as consumers of services?
Towards peer-to-peer SOA. Microsoft's Indigo is a good example of an advanced SOA substrate that can run identically on servers and clients. What are the opportunities for a peer-to-peer SOA that can produce and consume services throughout the network?
Todd Biske has useful comments on various topics.
1Warning: Do not read this while drinking coffee or you might spritz your keyboard.
Former URL: http://weblog.infoworld.com/udell/2005/10/25.html#a1328