Portals: The Original SOA Framework


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Application Integration Summit Ray Valdes June 2006 Barcelona Portals: The Original SOA Framework These materials can be reproduced only with Gartner's written approval. Such approvals must be requested via e-mail — vendor.relations@gartner.com.
  • Strategic Planning Assumption: By year-end 2007, the frequency of use of the term "SOA" in mainstream press and vendor communication will be less than one-quarter of the level reached in 1Q06, even though the envisioned benefits of SOA will not be achieved by a majority of enterprises during that same time period (0.8 probability). During the late 1990s and early 2000, Gartner called the term "portal" the most misunderstood term in IT. The term was used in reference to large consumer Web sites (destination portals such as Yahoo), a style of user interface (for example, a sales force automation application sporting a particular look and feel), and a type of software package sold by enterprise software vendors (pioneering portal vendors such as Plumtree and Epicentric). Today, there is a strong consensus among vendors, customers, IT professionals and the press as to what constitutes a portal. This strong consensus is absent for the term "service-oriented architecture" (SOA). Although SOA is now widely used by many enterprise software vendors as part of their marketing messages (one company has even renamed itself SOA Software), the term's meaning remains muddy and diffuse. SOA has been used to refer to systems built with a particular language (Java/J2EE and .NET), a technology (XML Web services), a programming paradigm (object-oriented programming) or middleware (enterprise service bus). In fact, SOA is none of these. Rather, it is a design approach or pattern, a discipline, one approach to modularizing distributed systems.
  • Key Issue: What is SOA and what benefits can it provide? A system built with an SOA consists of subsystems that interact in a loosely coupled, coarse-grain manner, with a minimum of state, and with a well-defined contract. The assumption is that the subsystems are fully autonomous: There is no requirement, for example, that these subsystems be built by the same organization, on the same platform, or with the same toolset. Rather, each is assumed to have its own life cycle, and can freely participate in interactions with a number of other autonomous systems. In addition, all interactions are governed by the same contract or formal interface description, as long as there is agreement on the mechanics of intersystem communication. The power of the SOA architectural approach is that it allows autonomous subsystems to be assembled into entities (SOA applications) that can be as cohesive externally as applications built with older architectural approaches (that is, classic structured programming modularization, or object-oriented paradigm). The benefit of SOAs over these older approaches is increased agility and greater tolerance for change throughout the life cycle of a system, compared with a system that assumes tight coupling and homogeneity across the subsystems. Strategic Planning Assumptions: By year-end 2006, more than 25 percent of Global 1000 companies will have embarked on an SOA initiative visible at the enterprise level (0.7 probability). By year-end 2008, the majority of these initiatives will have not yet delivered significant business benefits in terms of increased agility and flexibility (0.7 probability).
  • Strategic Planning Assumption: Through 2007, at least one-third of software systems that are labeled SOA will not rely on loosely coupled, coarse-grain, stateless connections (0.8 probability). Key Issue: What is SOA and what benefits can it provide? Service-oriented systems do not require the Web services suite of protocols, but the Web services protocol family provides a standard, widely supported foundation for intercommunication between SOA systems. Portal technology predates Web services, but has evolved to incorporate support for this distributed computing technology, along with other technology for application integration (for example, message queues and connectors). Another benefit of a SOA is that two subsystems can each pursue their own destinies, their own life cycles. As long as there is a contract that governs the interaction between the two, they can evolve separately. Thus, SOAs offer greater flexibility and agility. Enterprises can recombine, reassemble and orchestrate their systems with other systems to create composites more quickly than they would by developing a monolithic system from scratch. But the SOA phenomenon is not without shortcomings and limitations. SOA is only for systems that interact in a loosely coupled, coarse-grain manner, and for some systems, the application requirements dictate a more-tightly coupled interaction. SOA modularization is of a different kind than object-oriented modularization, a distinction that is sometimes hard to grasp for developers steeped in older approaches. Despite much lip service from vendors and professional services firms, the SOA architectural approach is still not widely understood. Many developers have a grasp of the general concept, but implementation-level patterns and tactics are not widely known. And, although vendors are working on the problem, SOA still lacks robust support from development tools.
  • Strategic Planning Assumption: Through 2010, enterprise information systems that follow the SOA design pattern will have significant advantages over non-SOA systems in meeting changing business requirements (0.8 probability). Key Issue: What is SOA and what benefits can it provide? Moving to a service-oriented architecture does not happen automatically. It is not an inevitable outcome of using Web services protocols, or using a particular development platform or tool. SOA is a discipline, a process, an approach to system design. The full process of moving enterprise information systems to SOA requires a number of steps. First, rethink the way systems are connected and match the quality and type of connection to the business and technical requirements of the application. Formulate a plan to refactor and repartition systems based on these requirements. If necessary, wrap legacy systems with a service-oriented layer of abstraction. Specify the interfaces between systems in a documented, formal manner — a contract expressed in a formalism such as WSDL. Make these interfaces discoverable and accessible through a services repository. Implement systems for service monitoring and systems management. Supplement existing security mechanisms and policies with additions appropriate to service-oriented architecture. Only after these steps have been undertaken can the benefits of SOA can be achieved. These benefits include greater agility for enterprise information systems, being able to assemble and reconfigure systems to meet changing business needs. Code can be reused, developer productivity improved, and the IT backlog reduced.
  • Key Issue: How have portal technologies evolved to support SOA? Key Issue: How have portal technologies evolved to support SOA? Portal technology has evolved through multiple generations since the first portals in 1997. Each generation builds on the previous one. Generation 1 was all about access to content, providing personalized delivery of content plus unified search and basic presentation management. Generation 2 scaled up the technology foundation with a robust extensible application framework, basic application integration and the beginnings of collaborative features. Generation 3 added process integration, and basic support for Web services and for multiple portals. Generation 4 is the current generation, and it introduces support for portal federation, composite applications and portlet standards (Java Specification Request [JSR] 168 and Web Service for Remote Portlets [WSRP]). These generations show where the majority of portal products are at a given point in time. Of course, not all vendors support all features, and some will lead others by as much as several years. This technology stream is independent of the way in which a portal package is used (that is, an end-user organization can undertake a Generation 1 deployment using the latest Generation 4 technology). Portal technology is also distinct from the way in which portal products are packaged, increasingly one of bundled suites — application platform suites (APSs) and smart enterprise suites (SESs). Generation 5 portal products push SOA to new levels. They will provide off-the-shelf support for service-oriented business applications (SOBAs), packaged integrating processes (PIPs) and packaged composite applications (PCAs), as well as process orchestration and syndication of services.
  • Strategic Planning Assumption: Through 2007, the number and types of nonportlet connections between portals and external systems will continue to increase (0.7 probability). Key Issue: How have portal technologies evolved to support SOA? Portals are sometimes thought of as being purely the presentation layer for enterprise software. This limited view ignores a major source of business value in portals, which has to do with aggregation and integration. Portals are about aggregation and integration: They aggregate content and integrate business function. Portals blur the boundaries between applications, between content silos, between organizational structures, between applications and infrastructures and between enterprises. This is needed to provide unified and effective access to all the information resources in the organization: structured content, unstructured content, business logic in legacy applications, and new logic in composite applications. The benefits resulting from this include increased productivity, agility and acceleration of business decisions through improved access to content. To achieve these benefits, portals need many different ways to connect to other systems and applications. Portlets are the most visible mechanism and the most widely used. Every portal vendor offers a library of portlets that connect to major applications (ERP, SCM, CRM) as well as to major systems (e-mail, collaboration, document management). Beyond this, portals connect to other resources through systems such as the embedded search engine, directory access system (LDAP). These are mostly read-only connections. In addition, portals connect through the application integration layer, through the business process modeling layer. These connections are first-class, two-way connections. The diversity of connection types gives the portal its utility value as the "Swiss Army knife" of enterprise software.
  • Strategic Planning Assumption: Through 2007, the aggregate number of portal instances deployed within Global 500 companies will not decrease more than 20 percent, despite ongoing efforts at portal rationalization (0.7 probability). Key Issue: How have portal technologies evolved to support SOA? The long-standing vision of the enterprise portal has been as the center of gravity for the entire "solar system" of IT within an organization: the diverse collection of applications, content repositories, and supporting software infrastructure (such as enterprise directories and data warehouses). The portal becomes the center of that system, the sole point of aggregation and integration. In practice, the reality of portal deployment as found in the average large enterprise is much less elegant and more complicated. There are often multiple portals located in various business units and departments, or closely associated with particular applications (by vendors of those applications). This situation is often a result of accident rather than design, from a combination of historical circumstances (such as a merger or acquisition). Even as these complexities are ironed out and removed (legacy portals from an acquisition retired), new portals may be introduced. For example, many organizations that are using SAP ERP system are now introducing SAP portal as a front-end to those applications. Microsoft Sharepoint portal is growing rapidly at the grassroots level as departments and business units search for a simple way for teams to collaborate, at a perceived low price. IBM is selling its packaged composite applications (for narrow-scope functions such as Sarbanes-Oxley compliance) that come bundled with a portal. Ironically, even though the value proposition of portals is to connect to any system (software infrastructure or application), few portal vendors have invested in making their portals interoperable with those of others — other than sometimes nominal support for the two main cross-vendor standards, WSRP and JSR168.
  • Strategic Planning Assumption: By year-end 2007, fewer than 40 percent of established content service providers will support WSRP (0.7 probability). Key Issue: How have portal technologies evolved to support SOA? These are portal components that understand the WSRP protocol (Web Services for Remote Portlets). The portal is basically yielding a portion of screen real estate to a remote server. User interaction is funneled through the portal to the remote system, which gets user events and responds by sending the presentation back to the portal, which throws it on the screen for the user. Although the WSRP protocol uses Web services protocols to transfer data from WSRP producer (content provider) to WSRP consumer (portal), it is not service-oriented in the usual sense of SOA. The consumer yields control of the user interaction to the provider and, in effect, stands on the sidelines for the duration of the task. Because of this surrender of control, the SOA concept does not apply (because SOA has to do with a style of interaction between two systems, and here, in effect, there is only one system generating data through a transparent or passive pipeline). Nevertheless, a WSRP-based interaction can form part of a service-oriented scenario in the same way that object-oriented components can comprise part of a broader-scope SOA scenario. Despite being mostly orthogonal or separate from SOA, WSRP can be a valuable part of the portal implementer's toolkit.
  • . Tactical Guideline: Establish a policy that specifies JSR168 and its successor, JSR286, as the default choice for custom portlet development, but allow leeway for exceptions. Key Issue: How have portal technologies evolved to support SOA? JSR168 is a standard that governs how portlets live, work and die inside a Java-based container (portal framework). JSR168 was long-awaited in the early part of this decade because of the highly fragmented portal market: a large number of vendors, almost all with Java-based portals, but all with unique portlet APIs on top of that common foundation. The hope was JSR168 would provide organizations with multiple sources of portlets, because third-party component vendors could target across multiple vendors rather than single-vendor APIs. Now that JSR168 has been finalized and incorporated into portal packages, this vision of a vibrant third-party aftermarket has not materialized. Reasons include: limited scope of the spec (major limitation being lack of interportlet communication, which limits the functionality that can be packaged into a portlet or collection of portlets), slow incorporation of JSR168 into shipping portal products (despite much lip service), lack of awareness among portal customers (they have a lot to digest). The strongest support for JSR168 comes from open source portal authors, who see the standard as mitigating the risk that enterprises may perceive in open-source products. For a variety of reasons, including immaturity of packages, adoption of open-source portals has been slow. This has not helped the broader momentum of JSR168. JSR286 improves upon JSR168 by adding WSRP-compatible inter-portlet communication, and compatibility with J2EE 1.4, with JSF, with WSRP caching, and with JSR188-based profiles.
  • Strategic Planning Assumption: By year-end 2007, the majority of portal vendors will refactor their packages to expose nonportlet subsystems via service-oriented interfaces (0.7 probability). Key Issue: How have portal technologies evolved to support SOA? Over the years, portal deployments have grown in sophistication, evolving from content-centric to application-centric (see "Gen-4 Portal Functionality: From Unification to Federation," G00117444). Increasingly, it has become a requirement for portal vendors to offer application integration capability with their portal product, either as standard feature or as an extra-cost option. This consists of raw integration capability such as a message queue system or enterprise service bus, as well as value-added layers such as a library of off-the-shelf connectors that can plug into well-known interfaces of established business applications from Siebel Systems, PeopleSoft/Oracle and SAP. Developers can use the application integration capability in a portal in either a SOA or non-SOA manner, depending on the target system that the portal is connecting to. Some systems will expose a coarse-grain SOA interface, others will use a conventional API that is tightly coupled. System developers can wrap these APIs with a service-oriented wrapper, or target the system directly with a non-SOA connection. Connections based on a the vendor's library of pre-built connectors are somewhat more constrained with respect to service orientation, but even these can be wrapped with a service-oriented interface, not at a remote port but local to the portal (that is, the connection between the portlet and the application integration substrate).
  • Key Issue: How have portal technologies evolved to support SOA? Web services are gaining popularity as a new form of clustered business logic. Whether Web services are used across the Internet (via HTTP) or from an internal repository, each service will be, at best, a fragment of a larger business process. As enterprises build composite processes from Web services, a natural evolution of BPM will occur. BPM will act as the "glue" to link discrete process elements (for example, Web services) into a dynamic flow. As portal technology continues to evolve, an emerging requirement for portal products is to embed or integrate the portal with a business process orchestration engine, preferably one that can understand models expressed in BPEL (Business Process Execution Language). These models do not explicitly require SOA but will greatly benefit from growth of SOA-based interfaces. One could say that SOA gives business process management (BPM) engines something to work on, and (over time) BPM engines will unlock the potential of SOA. Most portal products support workflow today. A few are starting to take steps into process orchestration. By 2007, all leading portal products will support process orchestration (0.7 probability). Many portal frameworks have long-standing (albeit proprietary) interportlet communication mechanisms (such as IBM's click-to-action). These provide "on the glass integration" which allows construction of composite applications. Process orchestration enhances this existing capability, adding flexibility, manageability and interoperability. Strategic Planning Assumptions: By 2007, all leading portal products will support process orchestration (0.7 probability). Through 2008, the majority of enterprise portal deployments will not rely on process orchestration in a significant way (0.7 probability).
  • Strategic Planning Assumption: Through 2008, portals will be present in the majority of composite application deployments in Global 1000 companies (0.7 probability). Key Issue: How have portal technologies evolved to support SOA? Composite applications blur the traditional dichotomy between tactical and strategic application development. Tactical development has an emphasis on opportunistic time frames, rapid construction using high productivity tools, straightforward requirements and limited scope. Strategic development emphasizes doing a complex job correctly and systematically, with careful methodology applied by a large team of skilled developers, at the expense of a large budget and extended time frame. Composite applications allow the construction of enterprise-scope applications at tactical speeds. Not all composite applications leverage portals; some rely on proprietary front ends or runtime environments. But portals are a natural fit, because they provide a forward starting point for development, with facilities for integration, user interface management and administration. One can view the evolution of portals in three phases. The first phase, now past, is aggregation of content — access through search engine, delivery through personalization and presentation management, with a general but diffuse benefit of improved productivity. The second phase is integration of business function, providing access to existing enterprise applications through portlets that extract data and expose simple functions in the portal page, resulting in ROI. The next phase is portals as a development platform for new applications that can leverage of the capabilities provided by the portal. Composite applications play an important role in this emerging phase.
  • Strategic Planning Assumption: Through 2007, more than 50 percent of portal deployments will be content-centric; through 2008, no more than one-third of portal deployments will use the portal as the default platform for new applications (0.7 probability). Key Issue: How can portal deployments better support SOA initiatives? Portal technology has matured, and the leading portal packages are more alike than different, but there is a lag in adoption of features introduced with subsequent releases. A portal can be termed the "Swiss Army knife" of enterprise software — a multifunction tool that can be deployed in different ways by different enterprises. Two enterprises in the same industry sector, of similar size and financial characteristics, can deploy the same package for the same vendor in different ways, with a dramatically different cost structure. There are alternative ways by which enterprises can derive value from portals. Some find great satisfaction in a Generation 1 (G1) deployment, in which the portal is primarily used for unified access to content repositories across the organization. Often the reason for great satisfaction is the fact that the portal rationalizes and unifies previously disparate information resources, A G1 deployment can be accomplished on a G2, G3 or G4 platform. Other enterprises see the principal value of their portal deployments in providing easier access not to content, but to applications The first step in accomplishing this is through basic mechanisms such as single sign-on. The value of a portal deployment as perceived by end users is not necessarily the same value perceived by management (which might derive great satisfaction in, for example, reduced printing costs).
  • Client Issue: How can portal deployments better support SOA initiatives? The center of gravity of the dynamic system in which portals participate continues to shift. In 1997, portals were deployed for a single department or business-unit. These evolved to broad-scope enterprise-level deployments in 2000-2003. The portal became a strong central force in the IT landscape, one possessing substantial mass relative to what the portal aggregated and integrated — information resources more diffuse, more passive (that is, data rather than logic), that lacked the autonomy of first-class services. In such an landscape of relatively flat, nonautonomous constituent elements, the enterprise portal stood alone. With the advent of multiportal deployments, in the period 2003-2006, the center of gravity shifted and dispersed as new structures of substantial mass (peer portals) loomed in the IT landscape. These multiportal deployments include hierarchical, homogeneous (that is, from the same software vendor) configurations, peer-to-peer federated portals from different vendors, as well as semi-hierarchical "uber-portal" configurations. Now in 2006 and going forward through 2009, enterprises will find that theirs is not the only collection of structures on the landscape. Increasingly, enterprise portals will connect to services on the broad expanse of the public Internet in ways that are richer, more sophisticated and more pervasive, than the simple external content services that portals have always tapped into. These external services not only include base-level functions such as blogging, calendaring, content and ERP application functionality, but also an emerging set of higher-layer services such as distributed identity, shared metadata, and large-scale content aggregation. Strategic Planning Assumption: By 2008, at least 20 percent of enterprise portal deployments will connect to external services that are more than just content (0.7 probability).
  • Strategic Planning Assumption: Through 2008, the majority of Global 1000 companies will adopt the technology-related aspects of the Web 2.0 phenomenon, but will fail to adopt the aspects of Web 2.0 that have a social dimension, and the result will have minimal business impact (0.6 probability) . Key Issue: How can portal deployments better support SOA initiatives? The Web 2.0 phenomenon has gained tremendous visibility in the mainstream and trade press. As happened with SOA, Web services and portals, we expect IT vendors to try to capitalize on this trend by associating their products with Web 2.0 attributes. The challenge is that Web 2.0 is not just a set of technologies, but also attributes that have a social dimension: new business models, user-contributed content and user-generated metadata, more open and transparent business process, simplicity in design and features, and decentralized and participatory product and process. While it is straightforward to add specific technologies, such as Ajax and RSS to products, platforms and applications, it is more difficult to add a social dimension , such as user-contributed content or a new kind of business model, if it has not been architected into the application. Adding these new aspects requires rethinking the design of the system and possibly its target audience. It is therefore more challenging than a cosmetic makeover to the application via Ajax, because it can imply significant changes to the development process, business model and perhaps even the mission of the system that is under construction. Because these implications are more far-reaching, Gartner expects adoption within enterprises (as opposed to startups) to be at a much lower level than the simple incorporation of technology. However, missing out on the nontechnology aspects of Web 2.0 means that many organizations will also miss out on some of the positive business benefits.
  • Strategic Imperative: Consider how your applications can gain business value through user-contributed data and user-generated metadata. Key Issue: How can portal deployments better support SOA initiatives? Two distinct technologies and architectural approaches have evolved in parallel over the past decade. On the one hand, the Web channel has become an integral part of the way businesses and organizations engage with a range of external audiences — to project a brand, conduct commerce, support customers and constituents, and optimize external-facing business processes. On the other hand, there is a separate effort regarding internal information systems. These are being refactored and rearchitected using the patterns of service-oriented architecture, to better manage complexity, make development more efficient, and allow existing systems to evolve with flexibility and agility. After years of vendor exhortations to follow the vision and practices of SOA, organizations are moving on a path around which there is substantial consensus (i.e., loosely coupled and based on WS-*). Now change is under way with respect to the external-facing Web channel. It is being reshaped by a rapidly growing Web 2.0 movement, centered around precepts such as greater user participation, decentralized and distributed development, and increased openness and transparency in both technologies and business models, Although adoption by mainstream enterprises will be mixed and uneven, Web 2.0 will push the concepts and practice of SOA in a new direction: toward greater use of lightweight and open technologies, and increased incorporation of user-contributed content and user-generated metadata. Gartner forecasts that Web 2.0 will have an impact, but that adoption will be uneven, biased in favor of technology and less so around the social dimension.
  • Strategic Planning Assumption: At least half of the vendors that offered technology for rich internet applications (RIA) in 2006 will not exist as independent entities at year-end 2008 (0.8 probability). Key Issue: How can portal deployments better support SOA initiatives? Ajax is a label that refers to a browser-based technology and to a repertoire of techniques for Web design in which page elements and content are retrieved asynchronously in the background, and in which the page display is updated incrementally without redisplaying the entire page. Ajax techniques gained a high degree of visibility in the media with the emergence of several high-profile initiatives from Google, such as Gmail (Web-based e-mail) and Google Maps. Google did not coin the term, which originated with an outside observer at the design consultancy Adaptive Path. The techniques (use of JavaScript and XML for local loop processing and partial page refresh) are not new, and date back to 1999 with Desktop.com and to the Outlook Web Access mode in Microsoft Exchange. What is new is evolution in browsers and in hardware processing capacity that allows large amounts of JavaScript code to run correctly and consistently on browsers (Opera, Firefox, Safari and IE) with good performance. Google has been given both too much credit for Ajax (for techniques and terminology it did not invent) as well as too little credit for its initiatives such as Gmail and Google Maps, which are based on genuine innovations in usability and in server-side processing, as well as the Ajax-style client-side techniques.
  • Key Issue: How can portal deployments better support SOA initiatives? A long-standing dictum in software architecture is that the structure of a system reflects the structure of the organization that built it. This is known as Conway's Law, which first appeared in an April 1968 "Datamation" article by Melvin Conway, and has been relied on as a way of assessing and remediating the structure of large-scale complex systems. This insight has been applied to systems built with different methodologies and technology platforms, so it is also applicable to systems architected with the SOA design pattern. However, the actual wording of the original quote is even more applicable to SOA: "Any organization which designs a system … will inevitably produce a design whose structure is a copy of the organization's communication structure." This is relevant because SOA systems are distributed systems connected by a message-based architecture. If communication flow is dysfunctional at the organizational level, this dysfunction will likely surface at the information system level. If organizational units don't communicate well, there may be a disconnect in the SOA system, not at the "plumbing" (SOAP) level, but at the application-level (XML business document). Ironically, departments that work too closely together is not a good thing either, because high levels of coupling may result, reducing agility and evolvability. The quality of connections between subsystems not only affects correctness and agility, but also performance. Strategic Planning Assumption: Through 2008, the majority of SOA initiatives that lack changes to existing governance and organizational structures will fail to achieve business objectives in the time frame specified (0.7 probability).
  • Portal products provide a full spectrum of technologies for extensibility, data integration, application integration, syndication and service-orientation. Some of these capabilities such as WSRP and RSS have a single mode of use, which is largely non-SOA. Others, such as portlets, can be used in either a SOA-style architecture or a non-SOA "legacy" mode. For most scenarios involving portlets, the SOA approach is a better fit with the nature of portlets and with the mission of portals. However, enterprises must understand the nature of service orientation and the system requirements to know which mode to apply. Recommendations Keep in mind that portal technology is multifaceted and can support different kinds of architectural approaches, from tight (non-SOA) to loosely coupled (SOA and more). Consider SOA as just one approach to modularity and connected systems. When building connected systems, pick and choose among the different capabilities in portal: such as portlets using high-performance custom APIs, standards-based portlets, RSS-based syndication and composite app. capability. Prepare for the Web 2.0 wave, which introduces new approaches to platform and process. Be ready to re-evaluate and re-factor your process and organizational structure, not just technology and products.
  • Gartner Application Integration Ray Valdes Summit 2006 June 2006 Barcelona Portals: The Original SOA Framework These materials can be reproduced only with Gartner's written approval. Such approvals must be requested via e-mail — vendor.relations@gartner.com.
  • Portals: The Original SOA Framework

    1. 1. Portals: The Original SOA Framework Ray Valdes Research Director Internet Platforms & Web Services
    2. 2. Conclusions <ul><li>&quot;Portal&quot; used to be most misunderstood term in IT </li></ul><ul><li>&quot;Service-oriented architecture&quot; (SOA) is now most misunderstood </li></ul><ul><li>When understood, both have tremendous potential for positive impact </li></ul><ul><li>Portals are about aggregation, integration and connecting systems </li></ul><ul><ul><li>Content, data, information </li></ul></ul><ul><ul><li>Business process, applications, logic </li></ul></ul><ul><li>SOA is also about connecting systems </li></ul><ul><ul><li>Service-orientation is a pattern for distributed computing </li></ul></ul><ul><ul><li>SOA is not the solution, but one aspect of a solution </li></ul></ul><ul><li>SOA-style connections are not the only ways to connect </li></ul><ul><ul><li>Monolithic, procedural, RPC — still needed in many scenarios </li></ul></ul><ul><ul><li>Other ways to connect loosely coupled systems: WSRP, RSS </li></ul></ul><ul><ul><li>Portals offer many different ways to connect systems </li></ul></ul><ul><ul><li>Web 2.0 will introduce even other ways to connect: &quot;SOA 2.0&quot; </li></ul></ul><ul><li>Bottom line: Portals can be &quot;as SOA as you want them to be.&quot; </li></ul>
    3. 3. Vision of the Service-Oriented Enterprise Etc … HR Customer Service Finance Legacy Logic & Data Services Orchestrated Processes HR Legacy App Finance Legacy App CSS Legacy App LOB App Logic Data Data Data Logic Logic Logic Data Logic Data Service Service Service Service Process Model HR Process Model Across HR and Finance Process Model Budgeting Process Model Customer Service #1 Process Model Customer Service #2 Service Service
    4. 4. Service Orientation: An Architectural Pattern for Distributed Computing <ul><li>Services are </li></ul><ul><ul><li>Autonomous units of business function </li></ul></ul><ul><ul><li>Connected over distributed network </li></ul></ul><ul><ul><li>Contracted with respect to interface </li></ul></ul><ul><ul><li>Coupled loosely rather than tightly </li></ul></ul><ul><ul><li>Independent of platform, toolset, methodology, geography </li></ul></ul><ul><ul><li>Discoverable via registry </li></ul></ul><ul><ul><li>Standards-based , in the modern incarnation of SOA </li></ul></ul><ul><li>Services are not (just) </li></ul><ul><ul><li>Components – Services are a type of component </li></ul></ul><ul><ul><ul><li>Loosely coupled, coarse-grain, standards-based </li></ul></ul></ul><ul><ul><li>Objects – Services are &quot;less than&quot; objects (and this is a good thing) </li></ul></ul><ul><ul><ul><li>Objects have state, are designed for fine-grain interaction </li></ul></ul></ul><ul><ul><ul><li>Services can be composed of objects </li></ul></ul></ul>
    5. 5. Why Bother With SOA? <ul><li>Moving to SOA requires architects to </li></ul><ul><ul><li>Rethink modularity </li></ul></ul><ul><ul><li>Refactor and repartition systems </li></ul></ul><ul><ul><li>Specify contracts, interfaces </li></ul></ul><ul><ul><li>Wrap legacy systems </li></ul></ul><ul><ul><li>Set up system monitoring and management </li></ul></ul><ul><ul><li>Look at security in a new way </li></ul></ul><ul><li>Service orientation has value because it: </li></ul><ul><ul><li>Allows existing information systems to better tolerate change (that is, evolution-friendly) </li></ul></ul><ul><ul><li>Enables the organization to rapidly assemble new applications to support new processes and meet new requirements (greater agility) </li></ul></ul><ul><ul><li>Fosters reuse of code and components (improves developer productivity) </li></ul></ul><ul><ul><li>Reduces skill requirements for creating new application functionality (helps reduce the IT backlog) </li></ul></ul>
    6. 6. Six Generations of Portal Technology: It Is Still About Aggregation and Integration <ul><li>Gen 3 (Mid-2002-2003) </li></ul><ul><ul><li>Process integration Knowledge mgmt. </li></ul></ul><ul><ul><li>Multiple portal spt. Web services </li></ul></ul><ul><ul><li>Adv. personalization Federated search </li></ul></ul><ul><li>Gen 1 (1998-2000) </li></ul><ul><ul><li>Content mgmt./aggregation </li></ul></ul><ul><ul><li>Search/categorization </li></ul></ul><ul><ul><li>Personalization </li></ul></ul><ul><ul><li>Lightweight application framework </li></ul></ul><ul><li>Gen 2 (2000-Mid-2002) </li></ul><ul><ul><li>Application integration Collaboration </li></ul></ul><ul><ul><li>Mobile and wireless Mgmt. tools </li></ul></ul>Application/Data Integration Information Access/ Content Aggregation <ul><li>Gen 4 (2004-Mid-2005) </li></ul><ul><ul><li>Advanced Web services Multichannel interaction </li></ul></ul><ul><ul><li>Composite applications Personal content </li></ul></ul><ul><ul><li>Microsites JSR168 & WSRP </li></ul></ul><ul><li>Generation 5 (Mid-2005-2007) </li></ul><ul><ul><li>SOBA/PIP/PCA support Orchestration </li></ul></ul><ul><ul><li>Advanced collaboration User experience mgt. </li></ul></ul><ul><ul><li>WSRP V2 & JSR286 Portal as services </li></ul></ul><ul><li>Gen 6 (2008-2009) </li></ul><ul><ul><li>Portal ubiquity </li></ul></ul><ul><ul><li>User-managed portal aggregation (client-based/server-based/hosted) </li></ul></ul><ul><ul><li>Peer portal federation </li></ul></ul>Process Integration
    7. 7. Portals Connect to Systems in Many Ways Portlets, RSS, Subsystem Services, Application Integration External Systems & Services Portal Portlet Container Application Integration Layer Personalization Engine User & System Admin. Search Engine Workflow/Process Orchestration Access Control & Identity Mgt. External Systems & Services External Systems & Services External Systems & Services External Systems & Services External Systems & Services External Systems & Services Portlets Portlets Portlets
    8. 8. Multiple Portals Comprise a New Legacy That Incoming Portals Must Deal With Portal Container App. Integration Personal-ization User/Sys Admin. Search Workflow/Process Orchestration Identity Mgmt. Container App. Integration Personal-ization User/Sys Search Workflow/Process Identity Mgmt. Shared Infrastructure Portlets Portlets Portlets Portal Container App. Integration Personalization Portlets User/Sys Admin. Search Workflow/Process Orchestration Identity Mgt. Portlets Portlets Portal Container App. Integration Personalization Portlets User/Sys Admin. Search Workflow/Process Orchestration Identity Mgt. Portlets Portlets Portal Portlets Portlets Portlets Apps Apps Apps Apps Apps Apps
    9. 9. The Promise of WSRP Was External, but Value Thus Far Is Internally Facing Interoperability External Service Enterprise Another J2EE Portal WSRP Wrapper J2EE Portal JSR 168 Portlet WSRP Portlet Native Portlet .NET Portal WSRP Portlet WSRP Portlet Native Portlet JSR 168 Portlet Proprietary API Generic WSRP Protocol External Service External Service Generic WSRP Protocol Proprietary API Proprietary API Remote Portlet Instances Native Portlet
    10. 10. JSR168: Long Awaited Standard, Now Evolving to JSR286 <ul><li>The Fragmented Past </li></ul><ul><ul><li>Almost all portals built on a common technology foundation of Java/J2EE, servlets, JSP, XML, and (increasingly) Web services </li></ul></ul><ul><ul><li>Fragmentation above common layer due to diverse portlet APIs </li></ul></ul><ul><ul><li>Market fragmentation: many vendors with similar market shares </li></ul></ul><ul><li>The Stagnant Present </li></ul><ul><ul><li>JSR168 is cross-vendor standard but limited in scope </li></ul></ul><ul><ul><li>All vendors support it but none is strategically committed </li></ul></ul><ul><li>The Slow-Moving Future </li></ul><ul><ul><li>Efforts to address JSR168 limitations underway </li></ul></ul><ul><ul><li>&quot;Turning the crank&quot; will eventually produce a result </li></ul></ul><ul><li>Recommendation for Portal Customers </li></ul><ul><ul><li>JSR168 and its successor, JSR286, should be default choice (with appropriate exceptions) </li></ul></ul>
    11. 11. Subsystems in Portal Can Be First-Class Services <ul><li>Portlets are not the only points of contact between portals and external systems </li></ul><ul><li>Subsystems (such as search engine) can also be exposed externally </li></ul><ul><li>External systems can be apps. or even other portals </li></ul><ul><li>These subsystems can have conventional APIs or alternatively service-oriented interfaces </li></ul><ul><li>Portal vendors are just starting to refactor their packages </li></ul><ul><li>Similar to how business app vendors are refactoring applications as services </li></ul><ul><li>This unlocks what is a major source of hidden value in portals </li></ul>
    12. 12. Orchestration in and Outside the Portal Enterprise Enterprise Host Engines & Middleware Executable Processes & Workflows Abstract Process Models BPM/ Workflow Engine Process Model . Portal Process Model . Process Model . Process Model . Process Model . Process Model . Process Model . Process Model . BPM/ Workflow Engine Process Model . Portal Process Model .
    13. 13. The Vision of Portal-Based Development Tactical Strategic Portal-Based Code reuse low to medium low to medium high Approach tool-driven model-driven parameter-driven Business driver opportunistic systematic either Requirements simple complex simple Scope departmental enterprise either Skills junior developer senior developer business analyst Team size 1 to 6 6 to 60+ 1 to 3 Code longevity 6 months to 3 years 2 years to 10+ years indefinite Budget small to medium large small Methodology informal formal, systematic informal Risk tolerance high low medium Project duration 1 to 6 months 6 months to 6 years 1 to 6 weeks Connectedness low to medium medium high Code refactoring low low medium Integration use low medium high
    14. 14. Portal Deployments Evolve in Parallel with Technology 1996 2000 2004 2008 2010 Access to content (via search & personalization) Access to apps. (via single sign-on) Platform for new apps. Access to apps (via app. integration) Composite apps. Adaptive apps. Level of Business Transformation Web Services
    15. 15. Enterprise Portals and the Open Internet SOAP / Web Services WSRP Proprietary Protocols Open Internet RSS / Atom REST Enterprise Portal Portal Portal Enterprise Portal Portal Portal Enterprise Sector Content Aggregation Service Shared Metadata Service Distributed Identity Service Blogging Service Group Calendar Hosted ERP App Content Service Vertical Service Shared Content
    16. 16. Web 2.0 Wave Washes Over the Enterprise Enterprises Will Adopt the Least Important Aspects First Degree of Enterprise Adoption Technology Business Impact Moral: High adoption does not necessarily mean high impact . Ajax RSS User-Derived Metadata User Content Decentralized Non- Technology Participatory Openness Simplicity REST Mashups
    17. 17. Web 2.0 Pushes SOA in New Directions The Value Proposition of SOA is Kept or Enhanced: Increased Agility and Evolvability Web 2.0/&quot;SOA 2.0&quot; Web 1.0/SOA 1.0 <ul><li>Platform: .NET or Java/J2EE </li></ul><ul><li>SOAP and WS-* </li></ul><ul><li>Thin browser or fat client </li></ul><ul><li>Single server/farm </li></ul><ul><li>Loosely coupled </li></ul><ul><li>Application data </li></ul><ul><li>Individual transaction </li></ul><ul><li>Business development </li></ul><ul><li>Platform: LAMP </li></ul><ul><li>Lightweight REST </li></ul><ul><li>Ajax-enabled browser or mobile phone </li></ul><ul><li>Distributed servers </li></ul><ul><li>Even more loosely coupled </li></ul><ul><li>User-contributed data and metadata </li></ul><ul><li>Social interaction </li></ul><ul><li>Community development </li></ul>
    18. 18. Ajax Catches Fire at the Surface Level Easy to Add Snippets, Hard to Re-Factor for Full Framework <ul><li>What is Ajax? The latest fashion in Web design </li></ul><ul><ul><li>Asynchronous transfers – page elements load in background </li></ul></ul><ul><ul><li>JavaScript/DHTML – client-side processing more responsive </li></ul></ul><ul><li>Examples of Ajax-based sites </li></ul><ul><ul><li>Google Gmail, Google Maps, Flickr, Basecamp, TiddlyWiki </li></ul></ul><ul><ul><li>Pioneers: Outlook in 1998, Desktop.com in 1999 </li></ul></ul><ul><li>Real effectiveness comes when combined with </li></ul><ul><ul><li>Innovations in usability </li></ul></ul><ul><ul><li>Server-side processing </li></ul></ul><ul><li>The &quot;Portal Paradox&quot; </li></ul><ul><ul><li>Portals viewed as app front-ends </li></ul></ul><ul><ul><li>But UI designers face complex inflexible frameworks if you stray </li></ul></ul><ul><ul><li>Ajax will have limited scope (snippets and widgets) in the near-term </li></ul></ul>
    19. 19. Software Architecture as an Unintended Consequence of Social Architecture <ul><li>Context </li></ul><ul><li>The structure of a system reflects the structure of the organization that built it. </li></ul><ul><li>An organization with constrained lines of communication may build systems that don't interoperate and are difficult to monitor. </li></ul><ul><li>Attempts to change or improve the structure of the system are often reversed by forces which snap the system back to its original shape (this can be good or bad). </li></ul><ul><li>In the case of dysfunctional organizations, it can mean a continual struggle against design defects (bugs and performance issues). </li></ul><ul><li>Solution </li></ul><ul><li>To fix or refactor the software artifact, refactor or restructure the organization that created it. Of course, this can be very difficult. </li></ul><ul><li>Examine and cultivate process attributes: collaborative, community-based, transparent, repeatable and efficient. </li></ul><ul><li>Implications for SOA and Web 2.0: Will the &quot;tail wag the dog&quot;? </li></ul>
    20. 20. Recommendations <ul><li>Keep in mind that portal technology is multi-faceted and can support different kinds of architectural approaches, from tight (non-SOA) to loosely coupled (SOA and more). </li></ul><ul><li>Consider SOA as just one approach to modularity and connected systems. </li></ul><ul><li>When building connected systems, pick and choose among the different capabilities in portal: portlets using high-performance custom APIs, standards-based portlets, RSS-based syndication, composite app capability, etc. </li></ul><ul><li>Prepare for the Web 2.0 wave, which introduces new approaches to platforms and processes. </li></ul><ul><li>Be ready to re-evaluate and re-factor your process and organizational structure, not just technology and products. </li></ul>
    21. 21. Portals: The Original SOA Framework Ray Valdes