Architecture

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 .

Is SSL really secure/too much security

Ben Kloosterman — Sun, 12 Apr 2009 00:47:21 GMT

Is SSL really secure ? By encrypting messages on the wire people get the feeling its secure and people use it ubiquitiously.

Is encrypting on the wire something that really helps ? I don't really think so , with most networks it is VERY difficult and practically impossible to do .

eg
- In a LAN you need physical access to put a device in between reading all traffic from a PC ( in which case you have bigger problems)
- Switched mean a machine tap is not very usefull ( html is not broad cast)
- You need admin access to use a machine to tap if you have this you can install a reader in the browser which logs your actions ( without the ssl)
- Tapping internet links is not possible due to the amount of traffic. Note smaller links could be monitored by a government agency

However

- A simple browser addin via a trojan or admin access can read all SSL !

What about tapping Wireless/GSM , well wireless already has encryption . The encryption is prob harder to break then SSL due to the changing key,

So what do we get for SSL very little. Hence SSL just gives a false sense of security and wastes resources and adds complexity.

This brings me to a point i did some consulting for a number of projects for a company and the company had address information for their clients being sent to mobile phones . It was pointed out that the device only kept the clients the driver visited and it would be a LOT easier and cheaper to just follow the vehicles. We implementede it anyway as the client is always right .

Still i feel people over engineer security ....in the wrong places. I have seen systems with good SSL but laughable or no authentication ...ummm.

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.

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.

Eventing with and without Topics

Ben Kloosterman — Sat, 21 Feb 2009 12:17:16 GMT

While WS-Eventing has no support for Topics ( see last post) it is almost essential for efficient processing of messages if you have a large amount of subscriptions.

Consider the case of 10,000 Subscriptions for 10,000 Notification you are looking at 10^8 expensive xPath comparisons which will bring many servers down to its knees.

With EDA we can easily solve this problem ( compare to an overloaded DB) .

Lets say we have a Topicless share pricing feed something like

<Trades>
<Trade>
<Symbol>BHP</Symbol>
<Price>38.12</Price>
<Volume>10000</Volume>
<Exchange>ASX</Exchange>
</Trade>
</Trades>

Now WS-Eventing has a really nice feature in that subscriptions can force notifications to contain a header this header can be a Topic. Even better the EndTo can be another WS-Eventing server. With EDAm this is even easier as this subscription can be loaded in the configuration of the Notification server.
So we create subscriptions and organise the data eg by exchange then by group.

What we want is

ShareData
ShareData.Exchange.Group. Symbol.

That way actual clients can subscribe to the specific information they need ( most likely Symbol or Group )

Main Server (where the original feed enters)
Topicless (Default mode)

2nd Server ( Runs in Must have topic and server always loads all subs from Topic)
Subscriptions in the config file ( or Data ) break the data down

Subscription for Exchange add topic

eg Xpath filter = /Trades/Trade/Exchange="ASX"   Header in subscription
<Topics> ShareData.ASX</Topics>

we add one subscription for each exchange
We add subscription for each group and each code.

eg Xpath filter = /Trades/Trade/Exchange/Symbol="BHP"   Header in subscription
<Topics> ShareData.ASX.MetalsAndMining</Topics>

We now have 2 services ( the 2nd one can become many services if the load justifies it ( not needed for a cloud) ) and people can make a subscription based on the Topic and get just the data they require Better yet they can make subscription based on a cheap topic filter which would be orders of magnitude faster than xPath ( and is easier for the engine to index) . .

Lets have a look at the data , lets asume all these subscriptions are group subscriptions ( 20 groups * 500 subscriptions)   , now each Group will have 500 Notifications . The engine now only has to process each of those notifications for 500 subscriptions so we have 20 * 500 * 500 = 5,000.000 operations ( a 20 fold reduction) . O ( n* m) vs O( n * m/log(n) ) . Taking into account the difference in performance between a simple topic filter and Xpath you would be looking at 2-3 orders of magnitude improvement. which could correspond to 1 server instead of 200.

This translates into a simpler , more responsive and more cost effective system. With EDA ( and especially EDAM ) this reconfiguration could be done with no changes in code.

POS or SOA Lite TODO

Ben Kloosterman — Mon, 09 Feb 2009 05:34:40 GMT

I think Service Orientation has gone the way of J2EE/ EJB and needs to be pulled back like was done with POJO.

I propose POS Plain old Services or POSA for Plain old services architecture.

Rules.
1) There is only one rule and that is KISS.

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 .

.Net services message persistance

Ben Kloosterman — Mon, 09 Feb 2009 01:02:58 GMT

Well looks like .Net services doesn't have persistant messaging ( no queues or persistance of subscriptions ) . This will probably be address in v2 . There is a 30 second message buffer for polling replies but this is not the same.

This is especially an issue for mobile computing ( PDAs , phones etc which are often offline) and for wrapping legacy systems. Though its unlikely that legacy systems will be wrapped by .Net services ( more likely the service bus will redirect it to locally hosted services) .

Im not a big fan of queues however. See post.

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.