As part of my SOA class, we are currently going over some of the principles of service design. In particular, we were going over the principle of abstraction.  The example of technology abstraction that I used in class was a remote control.

The funny thing for me has been just recently my 10+ year old Pioneer AV receiver that is part of my home entertainment system finally started having problems after years of excellent service.  I had to replace it with a new Onkyo AV receiver that really has more options in it that I know what to do with. So I spent some time two nights ago, after the kids and wife had gone to bed, to swap out this component.  But the greatest thing for me was that when they went to watch TV and to listen to the radio the next day, they did not have to do anything differently!

Everything just worked using the same interface that they have always been used to, down to using the same key presses, because I had invested some time in consolidating my "service interface" to one programmable and extendable universal remote. So, the only additional thing I had done was to update the firmware in the remote control to now point to the new receiver on the back-end.

I would definitely consider this a practical example of the implementation of the principle of abstraction.

Many people believe that an Enterprise Service Bus (ESB) is a must have component of a SOA infrastructure.  The  usual argument put forth is that if you want security, manageability and reliability in your environment, you must have something that looks like a "bus" in your environment.

I have a slightly different perspective on this.  From my experience, there are other components that do an outstanding job when it comes to security functionality. In addition, an ESB really can't manage services that are not "plugged-in" to it (you need something like a WSM product). And finally, with the approval of and support for WS-ReliableMessaging as an OASIS standard, you no longer need some proprietary messaging technology to provide reliable messaging. You can leverage the support for the standard built into the basic service platform itself. So my experience has been that you do not need a "bus" in the middle through which all traffic should flow and all things in your enterprise should be connected to.

But at the same time, where I have seen the value of an ESB is from the perspective of its ability to easily tap into a variety of back-end systems and expose them using a contracted web service interface. So in my world, the ESB provides me ease of use when it comes to tapping into custom or Enterprise class systems (ERP, RDBMS, Mainframe) and "service-enabling" them. So an ESB is simply a type of Service Platform which can be used to build services and not a bus to which everything is connected.  The service created in this manner can be treated like any other service that you build or buy, and can be secured and managed just like you would any other service. 

In this model, I really did not see much value in having an ESB, given that we have a pretty comprehensive existing and heterogeneous SOA infrastructure that is designed to work together in a standards compliant manner and provides pretty much all of the functionality that an ESB is touted to fulfill. The only exception would be if there existed some back-end system that I could not natively tap into from a standard service platform and needed the facilities of an ESB to ease the connection into that proprietary or legacy system.

But I had the opportunity yesterday to listen to Anne Thomas Manes of the Burton Group at the "Pragmatic SOA  Governance" workshop that was put together by Michael Meehan and his crew from TechTarget.com. Great event, BTW!

What Anne's comments opened my eyes to was to take what I had above to the next step. From her perspective, an ESB is the new generation of Application Servers, and what it brings to the table is the ability for an organization to be resilient to application protocol changes.  So an ESB provides the ability to leverage the same core business logic that is used to build a capability, and expose it over multiple service protocols/interfaces. And if a new protocol needs to be supported, it is simply a matter of the ESB supporting it. Keep in mind the end product is still a contracted service interface. But in this case, that interface is not limited to SOAP but can be many others that may be much more peformant or optimized for that particular domain.

Conceptually, I can buy into this. Will have to see how well it does in real life.

I recently signed and sent off my official appointment letter which stated:

I am pleased to offer you an appointment as Lecturer in the [Johns Hopkins University] Whiting School's Engineering and Applied Science Program for Professionals. It is my understanding that you have agreed to teach the following course(s) for the Spring 2008 semester:

605.702.31 - Service-Oriented Architecture

I am looking forward to this new and interesting chapter in my life!

Recently, a lot of interest has been shown in SOA (Service Oriented Architectures). In these systems, there are multiple services each with its own code and data, and ability to operate independently of its partners. In particular, atomic transactions with two-phase commit do not occur across multiple services because this necessitates holding locks while another service decides the outcome of the transaction. This talk proposes there are a number of seminal differences between data inside a service and data sent into the space outside of the service boundary. The act of unlocking data as a copy of it is sent in the message means the interpretation of the received message must include the understanding that this data in unlocked. This changes how the data can be used.

