locked
scalability implies using web services? RRS feed

  • Question

  • Hi everyone

    I am an analyst- programmer here in Spain(I don't know what is the difference with a programmer, i usually do the same things) I am studying a lot about architecture right now because i am in a very big project in the company that recently has hire me, perhaps the biggest project of Spain. Because i am a computer engineer I like the big vision, not the fight with the vb6, this just pay my bills.

    We use a lot of com+ components, put all of them in all the machines of the farm and release it. Well, we have disastrous consequences because we can't accept all the expected users.

    Here we don't use SOA architectures with business buses and all that things. We use vb6 and COM 1.1.

    I think that we have a problem because our solutions aren't scalable, and we have a very primitive architecture of the different modules because of that our solutions aren't scalable. I think that buy another Xeon and put all com+ components of all modules of the project can't be considered scalability.

    My question is: for a very very big project: scalability implies SOA and WS?

    Hope the question is considered interesting and produces a debate

    Tuesday, March 7, 2006 5:52 PM

All replies

  •  creaturita wrote:

    My question is: for a very very big project: scalability implies SOA and WS?

    No it does not - there have been scalable systems before SOA was coined or WS invented - As for SOA, If you don't pay attention to the way you build each service they can still unscalable. Nevertheless, The fact that a proper partitioning to services will increase loose coupling can help you achieve better performance by, for example, letting you deploy each service on its own box .

    As for your performance problem - You should first try  to understand where is your performance problem coming from. try to isolate and understand your performance bottlenecks - you can use tools like Devpartner Studio Server  ot appsight blackbox (and probably a few others) to monitor your system.

    Once you know where you spend your time you can think of ways to increase performance.

    Also here are a few questions you can ask yourself in regard to your situation

    • What's the load balancing mechanism
    • Are the COM+ components stateless?
    • What is the performance of a COM+ component in low loads
    • How is the data divided between the computers
    • How is the storage configured  ?
    • Are the databases optimized (indexes, disk partitions etc.)
    • What are the LAN cards speeds ?
    • Is the interface between clients and COM+ component chatty of chunky?"

     

     

     

    Tuesday, March 7, 2006 10:29 PM
  • I agree with Arnon, systems prior to SO/Web services were scalable. Have you looked at the Component Load Balancing and Queued component service aspects of COM+. I suggest you look into these as for e.g. COM+ provides component load balancing across cluster of I think 6 or 8 servers.
    Wednesday, March 8, 2006 10:00 AM
  • Hi there,

    Sounds like an interesting project you are involved in - my special interest is in the area of performance and scalability in regards to the MS platform.  I'd like to communicate with you by email and see if I can help - please write to me at randy at crashproofing dot com, will you?

    Yo hablo espanol un poucito tambien. 

    gracias,

    Randy 

    Tuesday, March 21, 2006 6:21 PM
  • The previous posters on this thread already covered the fact that SOA/WS does not mean scalable by default.  What I would like to add is that scalability can come in a variety of flavors.  If your scalability is being driven by a heavy set of concurrent users then you primarily need load balancing and possibly data partitioning strategies.  If your scalability is more focused on the ability to work on large sets of data in your middle tier then you also have to start to determine strategies for data isolation so you can parallelize the work and make your applicaitons more 'grid-aware'.

    Scalability can not typically be handled by discussing high level architectural styles or patterns so looking at your scalability issues in terms of SOA/WS is not likely going to get you where you need to go.  If you think SOA/WS is a direction you want to head then it should be driven more by long term reuse capabilities (through standards adoption and interop potential).

    Wednesday, March 29, 2006 12:20 PM
  • Arnon had some great questions that you need to look at before you can even begin to look at solving your scalability problems.  Answering those questions will definately help you find the scaling solution that best suits your particular needs. But I suggest that you also consider other aspects such as expected growth, changes in usage (internal vs external)...the business stuff.  You should start with two architecutual models: where you are now and where you expect to be in a few years.  Then you can use those models to design a long-term solution.

    I'm going to jump in on SOAPitStop's post.  Making a product grid-aware requires that there is a grid to run the application or components on.  SOA, grid computing, and multithreading can work together to significantly improve scalability and performance.  Only by understanding your needs can you determine which combination of approaches will solve the whole problem.

    I work for Digipede Technologies (http://www.digipede.net) and we have a grid framework that you can run VB6 with COM on (as well as .NET 1.1 and .NET 2.0 applications), we even provide a VB6 sample.  Unlike most grid solutions the Digipede Network can distribute code objects (not just executables) and was specifically designed for Windows.  It is this functionality that I think you will find valuable.

    You can get a free Developer's Edition of the Digipede Network by filling out a request form at: http://www.digipede.net/faster/   use the Promo Code: MSArch

    Good luck,

    Kim Greenlee

     

     

     

    Wednesday, March 29, 2006 11:43 PM
  • If you are going down the GRID path - there are also some open-source options you may want to consider - here are a few

  • MS.NETGrid -   - An open source .NET implementation of  Open Grid Services Architecture and Infrastructure
  • OGSI.NET - Another open source implementation of the same standard
  • Alchemi.NET - Yet another open-source project - this time a part of the GridBus project
  • Arnon

Saturday, April 1, 2006 8:14 AM