I had the opportunity earlier in the week to attend the 9th Symposium on Identity and Trust on the Internet (IDtrust 2010) which was held at NIST.

Given that a lot of the work that I am currently doing is centered around externalized, policy driven Authorization using Attribute Based Access Control (ABAC) and the profiling and deployment of Enterprise Attribute Services, I found a paper [PDF] and presentation [PDF] given by Ivonne Thomas from the Hasso-Plattner-Institue for IT-Systems Engineering to be very interesting.

As an aside, one of the best explanations on conveying what ABAC is all about, particularly to business owners, was given by a colleague who works for the DOD in this particular domain (Thanks Ken B).

“Consider if you will, the following two situations.

You are standing in line at the Grocery store and a little old lady in a walker comes up to you and demands your driver’s license and proof-of-insurance! You will be making a particular decision at that time. Now, consider if the same question was asked of you with red and blue lights blinking behind you and someone with a badge and a gun is knocking on your windshield asking for the same information.

We make these types of decisions all the time in our lives based on a real time evaluation of who is asking the question, what they want access to, and the context in which the question is being asked. ABAC is how we could do the same thing in the electronic world. Making a real-time access control decision based on attributes of the subject, the attributes of the resource and the attributes of the environment/context.”

I love this explanation and have shamelessly stolen and used it to great effect in multiple situations.

Coming back to the paper, given that Attributes are used to make these critical access control decisions, how does one judge the “trust-worthiness” and/or “authoritative-ness” of each attribute that are used to make the decision?  How could one convey these qualities related to attributes to a Relying Party so that it can make a nuanced access control decision?

On the authentication front, we have an existing body of work that can be leveraged such as the OMB E-Authentication Guidance M-04-04 [PDF] which defines the four Levels of Assurance (LOA) for the US Federal Government and the attendant NIST SP 800-63 [PDF] that defines the technologies that can be used to meet the requirements of M-04-04.  In particular, you have the ability to use SAML Authentication Context to convey the LOA statements in conformance with an identity assurance framework.

The paper, which I think has a misleading title, uses the Authentication Context approach as an example and defines an extension to the SAML 2.0 schema for what is termed by the Authors as an “Attribute Context” which can be applied to each Attribute value. The authors define the parts as:

• Attribute Context This data element holds the attribute context,  which is comprised of all additional information to the attribute value itself. This element is the upper container for all identity metadata.
• Attribute Data Source This data element indicates the source from which the attribute value was originally received and is part of the Attribute Context. This  can  be  for  example  another  identity  provider, some authority as a certificate authority or the user himself who entered the data.
• Verification  Context This data element holds the verification context, which comprises all information related to the verification of an identity attribute value. The Verification Context is one specific context within the Attribute Context.
• Verification Status This data element indicates the verification status of an identity attribute value, which should be one of “verified”, “not verified” or “unknown”. The verification status is part of the verification context.
• Verification Context Declaration The verification context declaration holds the verification process details.  Such a detail could for example be the method that has been used for verifying the correctness of the attribute.  Further extensions are possible and should be added here.  The verification context declaration besides the verification status make up the verification context.

I know of many folks who are working on the policy side of this question of how to judge the “authoritative-ness” of an Attribute under multiple topics such as “Attribute Assurance”, “Attribute Practice Statements”, “Authority Services” etc. etc.  But I have often thought about how one would go about conveying these types of assertions using current technology. This approach seems to provide an elegant approach for doing just that:

As you can see in the above example, the extensions proposed by the authors integrate nicely into a standard saml:AttributeStatement and convey the metadata about individual attributes to a Relying Party that can make a more nuanced access control decision.

I think this is a great beginning and would love to see the authors submit this to the OASIS Security Services (SAML) TC so that it can become part and parcel of the SAML 2.0 specification. I would also love to see a Profile come out of the OASIS SSTC that would define a consistent set of Verification Context Declarations.  In particular I believe that the concept of referencing “Governing Agreements” as defined in the current “SAML 2.0 Identity Assurance Profile, Version 1.0” (which is in public review) has applicability to this work as well.

To be conformant to SPML v2 means that the SPML interface (Provisioning Service Provider / PSP) MUST:

• Support the set of Core operations
• a discovery operation {listTargets} on the provider
• basic operations {add, lookup, modify, delete} that apply to objects on a target
• Supports basic operations for every schema entity that a target supports
• Supports modal mechanisms for asynchronous operations

There are additional “Standard” operations described in the OASIS SPML v2 Specification [Zip]. The clear thing to keep in mind is that each operations adds a data management burden onto the provider, so the choice of whether or not to implement them should be considered very carefully.

From the perspective of deployment topologies, the PSP could be deployed separately from the Target or could very well be integrated tightly with the Target e.g. an SPML compliant web service interface on a target system.

One of the frustrating items for me when enquiring about SPML support in products has been the lack of clarity and visibility around exactly what has been implemented. All too often, vendors seem to have cherry picked a chosen set of operations (whether from the Core or from the Standard list) and used that to claim SPML support. I would be very curious to see if anyone can claim full SPML v2 compliance.

A particular use case for SPML that I am currently working on has to deal with the “batch” movement of attributes from multiple systems to a central repository. The typical flow is as follows:

• Per organizational policy & relationship to user, attributes are assigned in their home organization and/or business unit (Org A / Org B / …)
• Org A must move those users and/or their attributes to a central repository (Repository X) on a regular basis
• Repository X acts as the authoritative source of attributes of users from multiple organizations / business units and can provide those attributes to authenticated and authorized entities in a real-time request/response and in a synch-take-offline-use modes.

Some points to keep in mind are:

• Org A / B / … may have, and all too often do, have their own existing identity and provisioning systems as well as associated governance processes in place.
• The organizations and the repository may or may not be under the same sphere of control and as such cannot mandate the use of the same piece of provisioning software and associated connectors on both ends of the divide.
• The systems where the organizations store the attributes of their users may not necessarily be directory based systems.
• The Repository may or may not be directory based system.
• Identity / Trust / Security are, as you may imagine, rather important in these types of transactions.

