SOA

Developer Book Syndrome

Ben Kloosterman — Sun, 01 Nov 2009 13:33:07 GMT

A colleague of mine once stated that creativity is rare in technical people I had my doubts at the time as I’m fairly creative and often build unorthodox solutions tailor made to the problem but the longer I’m in the industry the more I agree.

The biggest symptom of this is something I called book syndrome. This is where famous author xyz ( eg Lowly , Fowler etc etc ) writes a strategy in a book and people use it in completely in inappropriate circumstances. When challenged on the solution they use the authority of the author to emphasize they are doing the right thing. While this technique may provide some job protection it is questionable that the famous author intended to apply it where it was applied ( eg Juval Lowly SOA 1 service per class ) and in many cases like Fowler there are many methods yet a single patterns is repeated ad nauseum without any concern for the special cases for each project..

And it is not just books, Universities have a lot to answer for drumming in OO yet for a lot of small to medium projects scripts and RAD provide better and more consistent results ( OO /RAD is Software theory relevant) . The fact is the bedrock of nearly all programming theory is based on 90% of the cost of an application being maintenance while true in the 50-80s this is clearly not true in the huge amount of small applications and scripts that never enter software studies ; in fact most of these programs never change over the life time of the program ( and are completely rewritten in a new technology after 10-15 years) is completely at odds with most of software development theory. I’m not against OO but I am against using OO in many inappropriate situations ( eg blindly following book – book syndrome) – even in an OO house RAD development will be faster , cheaper and deliver more reliable project deliveries.

The whole concept of an OO development house , an SOA house or a RAD house seems very wrong . Each has their pros and cons for each project and any competent team should be familiar with all techniques and use them where appropriate.

Every project needs to be taken on its own merits and facts like these are FAR more important whether OO is better than RAD or SOA.
- Amount of change /maintenance over the life of the project
- Fixed price contract
- Team skills (Architecting for the team)
- Breaking down the work ( eg SOA service layer and RAD front ends)

SOA 1 class per service Juval Lowy framework

Ben Kloosterman — Sun, 01 Nov 2009 13:12:25 GMT

I posted this a year ago.... I'm really against this make each class a separate service concept. It reminds me of the Microkernel and especially workplace OS but worse. The idea of microkernels was each service ( like memory) was an easily managed entity with carefully defined inputs and outputs which could be consumed.) Workplace OS took this to limit and performance was so poor that no amount of optimization would help. So they had no choice but to scrap the project ( were talking $2B 10 years ago) the bad thing is once such a design is made and implemented just like workplace OS it is very difficult and expensive to fix. Classes by nature frequently communicate with other classes ,serializing everything makes this far to slow. Think about big orders with 10,000 line items each line item could be a separate service call to add up some total and what do you gain ? I consider service to service communication and some sort of nearness analysis a vital part of SOA and grouping related classes into services will help significantly by - Increasing performance - Allow for better maintenance and less change as related changes will deploy together . - Allow for better OO/maintenance and Agile techniques within each service. ( though less outside) - Allows better integration and use of different services such as Java , CRM/ERP services etc. - Encourages chunkier cross service calls and better attention paid to the service interface ( for easier use, compatibility/maintenance and performance) - Discourages the service as a DB store proc wrapper. - Avoids having to put performance hacks in the wrong place to try to avoid cross class calls. This does not mean services should be 20 classes 3 is a good line but 1 to 9 is ok in a number of cases depending on class relationships. Basically if 2 classes communicate all the time they should be in the same service. I can see in 5-15 years hosted environments/frameworks hosting classes which can be moved to machines or be in proc though its far too early for this and you NEED the ability for classes to communicate via normal inproc ( without serialization) . I not you mention this for the future but telling people to use each class as a service now without some more comments on the hazzards ( especially when they don't have a lot of experience in SOA) will lead to a lot of frustration for some .

Can EDA SOA eventing systems be fast

Ben Kloosterman — Fri, 10 Jul 2009 03:01:03 GMT

A lot of traditional eventing systems use C++ and are dubious about whether the Lego block style SOA can provide sufficient performance.

Again it boils down to design