We then consider objects, SQL, and XML as different representations of data. Each of these models has strengths and weaknesses when applied to the inside and outside of the service boundary. The talk concludes that the strength of each of these models in one area is derived from essential characteristics underlying its weakness in the other area.

Source: Presentation by Pat Helland of "Data on the Inside versus Data on the Outside" at TechEd EMEA at Barcelona

Pat Helland's "Data on the Outside vs. Data on the Inside" paper has always been one of those must read items for me when it comes to Service Orientation. He recently gave a presentation on the topic at TechEd EMEA at Barcelona and has posted the slides. Definitely worth checking out...

Slides and notes from two presentations on REST and SOAP at QCon:

• Pete Lacey on REST and SOAP
• Sanjiva Weerawarana on SOAP and REST

Very different viewpoints. I enjoyed both

I was giving a presentation and demo today about Policy Based Management in a Web Services environment. The particular use case I was demonstrating was the ability to, by policy, change the type of authentication tokens that were accepted by a web service (from none, to hard-coded, to leveraging an existing identity store, to X.509 Certs etc.) depending on the level of assurance needed, without modifying the web service code.

The mechanism I was using as the Policy Enforcement Point (PEP) in my demonstration was an XML Security Gateway. XML Security Gateways are useful devices for a variety of reasons, but typically there are also drawbacks. The major one is that if you have XML Security Gateways from multiple vendors, you typically cannot define policies in the Policy Administration Point (PAP) of one vendor and push it out to the Gateways (PEPs) of another vendor. This issue becomes even more extensive when you consider that other pieces of web services infrastructure such as Web Service Management (WSM) products, ESBs etc. also have their own unique consoles for administration.

When you question the vendors on this, the typical answer that you get is that they are waiting for WS-Policy (and the associated domain specific languages under WS-Policy) to be approved and adopted to alleviate this issue. In the mean time of course, if you need that central administration, just standardize on our product I'll buy that to a certain extent, but what about support for those standards that have been out there for a while and have traction in the community? e.g. SAML and XACML.

One of the reasons that the acquisition of Reactivity and Securent by Cisco interested me, was that it brought together the possibility of an XML Security Gateway (acting as a PEP) backing against a XACML-based fine grained authorization service (PDP). I was not aware of anyone who supported this use case out of the box, although  I am aware of folks who have requested this functionality and the vendors who have either custom modified their products to enable this or have put it on their feature roadmap.

But I was recently made aware of at least one potential out of the box support for this capability by Mark O'Neill, CTO of Vordel. Mark pointed me to Vordel's XACML PEP Support, as well as a case study and information on interoperating with various XACML PDPs. Very interesting!

The W3C XML Schema Patterns for Databinding Working Group have published updated Working Drafts for "Basic XML Schema Patterns for Databinding Version 1.0" and "Advanced XML Schema Patterns for Databinding Version 1.0"

As I've mentioned before this is one of the only efforts who are looking at ways of working around the fact that XML Schema is inconsistently implemented across various web service Toolkits.

This is also the primary reason that I am moving away from databinding in general to consuming the XML directly which enables me to use native XML technologies such as XPath, XSLT etc.

What is even more interesting is that as part of the report they have come up with a Test Suite and have run it against a range of web service implementations (Axis, Axis2, .NET 2.0, WCF, XFire and more..) and documented it in an Interoperability Report. The results are interesting... to say the least!

Highly recommended reading if interested in web services interoperability.

• RELAX NG Specification at OASIS
• RELAX NG Tutorial at OASIS
• 10 reasons to model XML with RELAX NG , not W3C XML Schema
• Should you choose RELAX now?

When designing schemas, one tries to strive for modularity which allows one to build XML schemas that are composed of other schema documents. The keywords that make it possible are include, import and redefine.  Most folks who are used to schemas are familiar with import and if you want to maximize interoperability you should stay away from redefine since it is not implemented on a consistent basis.

That leaves the include keyword.  When you use include, one of the following should be true:

• Both schema documents (The including schema and the included schema) must have the same target namespace
• Neither of the schema documents should have a target namespace
• The including schema document has a target namespace, and the included schema does not.

In the last case, all components of the included schema document take on the namespace of the including schema document. The included schema document is sometimes referred to as a chameleon schema as its namespace changes depending on where it is included.

A best practice that I normally follow is to use chameleon schemas for common, reusable types so that I don't have to namespace qualify some very common schema types that I normally end up using across multiple schemas. 

I recently ran into an issue when actually working on this in that a particular .NET tool that I was using did not seem understand the use of option (3) i.e. chameleon schemas. Since I know the guys who developed the tool, and they are considered pretty much experts in the field, I was not that surprised when I pinged them on this and got back an answer that it was a known issue.

According to them, the reason that the issue exists is because of a lack of support in the .NET API itself and (this is way too low level for me) has to do with how the ServiceDescriptionImporter(SDI) class is not working properly. So you would have issues if you tried to use wsdl.exe with chameleon schemas in .NET 1.1 and 2.0. Not sure if the issue exists under WCF.

The workaround for this, which I implemented, was to qualify the included schema with the same namespace as the including schema. Not ideal, but got me to where I needed to.

Hopefully this is an issue that will be fixed.

Service Component Architecture (SCA) is something that has been popping up on my radar for some time now, but I've been having a hard time getting a clear idea of what SCA is all about from the vendor presentations and from the specifications themselves.

In particular I was interested in how it relates to SOA and Web Services, but what I had heard to date and what I took away from the various presentations/readings made me put it on the back-burner as a "new application thing from a bunch of Java vendors". 

I just changed my mind on this after reading David Chappell's "Introducing SCA [PDF]" white-paper.  It is a clear, vendor-neutral and most excellent description of what SCA is all about and the various pieces that make up SCA. In particular it sets the stage for understanding how various vendors who jump on the SCA bandwagon may choose to focus on or implement one or more of the the pieces of what SCA is in total.

I would also add that if after reading the white-paper you are interested in the standardization efforts around SCA, to check out the OASIS OpenCSA efforts.

In short, as noted in the white-paper "The reality today is clear: Anyone who's interested in the future of application development should also be interested in SCA." Read!

You don't get much! Rest with the small caps of course. The program starts (depending on whether or not you have something going on during breakfast) any time between 7 and 8:30 p.m. and goes on all the way through 6 p.m. Then there are networking and interoperability events that usually go on until 9 p.m. All in all, very full program with very little bit of slack or fluff.

Allrighty, now that I have made my lame joke, I did want to mention "REST Easy" workshop that was given by Pete Lacey.  I personally found it to be very enjoyable and educational. Pete is passionate, articulate and takes no prisoners on this topic.  You might as well have named the workshop "SOAP based web services are the spawn of evil and should be staked through the heart ASAP!"

As I mentioned to Pete afterwards, I am not in the OR camp (i.e. WS-* OR REST) as I believe that there is a place for both. I also think that 10 years from now we will be using a strange fusion of the two approaches and arguing about something else! In any case, I do believe that REST offers definite potential benefits if you can wrap your head around it and learn how to apply its constraints correctly in building solutions. I, for one, intend to dedicate some time to do just that. You can never have enough tools in your toolbox!

UPDATE:  Humor often does not come through very well when writing (and the above, now crossed-out sentence, was meant to be humorous). But based on Pete's comments below, I want to make sure that the reader's of this blog posting do not get wrong impression. Significant portion (> 95%) of the time was spent on REST principles itself, examples of an actual REST solution with code samples and a lot more and not on picking on  WS-*. To think otherwise would be very unfair to Pete and that is not my intent at all. My only intent with the above comment was to note that if you believe the premise and the promise of REST as presented in the workshop, you will come away with an aversion to the complexity that is inherent in the current state of WS-*. Which of course is why I noted above that I would indeed be investing time in learning more about REST.

Today was a good day!