To meet these needs, we are currently profiling SPML to support the Core SPML Operations as well as the optional “BATCH” capability.  The “ASYNC” capability is something that we are more than likely going to support as well as it provides a mechanism for the provider to advertise support for asynchronous operations rather than have a request for an asynch operation fail on a requester with an error “status=’failed’” and “error=’unsupportedExecutionMode’”.

Keep in mind that the end result will satisfy more than just the one use case that I noted above. In fact, it satisfies many other use cases that we have that deal with both LACS and PACS scenarios. In addition, the profile will also bring in the pieces that are noted as out of scope in the SPML standard i.e. the Profiling of the Security protocols that are used to assure the integrity, confidentiality and trust of these exchanges. Fortunately, we can leverage some of previous work we have done in this space for that aspect.

Mark Diodati at the Burton Group kicked off this conversation in his blog post "SPML Is On Life Support..." Other folks, notably Nishant Kaushik ("SPML Under the Spotlight Again?"), Ingrid Melve ("Provisioning, will SPML emerge?") and Jeff Bohren ("Whither SPML or wither SPML?") bring additional perspectives to this conversation. There is also some chatter in the Twitter-verse around this topic as well.

As someone who has been involved in both the standards process as well as end user implementation, I have a semi-jaded perspective to offer on what it takes for vendors to implement interfaces that are standards based in their tooling/products. First of all, let it be clearly understood that Standards are beautiful things (and there are many of them) but a Standard without vendor tooling support is nothing more than shelf-ware. So in the case of Standards Based Provisioning, in order to get that tooling support, multiple things need to happen:

• First and foremost, do NOT let a vendor drive your architecture! User organizations need to break out the "vicious cycle" that exists by first realizing that there are choices beyond the proprietary connectors that are being peddled by vendors, and secondly by stepping up and defining provisioning architectures in a manner that prioritizes open interfaces, minimizes custom connectors and promotes diversity of vendor choice.  Map vendor technology into your architecture and not the other way around, because if you start from what a vendor's product gives you, you will always be limited by that vendor's vision, choices and motivations.
• Bring your use cases and pain points to the Standards development process and invest the time and effort (Yes, this is often painful and time consuming!) to incorporate your needs into the base standard itself. I am finding that often the Technical Committees in Standards Organizations are proposed and driven by vendors and not end users. But in cases where there is a good balance between end users and vendors, the Standard reflects the needs of real people (The Security Services/SAML TC at OASIS often comes to mind as a good example).
• Organizations need to incorporate the need for open standards into their product acquisition process. This needs to go beyond "Product X will support SPML" to explicit use cases as to which portions of the standard are important and relevant. Prototype what you need and be prepared to ask tough, detailed questions and ask for conformance tests against a profile of the Standard.
• Be prepared to actively work with vendors who treat you like an intelligent, strategic partner and are willing to invest their time in understanding your business needs and motivations. These are the folks who see the strategic value and business opportunities in supporting open interfaces and standards, realize they can turn and burn quicker than the competition, and compete on how fast they can innovate and on customer satisfaction versus depending on product lock-in.  They are out there, and it is incumbent upon organizations to drive the conversation with those folks.

Moving on, let me reiterate the comments that I made on Mark's blog posting:

"The concern with exposing LDAP/AD across organizational boundaries is real and may not be resolved at the technology level. Applying an existing cross-cutting security infrastructure to a SOAP binding (to SPML) is a proven and understood mechanism which is more acceptable to risk averse organizations.

I would also add two additional points:

1. More support for the XSD portion of SPML vs. DSML in vendor tooling. There are a LOT of authoritative sources of information that are simply NOT directories.
2. There needs to be the the analog of SAML metadata in the SPML world (Or a profile of SAML metadata that can be used with SPML) to bootstrap the discovery of capabilities. The "listTargets" operation is simply not enough."

While I do resonate with the "pull" model interfaces noted by Mark in his posting, I do believe that exposing LDAP(S)/AD Interfaces either directly of via Virtual Directories outside organizational boundaries is a non-starter for many organizations.

At the same time I believe there exists options in the current state of technology to provide a hybrid approach that can incorporate both the pull model as well as provide the application of cross-cutting security infrastructure into the mix. The architecture that we are currently using incorporates a combination of both Virtual/Meta Directory capabilities as well as an XML Security Gateway to provide policy enforcement (security and more) when exposed to the outside.

I will also reiterate that there needs to be more support for the XSD portion of SPML vs. DSML. A lot of the authoritative sources of user information that I am dealing with are simply not found in directory services but in other sources such as relational databases, custom web services and sometimes proprietary formats in addition to LDAP/AD.

I hope to post some the use cases for standards based provisioning as well as the details of some of the profiling that we are doing on SPML to satisfy those use cases in future blog posts. Looking forward to further conversations around this topic.

I had a great time at Burton Group's Catalyst Conference this year.  Spent my time between the Identity Management, SOA and Cloud sessions. Also had an opportunity to attend the Cloud Security & Identity SIG session as well.

As the fast-thinking, slow talking, and always insightful Chris Haddad notes on the Burton APS Blog (Chris... enjoyed the lunch and the conversation) "Existing Cloud Computing's momentum is predominantly focused on hardware optimization (IaaS) or delivery of entire applications (SaaS)".

But the message that I often hear from Cloud vendors is:

• We want to be an extension of your Enterprise
• We have deep expertise in certain competencies that are not core to your business, and as such you should let us integrate what we bring to the table into your Enterprise

... and variations on this theme.

But in order to do this, an Enterprise needs to have a deep understanding of its own core competencies, have clearly articulated it's capabilities into distinct offerings, and gone through some sort of a rationalization process for its existing application portfolio.. In effect, have done a very good job of Service Orient-ing themselves!

But we are also hearing at the same time that SOA has lost its bright and shiny appeal and that most SOA efforts, with rare exceptions, have not been successful. For the record, success in SOA to me is not about building out a web services infrastructure, but about getting true value and clear and measurable ROI out of the effort.

So to me, it would appear that without an organization getting Service Orientation right, any serious attempt they make on the cloud computing end will end up as nothing more than an attempt at building a castle on quicksand.

The other point that I noted was that while there were discussions around Identity and Security of Cloud offerings (they still need to mature a whole lot more, but the discussion was still there), there was little to no discussion around visibility and manageability of cloud offerings.  A point that I brought up in questions and in conversations on this topic was that while people's appetite for risk vary, one of the ways to evaluate and potentially mitigate risk was to provide more real time visibility into cloud offerings.  If a cloud vendor's offerings are to be tightly integrated into an Enterprise, and I now have a clear dependency on them, I would very much want to have a clear awareness of how the cloud offerings were behaving.

From a technical perspective, what I was proposing was something very similar in concept to the monitoring (and not management) piece of what WS-Management & WSDM brought to the table on the WS-* front. In effect, a standardized interface that all cloud vendors agree to implement that provides health and monitoring visibility to the organizations that utilize their services. In short, I do not want to get an after-the-fact report on your status sent to me by e-mail or pulled up on a web site, I want the real time visibility into your services that my NOC can monitor. There was a response from some vendors that they have this interface internally for their own monitoring. My response back to them is to expose it to your customers, and work within the cloud community to standardize it such that the same interface exits as I move from vendor to vendor.

In the physical world, when an attacker is preparing to assassinate someone or bomb a target, the first thing that they will do is to determine how best to set up that attack. The phrase used to describe the initial phase of the set-up is called 'pre-operational surveillance'. 

Unfortunately, the default configuration of most web services allow a potential attacker to do the digital equivalent of pre-operational surveillance very easily. In the digital world, these type of threats are often classified under the category of 'Information Disclosure Threats'. There are two in particular (there are more) that I would like to call attention to:

1. SOAP Fault Error Messages
2. WSDL Scanning/Foot-Printing/Enumeration

1. SOAP Fault Error Messages

All too often, detailed fault messages can provide information about the web service or the back-end resources used by that web service. In fact, one of the favorite tactic of attackers is to try to deliberately cause an exception or fault in a web service in the hope that sensitive information such as connection strings, stack traces and other information may end up in the SOAP fault. Mark O'Neill has a recent blog entry 'SOAP Faults - Too much information' in which he points to a vulnerability assessment that his company did of a bank that provided information that enabled an attacker to understand the infrastructure the bank was running and presumably allowed them to further tailor the attack.

The typical mitigation for this type of information disclosure is the implementation of the 'Exception Shielding Pattern' as noted in the Patterns & Practices Book 'Web Service Security' [Free PDF Version] which can be used to "Return only those exceptions to the client that have been sanitized or exceptions that are safe by design. Exceptions that are safe by design do not contain sensitive information in the exception message, and they do not contain a detailed stack trace, either of which might reveal sensitive information about the Web service's inner workings." (FULL DISCLOSURE:  I was an external, unpaid, technical reviewer of this book).

You can either implement this pattern in software or use a hardware device like a XML Security Gateway to implement this pattern. Mark utilized a Vordel Security GW, but this is something that can be implemented by all devices in this category. I have direct experience with Layer 7 as well as Cisco/Reactivity Gateways and happen to know that they support this functionality and I don't doubt that IBM/DataPower and others in this space support it as well.

Note that this does not imply that the error's that happen are not caught or addressed but simply that they are not propagated to an end-user.

2. WSDL Scanning/Foot-Printing/Enumeration

Appendix A of 'NIST 800-95: Guide to Secure Web Services' provides a listing of common attacks against web services, and you will note that there are many references to the information that can be found in a WSDL that can lend itself to a variety of attacks including Reconnaissance Attacks, WSDL Scanning, Schema Poisoning and more.

And in the 'Security Concepts, Challenges, and Design Considerations for Web Services Integration' article at the "Build Security In" web site sponsored by the DHS National Cyber Security Division, it notes that "An attacker may footprint a system’s data types and operations based on information stored in WSDL, since the WSDL may be published without a high degree of security. For example, in a world-readable registry, the method’s interface is exposed. WSDL is the interface to the web services. WSDL contains the message exchange pattern, types, values, methods, and parameters that are available to the service requester. An attacker may use this information to gain knowledge about the system and to craft attacks against the service directly and the system in general." 

The type of information found in a WSDL, and which can be obtained simply by appending a ?WSDL to the end of a service endpoint URL, can be an extremely useful source of info for an attacker seeking to exploit a weakness in a service, and as such should not be provided or simply turned off.

There are multiple ways of mitigating this type of an attack which include turning off the automatic ?WSDL generation at the SOAP stack application level or by the configuring the intermediary that is protecting the service end-point. For example, most XML Security Gateway's by default turn off the ability to query the ?WSDL on a service end-point.

I consider this to be a very good default.

When this option is implemented, there are often a variety of questions that come up that I would like a take a quick moment to address.

Q. If you turn off the automatic WSDL generation capabilities (i.e. ?WSDL) how are developers supposed to implement a client that invokes the web service?

There are two ways. (1) Publish the WSDL and the associates XML Schema and Policy files in an Enterprise Registry/Repository that has the appropriate Access Control Mechanisms on it so that a developer can obtain a copy of the WSDL/Schema/Policy Documents at design time. (2) Provide the WSDL/Schema/Policy files out of band (e.g. Zip File, At a protected web site) to the developer. 

Oh yes, there is always the run-time binding question that comes up here as well. What I will say is that run-time binding does not mean "run time proxy generation + dynamic UI code generation + glue code" but simply that the client side proxy and the associated UI and glue code are generated at design time, but that the end-point that the client points to may be a dynamic lookup from a UDDI compliant Registry. I've done this before and this does not require any run-time lookup of a web service's WSDL.

There is an additional benefit to this method as well. Have you ever gone through the process of defining a WSDL and Schema using best practices for web services interoperability, implemented a service using that WSDL and Schema, and then looked at the auto-generated WSDL? You may be surprised to find that the automatic generated WSDL may be in a majority of cases is not as clean or easy to follow and in some cases may indeed be wrong. The best practice for developing interoperable web services recommends following a contract-first approach. This requires that the "contract" i.e. the WSDL and the Schema to be something that is developed with a great deal of care given to interoperability. Since the automatic generation of WSDL is platform-specific, there is always the possibility of some platform-specific artifacts ending up in the contract documents, which is not what you intended to happen.

