|
Service Oriented Architectures (SOA)
I was reading Keith Short's blog (http://blogs.msdn.com/keith_short) and his work on WhiteHorse, the new design tool that will ship with Visual Studio.NET 2005 that helps architects design their SOA applications.
I was also recently reading Micrsoft's "Application Architecture for .NET" and I pretty much skimmed over the stuff dealing with web services because I rarely include them in my architecture.
However, I see more and more mention of SOA so it's caused me to rethink some of my ideas on architecture. How many of you are building architectures that rely on webservices?
I'm not referring to those insipid examples such as retrieving weather or stock quotes, I'm talking about using web services in solutions that drive the business.
How many of you are using webservices in a totally homogenous environment?
I understand the reasoning for using them and I can see their advantages, I'm just curious as to how many people are routinely including them in their architectures today.
Mark Hoffman
Monday, April 19, 2004
I am!
I'm finishing up an InfoPath form that works entirely with webservices (fetches lookup lists, prepopulates data, saves changes).
The neat thing about it is that it defuses questions like "does it work with Oracle" or "will it run against WebSphere?" since they can both publish XML-based web services.
Philo
Philo
Monday, April 19, 2004
"How many of you are using webservices in a totally homogenous environment?"
Web services in a totally homogenous environment is architectural astronaut stuff. It can't be justified from a performance, feature, or scalability perspective, so instead it's for the vague undefined "maybe one day..." cross platform non-need.
.
Monday, April 19, 2004
SOA is simply what you get when you can't do fine
grained method calls across processor boundries.
You don't need web services to do it. Most CORBA
apps, for example, ended up with a services style
interface.
son of parnas
Monday, April 19, 2004
One reason (the main reason) to use web services in an internal environment - if an application may need to be used outside the firewall (laptop users). With web services, you just need to open port 80...
However, even inside the firewall web services can make development easier in a multi-tiered app. They *are* fatter, so it's a tradeoff, but being able to hit page.asmx and actually interact with the web service and know *that* part is working sure seemed to make things move faster for me. :-)
Philo
Philo
Monday, April 19, 2004
"One reason (the main reason) to use web services in an internal environment - if an application may need to be used outside the firewall (laptop users). With web services, you just need to open port 80..."
This is an ABSOLUTELY HORRIBLE reason to push web services.
If an RPC service needs to be used outside of the firewall akin to being used internally, have the laptop users VPN in - don't just expose arbitrary services (and likely vulnerabilities) under the all-encompassing port 80 umbrella.
.
Monday, April 19, 2004
"Web services in a totally homogenous environment is architectural astronaut stuff. It can't be justified from a performance, feature, or scalability perspective, so instead it's for the vague undefined "maybe one day..." cross platform non-need. "
This is one of the reasons I asked the question. My original view of web servies was "Hey! This is a great way to communicate across disparate systems!" And I pretty much left it at that.
..however, I'm seeing more and more people position web services as a solution within hetergenous environments. This leaves me scratching my head to some degree. I've heard the arguments for it (flexibility) but I've also relegated it to the "solution looking for a problem" arena.
Mark Hoffman
Monday, April 19, 2004
"have the laptop users VPN in"
Easier said than done.
1) Manymany broadband providers block VPN access unless you pay for their "business" plan
2) VPN over dialup can be flaky and/or painful
3) Both 1 & 2 apply to hotel/motel access
4) Because VPN from inside the firewall out is an unusual configuration, your users may be screwed if they're at a client site and need to access your servers.
I've done the VPN thing. I've encountered the full list above, and it's always painful and annoying.
Microsoft uses RPC over HTTP for Outlook access now - since I've started using that, in general if I have an IP I get email. Period. It just works.
I will grant that there need to be security analyses done before just sticking a machine on port 80 open to the world, but don't be a luddite about it either. Web services or RPC over HTTP/HTTPS for external access to internal resources is NOT a solution looking for a problem - it happens to be a damn good solution for a very real problem.
Philo
Philo
Monday, April 19, 2004
I'm not sure what SOA architectures are but since it seems related to web services .... I see web services as a controller. I write my applications to be used by controllers. I usually have 2 controllers: crons and web pages. If I needed to have an app provide web services then I'd just write a web services controller for the application. That may entail some work but I would not have to change any core functionality of the application itself.
Me
Monday, April 19, 2004
VPNs stink also because:
1. the security locks down your machine for other use
2. it's a pain to setup and debug
son of parnas
Monday, April 19, 2004
"VPNs stink also because:
1. the security locks down your machine for other use
2. it's a pain to setup and debug"
1. I'm not sure what you're talking about here, however with a bit of intelligence with routing tables, you can setup VPN connections such that only packets destined for the corporate network use the VPN. This is what I've always done, and browse the porn sites simultaneously with no problems.
2. This is just nonsense (as is the claims about it being unstable). I've used VPNs over crappy dial-up to high speed hardwired, all with absolutely minimal problems.
.
Monday, April 19, 2004
But what if we are talking about purely internal applications?
I should have said that earlier. I agree that if you need external access data that is stored internall, then web services provide a good solution for this.
I'm referring to completely internal solutions that are not available externally. I hear people recommend web services even in an internal, homogenous environment, so I'm curious if anyone is actually doing it and what their reasonings were.
Mark Hoffman
Monday, April 19, 2004
I have. Once.
Not that I would avoid doing it again if it seemed like the right choice.
In this case we have a work order tracking program that I blatantly ripped off from FogBugz (I asked Joel how he felt about it before I did though). I originally wrote it using ColdFusion since that was what we used internally for our web based apps. Shortly after writing it, we got Ipaqs and the boss wanted our field guys to be able to "gas and go" their Ipaqs with their current open tasks.
So...I wrote some more ColdFusion code that generated some XML for the Ipaqs to consume along with an app on the Ipaqs that would refresh itself whenever it detected an active network connection and put a pretty form based UI on the whole thing.
Then the boss requested other changes, etc, ad nauseum.
Anyway, .NET was released, so I decided to give this app a whack as a web service. The logic was fairly straight forward, it wasn't a problem to port over, and it worked.
So then I wrote a web based UI to call the web service, and also rewrote the hand held app to do the same. It wasn't really a problem.
I plan to eventually write a Windows Forms client for the thing as well, as I personally hate using a Web UI.
It worked, it's relatively pain free, and it opens up more options as to what kind of front end you want to use. It also had the normal web app benefits in that if there is an issue in your back end logic, you can rewrite and redeploy with little fussing about on the end user's machines. I don't think it's a panacea or anything though. You might have an app that it makes sense for, you might not.
Steve Barbour
Monday, April 19, 2004
Services Oriented Architecture is there to drive re-use through your applications. I work for a bank, so that is the example I will use. Accounts get opened for many different things, yet they are all just opening an account. Why not create one accountopen() service and expose it that way?
This is no different than building reusable functions in your application, but on a more grand scale. I believe that SOA can provide many benefits in the right scenario. Not every thing should be written as a web service, but then not everything should be written COM+ or any other technology. Use the right design pattern for the application!
Mike
Monday, April 19, 2004
"Why not create one accountopen() service and expose it that way?"
But what advantage did this provide over just exposing the object through COM+?
Mark Hoffman
Monday, April 19, 2004
>But what advantage did this provide over just exposing >the object through COM+?
Platform neutrality when using web services. Other
than that the idea is the same. The web stuff
is simpler because you don't worry about distributed
grabage collection and reference counting.
son of parnas
Monday, April 19, 2004
I am talking about VPN software that locks down
your entire system except for talking with work.
And it was also a pain to setup and use. How
you can disagree with things that actually
happened to me is quite fascinating.
son of parnas
Monday, April 19, 2004
Uh, okay. Let me quote:
"VPNs stink also because:
1. the security locks down your machine for other use"
Gee, that doesn't sound like a "some esoteric VPN that isn't what 99.99999%+ of the population uses locks down your machine" statement. It sounds like an absolute statement that VPNs do some hypothetical "locking down" of one's machine. Pure FUD.
99% of the world uses Microsoft's built in VPN, and all it does is enable a secure connection from A<->B (secure removing the need for worries about SSL, blah blah blah). Now what may be confusing you is the fact that by default it makes the VPN connection the default route (meaning that suddenly thehun won't load because the corporate firewall is blocking it -- your packets are going through the VPN to the company, and then are as if they originated there), however it's a trivial batch file to switch back to using the VPN only for traffic within the corporate internal IP range, then connecting everywhere else through your native connection.
I will say again that promoting ANYTHING because it allows you to push stuff through port 80 is pure, utter ignorance, and it reeks of an area of this industry that needs a crackdown. "Gee, the IT department won't let me share files with the outside world...well I'll put it in Sharepoint and open port 80!"
.
Monday, April 19, 2004
> 99% of the world uses Microsoft's built in VPN,
Guess my company is part of the 3rd world. So FUD
you. Sorry, like that one...
son of parnas
Monday, April 19, 2004
>One reason (the main reason) to use web services in an internal environment - if an application may need to be used outside the firewall (laptop users). With web services, you just need to open port 80...
What about .NET remoting over HTTP?
http://www.ingorammer.com/RemotingFAQ/RemotingUseCases.html
John Rusk
Tuesday, April 20, 2004
SOA != WebServices
Someone asked what would be gained by using an SOA instead of just a COM component in the openaccount() example. Well, if you design the component a certain way than you effectively have an Service Oriented Architecture in place.
This seems to offer a decent definition:
http://www.objectwatch.com/issue_45.htm :
"A Service-Oriented Architecture (SOA) is a set of architectural principles that define how autonomous systems interoperate."
r
Tuesday, April 20, 2004
Rocky Lhotka on "SOA, dollar signs and trust boundaries":
(finishes up)"In the end, I think the trust boundary mindset is most valuable guide for SOA. Using SOA is expensive (in terms of complexity and performance). It is not a price you should be willing to pay to have your UI talk to a middle tier. There are far simpler, cheaper and faster philosophies, concepts and technologies available for such interaction.
On the other hand, crossing trust boundaries is expensive and complex all by itself. This is because we have different applications interacting with each other. It will always be expensive. In this case, SOA offers a very nice way to look at this type of inter-application communication across trust boundaries, and can actually decrease the overall cost and complexity of the effort."
http://www.lhotka.net/WeBlog/PermaLink.aspx?guid=05f88592-9ecb-4331-a86b-cfeebc411dfe
Dave Hallett
Tuesday, April 20, 2004
I always believed the main benefit of the SOA would be the loose binding. With autonomous messages passing between the services the interdependencies could at least in theory be reduced to a minimum.
Besides, if we are talking large systems, there is no such thing as a "homogeneous" environment, right?
Just me (Sir to you)
Tuesday, April 20, 2004
"SOA != WebServices"
<light bulb goes off>
See, whenever I saw SOA, I was thinking it was referring to an architecture where the services were web services. Aha!
Mark Hoffman
Tuesday, April 20, 2004
Maybe this http://msdn.microsoft.com/architecture/journal/default.aspx?pull=/library/en-us/dnmaj/html/aj1soa.asp can be of help:
Understanding Service-Oriented Architecture
David Sprott and Lawrence Wilkes
CBDI Forum
January 2004
Summary: Gives a concise explanation of service-oriented architecture, what it is, and how it affects what architects, CIOs, project managers, business analysts, and lead developers do. (13 printed pages)
Just me (Sir to you)
Tuesday, April 20, 2004
as mentioned above, Web services make it really easy to take the app outside the firewall, especially when this isn't an upfront requirement.
In my case, I work for a software corp who has a Japanese, German and US office. Each office has their own web site and processes their own region's requests for product licensing. The problem is, they have to VPN to the US HQ to actually make the licenses.
With a Web service based app, I was able to give them all language-localized front-ends to a central license processor in our office.
Sassy
Tuesday, April 20, 2004
"as mentioned above, Web services make it really easy to take the app outside the firewall, especially when this isn't an upfront requirement."
But is that a feature of webservices or a simply a consequence of running over the UFBP (Universal Firewall Bypass Protocol, aka HTTP)?
Just me (Sir to you)
Wednesday, April 21, 2004
 Recent Topics
Fog Creek Home
| 
