Given the purpose of a PSDN Professional or Premier subscription, why does the SDK not include all of the PSC products? Don't they want us to experiment with Sonic ESB, Apama, EasyAsk, DataXtend, XQuery, etc.?
You're supposed to buy them all before you try them out!
You should find that SonicMQ® Professional Developer Edition and Sonic Integration Workbench are part of the PSDN subscriptions for 2006. As for whether any of the other products you mentioned might be part of PSDN for 2007, I can't say, but if you're interested in them, I'd recommend talking to your local sales rep.
PSDN is a product offering for OpenEdge. Until we decide to change the strategic direction of PSDN to incorporate all product under the Progress umbrella, we will only include in the SDK products that complement OpenEdge. In 2007 we are planning to include evaluations for some of these products.
Certainly if you would like to evaluate any other Progress product, please contact your local sales rep.
Regards
Kristen
The message at Exchange was that all of these products "complement OpenEdge". Certainly, the full Sonic ESB suite and accompanying products are a key part of Progress' SOA offering ... for OpenEdge, not just for non-Progress products! The only product which might be questionable as being complementary is DataXtend and that only because it doesn't yet support any released Progress version. If the message of that great bookstore demo is, "look how all these Progress products work together to achieve this clever solution", then they ought to all be in OpenEdge. Doesn't AutoEdge have a piece that requires Sonic ESB? Wouldn't it be great to keep adding pieces to AutoEdge that demonstrated the rest of these products? And, wouldn't that require a way to have those products without first committing thousands of dollars?
PSDN includes Sonic ESB and SonicMQ.
2006.3 announcement: http://www.psdn.com/library/entry.jspa?externalID=1122&categoryID=96
FAQ: http://www.psdn.com/library/entry.jspa?externalID=1025&categoryID=1
AutoEdge is outside the scope of the PSDN SDK.
If you'd like a copy of any other Progress Corp. product, you can talk to your local sales rep and get an evaluation.
Regards
Kristen
Didn't I just ask you this question off line and you told me that web page was inaccurate? My 2006.3 includes a green sheet with keys for the Integration Workbench and for "SonicMQ Prof Dev E", which I assume is SonicMQ Professional Developers Edition.... no ESB in sight.
The come from different origins and purposes, to be sure, but one has to recognize that one of the problems with AutoEdge as an example is that its richness requires a rich array of software underneath it in order to be able to demonstrate all of its capabilities. Few shops are going to have all of that software available ... unless they have a PSDN subscription ... exactly for the purpose of being able to explore all these technologies for their possible utility. In that respect, PSDN SDK and AutoEdge are delightfully complementary.
Mind you, I think all these products should be in the SDK even if AutoEdge didn't exist. It is merely that AutoEdge provides a preconstructed way to illustrate the use of the technologies.
Yes, Thomas you did ask me offline that very question. While attempting to update the newsletter page, it was brought to my attention the full understand what SonicESB is. The website is actually correct and it was only missing reference to Sonic MQ (which was my confusion), which was updated today.
The Sonic ESB 7.0 product family release includes the new Eclipse-based Sonic Workbench™ that dramatically accelerates the modeling, configuration, testing and deployment of projects across large-scale, distributed SOA environments.
The new, Eclipse-based Sonic Workbench™ 7.0 provides an integrated SOA toolset to streamline a project lifecycle. This is included in your PSDN SDK.
You will only see SonicMQ and Sonic Workbench on your green sheet.
I was going to update you with this information via email yet I got caught up with responding to you via the forum where these questions were also posted.
Regards
Kristen
While I am fuzzy on the details, I am aware that the workbench includes tools for designing many or all of the components of ESB, but what about the deployment components? SonicMQ Prof Dev E is definitely not the same thing as Sonic ESB.
Correct me if I'm wrong, but the Sonic Workbench is like the super-set of all sonic products required for development. ie, it includes Sonic ESB, Sonic MQ and the Sonic Workbench itself...
Perhaps you could tell us what you're trying to do that you can't do with the Sonic Workbench. That might make it easier to figure out which bits you think you are missing??
As I said, I do have the understanding that the workbench provides something like a superset of the development capabilities. But, to actually test anything, one needs the deployment products as well, no? What good does it do me to create a workflow for the Orchestration Server if I don't have a copy of the Orchestration Server to deploy it to? And how do I test to decide if this is how I want to go without it. Sure, eval licenses if the situation is immediate and concrete enough, but I thought the whole point of the SDK was to provide us with a base set of products so that we could try things.
Having only had it loaded for 2 days, I don't know what I can't do yet. But, it seems reasonable to expect that, if I don't have the deployment products, I can't do deployment for testing.
Thank you for your feedback. I will look into this.
Thanks
kristen
The message at Exchange was that all of these
products "complement OpenEdge"...
Not only at Exchange but the "Innovation Roadshow" has been all about how all of these products work together.
I agree -- the SDK should obviously include all of them. Anything less is, well, less.
Maybe we should make a comparison to the OpenEdge products. If you have OpenEdge Architect or OpenEdge Studio (either purchased or evaluation editions), you have the possibility to start 2 of each of the AppServer and WebSpeed agents. You didn't have to order the Application Server product and you didn't even have to enter serial codes for them.
Of course, the ability to use these components is strictly and some of the higher end functionality (eg. more than 2 agents/broker, Name Server Load Balancer, etc) is not there.
With the Sonic Workbench, you should have all the things you need to test the functionality of everything you can design.
Perhaps.
But a significant part of the attraction of the PSDN SDK, which we pay for, is that it includes licenses that permit realistic testing of realistic deployment scenarios. The Enterprise database license, for instance, is for 300 users.
There is a very distinct and qualitative difference between 2 and 300.
Just as there is a distinct and qualitative difference between "windows only" and "all platforms".
Also, while Sonic is obviously the most mature complimentary technology, this isn't just about Sonic. The message from Progress, the parent company, is that everything under the Progress umbrella is good for us and our customers and that it should all be considered when we are designing solutions. (Even though there may be some things that are currently somewhat better integrated than others.) A big part of the perceived point (and value) of the SDK is that it is "everything" in one package precisely so that we may have all of the tools necessary to do so at our disposal and on our whim.
I can understand and appreciate that it may take a few cycles to get a new acquisition or a new product in a suitable state to be rolled out to the SDK. That's less than ideal but understandable. But it is, at best, myopic to claim that Apama, Actional, DataXtend, EasyAsk, ObjectStore and so forth do not belong in the SDK as full-fledged products. Especially when you have big, bold and splashy presentations in front of 1,000 or so of your closest admirers extolling how well they all work together as a family.
Of course the SDK is not for deployment. But it is missing the point to use that as an excuse to exclude "high end functionality" and whole products. The very point of the SDK is to make high end functionality and products available. Presumably that is because an enlightened person somewhere in the hierarchy understands that if partners have such access they are much more likely to embed such products in their solutions which will, in turn, lead to far greater license revenue for Progress.
With the Sonic Workbench, you should have all the things you need to test the functionality of everything you can design.
Perhaps ... and perhaps not ... little limitations seem to creep in from time to time. Like 2 agents doesn't really allow for much of a stress test or for an application design in which load is spread across cooperating agents.
Also, as I understand it, the SDK doesn't include any tech support on any of the deployment products. So, what happens when I try my experimental test deployment and run into a problem? I have had to maintain my maintenance on my internal workgroup database license and client networking ... even though I have enterprise database in the SDK.
And, of course, Sonic Workbench doesn't do anything for Apama or EasyAsk or ...
Keep in mind that a couple of the newer products don't have a separate developer product at this time. These products started as a large enterprise products where there was no distinction between development and deployment licenses.
We're working on figuring out how to create package-able development versions on some of these pieces now. It is our goal that PSDN subscribers be able to experience the full range of what we have to offer. Where we can't have separate products, we're working on how to put together evaluation copies for PSDN.
Stay tuned.
(This is a much later response to an old thread, but the thread contains some information that seems to need clarification)
Sonic Workbench (the product and download) has a number of parts.
This is unlike OpenEdge Architect which runs code inside an embedded PVM within Eclipse. Sonic Workbench has the eclipse portion as well as all the runtime/deployment components for all the Sonic products. Whenever you "run" or 'test' in Sonic Workbench, then you are really deploying items to proper runtime containers and runtime deployments.
There are a few differences. The defaults for containers in Sonic Workbench installations are set up to help developers with debugging, and are not configured for high performance. So you should not use Sonic Workbench for Performance testing (but equally, you should not use SonicMQ Professional Developer Edition for this either).
Of note:
The bottom line here is that all the Sonic runtimes are available in Sonic Workbench.
Yes, but one can't actually set up a test deployment configuration as one would for a real installation, which seems to me a major limitation in terms of both self-education in how to do full installations and in terms of proof of concept testing.