Web Services != SOA

During a recent trip to a company technical summit a discussion came about related to how SOA is just Web Services. As a SOA Trainer, Architect and Implementer I live and breath it every day. Most peoples perspectives probably fall in this category and currently most of the SOA implementations that I have worked with have used Web Services. The key is that Web Services is just an implementation technology not a SOA.

Books from Thomas Erl, Intel Press and others have identified that SOA is a design paradigm that focuses on a series of principles that tie back into key business goals and benefits. Examples of these are presented at SOA Systems but include:

- Interoperability
- Federation
- Cooperative Development between Business Analysts and Technical Architects
- Vendor/Technology Choice
- ROI
- Reduced IT Effort
- Business Agility

Now a SOA could be constructed using CORBA, Java, SCA/SDO, Web Services, REST etc. The implementation mechanism that one chooses should support interoperability, federation etc. Currently XML Based technologies provide the best interoperability both in communication/exchange but in vendor support, standards, tooling but this may change over time and probably will.

So if a person asks me what SOA is, I simple identify it as a design paradigm for developing and evolutionary distributed architecture. It has its basis in OO, AOP, EAI, BPM and other styles. It is like the Bruce Lee of architectures having evolved from various fighting styles.

SOA Design Patterns

As part of the SOA Symposium I was excited to watch the release of the latest Prentice Hall title, SOA Design Patterns by Thomas Erl. This is a large effort and I was fortunate to be asked by Thomas to participate in a contributing author capacity. Over 80+ patterns are outlined and include many of the speakers at the SOA Symposium. It is good to see such cooperation and the development of more independent material for the international audience. Some of the patterns are available at www.soapatterns.org which will be updated to match the book as well as candidate design patterns.

Another title that I am very interested in reviewing is also another Prentice Hall title, Web Service Contract Design & Versioning for SOA.

SOA Symposium 1.0

Well it has been quite awhile since I have posted but now that I have a few minutes I figure I would discuss my experience at SOA Symposium 1.0 in Netherlands, Amsterdam. I am working for SOA Systems delivering SOA training this week and was fortunate to speak at three sessions and participate in a panel discussion with my peers. I was very impressed with the quality of sessions and speakers that were able to take time out and share their thoughts on the future of SOA. Check out www.soasymposium.com and look for publicly available content sometime in the future.

There was a lot of discussion on how SOA Governance is becoming more important along with more efficient platforms and alternative consumers. One common thread in my discussion with attendees was how important the people quotient is in creating a successful SOA.

Cape Clear ESB (Workday) Assemblies Context Options

One client I am assisting is the Cape Clear ESB and it Assembly functionality. This provides mediation support via a Spring Bean configuration file which is generated via graphical drag/drop tools. Because the Assembly Service is stateless and the project we were working on required some context sharing, we had to open up the covers and learn about org.springframework.context.ApplicationContext and org.springframework.beans.factory.InitializingBean. A single bean with a scope of singleton was developed to provide context for all instances of the assembly and when the assembly was loaded this information was initialized as part of the afterPropertiesSet() method.

Within each instance of the assembly, Cape Clear provides another context called com.capeclear.mediation.MediationContext which provides a setProperty() and getProperty() method. This provides simple storage of variables within an instance.

XACML: An option for authorization

I am currently taking the next step in security development learning about XACML from www.oasis-open.org. In the scenario that I am working on with the client, there Identity Management Solution will be acting as the Policy Authoring Point whereas the ESB that we have deployed will act as a Policy Enforcement Point and Policy Decision Point. Due to the fact that we have a clustered ESB a decision that we are mulling over is whether to have a central/shared directory for XACML Policies or use the support for XACML Request/Responses to do it real time. Our concern is the latency especially in a high volume environment and we are currently steering towards a shared directory. This will allow each ESB to take a portion of the load and keep the processing local.

As part of a SOA Solution we will be using Service Agents or Intermediaries to support the authentication (SAML) and authorization (XACML). The ESB provides out of the box interceptors for both of these and only requires that the Service Consumer be able to interact with the SAML Provider.

SAML

Well it's been awhile since my last post but work and life have been quite hectic. Currently I have a client that is attempting to integrate a Identity Management/Policy Decision application with their ESB. As part of this effort examination of the many options has presented itself and we have agreed to examine the Security Assertion Markup Language as a potential solution. The overall use case is to have internal/external clients use an SSO approach towards invoking available services.

To demonstrate this capability a SAML Assertion will be inserted into the SOAP Header of a request. The deployed Web Service in the ESB will include Message Processing Logic in the form of an interceptor. The interceptor will examine the SOAP Header and SAML Assertion. At this time, it will be absent of a Digital Signature which adds an additional layer of integrity for the Assertion. The other challenge is the use of SAML 1.0 versus the current supported version of 2.0. Fortunately, the PDP has support for SAML 1.0 eliminating the immediate need to custom code 2.0 support.

For a sample SAML Assertion, check out the Sun Web Site at:

Sun Sample

and OASIS which manages the specification.

OASIS Site

Service Scalability

Over the past few weeks I have spoken with several customers who are implementing SOA in various stages and have decided to employ Web Services as the foundation. One of the key concerns is scalability and the ability to handle large volume for public / private services. An approach that evolved from these discussions was the following:

- For new services, specify governance in the Service Analysis / Modeling phase. This should specify the SLA for the Service and help identify the potential reuse and usage pattern that may be experienced.

- Services typically begin with a single instance using protocols such as HTTP

- Service scalability should be tested via Performance tools to determine how it degrades with load, supportable performance etc.

- Services should be monitored using JMX or similar API to determine runtime usage and usage patterns.

- Make services stateless so that they can be easily clustered.

- If service usage is higher than anticipated, consider configuring a cluster of service instances and use Hardware or Software load balancing.

- If throttling is desired, have service instances read requests from a JMS Queue as this places an abstraction between the service consumer / service provider. Queues allow for asynchronous communication and persistence point for inbound requests. Services can then throttle how quickly requests are processed without losing messages.