Q. What about those existing/legacy services that do a run time lookup? Won't those break?

The question that needs to be asked at this point is why these services are doing a run time lookup, is there value being added by this capability in this client, and are there alternatives that will enable the client to provide the same functionality without compromising security? 

As an example take the case of a BEA Weblogic client.  If you will look at the documentation that BEA provides on building a Dynamic client you will note that they provide two different approaches, one that uses a dynamic WSDL lookup and another that does not. The interesting thing about this is that the approach that uses the WSDL makes a run-time lookup of a Web Service's WSDL which will end up breaking if the ?WSDL functionality is turned off. But the alternative approach of building a dynamic client provides the same functionality without the run-time WSDL lookup.

From what I can see, from a functional perspective there is no difference between the two approaches and given that one of the things that you want to do when developing web services, or any software for that matter, is to minimize the number of external dependencies, I would choose the second option of NOT doing a run-time WSDL lookup in this particular case. What is regrettable in this case is that it appears that the default configuration in BEA's tooling is to use the run-time WSDL option (Or so I have been informed), which leads to issues when folks who choose the default options with their tools develop the clients. 

Mitigating these information disclosure threats requires both developers and operational support folks to understand their shared responsibility for security. Developer's need to understand that security should be part of the software development lifecycle and is not something that is bolted on at the end or is 'thrown over the wall' for someone else to take care of. Operational folks need to understand that a layered defense in depth strategy is needed and that secure coding practices of developers are an essential component of any operational environment. In particular the mentality of "Firewalls and SSL will save us all" needs to change for all parties concerned.

Notes from an on-going online discussion to self, for use as a reference and for discussion:

"SOA is an architectural style, and an architectural style is a set of principles. Gartner has enumerated five principles that constrain SOA:

• modular
• distributable
• described
• sharable
• loosely coupled

To the degree a system exhibits all five, the more it qualifies as representing the SOA style"

- Nick Gall, Gartner

"SOA Principles of Service Design:

• Service Contracts
• Service Coupling
• Service Abstraction
• Service Reusability
• Service Autonomy
• Service Statelessness
• Service Discoverability
• Service Composability"

- Thomas Erl, SOA Principles of Service Design

"From my perspective, the overarching principle governing SOA is separation of concerns. This principle helps you determine how to factor functionality into services. Thomas Erl discusses service factoring and granularity in the SOA Fundamentals section of his book rather than treating SoC as a principle"

- Anne Thomas Manes, Burton Group

"The 4 tenets of Indigo as defined by Don Box, which has now been morphed into the Microsoft tenets of SOA:

• Boundaries are explicit
• Services are autonomous
• Services share schema and contract, not class
• Service compatibility is determined based on policy"

- Don Box, A Guide to Developing and Running Connected Systems with Indigo

"The 10 Principles of SOA, as expanded on the above 4 tenets, by Stefan Tilkov:

• Explicit boundaries
• Shared contract and schema, not class
• Policy-driven
• Autonomous
• Wire formats, not programming language APIs
• Document-oriented
• Loosely coupled
• Standards-compliant
• Vendor-independent
• Metadata-driven"

- Stefan Tilkov, innoQ

I've been using a combination of Anne's separation of concerns, Thomas Erl's principles and selected bits from the OASIS SOA-RM in the SOA class that I teach but the variations above look to be great fodder for some discussions!

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>

via Dims:

"For a while now, we've been building up a Stack comparison page at the Apache WS Wiki site:
http://wiki.apache.org/ws/StackComparison

Yes, You can edit it and update existing information on that page. Just click on the link at the top right corner and create an account for yourself ......"

Not a complete listing by any means (In particular it is currently missing the WCF/.NET 1.1/2.0 as well as the stacks from BEA and IBM), but a good starting point, especially if you are interested in the Open Source Web Service stacks.

Both Paul Fremantle in the comments on my previous entry and Sanjiva Weerawarana in his blog entry confirm that the option of moving away from serialization to handling the raw XML messaging is something that was designed into the Axis2 core but was not something that the majority of developers seem to be comfortable with. Very much appreciate the information. Would love to see some tutorials around this (if it is not there already) on either the WSO2 or Axis2 sites.

Sanjiva also noted the need to define a benchmark for testing that takes into account a lot more of the factors that I noted in my previous entry and offered to host it as an open source project.

So to start, what is needed would be some sort of a "real" application against which the tests could be run. Hmm... I'll throw one out for consideration. Have you thought about running your tests against the WS-I sample application?

According to the WS-I web site:

"The Sample Application presents a high-level, interoperable example of a supply chain management application in the form of a set of Use Cases that demonstrate use of Web services that conform to the Basic Profile 1.0."

Currently the Sample Application has been implemented by BEA Systems, Bowstreet, Corillian, IBM, Microsoft, Nokia, Novell, Oracle, Quovadx, SAP and Sun Microsystems (On a variety of web services stacks to be sure). Source code is available for download on the WS-I site.

Please keep in mind that I am throwing this out after about 5 minutes of thinking and have not really explored any of the details such as possible licensing restrictions by WS-I etc. Something to consider....

A reference to the SOA Practitioners' guide, which is hosted on BEA's Dev2Dev site, came across on one of the lists that I am on. According to the web site:

SOA is relatively new, so companies seeking to implement it cannot tap into a wealth of practical expertise. Without a common language and industry vocabulary based on shared experience, SOA may end up adding more custom logic and increased complexity to IT infrastructure, instead of delivering on its promise of intra and inter-enterprise services reuse and process interoperability. To help develop a shared language and collective body of knowledge about SOA, a group of SOA practitioners created this SOA Practitioners' Guide series of documents. In it, these SOA experts describe and document best practices and key learnings relating to SOA, to help other companies address the challenges of SOA. The SOA Practitioners' Guide is envisioned as a multi-part collection of publications that can act as a standard reference encyclopedia for all SOA stakeholders.

The guide is available in three parts:

• SOA Practitioners Guide Part 1 —Why Services-Oriented Architecture? This guide provides a high-level summary of SOA.
• SOA Practitioners Guide Part 2 —This guide covers the SOA Reference Architecture, which provides a worked design of an enterprise-wide SOA implementation with detailed architecture diagrams, component descriptions, detailed requirements, design patterns, opinions about standards, patterns on regulation compliance, standards templates and potential code assets from members.
• SOA Practitioners Guide Part 3 —This guide introduces the Services Lifecycle and provides a detailed process for services management though the service lifecycle, from inception through to retirement or repurposing of the services. It also contains an appendix that includes organization and governance best practices, templates, comments on key SOA standards, and recommended links for more information.

I've not had a chance to go through these documents in any great detail, but I do note that two of the reviewers for the documents are Brenda Michelson of Elemental Links, Inc. and Steve Jones of Capgemini Group who are both smart, competent people in the SOA space who spent some time on this effort. Looks like I'll have to dedicate some time to read these documents.

Ben Moreland, the Director for Foundation Services at the The Hartford, has a great article on SOA Governance up on eBizQ.  The Hartford is an organization in the financial sector who is at the forefront of SOA adoption and implementation on the commercial side of the house.

The keys to their success have been their strong Enterprise Architecture and Governance programs. Case in point is that, in a presentation that Ben gave recently, he noted that some time ago (2-3 yrs?) The Hartford sequestered both their Senior Business Executives and Enterprise Architects for an extended period of time (I believe it was around 4 months!) to hammer out a strategic plan for how they were going to employ technology to drive business value. Their approach to SOA is based on that strategic plan and is a clear indicator how serious these folks are about executing on that all too often mythical "Business/IT alignment" everyone talks about!

From the Article:

"Some people use SOA governance to mean service lifecycle governance—that is, governing the lifecycle of services from creation through deployment. Others take it to mean applying runtime policies to services. But is there more to SOA governance than this? Shouldn’t governance with SOA ultimately be about delivering on your business and SOA objectives? Finally, without a common understanding of what governance means, are organizations that adopt SOA simply setting themselves up for failure?"

The article identifies the Key Leverage Points of SOA Governance as People, Financial, Portfolio, Operations, Architecture, Technology and Projects, and as noted in the article:

The key thing to understand is that you can only achieve the change necessary for SOA success by putting policies and processes in place around all of the key leverage points denoted above—people, application portfolio, services portfolio, projects, services, enterprise architecture, enterprise technology platforms, and operations. If you put these policies in place—that is, if you govern your SOA journey wisely— you will be able to deliver on your SOA strategy and business objectives.

All in all, an excellent article from a practitioner and not a talking head :-) Check it out!

There is currently a war of words going on regarding the performance of some of the Java web service stacks including Axis2, XFire and JAX-WS 2.1 FCS. 

Instinctively, I think that this type of testing is asking the wrong questions and I am trying to articulate why that is so.

To start with, these steps seem to completely sidestep any of the design considerations that are associated with the development of any serious enterprise class web service. Those design considerations [Microsoft PAG: Improving Web Services Performance] include:

• Design chunky interfaces to reduce round trips.
• Prefer message-based programming over RPC style.
• Use literal message encoding for parameter formatting.
• Prefer primitive types for Web services parameters.
• Avoid maintaining server state between calls.
• Consider input validation for costly Web methods.
• Consider your approach to caching.
• Consider approaches for bulk data transfer and attachments.
• Avoid calling local Web services.

Secondly, this type of benchmarking tends to focus people on the immediacy and synchronous nature of web services rather than designing the system for asynchronous operation.  In a real production system, all too often the chunk of time that is taken up by the processing associated with the business logic that the web service is fronting may be a significant factor in the performance overhead associated with the web service. And as you go through your perf optimization, it may very well make sense to optimize that piece e.g. database calls (as that gets you the biggest bang for the buck) as you do your end to end performance engineering.

Lastly, this all seems to be about the relative performance of the various data binding frameworks that are out there (ADB, JiBX, XMLBeans etc.. etc..) which in turn brings up all the nasty interoperability issues related to serialization/de-serialization that deal with the impendence mismatch between XML Schema and the language of your choice (Java, C#, ...).  This is something that I have had a great deal of interest in, especially in trying to find work arounds to ensure interoperability. But more and more, I am becoming frustrated by this particular aspect of web services and am moving more towards avoiding serialization entirely and processing a message directly. This would also allow me to utilize some of the more powerful capabilities like XSLT/XPath etc.

Of course, this also moves me away from the web services mainstream and the "ease of use" argument that can be made due to the tooling support for XML to Object Mappings by the various vendors.  One of the things on my list of near term to-do's is to explore how hard/easy it would be to go down this path using some of the modern web service stacks such as WCF and Axis2. I really think that in the long term, it would be much more beneficial to me to go down this path and will more than likely also help out as I try to come up to speed on REST (Another one of my to-do's).

The latest edition of Thomas Erl's [Editor] SOA Magazine is out.

Service Elicitation: Defining the Conceptual Service
Fundamental to any SOA delivery project is the definition of services. More specifically, the ability to define what constitutes a service and how logic should be partitioned and represented across a collection of services. The ambitious goal of SOA to achieve unity between business and technology domains further makes service definition a critical step along a typical SOA roadmap. This is the second article in a series dedicated to exploring the functional side of SOA. It explores several ways to properly describe a service in a stage called "service elicitation," essentially the process of extracting services from business knowledge...

SOA and EDA: Using Events to Bridge Decoupled Service Boundaries
The distinction between service-oriented architecture (SOA) and event-driven architecture (EDA) can be traced down to message patterns. Understanding the implications of common exchange patterns, such as request-and-reply and publish-and-subscribe, helps determine both fundamental differences and commonality in these two complementary architectural models. It is appropriate and desirable to use the acronyms SOA and EDA to make this distinction, because both of these architectural styles are positioned in the same domain; SOA focusing on the decomposition of business functions and EDA focusing on business events. This article explores the differences between these two models and specifically studies how EDA patterns can be used to connect decoupled service domains...

SOA and the Emergence of Business Technology: How Business Services are Changing the IT Landscape
Globalization is having a tremendous impact on IT. Fueled by technological change and innovation IT is becoming more capable than ever of establishing itself as a true partner to business, a trend that is creating the opportunity for a new breed of IT professional: one that is both technology and business savvy. In this article we discuss the genesis of this accelerating wave of change, how it has been responsible for and relates to the service-oriented architectural model, and how it is contributing to a new field we can call "business technology"...

One of the questions that is often asked by certain folks is the relationship between Enterprise Architecture and Service Oriented Architecture. Some folks believe that SOA is the new version of EA, others that the disciplines are distinct. My personal belief that they are mutually supporting disciplines and the level of maturity that an organization has achieved in one will directly impact its ability to implement the other.

Given this the following quote, from Anne Thomas Manes of the Burton Group, really resonated with me:

"SOA also applies at the enterprise architecture level -- helping the [Enterprise Architects] optimize the application portfolio and data architecture. Nearly every large organization has way too many applications that implement the same capabilities and way too many data structures that represent the same information. The cost of ownership of managing and maintaining a bloated application and database portfolio keeps fixed annual costs very high, reduces the available funds for new projects, and severely limits the flexibility and agility of the organization. From the [Enterprise Architecture] perspective, the goal is to dramatically reduce duplication of application functionality and data structures by implementing shared capabilities as services and designing standard data structures for interfacing with those services. [Enterprise Architects] should be defining priorities for SOA projects.

When it comes time to design a specific application, the goal is to analyze the required capabilities of the application, identify capabilities that have already been implemented, and identify capabilities that other systems might need. These shared capabilities should be implemented as services -- not re-implemented in every application that needs them. Also any volatile capability should be implemented as a service to increase separation of concern and to enable easier management."

Figured I'd put it on the blog as I'm sure that I will be reusing this particular explanation in the future and it will be easier to point to it here with attribution given to Anne.

I was reading Todd's entry on "Services for Managing the Network" in which he comments on an article by the F5 folks which talks about a unified way to manage both services and network components through web service interfaces. 

This is something that I've been thinking about for a while as well.  To me a SOA runtime infrastructure should allow us to monitor, manage and administer across network, computing and service resources using standardized policies. In this ideal world, the appropriate domain experts (Security, Networking, QoS, SLA etc.) define the policies for that domain in a centralized manner, push out those polices to distributed appliances and service platforms across your Enterprise such that they can be enforced, and provides the ability to collect metrics on what is going on in your environment.

In some ways the greater challenge is not technical, but cultural. It lies in trying to provide a common frame of reference and understanding to folks who come from different background (NetOps/Transport folks, DataCenter/Computing Infrastructure folks, Service folks) on the impact of deploying a SOA runtime infrastructure. It is a challenge that I face on a regular basis and one that requires the most fundamental of skills - Communications and the ability to see the other person's point of view.

On the technical side of the house, the challenge is wrapped up in the phrase "standardized policies". To reach this stage requires two separate things to happen:

1. The ratification of standards that address these various aspects of management
2. Adoption of these standards by various vendors at the Network, Computing and Service layers

At the current stage of technology, some of what I am discussing above is possible by using a combination of WSM, Mediation Systems, Registry/Repository, Platforms and Network Devices. But unfortunately, given that a lot of the standards are not finalized, it requires one to use specific vendor products (where vendors have established interop relationships) that are using proprietary mechanisms in the absence of established standards.

So what are some of the standards that we should be tracking and urging our vendors to support in the policy and management space?

• Policy - WS-Policy to start with. But keep in mind that WS-Policy is simply a container and still requires the creation of multiple domain specific languages that will address areas such as SLAs and QoS etc.
• Provisioning - Adoption of Service Provisioning Markup Language (SPML) v 2.0. Keep in mind that this deals purely with user provisioning and not with service provisioning. Current service provisioning is, to a great extent, a manual process.
• Management & Reporting - The convergence of WSDM and WS-Management. Note that this has a dependency on the convergence of WS-Eventing (WS-Management needs this) and WS-Notification (WSDM needs this) into WS-EventNotification.

As you can see above, there is a lot of work that still needs to be done in this space and significant competition among the various vendor factions regarding what these standards should be. As you are building out your infrastructure, I would highly recommend that you question your vendors on their support for existing standards, their tracking and participation in the standards process, and their roadmap for support of future standards, so that in the end you have the ability to monitor, manage and administer your environment in a holistic manner.

This is a great introductory article on REST by Steve Vinoski of IONA titled "REST Eye for the SOA Guy" (PDF) that has been published in the current issue of IEEE Internet Computing. For more in-depth info, check out the RESTwiki .

P.S. My kids were kind enough, in the recent season of sharing, to share a rather nasty cold with me. Towards the end of the day yesterday, my co-workers were making the "warding-off-evil" signs in my direction,  so I am taking the day off today. Now that the medication has kicked in, I am using the temporary relief as an excuse to catch up on some technical reading which, unfortunately, I can tolerate only for short bursts. <sigh>

The latest edition of Thomas Erl's [Editor] SOA Magazine is out.

Implications of SOA on Business Strategy and Organizational Design

The need to somehow change the way we do business as a prerequisite to unlocking the transformative potential (and resulting competitive advantage) inherent in technological innovation is becoming increasingly recognized. The scope of discussion this time around however moves beyond organizational efficiencies to whole of market efficiencies, and the strategic implications this has in terms of planning and organizational design. Many business leaders have grown progressively indignant towards the over-sold and under-delivered powers of technology to effect their bottom line - these, the same people who are responsible for setting strategic direction, business planning, and capital investment. This is the first in a series of articles targeting the business community. It explores the implications of SOA on strategic planning and organizational design - from a business perspective.

Commercializing Services: Web Services Distribution Channels and SOA

Exposing web services to the outside world is much more complex than creating and maintaining services geared towards internal consumption. While internally focused projects have their technical challenges, outwardly focused web services initiatives bring to the fore a whole host of non-IT related issues such as business strategy and marketing. Those who proceed with such projects with the same mindset that made their internal projects successful run a significant risk of failing. Web services initiatives aimed at serving the needs of non-captive customers and partners are akin in effort to that of creating a new business channel and not merely a systems integration project. In order be successful in these efforts, you must clearly understand your organization's objectives, your customer's needs and the Web Services Distribution Ecosystem...