Gave my presentation today and got some incredibly good engagement and feedback on it which I need to follow-up on. It appears that a lot of folks share the trials and tribulations that we are going through as we are deploying our SOA environment, so sharing the information on how best we are accomplishing what we need to do and some of the best practices we have identified definitely opened up a floodgate of ideas for possible collaboration, which was exactly what we were hoping for!

The sessions as usual were outstanding and I ended up in the evening having some intense and wide ranging conversations with both Anne Thomas Manes as well as Jonathan Chaitt from Disney. Anne is the SOA track lead for Catalyst conference and really did a great job of putting together a great selection of folks (Burton, End Users, Vendors, Independents) while keeping it all real.  I also really enjoyed chatting with the Disney folks. They are doing some really fine work in the area of fine grained authorization and are folks I hope to keep in touch with. 

Also attended both an OASIS XACML Interop event as well as a WS-I Basic Security Profile Interop Session which really opens up some possibilities for some of the things that we are considering.

All in all an excellent day topped by some an awesome personally guided walking tour of downtown SF (Some amazingly beautiful buildings out here) by a rather remarkable gentleman that I met the last time I was out here who just so happens is a former SF resident.

Trends driving enterprise IT

• Today's toys = tomorrow's tools
• SaaS as a new business model
• Semantic disparity
• Integration of collaboration into business apps
• Virtualization
• Automating regulatory compliance and governance
• more...

Organizations should build general-purpose reusable infrastructure based on standards to ensure management, consistency etc. Tension between building for today and architecting for tomorrow. Realize that tech is fleeting.

Growing resistance to super-platform from best of breed. Innovations in raising level of abstraction and in the pursuit of simplicity.

Super-platform vendors are not just selling app servers but SOA/BPM platforms. More "stuff" in the core platform. But also more specialization in the areas of:

• Domain-specific languages
• OSS rebel framework
• Mobile frameworks
• UI frameworks
• Others..

Increasing simplicity

• REST/WS-*/POX
• Dynamic vs. compiled languages
• 80/20 rule specialized frameworks (e.g., Rails)
• Lightweight containers

Increasing abstraction

• Model-driven development
• Declarative languages
• Data services
• Infrastructure services

Assume heterogeneity at the core. Pursue simplicity and abstraction. Invest in infrastructure (SDLC, Governance, Runtime, Security, Data) to provide separation of concerns, increase productivity and efficiency and provide better governance and consistency.

Don't let the vendor dictate your strategy

• Design own infrastructure
• Identify functional capabilities and map vendor tech into them
• Best innovation from startup community
• Focus on principles and patterns and recognize that technology is fleeting
• Separation of concerns between Apps and Infrastructure
• More...

I am attending the Burton Group Catalyst conference in San Francisco this week. Flew out on here on Monday and attended some workshops over the last couple of days on Identity Federation Technologies, Application Security and my personal favorite, Pete Lacey's workshop on REST.

Today is also the first day that I am feeling relatively human as over the last three days I've been suffering from what felt like all of the symptoms of a flu.  Liberal amounts of rest combined with regular dosages of various pain killers seem to have improved the situation. Which is a good thing since I am scheduled to give a case study presentation on Thursday:

SOA and Security: A Pattern-based Approach

A critical part of building out a SOA runtime infrastructure is the requirement to directly address the threats to message exchanges that exist in a non-benign environment. As JHU/APL is building out its SOA infrastructure for our GIG Testbed environment, we are taking a measured and hopefully realistic approach to web service security that is leveraging best practices from the community that are embodied in various security patterns.

To the greatest extent possible, we are mapping various applicable security patterns to physical implementations using components of a SOA runtime infrastructure such as mediation and web service management systems in combination with applicable security and WS-* standards. This presentation will provide an overview of this effort, with drill downs into some specific patterns and their corresponding implementations, as well as provide insight into some of the related but non-technical issues such as governance and building a community of practice around this effort.

"I've set my bozo bit for WS and SOA types who are repositioning themselves as REST stalwarts. Spotting a bandwagons is not an indicator of competence. " - REST Person

