This is a must read:
http://www.theonion.com/opinion.php?i=1&o=1
Come on... shouldn't someone do the Turbo ESB???
You're ESB only does queues, routing and transformation! Mine does all that plus [fill in blank]. Think I'm joking... just wait.
Friday, February 20, 2004
Thursday, February 19, 2004
WebMethods to Close Office, Lay Off Workers
I almost missed this:
"WebMethods lost $11.1 million in the quarter ended Dec. 31. Since it went public in 2000, WebMethods has only reported a profit in one quarter, $157,000 for the three months ended March 31, 2003.
"Their inability to show profitability has been a very sore spot for investors," said David Hilal, an analyst at Friedman, Billings, Ramsey & Co. "They are doing what they can to appease investors."
See:
http://www.washingtonpost.com/wp-dyn/articles/A20530-2004Feb6.html
"WebMethods lost $11.1 million in the quarter ended Dec. 31. Since it went public in 2000, WebMethods has only reported a profit in one quarter, $157,000 for the three months ended March 31, 2003.
"Their inability to show profitability has been a very sore spot for investors," said David Hilal, an analyst at Friedman, Billings, Ramsey & Co. "They are doing what they can to appease investors."
See:
http://www.washingtonpost.com/wp-dyn/articles/A20530-2004Feb6.html
When is a service not an orchestration?
When is a service not an orchestration? This is the question that Christoph asks?
His point is that all bpel orchestrations 'are services' and if one wanted you could use the orchestration as an agility mechanism. For example, you know that you need a service 'foo' - why not make an orchestration 'foo' where the 'foo' orchestrations calls the 'foo' service. In essence, you treat the orchestration like a proxy to the end service. Christoph goes on to point out that like any proxy-calls, you incur extra overhead. By proxying, you don't tie the 'foo' service directly to the non functional requirements (logging, security checks, business activity monitoring, etc. ) you could add additional steps into the orchestration to perform these for you.
Overall, I'd have to agree with where Christoph landed - if the orchestration is time sensitive or doesn't look like it will need any 'decorators' - then just make it a service. If it is part of a long running business process and isn't necessarily time sensitive than consider front-ending the service with an orchestration and add the decorators.
In the long run this may kind of 'orchestration-proxy for NFR's' might go away. I'm still a big believer (as is Christoph) in using declarative aspects on services. In this manner, you would declare the decorators on the service and when the service was called and it would trigger the decorator calls (think Aspect Oriented Services). Either way... I'm not sure which one is easier to read / debug. Although it does raise a good point - we probably need a metatag to state if a service call is part of a NFR resolution or if it is a legitimate Functional step in the orchestration...
His point is that all bpel orchestrations 'are services' and if one wanted you could use the orchestration as an agility mechanism. For example, you know that you need a service 'foo' - why not make an orchestration 'foo' where the 'foo' orchestrations calls the 'foo' service. In essence, you treat the orchestration like a proxy to the end service. Christoph goes on to point out that like any proxy-calls, you incur extra overhead. By proxying, you don't tie the 'foo' service directly to the non functional requirements (logging, security checks, business activity monitoring, etc. ) you could add additional steps into the orchestration to perform these for you.
Overall, I'd have to agree with where Christoph landed - if the orchestration is time sensitive or doesn't look like it will need any 'decorators' - then just make it a service. If it is part of a long running business process and isn't necessarily time sensitive than consider front-ending the service with an orchestration and add the decorators.
In the long run this may kind of 'orchestration-proxy for NFR's' might go away. I'm still a big believer (as is Christoph) in using declarative aspects on services. In this manner, you would declare the decorators on the service and when the service was called and it would trigger the decorator calls (think Aspect Oriented Services). Either way... I'm not sure which one is easier to read / debug. Although it does raise a good point - we probably need a metatag to state if a service call is part of a NFR resolution or if it is a legitimate Functional step in the orchestration...
Tuesday, February 17, 2004
OpenStorm Launches
Today we are officially launching OpenStorm Software. See: http://www.openstorm.com We unofficially launched the company in August of 2002 - but went back into a semi-stealth mode to significantly enhance the product.
Our primary goal was simple: create a product that had the simplicity of a Microsoft tool and the scalability and reliability of an IBM tool. We think we did it. First, we took our original .Net orchestration engine and rewrote it in Java for the J2EE platform. The design leverages a message oriented architecture and facilitates logical and physical tiering between the 'communication server' (http, etc.), the message broker (JMS, MSMQ) and the orchestration server (native BPEL, exposed as a service).
Then, we rewrote the entire user interface for the developer tooling. We chose the .Net platform for the UI for a couple of reasons: 1. We believe that we can build better interfaces in a shorter period of time than on just about any other platform. 2. We intend on facilitating "Office Orchestration" - enough said.
The only issue we are having from a timing perspective is that the .Net Web Service Enhancements (WSE) remain in beta. Thus, we will be waiting on some enhancements before we make the .Net BPEL server available. We also decided that we wouldn't make the first release downloadable. Instead, we are inviting partners and qualified prospects to install the system and work with an assigned OpenStorm team to ensure success.
I think the product turned out great. It will serve as the foundation for service oriented integration (A2A and B2B). It will also serve as the underlying engine for the next generation of BPM (Service Oriented, Process Driven Architectures).
Lastly, I want to congratulate the team - you kicked ass. They are now busy working on the next release. Stay tuned.
Our primary goal was simple: create a product that had the simplicity of a Microsoft tool and the scalability and reliability of an IBM tool. We think we did it. First, we took our original .Net orchestration engine and rewrote it in Java for the J2EE platform. The design leverages a message oriented architecture and facilitates logical and physical tiering between the 'communication server' (http, etc.), the message broker (JMS, MSMQ) and the orchestration server (native BPEL, exposed as a service).
Then, we rewrote the entire user interface for the developer tooling. We chose the .Net platform for the UI for a couple of reasons: 1. We believe that we can build better interfaces in a shorter period of time than on just about any other platform. 2. We intend on facilitating "Office Orchestration" - enough said.
The only issue we are having from a timing perspective is that the .Net Web Service Enhancements (WSE) remain in beta. Thus, we will be waiting on some enhancements before we make the .Net BPEL server available. We also decided that we wouldn't make the first release downloadable. Instead, we are inviting partners and qualified prospects to install the system and work with an assigned OpenStorm team to ensure success.
I think the product turned out great. It will serve as the foundation for service oriented integration (A2A and B2B). It will also serve as the underlying engine for the next generation of BPM (Service Oriented, Process Driven Architectures).
Lastly, I want to congratulate the team - you kicked ass. They are now busy working on the next release. Stay tuned.
Saturday, February 14, 2004
BEA on Web Services
I largely disagree with the BEA position on web services:
Now, of course, an intelligent app server can detect if the two services are local and bypass the marshalling. I think what BEA is saying is "our web services implementation isn't smart yet..." - and that's Ok.
If you take BEA's advice - you'll likely end up with a tightly coupled, Java based application. Thus, you only integrated at the edges. I'm not a fan of this approach. Don't get me wrong - not everything should be a service - but saying, "you should place business logic in custom Java controls instead of web services" is definitely not my way of thinking! In my humble opinion, this is one of the faults with the WebLogic Integrator. It leads to 'inlining java code directly into the process code' - - which quickly turns into a mess.
Now, of course, an intelligent app server can detect if the two services are local and bypass the marshalling. I think what BEA is saying is "our web services implementation isn't smart yet..." - and that's Ok.
If you take BEA's advice - you'll likely end up with a tightly coupled, Java based application. Thus, you only integrated at the edges. I'm not a fan of this approach. Don't get me wrong - not everything should be a service - but saying, "you should place business logic in custom Java controls instead of web services" is definitely not my way of thinking! In my humble opinion, this is one of the faults with the WebLogic Integrator. It leads to 'inlining java code directly into the process code' - - which quickly turns into a mess.
Friday, February 13, 2004
The Case for Orchestration Tooling
As the Stencil Group points out, moving to a modular system has great benefits:
Now, if you were to look at the back side of the 'modular system' you would notice that there are wires running in every direction, hooking all of the modules (or services) together. If you've ever had to wire together the components in your stereo system, you know what kind of nightmare this can be.
The neat thing about monolithic systems is that they don't expose the ugly wires to the outside world. Of course, there is a huge downside in this approach as well - you're stuck with the whole elephant. The goal of orchestration is to get the best of both worlds: the flexibility of a modular system with the simplicity of a monolithic system. In most enterprises, you won't be dealing with a small handful of components, it will be hundreds, if not thousands of services that need to come together. Imagine trying to wire a stereo system with a thousand components...
Now, if you were to look at the back side of the 'modular system' you would notice that there are wires running in every direction, hooking all of the modules (or services) together. If you've ever had to wire together the components in your stereo system, you know what kind of nightmare this can be.
The neat thing about monolithic systems is that they don't expose the ugly wires to the outside world. Of course, there is a huge downside in this approach as well - you're stuck with the whole elephant. The goal of orchestration is to get the best of both worlds: the flexibility of a modular system with the simplicity of a monolithic system. In most enterprises, you won't be dealing with a small handful of components, it will be hundreds, if not thousands of services that need to come together. Imagine trying to wire a stereo system with a thousand components...
Service Types?
I'm looking for some common vocabulary to describe the various nomenclatures found in service operations. Here is what I've been using:
Pass-All Service – This is a service that passes the verb and noun into a generic service entry point. An example would be: “do( Add, Employee, EmployeeInfo)” , or do("insert into Employee ...")
Verb-Only Service – This is a service that states the kind of action that will be requested in the operation name, but passes in the nouns. An example is “Add(Employee, EmployeeInfo)”
Verb-Noun Service – This is a type of service that states both the action and the nouns (the target of the actions) in the operation name. An example would be AddEmployee( EmployeeInfo ).
Is there already terminology for these different interface styles? If so, please send me a note.
Pass-All Service – This is a service that passes the verb and noun into a generic service entry point. An example would be: “do( Add, Employee, EmployeeInfo)” , or do("insert into Employee ...")
Verb-Only Service – This is a service that states the kind of action that will be requested in the operation name, but passes in the nouns. An example is “Add(Employee, EmployeeInfo)”
Verb-Noun Service – This is a type of service that states both the action and the nouns (the target of the actions) in the operation name. An example would be AddEmployee( EmployeeInfo ).
Is there already terminology for these different interface styles? If so, please send me a note.
Thursday, February 12, 2004
BPEL Data Mapping
One of the early lessons that we learned was that data mapping between xml documents was a tough thing to do manually. BPEL leverages XPath extensively - thus to do it right, you need an integrated XML data mapping and XPath manipulation tool to facilitate the mapping between service calls. See:
In the OpenStorm product this tool gen's the code for the 'Assign' tag based on drag & drop interfaces. We are finding that it significantly reduces the potential for syntax errors. It has also reduced the time to create complex orchestrations by about 40%.
In the OpenStorm product this tool gen's the code for the 'Assign' tag based on drag & drop interfaces. We are finding that it significantly reduces the potential for syntax errors. It has also reduced the time to create complex orchestrations by about 40%.
Tuesday, February 10, 2004
Web Service Documentation
It is great to see that products are coming out to help document web services. This is another step in the maturity process. Now... we need people to learn how to write good documentation for their wsdl's and bpel's.
Take a look at this:
http://www.wsdox.com and the samples: http://www.wsdox.com/samples/index.html
I'm very excited to see the BPEL documentation as well. The team as Wsdox are also planning on authoring guidelines about writing good documentation for web services. In addition to tooling, we need best practices.
In my inquiry, they also mentioned some interesting notes about their roadmap including: documenting the WS-* aspects of services, making the tool a web service :-), documenting some of the other artifacts (XSL, XQuery, etc.) -- very good stuff. I'm also glad to see that they are OEM'ing the software - so many products should be using this kind of stuff...
Take a look at this:
http://www.wsdox.com and the samples: http://www.wsdox.com/samples/index.html
I'm very excited to see the BPEL documentation as well. The team as Wsdox are also planning on authoring guidelines about writing good documentation for web services. In addition to tooling, we need best practices.
In my inquiry, they also mentioned some interesting notes about their roadmap including: documenting the WS-* aspects of services, making the tool a web service :-), documenting some of the other artifacts (XSL, XQuery, etc.) -- very good stuff. I'm also glad to see that they are OEM'ing the software - so many products should be using this kind of stuff...
Sunday, February 08, 2004
Patni issue oversubscribed 22 times
Offshore software development continues to be hot for the investment community:
The initial public offer (IPO) of Patni Computer Systems has been oversubscribed 22 times. The company is raising $95 million, which is the largest thus far by a software company in the last four years. In 1999, HCL Technologies had come out with $182 million issue.
Amit Chandra, member of the board, DSP Merrill Lynch, said, “The overwhelming response to the Patni book-built issue during the extremely choppy secondary market environment shows the strong investor appetite for high quality Indian paper.”
...
GE has a 10 per cent stake in Patni and relies on the US company for about 45 percent of its revenues.
This is the company that my brother in GE Atlanta lost his job to. Way to go GE! Cut costs by replacing American workers with Indians, invest in Indian companies and help them go public! GE - you're one class act. Maybe they could take their proceeds and try to get that pesky law about freed slaves overturned.
From: http://www.business-standard.com/today/story.asp?Menu=1&story=33841
The initial public offer (IPO) of Patni Computer Systems has been oversubscribed 22 times. The company is raising $95 million, which is the largest thus far by a software company in the last four years. In 1999, HCL Technologies had come out with $182 million issue.
Amit Chandra, member of the board, DSP Merrill Lynch, said, “The overwhelming response to the Patni book-built issue during the extremely choppy secondary market environment shows the strong investor appetite for high quality Indian paper.”
...
GE has a 10 per cent stake in Patni and relies on the US company for about 45 percent of its revenues.
This is the company that my brother in GE Atlanta lost his job to. Way to go GE! Cut costs by replacing American workers with Indians, invest in Indian companies and help them go public! GE - you're one class act. Maybe they could take their proceeds and try to get that pesky law about freed slaves overturned.
From: http://www.business-standard.com/today/story.asp?Menu=1&story=33841
Saturday, February 07, 2004
More on Pass-by-Reference
Stefan Tilkov made an interesting point, " I believe anytime you make a copy of some data - which is unavoidable if caller and callee don't reside in the same address space - you can't do pass by reference."
Here are some things that I've been thinking about:
----
Pass by Value implies the creation of multiple copies of the data and any changes made to one copy do not propagate to the other copies.
Pass by Reference implies a single 'master' instance of the data; thus all changes made to one copy apply to all references.
----
Pass by Value implies that the data 'value' is created at the time determined by the sender.
Pass by Reference implies the data 'value' is populated at the time determined by the receiver.
----
Pass by Value implies that the copies of the data were a snapshot in time. Thus the data may become stale between accesses.
Pass by Reference implies that the data is 'current' - however, it may not reflect the state of the data as intended by the sender.
Both Pass by Reference and Pass by Value can use a 'leasing' mechanism to deal with stale information or stale resources.
----
Pass by Value implies that the contents of the message is data. (Out of scope: mobile agents and Jini style proxies)
Pass by Reference implies that the contents of the message is either a pointer to data, a pointer to functionality or both.
----
Pass by Value implies that the contents of the message are fully contained within the message, thus you pass *everything*
Pass by Reference implies that the contents of the message are not contained within the message and the recipient can choose at runtime which piece of the data they are interested in.
----
Pass by Value can be implemented in a single call.
Pass by Reference requires at least 2 calls; the first one sends the pointer, the second call retrieves the data (by value)
----
Pass by Value implies that the message contains the exact information desired by the sender (maintains data integrity)
Pass by Reference does not guarantee that the data being passed is that which was desired by the sender. This is due to the potential modifications of the data between 'send time' and 'retrieve time'. This problem can be overcome by using some sort of locking or checksum mechanism.
----
- I like the idea of not passing around 'fat messages' (extra information that the ultimate receive may not be interested in)
- In some cases, I like the idea of passing pointers to data.
- In some cases, I like the idea of passing XQuery expressions that point at virtual endpoints where the predicate is populated by the ultimate receiver and a lease verifies that the data/resource isn't stale. Here, I'm not sending the data - I'm sending a partial evaluation expression for the data.
However, you'll notice that this style of programming is starting to sound like what we did in the client/server days of stuffing all of our messages in our relational database and then passing around SQL statements that referenced the data. Issues here too.
Stefan is right in that remotely referenced information eventually becomes a *value*. But the Pass by Reference model has additional attributes that should be considered at design time. It is my opinion that PbV and PbR will both exist in the web services world and should be part of the toolbelt of the service designer. The aforementioned differences should be weighed when deciding between them.
Here are some things that I've been thinking about:
----
Pass by Value implies the creation of multiple copies of the data and any changes made to one copy do not propagate to the other copies.
Pass by Reference implies a single 'master' instance of the data; thus all changes made to one copy apply to all references.
----
Pass by Value implies that the data 'value' is created at the time determined by the sender.
Pass by Reference implies the data 'value' is populated at the time determined by the receiver.
----
Pass by Value implies that the copies of the data were a snapshot in time. Thus the data may become stale between accesses.
Pass by Reference implies that the data is 'current' - however, it may not reflect the state of the data as intended by the sender.
Both Pass by Reference and Pass by Value can use a 'leasing' mechanism to deal with stale information or stale resources.
----
Pass by Value implies that the contents of the message is data. (Out of scope: mobile agents and Jini style proxies)
Pass by Reference implies that the contents of the message is either a pointer to data, a pointer to functionality or both.
----
Pass by Value implies that the contents of the message are fully contained within the message, thus you pass *everything*
Pass by Reference implies that the contents of the message are not contained within the message and the recipient can choose at runtime which piece of the data they are interested in.
----
Pass by Value can be implemented in a single call.
Pass by Reference requires at least 2 calls; the first one sends the pointer, the second call retrieves the data (by value)
----
Pass by Value implies that the message contains the exact information desired by the sender (maintains data integrity)
Pass by Reference does not guarantee that the data being passed is that which was desired by the sender. This is due to the potential modifications of the data between 'send time' and 'retrieve time'. This problem can be overcome by using some sort of locking or checksum mechanism.
----
- I like the idea of not passing around 'fat messages' (extra information that the ultimate receive may not be interested in)
- In some cases, I like the idea of passing pointers to data.
- In some cases, I like the idea of passing XQuery expressions that point at virtual endpoints where the predicate is populated by the ultimate receiver and a lease verifies that the data/resource isn't stale. Here, I'm not sending the data - I'm sending a partial evaluation expression for the data.
However, you'll notice that this style of programming is starting to sound like what we did in the client/server days of stuffing all of our messages in our relational database and then passing around SQL statements that referenced the data. Issues here too.
Stefan is right in that remotely referenced information eventually becomes a *value*. But the Pass by Reference model has additional attributes that should be considered at design time. It is my opinion that PbV and PbR will both exist in the web services world and should be part of the toolbelt of the service designer. The aforementioned differences should be weighed when deciding between them.
Friday, February 06, 2004
I'm worried
I lived the dot-com life. My consulting customer base was every bad idea from Garden.com to BubbaJunk.com. I saw venture investors who were normally smart people throw their money away. I saw hard working employees work nights and weekends, dreaming for the next big IPO.
Well, in Austin it is now apparent that things are beginning to turn around. The first 'major' sign happened last night - the Austin Business Happy Hour returned. And unlike the last 3.5 years - the event was packed. People were optimistic - startups were emerging. Pretty much everyone had jobs and those that didn't have jobs had left on their own. The event was reminiscent of the dot-com days (minus the recruiters).
So, why am I worried? I'm worried for two reasons:
1. The startups that I'm seeing emerge look just as stupid as the ones I saw emerge in 1998.
2. The startups aren't going to get funded by VC's. Entrepreneurs may be quick to forget, but the VC's aren't.
I don't mean to be a stick in the mud, but business is still tough. Sure, things are picking up - everyone is doing better, but it is no cake-walk. Sometimes I get the feeling that the startups that are forming right now are based purely on the fact that the smart people that went into hiding (took a job with a big company), just can't stand working in the cube from 9 to 5 anymore and feel the need for speed.
Well, I hope I'm wrong. I enjoyed partying like it was 1999...
Well, in Austin it is now apparent that things are beginning to turn around. The first 'major' sign happened last night - the Austin Business Happy Hour returned. And unlike the last 3.5 years - the event was packed. People were optimistic - startups were emerging. Pretty much everyone had jobs and those that didn't have jobs had left on their own. The event was reminiscent of the dot-com days (minus the recruiters).
So, why am I worried? I'm worried for two reasons:
1. The startups that I'm seeing emerge look just as stupid as the ones I saw emerge in 1998.
2. The startups aren't going to get funded by VC's. Entrepreneurs may be quick to forget, but the VC's aren't.
I don't mean to be a stick in the mud, but business is still tough. Sure, things are picking up - everyone is doing better, but it is no cake-walk. Sometimes I get the feeling that the startups that are forming right now are based purely on the fact that the smart people that went into hiding (took a job with a big company), just can't stand working in the cube from 9 to 5 anymore and feel the need for speed.
Well, I hope I'm wrong. I enjoyed partying like it was 1999...
Wednesday, February 04, 2004
Pass by Reference : Answer #2
As previously posted, I've been looking at options for passing by reference. It has been interesting to see how people interpret this question. The first divide occurs in regard to 'what' is being referenced in the pass: pointers to data or pointers to services (or pointers to service that front-end data).
One thing that everyone seems to be agreeing on is that the 'pointer' is the URI. Last night I had a brief discussion with Dave Langworthy of Microsoft. Dave confirmed a couple of things. 1. There is no WS-EndpointReference specification, the portions of that spec that were relevant were rolled into the WS-Addressing specification. 2. I can accomplish what I want by using the endpoint reference functionality.
This threw me for a loop, mostly due to my lack of knowledge on this spec. Dave went on to explain that there are two primary pieces of the WS-Addressing specification:
1. The Message Header - This gives the from/to info for the header of the SOAP envelope
2. Endpoint References - This points to resources; these resources could be data, processors or other. Also, the Endpoint Reference is a 'type' which can be used in the body of a soap message. This means that you would define your WSDL 'message part' using an Endpoint Reference as the 'type' of a 'part'.
Within the 'EndpointReference' structure, there are a couple items of interest:
1. 'Address' - This is the URI of the data that you want to reference (or the actual endpoint referencing a service that gives you access to the data)
2. 'Reference Properties' - This is the bucket where you add qualifiers to zero-in on the information you are looking for. In my case, it will likely be an XPath expression that points to a specific element in an XML schema.
Summary - you can use an endpoint reference as standard type to act as a pointer to a resource. This standardized type can be leveraged inside of your own messages.
Sidenotes:
- The Address could specify a 'virtual' address that performs further resolution
- The Address could point to the URI of 'localhost' enabling pass-by-reference in local mode
- I'm not sure if there is a standardized way to drop in an XPath expression in a ReferenceProperty (anything special?)
- If the Address is referencing an XML document don't expect locking / synchronization, etc.
One thing that everyone seems to be agreeing on is that the 'pointer' is the URI. Last night I had a brief discussion with Dave Langworthy of Microsoft. Dave confirmed a couple of things. 1. There is no WS-EndpointReference specification, the portions of that spec that were relevant were rolled into the WS-Addressing specification. 2. I can accomplish what I want by using the endpoint reference functionality.
This threw me for a loop, mostly due to my lack of knowledge on this spec. Dave went on to explain that there are two primary pieces of the WS-Addressing specification:
1. The Message Header - This gives the from/to info for the header of the SOAP envelope
2. Endpoint References - This points to resources; these resources could be data, processors or other. Also, the Endpoint Reference is a 'type' which can be used in the body of a soap message. This means that you would define your WSDL 'message part' using an Endpoint Reference as the 'type' of a 'part'.
Within the 'EndpointReference' structure, there are a couple items of interest:
1. 'Address' - This is the URI of the data that you want to reference (or the actual endpoint referencing a service that gives you access to the data)
2. 'Reference Properties' - This is the bucket where you add qualifiers to zero-in on the information you are looking for. In my case, it will likely be an XPath expression that points to a specific element in an XML schema.
Summary - you can use an endpoint reference as standard type to act as a pointer to a resource. This standardized type can be leveraged inside of your own messages.
Sidenotes:
- The Address could specify a 'virtual' address that performs further resolution
- The Address could point to the URI of 'localhost' enabling pass-by-reference in local mode
- I'm not sure if there is a standardized way to drop in an XPath expression in a ReferenceProperty (anything special?)
- If the Address is referencing an XML document don't expect locking / synchronization, etc.
Tuesday, February 03, 2004
Web Services and Grid
Here's a nice presentation on web services and grid technologies (WSRF):
http://www.globus.org/wsrf/sabbah_wsrf.ppt
http://www.globus.org/wsrf/sabbah_wsrf.ppt
'Pass by Reference' in web services
I've been looking into my options for providing 'pass by reference' capability in web services. I know, I know - PBR is the root of all evil in loose coupling. But it is also the performance enabler for many applications. Thus, the goal is to identify the best mechanism that enables loose coupling while still providing performance.
My initial quest took me down a road that I'm calling "Pass By RESTference". I ran the concept by the smart guys on the Yahoo SOA group and it didn't get nuked (which is good in that group). The next issue is, how do you do it? Well, the closest example I've seen is probably this:
http://wiki.astrogrid.org/bin/view/Astrogrid/RestStyleWebServices
I'm going to chase down a couple other items... it has been rumored that WS-EndpointReference has something to say about this problem. In addition, I'm hearing that the OGSA guys have an alternative answer. More to report later.
My initial quest took me down a road that I'm calling "Pass By RESTference". I ran the concept by the smart guys on the Yahoo SOA group and it didn't get nuked (which is good in that group). The next issue is, how do you do it? Well, the closest example I've seen is probably this:
http://wiki.astrogrid.org/bin/view/Astrogrid/RestStyleWebServices
I'm going to chase down a couple other items... it has been rumored that WS-EndpointReference has something to say about this problem. In addition, I'm hearing that the OGSA guys have an alternative answer. More to report later.
Sunday, February 01, 2004
Analysis of Orchestration Space
I know it isn't traditional to post your competitive analysis - but I'm not very traditional. Here is a copy of my internal analysis of the orchestration space (from an OpenStorm perspective).
=============================================
Don,
You were asking about competition. Here's a breakdown:
High-end EAI: (SeeBeyond, Tibco, Vitria, WebMethods.)
Big 3 (IBM, BEA, MS)
BPEL Pure Plays (Collaxa, FiveSight, Vergil, Choreology)
Web Service Networks with BPEL (GrandCentral)
Workflow (Dralasoft, Reactor)
Pure play BPM (Lombardi, Fuego, Savvion, Intalio)
JMS and ESB providers (SpiritSoft, Sonic, Fiorrano)
Web Service platform providers (Systinet, CapeClear)
The fact is... orchestration is a sweet spot and people are looking at it from many different angles. Here's my take on how it might play out:
High-end EAI - These guys are having a hard time competing on cost and putting together a message that doesn't bastardize their current high-end revenue stream. They will likely take a 'wait and see' attitude towards orchestration, putting out an offering, but not really marketing it. It is likely that they will spread some FUD about orchestration, saying it is slow or lacks functionality and that their proprietary offerings are more 'seasoned'. Ultimately they will have to play in the game or will become outdated.
The Big 3 (IBM, MS, BEA) have a different story to tell. Their story is "Orchestration is great, but it is only a small piece of the puzzle". They won't try to have the best orchestration offering, just one that integrates into their stack the best. IBM shops will want IBM, MS shops will want MS... These guys will get a significant piece of the pie; they always do - people buy here for peace of mind. BEA may have a bigger challenge; their offering lacks substance and BEA doesn't have the clout that MS or IBM have.
BPEL pure plays - perhaps a more interesting category. Collaxa came out with an early lead but then went on to put out 14 or so betas and still haven't knocked it out of the park. Vergil, Choreology and FiveSight are all still a bit early - mostly in stealth. Thus too early to tell. Expect to see these guys either partner, strategic partner or drop into a niche market.
Web Service Networks - A couple of months ago Grand Central announced that their web services network would support BPEL. Although I'm not sure, it appears as though they rolled their own implementation of BPEL - which would be odd for an infrastructure provider. The implementation had a significant number of non-standardized extensions which I believe they needed to more fully support their existing network. Maintaining a BPEL engine is a bitch - in the long run, I would expect GC to OEM an engine from somewhere else - unless they are getting out of the ASP market all together.
Workflow - Workflow and Web Service Orchestration may seem like a similar problem, but in reality they are very, very different. Some of the vendors that claim features similar (but different) will likely confuse uneducated buyers -but the customers that we want will know the difference.
Pure Play BPM - These guys have had every opportunity to break up their monolithic architectures into a component-ized (or service oriented) architecture. As far as I know, none of them have made significant progress down this path. Intalio seems to get it but doesn't seem to be delivering the message. If these guys start delivering a "SO-BPM" story (Service Oriented BPM), watch out - they could be real contenders (of course, they will have to have product to back it up).
JMS / ESB - Here there are two categories 1. Sonic, 2. Everyone else - The fact is, Sonic is a marketing machine. I tip my hat to them. These guys not only could sell ice to Eskimos - they do! In the short term, I think they will be the single biggest threat. However, they have some baggage they bring with them (JMS is commoditized, ESB will eventually be a joke) All of the other ESB vendors will have to compete based on product features/functionality/price (think bake-offs against Sonic).
Web Service Platforms - Oddly, there are really only 2 platform providers left (Cape Clear and Systinet). Both of the players will need to get an orchestration offering. Their issue will be to knock orchestration out of the park - otherwise they will have to lead with their less expensive and commoditized SOAP stacks - and then try to upsell to a more expensive offering.
===============================
If you believe in the 'web services programming model', 'service oriented integration' or 'pervasive integration' then it is only a matter of time before you realize that orchestration is the flagship of this rather complex offering. Protocol offerings should be built into the operating system (and will be). Queues are commoditized... and making 'web service enabled queues' takes about a day of engineering effort. The 80-20 rule on transformation makes out of the box, pipelined XSL offerings attractive. However, debugging a distributed, service oriented, message based, declarative policy based, multi-platform, asynchronous, concurrent, cross-enterprise process is.... "hard". The issue around orchestration will quickly turn to 'total cost of ownership' - the vendor that wins will be the one that allows the enterprise to reduce the cost of maintaining production instances (keeping the service network up, debugging issues, resolving performance problems, maintaining version, etc.) The offerings will have to go beyond orchestration and into 'composite distributed applications'. The expectations that will be placed on our new service oriented virtual machine (the service network) will be significant. As the new programming model emerges, people will be wanting a vendor that isn't a 'spot' technology but rather an enabler of the new model - that's where we come in.
=============================================
Don,
You were asking about competition. Here's a breakdown:
High-end EAI: (SeeBeyond, Tibco, Vitria, WebMethods.)
Big 3 (IBM, BEA, MS)
BPEL Pure Plays (Collaxa, FiveSight, Vergil, Choreology)
Web Service Networks with BPEL (GrandCentral)
Workflow (Dralasoft, Reactor)
Pure play BPM (Lombardi, Fuego, Savvion, Intalio)
JMS and ESB providers (SpiritSoft, Sonic, Fiorrano)
Web Service platform providers (Systinet, CapeClear)
The fact is... orchestration is a sweet spot and people are looking at it from many different angles. Here's my take on how it might play out:
High-end EAI - These guys are having a hard time competing on cost and putting together a message that doesn't bastardize their current high-end revenue stream. They will likely take a 'wait and see' attitude towards orchestration, putting out an offering, but not really marketing it. It is likely that they will spread some FUD about orchestration, saying it is slow or lacks functionality and that their proprietary offerings are more 'seasoned'. Ultimately they will have to play in the game or will become outdated.
The Big 3 (IBM, MS, BEA) have a different story to tell. Their story is "Orchestration is great, but it is only a small piece of the puzzle". They won't try to have the best orchestration offering, just one that integrates into their stack the best. IBM shops will want IBM, MS shops will want MS... These guys will get a significant piece of the pie; they always do - people buy here for peace of mind. BEA may have a bigger challenge; their offering lacks substance and BEA doesn't have the clout that MS or IBM have.
BPEL pure plays - perhaps a more interesting category. Collaxa came out with an early lead but then went on to put out 14 or so betas and still haven't knocked it out of the park. Vergil, Choreology and FiveSight are all still a bit early - mostly in stealth. Thus too early to tell. Expect to see these guys either partner, strategic partner or drop into a niche market.
Web Service Networks - A couple of months ago Grand Central announced that their web services network would support BPEL. Although I'm not sure, it appears as though they rolled their own implementation of BPEL - which would be odd for an infrastructure provider. The implementation had a significant number of non-standardized extensions which I believe they needed to more fully support their existing network. Maintaining a BPEL engine is a bitch - in the long run, I would expect GC to OEM an engine from somewhere else - unless they are getting out of the ASP market all together.
Workflow - Workflow and Web Service Orchestration may seem like a similar problem, but in reality they are very, very different. Some of the vendors that claim features similar (but different) will likely confuse uneducated buyers -but the customers that we want will know the difference.
Pure Play BPM - These guys have had every opportunity to break up their monolithic architectures into a component-ized (or service oriented) architecture. As far as I know, none of them have made significant progress down this path. Intalio seems to get it but doesn't seem to be delivering the message. If these guys start delivering a "SO-BPM" story (Service Oriented BPM), watch out - they could be real contenders (of course, they will have to have product to back it up).
JMS / ESB - Here there are two categories 1. Sonic, 2. Everyone else - The fact is, Sonic is a marketing machine. I tip my hat to them. These guys not only could sell ice to Eskimos - they do! In the short term, I think they will be the single biggest threat. However, they have some baggage they bring with them (JMS is commoditized, ESB will eventually be a joke) All of the other ESB vendors will have to compete based on product features/functionality/price (think bake-offs against Sonic).
Web Service Platforms - Oddly, there are really only 2 platform providers left (Cape Clear and Systinet). Both of the players will need to get an orchestration offering. Their issue will be to knock orchestration out of the park - otherwise they will have to lead with their less expensive and commoditized SOAP stacks - and then try to upsell to a more expensive offering.
===============================
If you believe in the 'web services programming model', 'service oriented integration' or 'pervasive integration' then it is only a matter of time before you realize that orchestration is the flagship of this rather complex offering. Protocol offerings should be built into the operating system (and will be). Queues are commoditized... and making 'web service enabled queues' takes about a day of engineering effort. The 80-20 rule on transformation makes out of the box, pipelined XSL offerings attractive. However, debugging a distributed, service oriented, message based, declarative policy based, multi-platform, asynchronous, concurrent, cross-enterprise process is.... "hard". The issue around orchestration will quickly turn to 'total cost of ownership' - the vendor that wins will be the one that allows the enterprise to reduce the cost of maintaining production instances (keeping the service network up, debugging issues, resolving performance problems, maintaining version, etc.) The offerings will have to go beyond orchestration and into 'composite distributed applications'. The expectations that will be placed on our new service oriented virtual machine (the service network) will be significant. As the new programming model emerges, people will be wanting a vendor that isn't a 'spot' technology but rather an enabler of the new model - that's where we come in.
Subscribe to:
Posts (Atom)