IBM BS029ML Self Help Guide - Page 24

Building the right Portal architecture, 2.1.1 Addressing functionality

Page 24 highlights

2.1 Building the right Portal architecture WebSphere Portal Server architectures come in many shapes and forms. This is in part attributed to the demands of modern day e-business, where the need to establish a robust, open, scalable, and strategic infrastructure platform to set the standard for system reuse and interoperability exists. WebSphere Portal Server achieves all of these goals through the establishment of an extensible framework of services, and then, by being deployed as an Enterprise Application on top of either WebSphere Application Server or WebSphere Process Server (certain restrictions apply). Leveraging upon the strengths of the underlying WebSphere technology make it possible for WebSphere Portal Server to support everything from the small workgroup (WebSphere Portal Express) to the high-volume enterprise, to the geographically distributed Portal. Indeed, IBM recognizes that "one size does not fit all" when it comes to planning and architecting a Portal solution. To the experienced Portal Solution team, functional and operation aspects need to be considered with equal rigor and importance when implementing a successful Portal solution. It is acknowledged that the principles of good architectural design and development go hand in hand with the adoption of a suitable methodology. Indeed, the IBM Global Services Method (GS-Method or GSM) has been the basis for many successful WebSphere Portal Server deployments. However, the merits and application of such methodologies are beyond the scope of this particular Redpaper. 2.1.1 Addressing functionality Functionality remains the main driving force behind many of the systems and solutions that we use each day. Without functionality, a system or solution fast becomes obsolete. Portals are no exception to this rule. Although no specific functional requirements are documented within this chapter, as attempting to do so would prove futile given the uniqueness of many WebSphere Portal Server deployments, one can dramatically improve the success factor of a deployment by accurately capturing conditions such as the following: What the specific applications, services, or products are that a WebSphere Portal Server implementation should support. What the high level capabilities are that an implementation should have, for example, security, user collaboration, user interface, and so on. What the general use cases are that best describe the business functionality required from the implementation. 2.1.2 Addressing integration Integration is not a trivial issue and requires time and effort to accurately establish the most appropriate solution. A good WebSphere Portal Server architecture, therefore, addresses integration as early on in a project as possible. WebSphere Portal Server integration can be loosely classified into the following three categories. 10 IBM WebSphere Portal V6 Self Help Guide

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242

10
IBM WebSphere Portal V6 Self Help Guide
2.1
Building the right Portal architecture
WebSphere Portal Server architectures come in many shapes and forms. This is in part
attributed to the demands of modern day e-business, where the need to establish a robust,
open, scalable, and strategic infrastructure platform to set the standard for system reuse and
interoperability exists. WebSphere Portal Server achieves all of these goals through the
establishment of an extensible framework of services, and then, by being deployed as an
Enterprise Application on top of either WebSphere Application Server or WebSphere Process
Server (certain restrictions apply).
Leveraging upon the strengths of the underlying WebSphere technology make it possible for
WebSphere Portal Server to support everything from the small workgroup (WebSphere Portal
Express) to the high-volume enterprise, to the geographically distributed Portal. Indeed, IBM
recognizes that “one size does not fit all” when it comes to planning and architecting a Portal
solution.
To the experienced Portal Solution team, functional and operation aspects need to be
considered with equal rigor and importance when implementing a successful Portal solution.
It is acknowledged that the principles of good architectural design and development go hand
in hand with the adoption of a suitable methodology. Indeed, the IBM Global Services Method
(GS-Method or GSM) has been the basis for many successful WebSphere Portal Server
deployments. However, the merits and application of such methodologies are beyond the
scope of this particular Redpaper.
2.1.1
Addressing functionality
Functionality remains the main driving force behind many of the systems and solutions that
we use each day. Without functionality, a system or solution fast becomes obsolete. Portals
are no exception to this rule.
Although no specific functional requirements are documented within this chapter, as
attempting to do so would prove futile given the uniqueness of many WebSphere Portal
Server deployments, one can dramatically improve the success factor of a deployment by
accurately capturing conditions such as the following:
±
What the specific applications, services, or products are that a WebSphere Portal Server
implementation should support.
±
What the high level capabilities are that an implementation should have, for example,
security, user collaboration, user interface, and so on.
±
What the general use cases are that best describe the business functionality required from
the implementation.
2.1.2
Addressing integration
Integration is not a trivial issue and requires time and effort to accurately establish the most
appropriate solution. A good WebSphere Portal Server architecture, therefore, addresses
integration as early on in a project as possible.
WebSphere Portal Server integration can be loosely classified into the following three
categories.