"REST is now the hot chick in town. Its on the uptick of the hype curve. Atom is going to be taking over soon. Until we get past the top of the hype curve its impossible to have intelligent, analytical, critical conversations with the fanatics." - WS-* Person

From the perspective of someone who just wants to get things done, this is simply MAD. <sigh>

I had a chance to geek out over dinner with a couple of friends, Ken Laskey and Chris Bashioum, as well as a colleague of theirs (Rob Mikula) from MITRE. We got together to talk about SOA Governance since both Ken and Chris are fellow members on the OASIS SOA-RM TC and the three of them team teach a SOA course at MITRE that heavily leverages the SOA-RM.

Unsurprisingly, the conversation ranged across the board from SOA adoption, granularity of services, performance impact of composite services and possible ways to mitigate them, the role of the UDDI protocol, data model extensibility in Repositories, WS-Policy, Consent of the Governed and how it applies to SOA Governance, the role of a Center of Excellence in the adoption and operation of a SOA and more...

A discussion that we were having also provided me with a way forward in something that I've been struggling with regarding the SOA course that I will be teaching for Johns Hopkins University. What type of project/exercise work can the students work on for the class? What Ken, Chris and Rob do in their two day class is to have their students work through a case study on integrating multiple information systems using a SOA approach. Given that I have a semester's worth of time, a case study with drill downs in specific and relevant areas running the gamut from governance and requirements to actual implementation of services could be very useful in driving home the lecture/discussion points while at the same time providing me with a mechanism to gauge if the students are actually grokking the information. Will have to give some serious thought on how to go about structuring this.

All in all, an immensely enjoyable evening!

I will be teaching a graduate degree class on Service Oriented Architecture via the Johns Hopkins University's Engineering Programs for Professionals.  The exact date is uncertain, but I expect it to be either in the Fall of this year or the Spring of next year. Here is the class description:

605.702 Service Oriented Architecture

This course will explore SOA concepts and design principles, interoperability standards, security considerations as well as runtime and governance infrastructure for SOA implementations.

Web services will be used as an example of implementation technology for SOA and as such, the exploration of runtime infrastructure will focus on standards based support for SOA requirements in modern service platforms such as .NET/WCF and Java/Axis2, the role of mediation systems such as XML Security Gateways and ESBs, as well as how Registries, Repositories and Web Service Management capabilities map into an implementation of a SOA.

Given its focus on shared capabilities, SOA involves more than technology. Therefore, additional topics will include the impact of SOA on culture, organization, and governance.

If you thought the definition of SOA sounded familiar, you would not be mistaken.

I am really looking forward to teaching this class, if for no other reason that I have found that in the process of teaching (or preparing and giving a presentation) and interacting with the audience, I often learn a great deal as well.  Given the rapid change in this topic area, this course more than likely will tend to morph on a semester to semester basis as our shared understanding of what SOA is and how best it can be implemented advance.

UPDATE (4/11/07): Course description was recently updated to be bit more descriptive (or buzzword compliant - take your pick)

I recently came across this resource from Sun. According to the web site:

This tutorial explains how to develop web applications using the Web Service Interoperability Technologies (WSIT). The tutorial describes how, when, and why to use the WSIT technologies and also describes the features and options that each technology supports.

WSIT, developed by Sun Microsystems, implements several new web services technologies including Security Policy, WS-Trust, WS-SecureConversation, Reliable Messaging, Data Binding, Atomic Transactions, and Optimization. WSIT was also tested in a joint effort by Sun Microsystems, Inc. and Microsoft with the expressed goal of ensuring interoperability between web services applications developed using either WSIT and the Windows Communication Foundation (WCF) product.

[...]

The Web Services Interoperability Technology Tutorial addresses the following technology areas:

• Bootstrapping and Configuration
• Message Optimization
• Reliable Messaging (WS-RM)
• Web Services Security 1.1 (WS-Security)
• Web Services Trust (WS-Trust)
• Web Services Secure Conversation (WS-Secure Conversation)
• Data Contracts
• Atomic Transactions (WS-AT)
• SOAP/TCP

