WS-?????

Quite a few standards exist that are used in the SOA arena. Here is a brief summary of the most common and pervasive.

Security with WS-Security
Security can be grouped into 3 types, MLS (Message level security), TLS (Transport level security) and Mixed.

MLS refers to when the message itself is secure. Real world example would be a document in a FedEx envelope that is sealed. TLS refers to making the transport secure, so perhaps the FedEx truck is locked, but if I was to get inside the truck, I could find and potentially read the document.

MLS usually involves data integrity, aka, how do we know the letter was not altered and data confidentiality, how do we know the data is not readable by unauthorized readers.

For the later we utilize encryption xml-Enc whereas for the former we using xml-DSig or digital signatures. Digital signatures are when you create a message digest, or a hash of the content you choose to sign and then encrypt this hash with a shared secret key.

To verify integrity, the reader can create the same hash, encrypt with the shared secret and then compare the signatures. If they don't match the message was tampered.

TLS is the common network security, either using HTTP with SSL or using HTTP authentication protocols, basic etc. TLS is generally faster since we don't have the computing overhead of signing the messages, but are not as secure as MLS especially in multi-hop and/or routing scenarios. (TLS only establishes a node-2-node secure channel).

Mixed is when we use a combination of both, so encrypted document inside a secure transport. Many developers choose to use a home-grown authentication scheme (Custom SOAP Headers) in conjunction with TLS.

Distributed transactions with WS-C(AT) or WS-C(BA)
Transactions are defined by the WS-Coordination and Atomic Transactions (AT)or Business Activity (BA). WS-Coordination defines how we enlist in a transaction and acts as the coordinator.

The AT or BA component defines whether we have a ATOMIC transaction so we "block" all participants until we have a ALL PASS, or BA when we have long running transaction and the "blocking" scenario wont work. With BA we opt for a compensation model.

In these cases, we assume success but provide a compensation mechanism so if we do need to roll back, we can manually do so if notified by the coordinator.

More on Reliable Messaging in my next post...

Live & learn

Language Syntax
Having spent an equal amount of my software engineering career in the Java and Microsoft camp, I have had the priviledge to have seen many problems solved in similar ways.

In the presentation tier, there was ASP, which was followed by JSP. JSP provided us the strength of Java in a similar syntax as ASP, freeying us from harcoded HTML in Servlets. Tag libraries were mirrored by Web Controls in the ASP.Net world.

EJB followed MTS to allow scale out scenarions in the Middle Tier. Btw, ever wondered why Microsoft did not implement Entity beans? Ask the EJB containers how complex it is to cache data in objects across a cluster, while keeping them in sync with the DB without loosing the performance benefits you were trying to accomplish in the first place :).


Under the hood
It is not uncommon for companies to evaluate and leverage learning from the "otherside", and I guess it goes both ways.


But the biggest similarity is in .Net vs J2SE, or CLR vs JVM, Bytecode vs IL, C# vs Java. If comparing the language syntax is not enough, looking under the hood at bytecode and IL, you get the picture. Callvirt or shall we say invokevirtual.



All good, looking forward what the next generation Java would look like, and then the next .Net and so on and so on....

OOP vs SO

Object Oriented programming has served us well and will continue to do so. In the case of a SOA, this would imply to only inside the edge, the so-called boundary of my service. Once outside the edge, we need to think in terms of messages. Messages, unlike objects don't have methods.

I have seen too many implementations try and send Business Objects over the wire, only to notice that the business rules in the object did not make it across the WSDL. So to de-serialize the BO's and have them contain methods, we need to modify the client proxy and use a shared library so the server and client can refernce the same BO library.

At a first glance this seems like a rocking solution, but we have just violated the very essence of SOA, loosely coupled components.

Another challenge with BO's is inheritance. While WSDL 2.0 does support the notion of inheritance, again we need to move away from the OOP concepts for the edge.

The Java community often refers to DTO, Data Transfer Objects, to describe a object or structure that contains only data fields, no methods. This is the closest analogy I can think of between the messages of the SO world and objects of the OO world.

So suppose we buy of on this idea, how do we provide tranditional BO like experience in the SOA world? The short answer is, we dont. Having said this, I have seen implementations where the client exposes a BO type interface, and have the BO internalize the service proxy to do all the service calls.

So a call to User.Save(), will internally call the coresponding method on the proxy and service. Personally, I would not go this route, as this hides the fact that we are crossing a boundary and developers may not understand all the implications involved with that single statement.

Secondly the definition of the User object lives inside the client app domain. A similar user object may in fact be exposed by the service (WSDL) and generated by the proxy, so we may be duplicating the entity.

My preference is to create a Business Facade layer, wrapped around the proxies. Instead of calling User.Save(), we would call UserFacade.Save(aUserDTO), or UserDTO user = UserFacade.FetchUser(userId) etc. Hydrating the UserDTO and passing it to the Save method, just seems more aligned to the fact that a message is constructed and will be passed over the wire. I most cases the UserDTO may be the very object generated of the service WSDL.

Boundaries need to be explicit and developers should not be shielded, in constrast with DCOM, of the implications of network latency, out-of-process execution etc.

Having this extra layer of indirection allows us to swap out services, without impacting the rest of my client code.

OOP still has a huge role to play inside the edge, but we need to learn to think in terms of message when we are sending packets of information across our SOA.

And so it starts...

Finally I have entered the realm of the 21st century media, Blogging. I never was one for giving my opinion unless solicited, but hell, why not. This gives me an opportunity to improve my English.

As I am sure you can tell from the title of my Blog, I am passionate about SOA or (Service Oriented Architecture). If only I had the faintest idea what SOA really was....

My mission with this blog is to discover SOA with my audience (self + 1) and hopefully before too long, be able to crisply articulate SOA and how it will make your business more agile, extensible and ready for change.

To be honest, I have dabbled in the SOA space, and my current project involves migrating from a monolithic service based application, to a SOA. O yes, btw, the mere presence of web services does not imply SOA, nor does a SOA require web services. I have seen web services been used as a new transport, without any architectural changes, which is oddly enough the worst scenario, as SOA by the nature of the transport, SOAP(XML) is probably the most bloated wire payload.

But having delt with the worst of SOA, e.g, not the fasted distributed architecture on the block, tapping the benefits is an easy task. In my next posting, I will attempt to explain where SOA fits into the OOP model we all have come to know and love, and when to let go of OOP. Think in messages....