Benefits of delivery server
ng
We installed Delivery Server (or live server as it then was) a few
years back. We've never been able to get the search working properly
and haven't used the personalisation as we initially intended. We are
now considering removing delivery server. It would be good to hear
from others the pros and cons that you have found with delivery server
to help us with our decision.
Many thanks
Tony Gayter
--
You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group.
To post to this group, send email to reddot-c...@googlegroups.com.
To unsubscribe from this group, send email to reddot-cms-use...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=en.
Tim D
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.
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.
Tony Gayter
--
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.
ng
I will let you know how we get on.
On Nov 30, 3:53 pm, Tony Gayter <tonygay...@gmail.com> wrote:
> When I said about it being bespoke I meant the system as a whole. ie. how
> many people do you know that could hop into a delivery server project and
> how many do you know that would be able to step into a .net project and
> know what they are doing. You would need special training to use DS and get
> used to the dynaments etc..
> With .net I can just get the cms to pass data to controls and .net can do
> what it wants to it. Also the search engine wasnt great last time I used it
> (although it does sound like its getting better), using .net allows the
> client to choose how they want it searched, most of the time they already
> have a google mini or GSA.
>
> Regarding technical benefits, I know it integrates fairly well but I dont
> think there are enough benefits on a solution which costs a lot to
> implement (cost of the delivery server + the cost of someone who knows how
> to use it etc..) vs doing it in .net which is a free framework, a huge
> amount of online support, thousands of .net developers to hand and pretty
> much any code already on google to use.
>
> I know in some situations it might be good to use but I havnt come accross
> one yet which couldnt be done quicker, easier and cheaper using .net.
>
> Just thought of a reason to use it, you might be restricted to a unix
> platform and with DS running on Apache it wouldnt be as much of a pain to
> get running as it was on an iis box (we had to use isapi rewrite and that
> had to be run on IIS as we had a number of URLs assigned in a way that
> Apache couldnt handle).
>
> On 30 November 2011 14:28, Tim D <timothy.j.da...@gmail.com> wrote:
>
>
>
> > 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 reddot-c...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > reddot-cms-use...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/reddot-cms-users?hl=en.- Hide quoted text -
>
> - Show quoted text -
ng
and Danny pointed me towards a previous google groups discussion on
this - https://groups.google.com/group/reddot-cms-users/browse_thread/thread/36b7440b382f32f0/f30b02a23b44f5e8?hl=en&lnk=gst
For others who may be interested. Apologies not to have found before.
On Dec 6, 4:13 pm, ng <ngraham...@gmail.com> wrote:
> Tim, Tony, thank you.
> I will let you know how we get on.
>
> On Nov 30, 3:53 pm, Tony Gayter <tonygay...@gmail.com> wrote:
>
>
>
> > When I said about it being bespoke I meant the system as a whole. ie. how
> > many people do you know that could hop into adeliveryserverproject and
> > how many do you know that would be able to step into a .net project and
> > know what they are doing. You would need special training to use DS and get
> > used to the dynaments etc..
> > With .net I can just get the cms to pass data to controls and .net can do
> > what it wants to it. Also the search engine wasnt great last time I used it
> > (although it does sound like its getting better), using .net allows the
> > client to choose how they want it searched, most of the time they already
> > have a google mini or GSA.
>
> > Regarding technical benefits, I know it integrates fairly well but I dont
> > think there are enough benefits on a solution which costs a lot to
> > implement (cost of thedeliveryserver+ the cost of someone who knows how
> > to use it etc..) vs doing it in .net which is a free framework, a huge
> > amount of online support, thousands of .net developers to hand and pretty
> > much any code already on google to use.
>
> > I know in some situations it might be good to use but I havnt come accross
> > one yet which couldnt be done quicker, easier and cheaper using .net.
>
> > Just thought of a reason to use it, you might be restricted to a unix
> > platform and with DS running on Apache it wouldnt be as much of a pain to
> > get running as it was on an iis box (we had to use isapi rewrite and that
> > had to be run on IIS as we had a number of URLs assigned in a way that
> > Apache couldnt handle).
>
> > On 30 November 2011 14:28, Tim D <timothy.j.da...@gmail.com> wrote:
>
> > > I'd disagree, based on definitions, with Tony thatDeliveryServer(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.DeliveryServerhas
> > > multiple layers of caching natively so we carry forward the baking
> > > mentality of ManagementServereven into dynamic contentdelivery, 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 inDeliveryServerthe 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 beDeliveryServer
> > > 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 ManagementServer(with its code agnostic nature) and custom
> > > applications fordelivery. 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 ManagementServer. A big difference is you don't
> > > execute ASP.Net (JSP, PHP, RoR, etc..) code directly into aDeliveryServer
> > > 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 reddot-c...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > reddot-cms-use...@googlegroups.com.
> > > For more options, visit this group at
> > >http://groups.google.com/group/reddot-cms-users?hl=en.-Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -