I'd disagree, based on definitions, with Tony that Delivery Server (DS) is more bespoke than a custom built ASP.Net application. It is a domain specific application though, focused on content centric sites (intranets, extranets, and public sites). If you want to build a calculator or Photo-editing application it won't fit the bill. Although it's integration capabilities may let you expose apps or work in conjunction with apps written in a more suitable language.
*Pros:* Personalization. You can leverage categories and keywords to be passed on as metadata that will drive business rules for security, teasing premium content, providing related content, providing personalized content lists based on interests, and numbers of other scenarios. Personalization can be expensive (performance wise) so one of the most important parts of scalable sites with personalization is advanced caching. Delivery Server has multiple layers of caching natively so we carry forward the baking mentality of Management Server even into dynamic content delivery, by baking as much as we can and caching the baked parts. We do this by a mechanism called Component Cache that allows elements of a page to be cached independently. This is something other languages don't provide out of the box<http://www.devtrends.co.uk/blog/donut-output-caching-in-asp.net-mvc-3>. Integration. SOAP (Web Services), REST (HTTP), Relational DB (RDB - with connection pooling), Open API are three connectors and a Java API layer that allow you to integrate with pretty much anything. The first three take out much if not all the work of stubbing and post processing. The Open API lets you call any Java library (LDAP, SAP, Peoplesoft, etc...) and return a text or XML result. You can then render the results into your design. At the rendering engine in Delivery Server the Web Content and Integration results. As well authentication means exist so you can establish trusted authentication with external applications whether you intend the to run as a portal above DS. Search. Once setup this allows for quite easy setup of facets based on your taxonomy. Support should have a checklist of things to review for Verity K2 installs if you are having issues. With the latest release this supports Verity K2 and OpenText Common Search. In v11 OT Common Search integration is deeper, OT Semantic Search is integrated, there is a new constraint system that should enable more performant searches even in organizations with large ACLs (users with ~50 group memberships). *Cons:* XML and XSL. I don't see this as a draw back but I know a lot of people who understand well formedness and validity in XHTML don't want to translate that to other syntaxes. I think you'll find on Google Group or Solution Exchange there are people who will help overcome hurdles around specific issues in implementing a use case. I've trained several consultants with no prior XML/XSL experience to be Delivery Server Consultants with little more than some projects and w3schools as a reference guide so I'd suggest if you have someone who's open and with some programming or JavaScript knowledge you'll be successful. Investment in knowledge. Tony isn't wrong if you don't want to do some training and/or get some services to get an established environment and solid foundation you may face challenges down the road and may have been better using Management Server (with its code agnostic nature) and custom applications for delivery. If you don't have large libraries of custom code consider which approach is better suited to your end goals, companies buy of the shelf applications to reduce costs of custom code maintenance. *Summary* It has real technical benefits. If there are specific challenges you have reach out to support and your account team to let them know, they may be able to help and give some advise in that channel as well. The technical and adoption concerns are that different from those I hear expressed from time to time around Management Server. A big difference is you don't execute ASP.Net (JSP, PHP, RoR, etc..) code directly into a Delivery Server page, you call it via web services, link to it, embed it with portlets, or serve it content via REST/SOAP. -- You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/reddot-cms-users/-/yc1dwZZoLoQJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=en.