AJAX: Bringing SOA to the Front Lines

A service-oriented architecture (SOA) can provide enterprises with significant benefits, including the ability to reuse application functionality and to interconnect heterogeneous applications to create new composite ones. However, a critical component to the realization of SOA benefits is that users throughout the extended enterprise can efficiently access and interact with key resources. Otherwise you cannot fully leverage your infrastructure investment. Using AJAX rich internet applications (RIAs) as the presentation tier, however, can significantly enhance the impact of SOA. This article explains how companies can link their employees, customers and partners, with a scalable, flexible interface to efficiently interact with service-oriented resources.

Always an an interesting read.

I am a member of the OASIS SOA Reference Architecture Subcommittee which is part of the SOA-RM (Reference Model) Technical Committee. We had a F2F meeting before the holidays and one of the items that came up during our discussion was the need to engage the wider community to make sure that the work we are doing is relevant and applicable to implementers, and to solicit feedback for incorporation into this ongoing work. So I asked our chair if I could blog about this work and he said sure (Thanks Frank!), provided that I mention that this is a work in progress.

So, this is a work in progress :-)

On a serious note, comments/corrections/additions/pointers/hints/smoke signals are very welcome and I or any other member of the TC can act as your conduit and make sure that it is presented to the TC at large. Please feel free to leave comments on this blog entry or contact me directly. Needless to say, if your organization is part of OASIS, we are a friendly bunch of folks doing some interesting and complex work, and would very much welcome your direct participation!

On to the topic at hand. A particular interest of mine in the SOA-RA is the area of governance and we had a discussion on this topic that I wanted to share.

SOA & GOVERNANCE

The starting point of the discussion was the definition of SOA as defined in the SOA-RM which states that "Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains."

But when we speak of traditional IT governance, it usually means governance applied within the Enterprise; within a single ownership domain if you will. But in the case of a SOA implementation it needs to be applied across ownership domains, across Enterprises. And that requires a different set of carrots and sticks, perhaps something much more contractual in nature rather than something direct. And that in turn brings to light the fact that what one organization considers governance will be completely different from what another organization considers governance.

At this point, I proposed a definition of governance that is consistent with the above and has resonated very well with me. Requiring no original thought on my part, I quoted Anne Thomas Manes of the Burton Group who has said “Governance refers to the processes that an enterprise puts in place to ensure that things are done right, where "right" means in accordance with best practices, architectural principles, government regulations, laws, and other determining factors. SOA governance refers to the processes used to govern adoption and implementation of SOA.” With the exception of adoption bit, the committee members agreed that this was a good working definition. This also tied in very nicely with an earlier comment by a colleague, Ken Laskey of MITRE, that "Governance for SOA [...] is likely to parallel governance for traditional commerce", and that "There will be a range of governance depending on the perceived needs of the participants."

One of the items on my to-do list is to research the governance practices of large enterprises, especially ones in which the business units have a great deal of autonomy, to distill some lessons on what works and what does not work. At this point in time, I personally have not seen examples of SOA implementations that span Enterprises. Or rather Enterprises that are equivalent in authority/power/influence. Any examples you can share would be very appreciated.

As we progressed along this path, one of the items that became much clearer is that governance by its very nature implies the authority to govern. That authority can be formal or informal and could be codified in an explicit manner or implied. But in all cases, there is the concept of authority. Given this, implementing SOA governance requires:

1. Formulation of polices that are appropriate to the domain
2. The ability to enforce the policies
3. The ability to obtain metrics on what is working and what is not
4. Implementing feedback [and adjudication] processes that can adjust the existing policies as needed

<aniltj - personal comments>

Speaking for myself, and not for the committee at large, one of the items that we need to keep in mind regarding governance is that it should not just be the big hammer. It should also be the mechanism for providing motivators to moving to and doing the right things in a SOA. Not just the de-motivators. And the reality as regards to SOA governance is that it should be an extension of your existing IT governance where you add the SOA specific bits. I think the challenge here will be figuring out what that amorphous line is. It does not make sense in the SOA RA to document IT governance components, but there is definitely overlap and mutual support. Just as with EA and SOA. 

Above all, I think we need to realize that when we speak of formulating SOA polices, we are dealing with people and behavior and culture and not just technology. Which means it is messy and imprecise. As the old saying goes "Technology is easy, People? That's Hard!".

</aniltj - personal comments>

Again, a work in progress. Input and comments are solicited and welcome.

UPDATE: 1/3/07 - incorporation of off-line comments.

UPDATE: 1/4/07 - I just noticed that OASIS also has a public SOA-RM Comment Listserv, which folks can use to provide feedback as well. Please use whichever mechanism works for you.

As we move beyond the infancy of SOA, there is general consensus that it is not just about the technology but about using technology to solve critical problems that are facing businesses/agencies/organizations.

But as ever, we operate in a non-benign environment, and the realization of the Architecture requires one to consider the myriad of threats that can be brought to bear on a SOA implementation.

I am trying to graphically represent some of the threats that can be brought to bear against the exchange of messages in a SOA e.g. In a SOA implemented using web services.

There are two that I explicitly did not put on the graphic, and those are:

1. Unauthorized Service Consumers
2. Rogue Service Producers

Not because they are not important, but simply because I'm still trying to figure out a way to represent them on this graphic in a clean manner.

This is only the starting point for a discussion of security threats in a SOA, and there has been some work done to date on various security design patterns that can be used to mitigate these threats.

This is definitely an area that I am going to be exploring in much greater detail.

Joe McKendrick has a list of Ten companies where SOA made a difference in 2006 .  These are companies that moved beyond the pilot stage into live deployments and are seeing results. They include:

• eBay
• IBM
• Wachovia Bank
• Harley Davidson
• Hewlett Packard
• Ameriprise Financial
• Amazon
• Citigroup
• OnStar
• Dreamworks Animation SKG

A good list to point to when asked about examples of successful SOA implementations.

Update (12/26/06):  Another eight more companies (International Truck, MedicAlert, Experian, Washington Group, Siemens AG, The Hartford, FBI, Monster).