WCF C# can process over 22000 small messeges per second on an average 2 year old quad server. http://msdn.microsoft.com/en-us/library/bb310550.aspx#wcfperform_topic4.

This is more than sufficient for most applications especially as with eventing systems you can add servers relatively simply , the algorithms which manage the propogation of subscriptions and the path are far more important . ( Distributed Event-Based Systems (Muhl , Fiege and Pietzuch) is a good book which covers the theory here .

The other big issue often sited is latency but EDAM ( which uses Windows Communication Foundation ) has sometimes achieved cross machine rates of 3ms again the design is critical here if you pass through 6 nodes each adding 20 ms it can become quickly unacceptable. Often people will use all the features of SOA such as queues , transactions , encryption etc yet wouldn't implement these on a typical C++ system these can be killers , don't use them unless you HAVE to and since most C++ eventing systems dont you better have a good reason. .

I would also add Network latency between companies , cities or even countries add far more significant delays. With human reaction being about 120ms (At best) the small delays these services add are insignificant.

The end result is you CAN build lego block style SOA , high speed eventing systems with a good a design and gain all the SOA benefits .

You could argue computer trading systems require better times but again i think the small differences you will get ( single figure ms at best ) are more than outweighed by a flexible design. eg instead of running the trades on the clients premises , critical trades can be uploaded to a providers machine near to the exchange this is often hard due to inflexible implementations . A strong and flexible design means more optomization can be made more easily eg message priritization , packing multiple data messeges for efficiency etc

Like premature code optomization the desire to be as fast as possible does not outweigh good progamming algorithms and design.

Ok i said it enough a flexible and strong design is far more important than premature optomization and making things as fast as possible,

Why should you use an Event Driven Architecture (EDA)?

Ben Kloosterman — Fri, 27 Mar 2009 02:14:01 GMT

There is a lot of documentation on EDA and people working with SOA and call backs will naturally gravitate to EDA , but i have often wanted a simple reason why. Here i will attempt this and focus on service based EDA's.

1. It Naturally mirrors organisations.

High level EDA events are business events. With EDA anybody may receive these events and act accordingly. This means extending events to new applications is a trivial excercise.

2. Low integration costs

Integration expenses are massive, EDA makes it really easy for systems to communicate even more so than SOA's which require writing a system to interact with the appropriate services. With an EDA an admin can add a subscription and the appropriate messages will be sent to new system

3. Lower hardware costs

Sure machines are cheap but for large scale systems ( where EDA's shine) going from 500 servers to 10,000 servers is a big hit.

4. It is simpler. Information which EDA's are good at often have to be polled .

EDAs are often used for live events , when something happened with simple SOA services or with Databases this requires frequent polling. Polling results in significant overheads and thare a few issues to ensure you dont get duplicate data.

5. Information is live. Anybody including clients can get information as soon as the company receives it . eg Bank transfers , courier scannings,share quotes etc

6. It brings organisations and their IT systems together.

The easier integration and the capturing of real business events mean other IT teams are more likely to use them , this results in less duplication and technology islands. ( Though see below)

7. It allows groups to be autonomous and still work with enterprise events.

One of the big issues with SOA /large DB systems is its big centralised IT. You sometimes need to meet standards etc . These standards are required since a single consumer can bring down the whole DB , With EDA down stream system systems provided little or no impact and hence can go unrestricted. This allows quick and dirty systems needed for a new startup within the company to see if it is viable etc. Futhermore you have a lot less restriction on the data you get , you are not required to use certain Service operations or stored procs. You can use any Xpath query and have the information you need in real time and can then store and use it yourself.

8. Strong EDA's can result in smaller duplicated Data stores.

In small organizations EDA will result in single data storage , in larger ones duplicate data will normally evolve , these will not have the same information but there will be overlap. This is good as it allows the appropriate business to manage the data.

9. Creating a good EDA can be easier to implement than good SOA's.

Creating a good SOA is hard , you need to consider Data ( multiple service access ?? ) , orchestration , polling ,Service Bus , Data ware housing etc

With an EDA based SOA the focus is on Events and hence has a looser policy on SOA's , things like Data storage are up to the individual team who may or may nor share.

The key point here is the focus is and remains on the important part of the architecture the actual business events. SOA systems tend to wonder as vendors write many pages on their products and people spend a lot of time learning them and debating technical issues.

10. Completely loosely coupled

The sender knows nothing about the receiver and hence dependencies do not form.(Which also leads to lower integration costs above) .

Weaknesses

1. Not suitable for most small companies

Like SOA's its pointless using EDA for a small part of the enterprise. Its like designing a big building but make 1 apartment have full height curved windows. The one exception is companies with lots of monotoring systems as these are by definition event driven and hence map well to EDA's (Stock Brokers , Couriers , Police /Security , Military ,Aviation etc)

2. No Shared Data .

EDAs dont have any form of data storage and hence you still need these in your EDA . However they work well with Data warehouses which can store the data from the events it receives. EDAs dont work well for firms with massive data processing ( eg Credit card bonus point provider).

3. All data is live ,so bad for partially connected systems like mobile phones.

Partially connected systems need a store retrieve mechanism ( Note our EDA system EDAM provides this)

4. Need capability to receive events

Receiving events requires a dynamic subscription or a fixed Ip address. Dynamic subscriptions in WS-Eventing are a bit clumsy . Note EDAM has a Windows Communication Foundation interface to make this easy. .Net services ESB also helps get through firewalls to receive events.

EDA vs Cloud storage

Ben Kloosterman — Fri, 27 Mar 2009 00:55:33 GMT

Cloud storage promises a lot of the things that EDA does namely almost unlimited scaling however EDA implemented in the Cloud has significant advantages.

Firstly while Cloud storage Data may scale extremely well , it does so by using masses amounts of caching or disk spindles. In itself this is not an issue but if you have say 1,000,000 users querying/polling a 10 Gig Table While the performance is likely to be good the CPU usage will be massive and this is where cloud computing bites you - in the pocket. And the situations will get worse as data increases.

However EDA implemented in the Cloud immediately gives you a massive reach and can be combined with a Bus like the .Net Services bus to control access and get through firewalls.

SOA and Cloud computing

Ben Kloosterman — Fri, 27 Mar 2009 00:45:00 GMT

Great article from Zapthink. . Especially
"
the ESB has been far too central in organization’s discussions about SOA. The logic goes that all you need to do is develop a bunch of Web Services, plop them on an ESB and voila, you have a SOA. Isn’t it amazing that you can get architecture without actually doing architecture? As ridiculous as this might sound, for many organizations, this approach represents fully their SOA strategy. But, the movement to cloud computing throws the ESB “strategy” out the window.

In the cloud computing world, you have no visibility into the infrastructure, nor do you know where and how it is implemented.

By: Ronald Schmelzer
Posted: Mar. 25, 2009

In our previous ZapFlash, ZapThink Managing Partner Jason Bloomberg explored the recent upswing in interest in Cloud Computing and evaluated its merits vis-à-vis Service-Oriented Architecture (SOA). In that ZapFlash, Jason concluded that cloud computing is an ill-defined term that has turned into a bandwagon that vendors, consultants, and end-users alike are jumping on without asking first where they are going. He also complained that there is a broad chasm between the sort of public clouds espoused by organizations like Amazon and the internal do-it-yourself clouds that large vendors would like you to sink your time and money into. But, his biggest bugaboo was that too many well-intentioned individuals and organizations are jumping without doing architecture of any sort, let alone SOA. Lack of an architecture perspective, preferably a Service-oriented one, is sure to doom any cloud computing effort just as much as it has doomed Web Services on a Bus efforts branded as “SOA”.

However, that’s not ZapThink’s final word on cloud computing. In this ZapFlash, we’d like to take a different perspective on whether cloud computing holds water with regards to SOA. In particular, there are some aspects of cloud computing that positively inform SOA and vice-versa, and allow us to shift the conversation of SOA beyond what many still consider to be standards-based integration.

Finally… a Reason to Stop Talking about ESBs
One of the best reasons to bless the cloud computing movement is that it finally allows us to shift the focus away from the Enterprise Service Bus (ESB). As you may recall from a number of previous ZapFlashes on this topic, the ESB has been far too central in organization’s discussions about SOA. The logic goes that all you need to do is develop a bunch of Web Services, plop them on an ESB and voila, you have a SOA. Isn’t it amazing that you can get architecture without actually doing architecture? As ridiculous as this might sound, for many organizations, this approach represents fully their SOA strategy. But, the movement to cloud computing throws the ESB “strategy” out the window.

In the cloud computing world, you have no visibility into the infrastructure, nor do you know where and how it is implemented. Indeed, you can both provide and consume Services without having to give a whit about the stuff in the middle. After all, that’s why it’s called cloud computing and not “vendor A’s bus” computing. Not only can you build a perfectly good SOA using a cloud as your infrastructure, but it might actually be a best practice to do so. In our Licensed ZapThink Architect (LZA) boot camps, we frequently espouse the position that Services should be designed to be location-independent, implementation-neutral, and distributed (potentially heterogeneous) intermediary based. A good cloud implementation should allow you to do all three.

With all this cloud goodness, there’s no need to even have to start your SOA planning by buying (or contemplating buying) an ESB. Design your Services to be infrastructure neutral and you can put them in the cloud or on existing infrastructure or on network intermediaries. Does it matter? No. This of course means that you should beware message queues that turned into EAI platforms that turned into ESBs getting turned into “cloud platforms”. Remember that you heard that warning first here, from ZapThink.

There is a major difference, however, between organizations that might leverage a third-party cloud as their SOA infrastructure from those enterprises that may want to implement their own internal clouds to serve as their SOA infrastructure. For the latter, you’ll still need some sort of infrastructure to make the Services behave in a cloud-like manner. However, odds are that it won’t look like what your current ESB looks like. After all, if a cloud was simply a message bus, then why don’t we call it such? Odds are that an internal cloud will look like more like the old grid-based computing infrastructure with massively redundant systems and virtualized compute infrastructure. In any case, the when the SOA conversation turns to cloud, it will necessarily have to turn away from being ESB-centric since there will be many more options for your SOA infrastructure deployment.

The Power of Service Virtualization
Another benefit of adding cloud computing to the SOA mix is that it allows us to consider the power of virtualization from the outset of designing our Services, rather than as an afterthought. In our previous ZapFlash on this topic, Jason complained that virtualization and SOA, while good in concept to combine, are not done so in practice because the people involved in the virtualization efforts and the SOA team are usually different people addressing different issues. However, that does not need to be the case.

Indeed, planning to use a cloud as your SOA infrastructure will require you to think about how to design, manage, govern, secure, and compose your Services from a virtualized perspective. At a 30,000 foot level, virtualization as a concept requires you to abstract a single instance of a particular resource as multiple. This means that a single storage resource becomes a virtualized many, as does compute and application resources. From a SOA perspective, Service virtualization therefore means that there should not be a single implementation, contract, composition, or process for the Service. Rather, each of these things should be virtualized so as to minimize the impact of failure, improve overall performance, and allow for variability and flexibility when things change. By focusing on movement to cloud computing infrastructures for SOA as an excuse to design virtualized Services, you are doing yourself a favor, even if you don’t end up deploying those Services in a cloud.

The ZapThink Take
This brings us to probably the biggest benefit of this whole cloud computing hoopla – a change in the way we think about Services. For those of you who have long considered Services to be location-independent, infrastructure-neutral, network intermediary-based, process-focused, and contract-driven then the cloud computing movement doesn’t really add much color to your SOA vision other than confirm what you have already suspected about SOA: you don’t need Web Services and you don’t need an ESB to make SOA a success. However, for those that have equated SOA with Web Services and ESB, they might see this looming cloud computing movement as the next iteration of their SOA efforts. For these readers, we would say, “finally!”

To properly implement SOA, you need to have abstraction as your primary perspective. But this also needs to be your primary perspective when you implement cloud computing initiatives. Service-oriented cloud computing is in many ways a redundant statement. Not having a Service-oriented perspective on cloud computing means you’re building tightly coupled clouds, which in theory should not even be possible. Having a non-cloud perspective on SOA means that you might (potentially) be building infrastructure-coupled Services that are not properly abstracted. While it’s certainly the case that you can build non-cloud SOA just as you can build non-SOA cloud, the reality is that one informs the other to the extent that it changes your thinking on each concept, even if you don’t implement the other.

Designing Services as if they would be implemented in a cloud, even if they are not going to be, helps you to build Services they way they should be built. Likewise, implementing cloud infrastructure as if it would be the core infrastructure for your SOA, replacing your ESB usage helps you to build a properly abstracted and agile cloud infrastructure, even if it never handles a single Service request. And this is why in many ways cloud computing can hold water. The question is, what will the future of cloud computing be? The dark, stormy cloud that is more like fog described in our first ZapFlash, or the silver lining on wispy clouds described here? The choice is not really ours. It’s yours. After all, you can’t buy architecture… you can only do it.

WS-Eventing flaw

Ben Kloosterman — Sun, 15 Feb 2009 04:39:47 GMT

Just doing some work on eventing and having a look at a number of implementations there is a pretty annoying feature / flaw .

By default the only filter supported is Xpath and the specification specifically states that

This specification does not constrain notifications because any message MAY be a notification. from http://www.w3.org/Submission/WS-Eventing/.

I have no issues for this - sometimes you want any message , however this is a very expensive way to do this especially when you have a large amount of events with different topics all coming through a single notification service ( load balanced) .

All the implementations i have seen ( including the sample in the specification ) introduce the concept of a topic to route the data.

eg

Sample in spec uses a header

    <ow:EventTopics>weather.report weather.storms</ow:EventTopics>

and a custom filter

 <wse:Filter xmlns:ow="http://www.example.org/oceanwatch"
(43)           Dialect="http://www.example.org/topicFilter" >
(44)         weather.storms
(45)       </wse:Filter>

MSE ( Managed Service Engine from Microsoft)

Uses a custom filter http://services.microsoft.com/2006-07/ServicePlatform/MSE6/Eventing/EventFilter/ which includes topics in the body of their custom event message.

Roman kiss implementation includes a string topic in his subscribe message and has one topic per notification end point.

The end result is everyone will build there own system and filters.

Basically all the authors recognize that the default spec will have performance issues and can be easily optomized ; So why didnt the spec include an optional header on notifications and a simple canonical topic/subtopic filter ? This way the majority of eventing systems can talk to each other without resorting to XPath.

Why use Queues ( MSMQ) in services ?

Ben Kloosterman — Mon, 09 Feb 2009 02:43:38 GMT

Queues love them or hate them seem to be pretty popular. I'm definetly on the hate side especially persistant queues

Lets look at some recommendations

Use private queues. Very few applications need public queues and the performance hit is substantial.
Use non-transactional queues. Again, very few applications need transactional queues.
System.Messaging is messed up in a lot of ways, but you can work around that.
Use the asynchronous methods of System.Messaging (BeginReceive and BeginPeek) where possible.
Learn to build your own formatter for System.Messaging.

I agree with all these but is this how queues are used ? No.

Queues tend to be used in 3 scenarios

To capture a critical piece of information ( persistant queues)
To handle a slow legacy system.
Integrate with non .NET systems

Integration is better handled by SOAP or REST services.

Slow legacy systems can be handled better with Workflows and Windows Communication Foundation throttling.

Capturing a critical piece of information is better handled by Workflows or SQL . eg since you need to record the data in a DB anyway, create the data and workflow and if it fails notify the sender. Note Transactions may be used here.

Why not just use queues ?

Its not simple , it looks simple but a real implementation has a number of complex issues ( Poison message and performance/scaling especially)
in scenarios where the the client cant be notified it still not a good idea to use a queue as the code that adds the item to the queue may also fail.
Poison messages / Journalling . This is probably the worst thing - especially when receiving messages from different systems. A single message can block the queue and your system as effectively as hitting the power switch. The solution is to move the message to a new queue increasing complexity and the idea of a simple queue. However you now have a message that the system failed to understand so you need to handle it and remember the client thinks you have handled it . Often custom systems or manual intervention needs to be done to handle these.
Persistant message Queues use local disk that needs to be managed. Run out of space/quota due to a large number of transactions or poison messages over time and your queue stops. ie More infrastructure to manage , more things that can go wrong.
Scaling . Queues do not really scale past the single machine / processor. Most people use persistant/transaction queues which are bound by disk performance of a single machine. Multi-threaded processing of a queue is possible but requires threadsafe code (which most web or Windows Communication Foundation services do not) . You can use a load balancer and write to multiple services each with their own queue but you break the concept of a single queue ( eg a legacy system can now receive requests from n services and can become overloaded ) you now have n queues and the queues just become the transport for communicating to each service . Each machine needs to have the queues a and local storage for persistance configured. Lastly poison messages need to be dealt with at each machine.
Clustering works, but it is difficult to configure correctly and malfunctions often ( well Microsofts one does) . In addition, to run Microsoft's Cluster Server you must also run Windows Server Enterprise Edition which is costly. Note this tends to be a fallover cluster.
Default serialization is custom.
Many people try to write local and read remote from queues.

Here is a great article on using MSMQ tips http://www.devx.com/enterprise/Article/22314/0/page/1 note the recomendation is to turn of all the things people use queues for.

So what about the alternatives?

For a start we need to consider the alternative which is a plain WCF tcp service. We get security , scaling performance and transactions. We don't get persitence ( though long running services /WF does give you this ) and the concept of capturing as much critical data as possible even if there is a system fault. .

To handle this I prefer some simple code (and hence reliable) that stores critical information like orders immediately in a DB (after some basic validation eg not empty , has a customer etc ) and if successful returns this to the client , if not it will tell the client why and an appropriate error ( which help the client use and like the system) . Note this code is similar to the code that would put the information on the queue ( this is normally pretty simple must work code also ) .

You can then calls a process function via worker thread ( or in larger systems a seperate service can retrieve the record or workflow from the DB and process it this process can be sequential and or parallel if needed , note DB maybe a persisted workflow) . This remains simple , reliable and can scale . Best of all records that fail can be processed as normal eg an Order that fails to process is an order in the db and an order management app can probably bring it up allowing you to see it. ( All apps including queues need to handle bad user data anyway)

Please note while a Workflow is almost ideal and can contain the data i would not do this and store the data seperately . The main reason for this is Workflows (up to 3.5 , i dont 4.0 ) uses binary serialization which if you change the assembly version can give you a lot of grief in retrieving a workflow. Its better just to have the data seperate so you can resumbit it for processing if needed. If Workflow had an xml persitance representation id probably consider ( especially for smaller apps) just saving the workflow as you could manually retrieve the information in a meaningful format from the DB .

What is Azure Services ?

Ben Kloosterman — Sat, 07 Feb 2009 02:21:46 GMT

Are Azure services a cloud or are they an ESB ?

While Azure does not have this it has FAR more than most ESB in terms of connecting clients to services. Sure it has router support

Azure >> ESB (Internet hosted , with integrated internet security , scalable)
Azure >> Cloud computing ( not just Client - Service routing and hosting but also it has sender-receiver relay , multicast , firewall pass through , and enterprise-cloud security integration)

The big thing is people see it as a cloud .. however i think the biggest thing is it can redirect clients requests into your internal systems ( or partners!) in a secure manner with a global logon. Or facilitate secure communication between clients and companies ( as well as B2B)

A lot of people say the Enterprise will not put services in the cloud - i dispute this. VPNs are used to drive many branch offices which was not done earlier its a question how comfortable they are with the management and security. Like outsourcing to india.

Windows Azure services - First impressions

Ben Kloosterman — Fri, 06 Feb 2009 00:55:23 GMT

I have been looking at the PDC cast of Windows Azure and all I can say is wow.

At first i thought it was just another cloud but its a new generation compared to other offerings and most important its designed to win corporates. Integrating with current enterprise systems in a secure manner will be the key.

Will it succeed - certainly ( barring some outage disasters which will hurt them bad) . However it wont succeed just for Web 2.0 ( of which i am sceptical in the long term) but think of corporate laptops ,PDAs , small offices etc . Once resources move to the cloud i suspect a lot of corporate private framerelay /atm links may be replaced by using the cloud though this is years away.

However i think there is a certain amount of FUD involved , i may be mistaken as Microsoft could have put billions into the project but the feature list seems rich so it maybe a case v1 will be delayed or not feature complete.