This looks to be a rather good resource to learn about Web Service Interoperability between Sun and Microsoft stacks using some of the advanced WS-* standards and specifications.  The highlight above regarding the joint Sun/Microsoft testing is mine. Worth checking out.

I had the opportunity today to give a presentation on SOA and its relationship to Net-Centricity to various folks in my organization. During the Q&A session that followed the briefing, there was a question regarding service versioning.

Just to provide some context, in my briefing one of the items that I touched on is the concept of Loose Coupling and how that enables the abstraction of interface from implementation and gives a service provider the ability to change out their implementation without affecting the service consumer.

To paraphrase the question "I have a service that is being used by multiple parties, and I am changing the implementation of that service but not the interface. (1) From a testing and certification perspective, what should I do? (2) What mechanisms exist to communicate this change to all the folks who are using my service?"

The interesting variation that this particular question posed was that changing out the implementation in this example was NOT about changing implementation technology but changing the processing algorithms/business logic associated with the implementation.

My answer to (1) was that if the algorithm/business logic change had the effect of changing the expected result (as compared to the original implementation), at that point I would consider this implementation to be a whole new service and would consciously break the interface. For example, in the case of a web service implementation, I would change/update the namespace of the schema such the it would break compatibility with existing service consumers. I would also have to have this service be tested and certified as though it was a new service.

But before I do that, I would have to notify the consumers that are using my service that I am about to make this change. Which relates to my answer to (2). AFAIK, at present there is no standardized, automated way of notifying all existing service consumers that I am about to change out my implementation. So in the current state of technology, what I would have to do would be to set up a mechanism/process as part of the original client provisioning on how I as a service provider would communicate changes and updates of importance to my service consumers.

The example I pointed to was how Google implements its AdWords API versioning strategy:

The AdWords API supports multiple recent versions of the WSDL to allow developers time to migrate to the most recent version. Once an earlier version of the WSDL has been replaced by an updated version, the older version will be supported for four months after the launch of the newer version.

During this period, the AdWords API will continue to provide developer access to and documentation support for any version dating back two months.

You can tell which version of the WSDL you are accessing based on the access URL namespace, which includes the version number. Versions are named with the letter 'v' followed by whole numbers (v5, v6, etc.).

The Release Notes summarizes changes between versions. In addition, new versions and shutdowns of older version are announced via the AdWords API Blog.

In addition to this documentation, whenever we release a new version of the AdWords API, new versions and older version shutdowns will be announced via the AdWords API Blog.

In the above example, the communication mechanism is the AdWords API Blog and it is incumbent upon service consumers to subscribe to it to keep updated on what is going on with the API. And Google provides a 4 month window in which they run both the old version and the new version side-by-side to give you time to move from one to the other.

But I have to admit that this is a situation that I have not personally run into (change in implementation logic, no change in interface), so I am basing my answers on various community best practices and conversations with folks who have had to do this.  If you have run into this particular situation before, I would be very interested in knowing how you handle this in your organization, especially any info you can share on the governance policies and processes that you have put into place to communicate upcoming changes.

There is an interesting article over at Thomas Earl's SOA Magazine site by Cory Isaacson titled "High Performance SOA with Software Pipelines".

In the article, Isaacson notes that "Distributed service-oriented applications, by their nature, take advantage of multi-CPU and multi-server architectures. However, for software applications to truly leverage multi-core platforms, they must be designed and implemented with an approach that emphasizes concurrent processing".

He identifies and explains current approaches to dealing with concurrency in applications such as:

• Symmetric Multi-Processing in which a SMP server operating system manages the workload distribution across multiple CPUs.
• Automated Network Routing in which service requests are routed to individual servers in a pool of redundant servers.
• Clustering Systems in which multiple servers share common resources over a private "cluster interconnect".
• Grid Computing in which applications are divided into sub-tasks that can execute independently.

... as well as the various limitations associated with the current approaches. He also identifies a new approach, based on a methodology called software pipelines, which can enable businesses to achieve the benefits of concurrent processing without major redevelopment effort. I found it to be fascinating reading as I personally have not done much work with multi-threaded applications or grid computing.

As an aside, the challenges of programming for multi-core chips and how to make that easier for the developer was a key theme in Bill Gate's keynote address at the recent Microsoft MVP Summit.

As I have noted before, performance engineering to me is something that should be considered in an end to end manner.  Currently, in the web service world, there are folks who are tackling this problems using hardware (e.g. XML Security Gateways) and by using binary encoding approaches, but IMHO, not a lot of work being done to provide best practices for optimizing the design of the services themselves.

An exception to the rule, and an excellent source of information on performance engineering that I always point to, are the first three chapters in the PAG Perf & Scale book. So, for your reading pleasure, let me point to them once more:

• Fundamentals of Engineering for Performance
• Performance Modeling
• Design Guidelines for Application Performance

Just to be clear, it does not matter if you are in the .NET camp or the Java Camp or any of the other language/platform camps, the information above is equally applicable and relevant.

One of the first things that is brought up when one talks of web services interoperability is the Web Services Interoperability Organization (WS-I) and conformance to the WS-I basic profile, and how that ensures interoperability (Allrighty, I am deliberately choosing not to talk about how WS-I punted on XML Schema profiling and how you can build web services that are WS-I basic profile compliant but NOT interoperable).

Many folks have the impression that the WS-I is a standards organization. It is important that it is not and that it is a coalition of vendors.  There is a rather interesting blog post by Erik Johnson, the former chair of the WS-I XML Schema Planning Working Group, that sheds some light on some of the internal processes at this organization.

As someone who is actively involved in the standards work that is going on at OASIS, it is always fascinating for me to get insight into how other organizations work with specifications and standards in the SOA and Web Services space.

Patterns are your friends. Patterns keep you from having to reinvent the wheel and it allows you to leverage best practices. Patterns provide a common vocabulary that can be used to share information between folks who often come from different backgrounds. I like patterns!

I was one of the external reviewers for the PAG book on Web Service Security Patterns, so using a pattern based approach is something that I am very much following as part of the design and deployment of a SOA runtime infrastructure. 

Yesterday, a colleague and I were discussing one of the design decisions we made in configuring our environment to enable access for external applications and services to web services within our private network. The enjoyable part of the conversation for me was in using a pattern as a common mechanism of communication to discuss the rationale for the decision, given that our backgrounds are a bit different (He comes from the Network/Comms background and I from the AppDev side).

In particular, the pattern that we used in this instance is the Perimeter Service Router Pattern. Here is a bit of detail on the pattern (follow the link for complete info):

Context

External applications require access to one or more Web services that are deployed within a private network. Access to the Web services and resources in the private network is restricted to authenticated users. External applications should not have access to resources used by the Web services in the private network.

Problem

How do you make Web services in a private network available to external applications without exposing resources in the private network?

Forces

Any of the following conditions justifies using the solution described in this pattern: 

• Internal Web services and dependent resources may be targeted by attackers who are external to the network. The organization must protect Web services on the internal network, so that any attacks do not affect the internal Web services or dependent resources.
• Attackers can gain information about the internal network, and use it to compromise the network. The organization must not reveal information about the internal network infrastructure that can be useful to attackers.

The following condition is an additional reason to use the solution:

• External clients need reliable access to fixed service endpoints. The location of a Web service's internal implementation may need to change dynamically to cater for the availability of dependent resources, or to cater for maintenance and batch processing windows. External clients should be unaffected by these changes.
  

Solution

Design a Web service intermediary that acts as a perimeter service router. The perimeter service router provides an external interface on the perimeter network for internal Web services. It accepts messages from external applications and routes them to the appropriate Web service on the private network.

The realization of this pattern for us was NOT in software but in hardware. We used a XML Security Gateway as the realization of the Perimeter Service Router pattern.

I, along with Todd Biske and some other folks, were recently interviewed by Phil Windley for an article on SOA and Governance which will be published in the March 5th print issue of InfoWorld. A lot of my thinking in this area has been influenced by a combination of my background in operational IT, my current work in the SOA space as well as my participation in the standards process as a member of the OASIS SOA-RM TC. 

