SOA
-
I've been taking more of a look at Service Oriented Architectures after hearing about some high profile companies using it. I have to admit that it sounded like more of a fad at first, but as I read more about it and delve into Service Broker, it seems that it's an interesting way to structure your application.
I caught a few articles, one general one and one Q&A with ConWay, a trucking company, that talks about their use of SOA. What I'd like to see more of, from MVPs, consultants, and others actually building these applications, is a straight comparison of how they'd tackle an application, both with and without SOA.
I've seen lots of technologies come and go in my life. Some hyped, some quietly being implemented, but in many cases what seems to be the biggest problems is that lack of knowledge by a large section of developers. Without the developers, nothing builds momentum, no matter how well it's structured. The big wins of the last 20 years, VB and Linux, have come about because of huge grass roots support from the people that do most of the grunt work. Developers in corporations building applications spurred VB from a Bill Gates hobby project to one of the most widely used languages in the world. Linux grew from hundreds of thousands of developers and system administrators wanting to tinker and tweak with the OS, something Windows didn't allow.
I think Service Broker is a great addition to SQL Server and while it makes for a more complex design, it seems like it would pay huge dividends down the road as you scale out your applications and need to expand the interactions between disparate applications. I've barely begun scratching the surface of it and I'd love to see more articles and samples of it's use as much as most of you.
I'm not sold that SOA will rule the world the way OOP has changed programming, but I think it has the potential. And I'd love to see more and more technical articles written that can better explain, at a lower level, how to build this architecture into your environment.
-
I've been looking into this as well, as far as I can see it is really just good sense formalised.
Having a monolithic code and fix built legacy app to moan about certainly gives me a chance to see some prime examples of exactly how not to build software.
I mean, isn't a DLL the same as SOA? Isn't it just an extension of three tier logic? Sure there is an increasing concentration on language irrelevance but at the end of the day if you've structured your DB so it can execute controlled atomic business transformations then you've done your job as a DBA and provided the basis for an SOA app. All you then need to do is provide hooks into your logic to whatever interface requires it, which is getting easier.
Personally I think CLR in 2005 is a bit of a bum steer, surely you shouldn't be surrendering bottom line control of the database to procedural languages, that way lies madness....
Or perhaps I'm just old fashioned?
-
I guess what I despise about our industry is the need to come up with something new to make our efforts at making a business or other type of enterprise run. Yes it is good to formalize better ways of doing something... However, better in what circumstance?
All computer tools, be they databases or operating systems, or programming languages, or methods of applying any or all of the above can be good if properly used and applied.
What I've seen in my history is the next new buzz word coming over the hill and if you answer honestly what you know about the subject, quite often you are considered NOT quite what we need for the job:-)
What companies need is honest technical managers that quite telling the board what they want to hear, and letting them know that just replacing the CIO is not going to make the cost of IT go away or reduce costs significantly. And the next NEW "thingie" coming from the key note speaker is probably just an old technology that has been refined and maybe even improved, but will still cost a lot of money to implement and have it's own set of problems:-)
I'm not against SOA, but I hate the siren call of the "new" stuff...
-
Richard,
I don't think it's an extension or it's like a DLL. The premise of SOA is truly disconnected, lously coupled systems. If system A needs system B to do something, it can send a message, not requiring a real time response. Maybe it's fancy error handling, but it really allows things to continue to flow when a tier is down. At least in places where it's possible in the business sense.
If the order processing system is down, does that mean we stop taking orders? If I deploy a bad DLL in order processing, the factory might stop, but also the order entry system in many monolithic applications. In an SOA environment, the sales orders can still come in and be Q'd and when the processing is fixed, it picks up the orders.
To me it's a kind of new middleware by architecting your application in pieces, as separate applications instead of one big app. It also should theorietically encourage more reuse since you can "ping" an already existing application for data without needing to pull in its code.
William, I don't think it's the best new thing, but is an interesting idea. It's similar to things I've built in the past, even in SQL Server, trying to disconnect functions from being too tightly coupled. Actually many of us have done this by putting emails in a table rather than a trigger or stored proc, and then having some other process pick them up.
-
I think the key question you have asked is "how to build this architecture into your environment".
Slowly. If you already have many established applications running, but not really working in conjunction with each other, then you are up for a big change.
If you're just starting out, you need to be Nostradamus to build it right first time for a business that is expanding.
Either way, some significant effort is required. This is actually a good thing. It forces businesses to actually focus on how the business operates. All too often when you go into a business to establish the requirements for a project, they are barely aware of how all the systems are or at least should be connected.
Sometimes the introduction of software should be accompanied by a change in the business process when the focus is improving the business. The alternative is just to map the old process into an application and be done with it.
SOA allows us to take a broader look at overall business processes in an attempt to streamline the business.
I'm not sure you can say that SOA is a technology, but your reference to OOP is more realistic. It is a mindset, a way of achieving a goal that hopefully provides benefits over other methodologies.
You also mentioned middleware. Like BizTalk and the other tools from other companies that do similar tasks. These are just tools that are part of the SOA mindset.
Personally, I like the concept because of the loose coupling. It makes for a much more robust environment.
- What I'd like to see more of, from MVPs, consultants, and others actually building these applications, is a straight comparison of how they'd tackle an application, both with and without SOA.At some point I will put an article together on this, but here is a real-World, albiet simplified, example (ever notive that SOA discussions are always conceptual?):SITUATION: A user is browsing your on-line catalogue. You want to collect data about the user and the products (product, language, OS, login ID, etc.)Below are two options. In both cases, you can get the info through either the QueryString, Session variables, or an encrypted string in the URL. In the footer of all pages that collect info, you put a hidden iframe page. Something like this: <iframe src='WebTracker.aspx' height='100%' width='100%' frameborder='0' scrolling='no'></iframe>OPTION 1: Get info from the web page then execute a Stored Procedure to immediately write the data to a tables(s)OPTION 2: Get info from the web page then immediately write a message to a message queue. Have another process (program or service to be precise) that reads from the message queue and executes the Stored Proc that you would otherwise use in Option 1.The obvious advantage is that you do not need to connect to the db for every web page hit. But, "loosely coupled" can be a bit of a misnomer because you do need a connection to the message queue server.Here is some of the code (it's not exact, but you get the idea):OPTION 1:SqlConnection conn = new SqlConnection();
conn.ConnectionString = System.Configuration.ConfigurationManager.ConnectionStrings["MyConnectionString"].ConnectionString;
conn.Open();
// Connect to database and run stored procedure
SqlCommand cmd = new SqlCommand("InsertFactData", conn);cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add(new SqlParameter("@ApplicationID", myTrackerInfo.ApplicationID));
cmd.Parameters.Add(new SqlParameter("@SessionID", myTrackerInfo.SessionID));
cmd.Parameters.Add(new SqlParameter("@IsNewSession", myTrackerInfo.IsNewSession));
cmd.Parameters.Add(new SqlParameter("@ViewDate", myTrackerInfo.ViewDate));
cmd.Parameters.Add(new SqlParameter("@LanguageCode", myTrackerInfo.LanguageCode));
cmd.Parameters.Add(new SqlParameter("@CountryCode", myTrackerInfo.CountryCode));
cmd.Parameters.Add(new SqlParameter("@OSID", myTrackerInfo.OSID));
cmd.Parameters.Add(new SqlParameter("@ProductID", myTrackerInfo.ProductID));
//Execute the command.
cmd.ExecuteNonQuery();// Close database connectionconn.Close();
OPTION 2:System.Messaging.MessageQueue mq = new System.Messaging.MessageQueue(m_Queue);// Create the message from the TrackingInfo object
TrackerInfo MyTracker = new TrackerInfo();
MyTracker.ApplicationID = this.ApplicationID;MyTracker.SessionID = this.SessionID;
MyTracker.IsNewSession = this.IsNewSession;
MyTracker.ViewDate = this.ViewDate;
MyTracker.LanguageCode = "NA";
MyTracker.CountryCode = "NA";
MyTracker.OSID = 0;
MyTracker.ProductID = 0;
// Create a new instance of a message
System.Messaging.Message newMessage = new System.Messaging.Message();newMessage.Label = "WebSupport";newMessage.Formatter = new XmlMessageFormatter(); // BinaryMessageFormatter();
newMessage.Body = MyTracker;
// Send messagemq.Send(newMessage);
WRAP-UP:At a later point you open the queue, get the data, and use that to run the insert stored proc. There are HUGE portions of this that I left out (opening the queue, the TrackerInfo class, and about half of the data fields), but the core of the idea is there. -
I think SOA gets both under and over used. Sending email is a great instance where you can build a service that many apps throughout the enterprise, and it encourages you to add more power (auto zip of attachments for example). FTP is another. I have a table where I can add a row that describes how to get the data for an RSS feed and a service to process it. Is that SOA? Anyone can add a feed for anything, so sort of? I see a lot of effort to make everything a queue and everything a service, and I think that goes too far.
I don't think DLL's fix the standard SOA description, but they admirably fit the job of loosely coupled design - assuming you actually will use it across applications. I'm far more interested in loosely coupled design. If I get that from SOA, DLL, or some other magic, doesn't matter to me! I've seen the benefits of loose coupling too many times.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply