Ryan, Dave and the crew have kicked off the OpenStorm blog. It will focus more on using the Service Orchestrator and general questions related to BPEL and service composition.
See:
http://www.openstorm.org
I don't see an RSS feed, but I'll ask them to put one up.
Saturday, March 13, 2004
Thursday, March 11, 2004
AT&T and GrandCentral Partner
See:
http://www.internetnews.com/ent-news/article.php/3324191
"AT&T WebService Connect allows different applications from different sources to communicate without time-consuming custom coding. And because it is XML-based (define), it's not tied to any one operating system or programming language.
Developed over the last year with partner Grand Central Communications, WebService Connect plays into AT&T broader strategy of evolving from a long-distance phone company to a provider of enterprise network services. "
...
"The service will be rolled out gradually in the coming months. It starts at about $34,000 per month, although prices could run higher depending on usage. In terms of its telecom competitors, AT&T believes it is farthest along in offering Web services (define) to its customers. "
Congratulations to GrandCentral!
http://www.internetnews.com/ent-news/article.php/3324191
"AT&T WebService Connect allows different applications from different sources to communicate without time-consuming custom coding. And because it is XML-based (define), it's not tied to any one operating system or programming language.
Developed over the last year with partner Grand Central Communications, WebService Connect plays into AT&T broader strategy of evolving from a long-distance phone company to a provider of enterprise network services. "
...
"The service will be rolled out gradually in the coming months. It starts at about $34,000 per month, although prices could run higher depending on usage. In terms of its telecom competitors, AT&T believes it is farthest along in offering Web services (define) to its customers. "
Congratulations to GrandCentral!
Wednesday, March 10, 2004
Jim Waldo clarifies position
Jim does a great job clarifying his position on standards:
http://www.artima.com/forums/flat.jsp?forum=106&thread=4892
Jim states:
Point one: Just because something is called a standard doesn't make it open; and something that isn't a standard is not, because of that, proprietary.
Point two: A standards body is often a lousy place in which to invent a technology.
Point three: The previous posting was not a veiled (thinly or otherwise) attack on any particular standards group or collection of standards groups.
Point four: If there are multiple groups competing to write a standard for the same thing, it is probably a safe bet that the technology being standardized isn't ready for standardization.
Well done. I think Jim fully understands it. Sucks doesn't it? Oh well.
Now, I'd like to see Jim (the brain behind Jini) take some of his vast knowledge and write a couple new standards... for starters, I think he'd have quite a bit to add to ws-discovery: (ws-leasing, etc.)
So, here is the WS-* formula:
1. Find a concern (think separation of concerns, they usually end in "ility")
2. Find a remedy to the concern.
3. Take the name of the concern and put the letters "WS-" in front of it.
4. Use as much protocol (with XML) to describe the remedy, use wsdl and the other ws-specs to weave a full story.
5. Publish your spec.
6. Wait for either MS or IBM to "expand" the idea, change the name and republish it with a higher degree of separation of concerns and a name that has a striking resemblance to the name you gave it.
7. Bicker to the press about it.
8. Wait approximately 6 months. Feel free to knock out your reference implementation during this period.
9. Watch the MS-IBM version become popular.
10. Terminate your version and publicly support the MS-IBM version. Be happy that a spec exists.
It really is a very simple, straightforward process. Best of luck.
http://www.artima.com/forums/flat.jsp?forum=106&thread=4892
Jim states:
Point one: Just because something is called a standard doesn't make it open; and something that isn't a standard is not, because of that, proprietary.
Point two: A standards body is often a lousy place in which to invent a technology.
Point three: The previous posting was not a veiled (thinly or otherwise) attack on any particular standards group or collection of standards groups.
Point four: If there are multiple groups competing to write a standard for the same thing, it is probably a safe bet that the technology being standardized isn't ready for standardization.
Well done. I think Jim fully understands it. Sucks doesn't it? Oh well.
Now, I'd like to see Jim (the brain behind Jini) take some of his vast knowledge and write a couple new standards... for starters, I think he'd have quite a bit to add to ws-discovery: (ws-leasing, etc.)
So, here is the WS-* formula:
1. Find a concern (think separation of concerns, they usually end in "ility")
2. Find a remedy to the concern.
3. Take the name of the concern and put the letters "WS-" in front of it.
4. Use as much protocol (with XML) to describe the remedy, use wsdl and the other ws-specs to weave a full story.
5. Publish your spec.
6. Wait for either MS or IBM to "expand" the idea, change the name and republish it with a higher degree of separation of concerns and a name that has a striking resemblance to the name you gave it.
7. Bicker to the press about it.
8. Wait approximately 6 months. Feel free to knock out your reference implementation during this period.
9. Watch the MS-IBM version become popular.
10. Terminate your version and publicly support the MS-IBM version. Be happy that a spec exists.
It really is a very simple, straightforward process. Best of luck.
Tuesday, March 09, 2004
Supply Chain Orchestration: RFID meets BPEL
Last week I made a visit to Boston to meet the people at Connecterra. These guys are in the "RFID middleware" space. This category is often called a 'savant' - although the industry seems to be moving beyond this term.
It was absolutely fascinating to see RFID signals get picked up by the readers, be sent to specialized RFID middleware where the signals were aggregated, filtered and eventually turned into web service (soap) calls. These calls could then could be consumed by a BPEL engine for processing. Immediately, the opportunities for "supply chain orchestration" are illuminated.
I've been working on a white paper called, "Supply Chain Orchestration" with Bob Betts for the last couple of weeks. The topic is huge - the impact is significant. We should have the paper done in a couple of weeks - I'll post a note when it is available.
It was absolutely fascinating to see RFID signals get picked up by the readers, be sent to specialized RFID middleware where the signals were aggregated, filtered and eventually turned into web service (soap) calls. These calls could then could be consumed by a BPEL engine for processing. Immediately, the opportunities for "supply chain orchestration" are illuminated.
I've been working on a white paper called, "Supply Chain Orchestration" with Bob Betts for the last couple of weeks. The topic is huge - the impact is significant. We should have the paper done in a couple of weeks - I'll post a note when it is available.
Adobe launches beta of XML/PDF Form Design Software
See:
Adobe Launches Public Beta of New XML/PDF Form Design Software
"Developers can easily integrate form data with core enterprise systems via XML, OLEDB and web services. Additionally, Adobe Designer allows users to design forms that can be used with digital signature technologies for facilitating secure electronic transactions."
Very exciting!
Adobe Launches Public Beta of New XML/PDF Form Design Software
"Developers can easily integrate form data with core enterprise systems via XML, OLEDB and web services. Additionally, Adobe Designer allows users to design forms that can be used with digital signature technologies for facilitating secure electronic transactions."
Very exciting!
WS-Discovery and Jini
News.com and Ron Schmelzer have once again teamed up to inform the public on web service specifications:
Ws-disc and Jini have a discovery component and Jini is a 'java' only thing. A couple other things worth noting:
1. Sun made a huge mistake by not bundling Jini with the J2EE stack early - this killed Jini - it was considered a 'device only' api.
2. Jini is API not a protocol - they later rewrote this functionality as a protocol for Jxta
3. Jini bundled remedies to concerns (leasing, discovery, proxy, service matching and tuple space) in a single spec.
My belief is that ws-discovery will catch on as long as people don't say, "The idea is very much the same as Jini". As cool as Jini was, it was doomed by Sun. If you want to describe ws-discovery, say "it's a multicast framework for dynamically finding resources on a net (wan, lan, scatternet, piconet, etc.) without knowing the address of any resources ahead of time."
WS-Discovery isn't bundling a ton of things together - it is a lightweight protocol for finding stuff across a variety of networks. It isn't based on a single language and has good support. It can make it - as long as we don't accidentally kill it in the cradle.
Ws-disc and Jini have a discovery component and Jini is a 'java' only thing. A couple other things worth noting:
1. Sun made a huge mistake by not bundling Jini with the J2EE stack early - this killed Jini - it was considered a 'device only' api.
2. Jini is API not a protocol - they later rewrote this functionality as a protocol for Jxta
3. Jini bundled remedies to concerns (leasing, discovery, proxy, service matching and tuple space) in a single spec.
My belief is that ws-discovery will catch on as long as people don't say, "The idea is very much the same as Jini". As cool as Jini was, it was doomed by Sun. If you want to describe ws-discovery, say "it's a multicast framework for dynamically finding resources on a net (wan, lan, scatternet, piconet, etc.) without knowing the address of any resources ahead of time."
WS-Discovery isn't bundling a ton of things together - it is a lightweight protocol for finding stuff across a variety of networks. It isn't based on a single language and has good support. It can make it - as long as we don't accidentally kill it in the cradle.
Thursday, March 04, 2004
The Web Service Dial Tone
Web Services are failing and I know why.
Most people I talk to think the lack of adoption is for one of two reasons:
1. The huge WS-* stack is too complicated and it reminds them of CORBA.
2. We haven't found a killer app for ws.
These are both interesting - but in my opinion, they are not the real reason why ws are failing. I firmly believe the answer is very simple; we haven't created a web services dial tone. When I plug my laptop into a network, it immediately sends a broadcast message to the network. Certain devices like routers, firewalls, gateways, etc. respond to the inquiry and pass on some information about their capability and service offerings. This transparent conversation creates a 'network dialtone' - it enables a device to plug into a network, discover the services and converse with them. This capability is at the heart of our TCP networks, but has not been realized in our 'web service networks'.
In order to create a ws-dialtone we need only a handful of capabilities.
1. Consumer-side applications need the ability to send a broadcast message to a network (UDP for web services).
2. Producer-side applications need to be able to listen to the broadcast and respond. They also need the capability to broadcast their availability.
3. UDP style broadcasts are limited to a sub-net. Thus, sub-net routing (via a soap router) is critical.
Much of this functionality is available via the WS-Discovery specification. However, a large number of people in the ws community view the aforementioned protocol as a tool to be used strictly in ad-hoc networks or for consumer hardware devices. And although this is a subset of the target audience, it has broader applicability in the enterprise environment.
As we continue our movement towards contract based development we will begin to see more emphasis on standardizing the contract. Today, our standardized contracts come in the form a platform like J2EE (technical contracts) or from industry working groups (business contracts). The combination of the standardized contract, the discoverable implementation and late binding will introduce a computing model that enables a service oriented system to automatically find producers for a predetermined piece of functionality and to bind to it. Imagine installing a workflow system and immediately after installation, the server found all of the other dependent services (LDAP, single sign-on, etc.) and registered the bindings to those services. This is the vision of a service oriented enterprise - it focuses on the simplified integration of systems by using ubiquitous protocols, standardized contracts and late binding on a dial tone network.
Most people I talk to think the lack of adoption is for one of two reasons:
1. The huge WS-* stack is too complicated and it reminds them of CORBA.
2. We haven't found a killer app for ws.
These are both interesting - but in my opinion, they are not the real reason why ws are failing. I firmly believe the answer is very simple; we haven't created a web services dial tone. When I plug my laptop into a network, it immediately sends a broadcast message to the network. Certain devices like routers, firewalls, gateways, etc. respond to the inquiry and pass on some information about their capability and service offerings. This transparent conversation creates a 'network dialtone' - it enables a device to plug into a network, discover the services and converse with them. This capability is at the heart of our TCP networks, but has not been realized in our 'web service networks'.
In order to create a ws-dialtone we need only a handful of capabilities.
1. Consumer-side applications need the ability to send a broadcast message to a network (UDP for web services).
2. Producer-side applications need to be able to listen to the broadcast and respond. They also need the capability to broadcast their availability.
3. UDP style broadcasts are limited to a sub-net. Thus, sub-net routing (via a soap router) is critical.
Much of this functionality is available via the WS-Discovery specification. However, a large number of people in the ws community view the aforementioned protocol as a tool to be used strictly in ad-hoc networks or for consumer hardware devices. And although this is a subset of the target audience, it has broader applicability in the enterprise environment.
As we continue our movement towards contract based development we will begin to see more emphasis on standardizing the contract. Today, our standardized contracts come in the form a platform like J2EE (technical contracts) or from industry working groups (business contracts). The combination of the standardized contract, the discoverable implementation and late binding will introduce a computing model that enables a service oriented system to automatically find producers for a predetermined piece of functionality and to bind to it. Imagine installing a workflow system and immediately after installation, the server found all of the other dependent services (LDAP, single sign-on, etc.) and registered the bindings to those services. This is the vision of a service oriented enterprise - it focuses on the simplified integration of systems by using ubiquitous protocols, standardized contracts and late binding on a dial tone network.
Tuesday, March 02, 2004
Whitehorse & Virtualization
Microsoft has been touting a next generation designer for creating services and then facilitating the deployment of the services. As Microsoft puts it:
"When creating mission-critical software, application architects often find themselves communicating with their counterparts who manage data center operations. In the process of delivering a final solution, the application's logical design is often found to be at odds with the actual capabilities of the deployment environment. Typically, this communication breakdown results in lost productivity as architects and operations managers reconcile an application's capabilities with a data center's realities. In Visual Studio Whidbey, Microsoft will mitigate these differences by offering a logical infrastructure designer (Figure 19) that will enable operations managers to specify their logical infrastructure and architects to verify that their application will work within the specified deployment constraints."
The environment allows you to drag a service description to a physical node and drop it on the node to signify deployment.
At first this seemed like a great idea, but after spending some time with the IBM grid team they quickly reminded me that "services belong to the network, not a predefined physical node". Thus, hardcoding service locations to a physical node kills the benefit of virtualization. Well - I agree - you want to drag your service to a "service network" and there should be various sub-nets that are partitioned based on resources and capability.
But, I must admit... the Whitehorse demo sure looks cool... It is very "Microsoft".
"When creating mission-critical software, application architects often find themselves communicating with their counterparts who manage data center operations. In the process of delivering a final solution, the application's logical design is often found to be at odds with the actual capabilities of the deployment environment. Typically, this communication breakdown results in lost productivity as architects and operations managers reconcile an application's capabilities with a data center's realities. In Visual Studio Whidbey, Microsoft will mitigate these differences by offering a logical infrastructure designer (Figure 19) that will enable operations managers to specify their logical infrastructure and architects to verify that their application will work within the specified deployment constraints."
The environment allows you to drag a service description to a physical node and drop it on the node to signify deployment.
At first this seemed like a great idea, but after spending some time with the IBM grid team they quickly reminded me that "services belong to the network, not a predefined physical node". Thus, hardcoding service locations to a physical node kills the benefit of virtualization. Well - I agree - you want to drag your service to a "service network" and there should be various sub-nets that are partitioned based on resources and capability.
But, I must admit... the Whitehorse demo sure looks cool... It is very "Microsoft".
Friday, February 20, 2004
Mach3 Turbo ESB
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.
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.
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.
Subscribe to:
Posts (Atom)
Posts