Do read the "Teaming up for SOA" article and let me know what you think.

I recently had the opportunity to look at some of the details of Web Services for Remote Portlets (WSRP), which is a web services protocol for aggregating content and interactive web applications from remote sources.  As an aside, if you are interested in a quick tutorial, I would recommend the OASIS WSRP TC's Web Services for Remote Portlets 1.0 Primer.

The interesting thing with this standard is that it is built on top of a few fundamental standards such as XML, SOAP and WSDL. But with WSRP, every single web service has the same set of operations (See graphic).

This is very similar to the REST architectural constraint of uniform interfaces, which means that all resources present the same interface to clients. As noted in Steve's excellent REST Article:

"A significant advantage of the uniform interface constraint lies in the area of scalability. For a client to correctly interact with a SOA service, it must understand the specifics of both that service’s interface contract and data contract. But for a client to invoke a REST service, it must understand only that service’s specific data contract: the interface contract is uniform for all services."

To apply this to WSRP, both the interface contract and the data contract are uniform for all WSRP services, and as such the consumer of the WSRP service is a generic construct. For example, pretty much all of the major portal implementations supply, at a minimum, a WSRP consumer portlet that can bring in a remote WSRP service without any coding.

While I understand that REST is about more than uniform interfaces, wonder what the REST folks would have to say about WSRP.

It would appear that Reactivity, makers of XML Security Gateway products and one of the few remaining independent companies in the SOA infrastructure arena, is in the process of being acquired by Cisco.

Given Cisco's traditional strengths as well as its SONA (Service-Oriented Network Architecture) efforts, I wonder if this acquisition will speed the convergence of management capabilities that span both the services and the network layers.

I was reading through the research article "Adaptive QoS for Mobile Web Services through Cross-Layer Communication" in the current issue of IEEE Computer Magazine in which the authors are proposing something called WS-QoS framework, which is an approach to unify Quality of Service (QoS) for web services across transport, computing and app layers.  It is an interesting read.

Per the article, the discovery, selection and invocation process consists, at a high level, of :

1. Service Provider registers with a UDDI based registry. Each service has a unique interface key.
2. Potential Service Consumer queries an "offer broker" (This is a new entity in the mix) for services that match a specific interface key AND QoS requirements
3. The offer broker acts as the middle man in identifying the "best match" between the QoS requirements of the Service Consumer and potential Service Providers who are registered in the UDDI based registry.
4. The Service Consumer directly invokes the identified best match Service Provider.

The manner in which QoS is codified is based on a specific XML Schema .

For example, for the Transport Segment you could have something like:

<operationQoSInfo name="myOperation">
...
<transportQoSPriorities>
<delay>5</delay>
<jitter>3</jitter>
....
</transportQoSPriorities>
...
</operationQoSInfo>

 For Servers it could be:

<serverQoSMetrics>
...
<requestsPerSecond>30</requestsPerSecond>
...
</serverQoSMetrics>

And at the App Layer you could have something that codifies facets like compression and decompression and other items.

As a thought exercise, given that the point of using web services is all about interoperability, I went through what would need to happen from the standards and vendor support to make all this real.

1. Given the amount of work going on around WS-Policy, wrap up the QoS information as a domain policy language for QoS under the WS-Policy umbrella
2. The direct integration of the "offer broker" functionality into the Registry/Repository
3. Built in support from the networking vendors that can map the codified policies into the appropriate technology specific network mechanism such as priorities for expedited forwarding, assured forwarding, best-effort etc.
4. Built in support from the server OS vendors that can map the codified policies into server performance levels. And given that a lot of folks are using virtualization in their computing tier, support from those folks as well.
5. Last but not least, agreement and profiling of the specification(s) between all of the web service stack vendors.

I am sure that I have grossly over-simplified a lot of things in the above and probably gotten some of it completely wrong. But the essence remains. Beyond this being a technically challenging problem, there needs to be significant amount of agreement between a lot of vendors as well as the incorporation of a variety of these technologies into the various product sets (Vendor Politics, Oh My!).

It is going to be a while! <sigh>