The SOA Reference Model (SOA-RM) was approved as an OASIS Standard on October 23, 2006.  Currently we are working on the SOA Reference Architecture (SOA-RA), and today was the first of three days of Face 2 Face Meetings for the RA work. Long and interesting day with a group of smart people.

I have traditionally had to be concrete and implementation focused (Make the rubber meet the road and not the sky!), so one of the challenges that I have as part of the process of working on the SOA-RA is in trying to distill my experience and lessons into something that can contribute to a body of work that exists at a higher level of abstraction, and applies to a wide range of implementations.

I had a chance to attend a Special Technical Session at the OMG Technical Meeting held in Arlington, VA today on Emerging Standards for SOA.  Enjoyed the talk on linking Web Service Specification Languages and Semantic Technologies by a friend of mine, Chris Bashioum of MITRE, as well as a most excellent briefing by Toufik Boulez of Layer 7 Technologies on WS-Policy. There were also very informative presentations on WS-Security and WS-I Security Profile as well as SCA and SDO and other various other topics.

As always it was also an opportunity to renew old acquaintances and make new ones. Surprisingly, a much more informative and enjoyable day than I expected!

Last Call Working Draft Review for Basic XML Schema Patterns for Databinding.  Here is some more information on this W3C Working Group:

"The W3C XML Schema Patterns for Databinding Working Group, part of the W3C Web Services Activity, has released two working drafts for review.The mission of this Working Group is to define a set of XML Schema patterns that will be efficiently implementable by the broad community who use XML databindings. Patterns which may prove useful to model include abstractions of structures common across a wide variety of programming environments, such as hash tables, vectors, and collections.

There are several ways of representing such abstracted data structures and Web Services toolkits are currently using ad hoc technologies to infer the most suitable language mapping when processing XML Schemas.Agreeing on a set of XML Schema patterns for which databinding optimizations can be made will facilitate the ability of Web services and other toolkits to expose a more comprehensible data model to the developer.

The WG has published a First Public Working Draft for "Advanced XML Schema Patterns for Databinding Version 1.0." This document defines an advanced set of example XML Schema 1.0 constructs and types in the form of concrete XPath 2.0 expressions. These patterns are known to be in widespread use and considered to be compatible with databinding implementations. Implementers of databinding tools may find these patterns useful to represent simple and common place data structures. Ensuring tools recognize at least these simple XML Schema 1.0 patterns and present them in terms most appropriate to the specific language, database or environment will provide an improved user experience when using databinding tools.

The WG has also issued a Last Call Working Draft for the "Basic XML Schema Patterns for Databinding Version 1.0" specification. A databinding tool generates a mapping between XML 1.0 documents which conform to an XML Schema 1.0 schema and an internal data representation. For example, a Web services databinding tool may use XML Schema 1.0 descriptions inside a WSDL 2.0 or WSDL 1.1 document to produce and consume XML and SOAP messages in terms of data structures in a programming language or data held inside a database."

Given that the impedance mismatch between XML Schema and Language Types are one of the major causes of Interoperability problems in web services toolkits, this work and these documents are definitely worth checking out.

LOL!  From Pete Lacey at the Burton Group:

SG: [....] From here on in we pass around coarse-grained messages—you like that term, coarse-grained?. Messages that conform to an XML Schema. We call the new style Document/Literal and the old style RPC/Encoded.

Dev: XML Schema?

SG: Oh, it’s all the rage. Next big thing. Take a look.

Dev: (Reads XML Schema spec). Saints preserve us! Alexander the Great couldn’t unravel that.

SG: Don’t worry about it. Your tools will create the schema for you. Really, its all about the tooling.

Dev: How are the tools gonna do that?

SG: Well, they will reflect on your code (if possible) and autogenerate a compliant schema.

Dev: Reflect on my code? I thought it was all about documents, not serialized objects.

SG: Didn’t you hear me? It’s all about the tools. Anyway, we can’t expect you to write XML Schema and WSDL by hand. Besides, its just plumbing. You don’t need to see it.

Dev: Whoa, back up. What was that word? Wizzdle?

SG: Oh, haven’t I mentioned WSDL? W-S-D-L. Web Services Description Language. It’s how you specify the data types, parameter lists, operation names, transport bindings, and the endpoint URI, so that client developers can access your service. Check it out.

Dev: (Reads WSDL spec). I trust that the guys who wrote this have been shot. It’s not even internally consistent. And what’s with all this HTTP GET bindings. I thought GET was undefined.

SG: Don’t worry about that. Nobody uses that. Anyway, your tools will generate a WSDL, and in the WSDL will be the schema.

Dev: But shouldn’t it be the other way ‘round? Shouldn’t I design the contract first and then generate the code?

SG: Well, yeah, I guess that sounds right in principle. But that’s not so easy to do, and very few SOAP stacks support WSDL-first development. Just let the tools worry about it.

This is so darn funny, especially when you consider that it is so true! Go read the entire thing, please!

From the announcement:

Apache Axis2 is a complete re-design and re-write of the widely used Apache Axis engine and is a more efficient, more scalable, more modular and more XML-oriented Web services framework. It is carefully designed to support the easy addition of plug-in "modules" that extend its functionality for features such as security and reliability.

Major Changes Since 1.0:
- - Significantly improved documentation
- - Significantly improved support for POJO services and clients
- - Significantly improved support for Spring services
- - Significantly improved Axis Data Binding (ADB) to increase schema coverage and overall stability
- - Improved service lifecycle model
- - Improved JMS support
- - Improved handler and module interfaces
- - Improved Eclipse and Idea plugins
- - New Attachments API for sending & receiving MTOM and SwA attachments
- - Built in support for WS-Policy via Apache Neethi
- - Added support for unwrapping Web service requests
- - Fixed tons of small and not-so-small bugs
- - Major refactoring of release structure to make usage easy

Known Issues and Limitations in 1.1 Release:
- - Unwrapping of response messages (coming in 1.2)
- - JSR 181/183 Annotation support (coming in 1.2)
- - JaxMe and JAXBRI data binding support is experimental

I have updated my "Install and configure Apache Tomcat/Axis for web service development on Windows XP SP2" post for Axis2 1.1.