Happy New Year and time for some demo code!

Happy New Year!

Wow, it’s been a while since I've had a chance to write a post as it’s been a whirlwind beginning of a year already!

Last week we had a chance to visit 6 European cities in 6 days as we talked to a number of companies about using our Enterprise Application Fabric (EAF) to solve a wide variety of problems. So thank you to everyone we talked to in Prague, Munich, Frankfurt, Erlangen, Zurich and London! (We didn’t intend to go to Zurich, but the events in London on January 16th gave us a chance to experience the cities hospitality…)

We have also had a large number of new product evaluations taking place over the last couple of weeks, so I wanted to post a couple of Visual Studio project templates that I use for training purposes in an effort to help those of you who are using Visual Studio.

This first example is a simple Hello World that illustrates how we use annotations and Reflection to inject and retrieve values from a class. While my example uses simple data types, you should know that we support rich data types, custom data structures and can even pass native data types between .NET and Java applications within a single EAF application, so goodbye isolated application deployment environments and hello fabric!

I’m also using our new MulticastSocket API for multicast messaging. This API is one of the new features that can be found in our upcoming 3.7 release.

To use this C# project temple, put this zip file into your \Visual Studio\Templates\Project Templates directory and select the File / New Project menu item from Visual Studio, then select Fabric_Task_HelloWorld from the My Templates Section of the New Project dialog box.

using System;
using System.Collections.Generic;
using System.Text;
using Appistry.Task;
using Appistry.Implementation;
 
namespace HelloWorldObject
{
    public class Class1
    {
 
        // MulticastSocket is a new API that allows Tasks
        // to send multicast messages to Log_monitor via 
        // the send method and also provides an API for 
        // retreiving the local machines TCP/IP address
        private static MulticastSocket messageSocket;
        private static System.Net.IPAddress localIP;
 
        public static void OnStartup()
        {
            messageSocket = new MulticastSocket("239.255.0.78", 4001);
            localIP = MulticastSocket.GetMachineIPAddress();
            messageSocket.Send("Setup done in: " + localIP.ToString());
        }
 
        // The ITaskRequest annotated with TaskRequest works
        // just like the v2.4 product (eg. request["MyValue"])
        private ITaskRequest request;
 
        [TaskRequest]
        public ITaskRequest mRequest
        {
            get { return request; }
            set { request = value; }
        }
 
        // The TaskProperty annotation allows you to pass fabric 
        // request values to existing class properties.
        private int myVar;
 
        [TaskProperty]
        public int MyProperty
        {
            get { return myVar; }
            set { myVar = value; }
        }
 
        // You can also add TaskReturnValue and TaskParameters to pass
        // fabric request values to your existing applications
        [return: TaskReturnValue("Hello_Return")]
        public string Hello([TaskParameter("in_arg")] string in_arg)
        {
            messageSocket.Send("Hello from:" + localIP.ToString() +
                " Request ID:" + request.Id);
            return myVar.ToString() + " " + in_arg + " " +
                localIP.ToString();
        }
 
    }
 
}

The final thing I want to point out is that I like to package and deploy my applications during the post-build event. So I have included the following commands in the projects Build Events -

fabric_pkg CS_App.xml

fabric_ctl -ufabric-admin/fabric-admin -d239.255.0.1:30000 deploy HelloWorld_App.fabric

You can use the log monitor to watch the fabric workers messages -

C:\log_monitor 239.255.0.78:4001

To call this fabric application from a client, create a C# Console Application and add the Appistry.NET dll found in the \Program Files\Appistry\System directory to your projects references.  Here is the simple client for making a single fabric call -

using System;
using System.Collections.Generic;
using System.Text;
using Appistry.FabricAPI;
 
namespace Fabric_Client_Sync
{
    class Fabric_Client_Sync
    {
        static void Main(string[] args)
        {
            Fabric fabric = new Fabric("239.255.0.1", 31000, Encryption.NONE);
 
            FabricRequest request = new FabricRequest("Hello_App", "CS_Process");
            try
            {
                //Put the request[""] values being sent to your task/process flow here
                request["MyProperty"] = 100;
                request["in_arg"] = "Hello World";
 
                fabric.Execute(request); // Synchronous invocation
 
                //Retrieve your results here
                Console.WriteLine(String.Format("{0}", request["Hello_Return"]));
 
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }
            finally
            {
                request.Dispose();
            }
 
            Console.WriteLine("All done, press any key to continue..");
            Console.ReadKey();
        }
    }
}

We have a lot of great plans for 2008 and one of my New Years resolutions is to publish a lot more code this year, so get ready!

I also wanted to thank Manoli.net for a feature they have that formats and maintains the color coding for C# code. (http://www.manoli.net/csharpformat/ ) It really makes my code look great! (OK, well at least it’s aesthetically pleasing… )

Let me know if you have any questions or comments...

Until next time!!

Mark

Outsource Reliability?

I just received a new ObjectWatch newsletter by Roger Sessions and it really struck a cord with the Enterprise Application Fabrics Scalability Simplified message that I’ve been evangelizing.

The latest newsletter describes a process coined by Roger called Simple Interactive Partitions (SIP).  The basis of which is a process based on a mathematical model for simplifying enterprise software's architectural complexity.

Within the three SIP whitepapers posted on the ObjectWatch site the Executive Overview outlines the five phases of the SIP process.  The step that really hit home with me was step 3, Partition Simplification which describes the removal of extraneous, redundant, or outsource-able functionality.  Which got me thinking why someone wouldn’t outsource reliability & scalability to the Enterprise Application Fabric?  What’s the engineering cost of developing something that can be found in a packaged, vendor supported solution?  It took us 6 plus years of engineering effort.  Do you have 6 years to do the same?

If your ready to lower the complexity of your enterprise solutions, read the SIP briefing papers, get a copy of Roger Sessions new book Controlling Complexity in Enterprise Architectures when it’s released later this year and give us a call!  Preferably not in that order as we can help you today!

Great process Roger, I look forward for the book!

Until next time...

Mark

Enterprise Application Fabrics – It’s not just a job!

One of the blog’s I’ve been following (besides Bob’s here at Appistry) is Marc Andreessen’s from my old nemesis Netscape. I really have enjoyed some of the insights Marc has shared around startup’s, VC’s and most recently, Career Planning.

In his career planning post, he shares a couple of rules that really resonated with me and I think they are worth repeating. Marc’s career rules –

  1. Do not plan your career – His point is that with the pace of technological change, it’s difficult to guess what’s going to happen in the future. And that career planning could be career limiting over the long haul.
  2. Instead of planning your career, focus on developing skills and pursuing opportunities – Here he elaborates on opportunities. The Opportunities that present themselves to you and those that you go out and create.

What really struck me about the second rule related to how the technology decisions we make during the course of our careers affect our future career opportunities.

During the course of my career at Microsoft, I got a chance to focus on a wide variety of technologies including operating systems, networking technologies, programming languages, relational databases, internet technologies and enterprise resource planning solutions. Each technology served as the foundation to learn something new. The seemingly random-career-walk through technology didn’t just linearly evolve, it morphed through unforeseen technologies that each contributed to some greater thing. (OK – Cue the black obelisk and 2001 Space Odyssey sound track) The reason I make this point, is that Enterprise Application Fabrics were a natural step in the evolution to my technology skill set. Fabrics leverage everything I know about databases, programming languages, operating systems and line of business solutions to create solutions beyond anything I could have imaged during my career. Fabrics allow me to leverage unforeseen opportunities!

OK, enough with the Space Odyssey. Are you ready to evolve your career and skill set to address unforeseen opportunities with Enterprise Application Fabrics?

Call us and we can tell you how to advance your career!

Until next time….

Mark

Appistry’s Enterprise Application Fabrics – The cure for scaling constipation and premature hardware acquisition

I’ve been following a blog thread by Hillel from Jackson Fish Market discussing the development trade off’s startups make between features and scalability and I had to point out this link called “The Constipation of Scale”. In his post, Brad Feld does a fairly good job of describing the development trade offs associated with keeping VC’s happy with features, and actually building a solution that scales. And I wanted to respond by describing how one of the startups we have been working with Clearent, was able to release new ‘scalable’ features on a timeline that satisfied their investors.

Clearent is a Credit Card processor that started two years ago with the goal of providing great customer service by being able to scale their company dynamically to meet customer demand. It’s great to hear the CEO Dan Geraty describe the common perception of the industry – “..that you have to start with a certain scale to be effective, and that with the Appistry fabric in place we are able to shatter those barriers to achieve competitive performance and economics with much smaller volumes”. The point is that EAF lets you scale your operations incrementally.

I’ll have to describe technically how the Clearent fabric parallelizes a sequential data processing problem in a future post. But in the mean time, think of it as a mini-Map Reduce.

So no Brad Feld, occasional constipation does not have to be a reality of life.… Appistry’s Enterprise Application Fabric can cure data processing irregularities. Call us and we can show you how…

Until next time…

Mark

Parallel processing Rip Van Winkle just woke up!

I just got back from attending a Microsoft HPC conference in Redmond Washington this week and during one of the breaks I had a chance to talk to another attendee who had previously worked at Microsoft back in the late 80's / early 90's. What this gentleman and I found we had in common was that back in the late 80's he taught at Microsoft University (which was Microsoft's only training facility in the 80's) where I had attended a couple of OS/2 development courses.

As we were talking about the good-old-days of developing for OS/2, we were reminiscing about all of the cool multi-threading and interprocess communication things you could do back then and it struck me. For the last twenty years, the number of times I have had the chance to do any parallel programming has been very limited within the context of developing and delivering business focused applications. Yet, here I sit twenty years later with about 100 people on the Microsoft campus talking about parallel processing again! Halleluiah!

I was starting to feel like a parallel processing Rip Van Winkle! That I just woke up from a twenty year nap and someone coined the terms embarrassingly parallel to point out how dumb we have been for not solving these types of problems via a parallel approach before!

Now, I would be the first to tell you that there were a lot of reasons for not doing parallel processing to solve embarrassingly parallel problems before. Given the hardware, languages and general developer parallel processing acuity of the day, the gains from parallel processing would have been negligible. But given the only recent change in the above list has been the advent of multi-core processors to continue Moore 's Law trajectory. Is that enough to take parallel processing main-stream?

When will main-stream development languages seamlessly address multi-core capabilities?

When will developers understand the intricacies of thread synchronization?

What if you didn't even need multi-core processors to do parallel processing? Did you know that you can take your Visual Basic programs, on single core commodity computers and they will solve embarrassingly parallel problems (and some not so embarrassingly parallel problems) reliably? No multi-threaded development experience necessary. Yes, you might have guessed it. It's called a fabric.

Bring us your embarrassingly Cobol or Visual Basic applications and we can show you how to make them embarrassingly parallel...

Until next time..

Mark

Technorati: , ,