Hi Hasko,
I've just had a look at the Application Service Catalogue view and there is indeed a sort of bug and an actual bug.
The actual bug with this is that if you happen to name your Application Service with a lower case first letter, e.g. myService instead of MyService, then it will not be shown in the catalogue.
The sort-of bug is that at the moment, the Application Service Catalogue only looks for Application Services and not Composite Application Services. The out-of-the-box views in Essential Viewer don't cover composites (Application Services or Application Providers) very well at the moment, but clearly they need to.
I'm going to fix the Application Service bugs and release a patch for these views that will be easy to apply by dropping updated XSL files into the correct folder of Essential Viewer. That should be done this week.
I'll get the Composite Application Providers onto the to-do list, too.
On the modelling side, what you've described sounds reasonable, as long as those are the components that make up the Online Banking service. There are some interesting debates to have around what happens to the Application Functions of the contained services. I think most often, you select the functions that are exposed by the composite from the suite of functions defined by the contained Application Services (i.e. you don't have to expose them all). In fact, in this case, you may choose not to define any functions for the top-level composite.
The other thing to be careful of in this scenario is to make sure that in the Application Layer you are focussing on behaviour, not technology. So, your "portal" service should represent the behaviour (specific application functionality) of the portal that your online banking service has and not the generic portal platform stuff that is actually part of the technology architecture of the application.
Finally, on the modelling, just because a service uses functions provided by another service doesn't mean that it's a composite. Many SOA solutions operate as a network of services and it's another interesting debate as to whether you would consider any path of function-invocations across that network as a composite. These kind of questions and scenarios were partly why Composite Application Services are not well supported in the Viewer at the moment. However, we felt that there were such things as composite services and wanted to make sure that we had something for them in the modeller. Such composites have quite strict semantics, though, that the composite represents a service that is truly made up of one or more other services - as opposed to a service that uses one or more other services (however, even a composite service needs some sort of provider implementation to make the composition happen, even if that's just a BPEL flow). Perhaps it comes down to whether or not the Composite can exist without any one of the contained services or whether it just stops working. I think that if it just stops working, then it's probably not a composite.
I'd be really interested in your views on this, as it would be great to define some heuristics and guidelines for Composites that apply to as many real-world scenarios as possible.
Jonathan