Last week, on my way to a presentation, I ran into this colleague of mine – the same one who had Why DTR ? Why not Perforce or ClearCase...?.
“Hey!” she said, apparently thrilled that she’d caught me finally, “I read your The Evolution of Development Infrastructure!”
“Evolution.” I corrected her.
“Whatever. But it left many questions unanswered – for instance, what’s this SAP Component Model all about?!”
“Well, yes, I’m planning to write more about those topics in the coming - ”
“Why don’t you tell me about it now?” she interrupted.
It was difficult to ignore her. “Fine.” I said, and walked over to a nearby table in the coffee corner. “What exactly would you like to know?”
“The what and the why – you decide the order.”
“I’ll begin with the what first.” I said. “Simply put, the SAP Component Model is a specification that outlines a way to structure our software into certain entities, and describe dependencies between these entities.”
“Okay. So if existing software must confirm to this model, then it must be restructured into these entities based on this specification, right?” she asked.
“That’s right. The main entities are Development Components and Software Components. Development Components contain objects you develop – Java source files, table definitions, XML files containing some WebDynpro definitions etc.”
“But currently, the sources we develop are grouped into projects – what happens to that abstraction?” she asked.
“You’re jumping to an implementation issue, but it will probably make things clearer – a Development Component maps to a project in Eclipse. So when you create a Development Component of a specific type in the SAP NetWeaver Developer Studio, it will create an Eclipse project of a particular Eclipse ‘Nature’. For example, a Development Component of type ‘WebDynpro’ will create a WebDynpro project, while a Development Component of type ‘Java’ will create a Java project.”
“Fine, but then why do we need this additional abstraction – Development Component - at all?” she asked.
“Now you’ve jumped to a completely theoretical aspect! Anyways, a brief answer would be that this abstraction (and other abstractions in the SAP Component Model) offers a standard interface for tasks that are common to all kinds of projects in different technologies. And this standard interface is the foundation upon which the tools and services of the NetWeaver Development Infrastructure are built.”
“That’s too abstract for me – how about some concrete examples?” she asked.
“I’ll provide them when I talk about the benefits of this model. Let’s get on with the basics first, okay?”
“Okay. I’ve read that a Development Component is like a black box – what does that mean?” she asked.
“It means that a Development Component is a unit of encapsulation and by default everything inside a Development Component is private. Let’s say you create a Development Component of type ‘Java’, and add some Java classes into it. At this point, none of your classes will be visible outside this Development Component – not even the public classes.”
“So we need to explicitly declare something as public at the Development Component level?” she asked.
“Right. This is where Public Parts come in. A Public Part is where you put those development objects you intend to make public. The outside world – other Development Components – can see and use only those entities which are exposed by a Development Component in a Public Part.”
“So if I place a private Java class into a Public Part of a Development Component, will it become accessible by others?” she asked.
“No. Development Components can only restrict visibility, and Public Parts cannot enhance the visibility semantic of the underlying technology. A Public Part cannot make a private Java class public.”
“Hmm…” she said, thoughtfully. “So if one Development Component wants to use another Development Component, it must reference a Public Part of the used Component, isn’t it?”
“Yes. “ I said, taking out one of the printed sheets I was carrying. “This diagram will give you an idea.”
“So the Development Component A can see and use only those java classes which are contained in the Public Part P1 which it references” she said.
“Right.” I replied, showing her another diagram. “As this diagram shows, Development Components can be nested. This brings in further rules about specifying dependencies across borders.”
“Component H can declare a dependency to component Y, but crossing the border in the other direction is not allowed – that is Y cannot declare a dependency to the inner component H. This is made clear by the cross marked red, which denotes a dependency that is not allowed. ” I explained.
“Wait a minute,” she said, “if a component cannot cross the border and use another component which is not at the top level, then how can these inner components expose their Public Parts to the outside world?!”
“That is done by propagating the entities in a Public Part of the inner component to the parent component – like this.” I showed her another picture.
“Okay, I understand the rules now,” she said, “but I’m still not clear about the real advantage of having Public Parts?”
“If you think of a Development Component as a module, then a Public Part of that Component is like an interface of the module. In general, it is good to separate the interface and the implementation, and this holds good at this level also.”
“I understand that.” She replied. “But even with Development Components, can’t we use the visibility mechanisms of the underlying technology to separate interface and implementation? If this were the case, when a java Development Component A references another java Development Component B, it gets access to all the public classes of the referenced component – simple ! This way we can avoid having another abstraction like ‘Public Part’ !!”
“Well,” I replied, “I think I need to go into the details of the advantages offered by Public Parts. Firstly, Public Parts make it possible to narrow down the compile-time dependencies between components to only those parts that are public. For example, instead of referencing a jar file that contains everything (even private classes that are unnecessary at compile time), a reference to a Public Part will result in a compile-time project reference to a jar file containing only the classes in the Public Part. The advantage of this is not immediately apparent, but take a look at it from two viewpoints: the IDE and the Build Server. From the IDE point of view, creating a project for a Development Component means downloading all the dependent binaries or archives, and here it is clearly a benefit if the archive to be downloaded has only the entities necessary at design time (and hence is smaller than the entire component). Similarly for the Build Server, this implies that that to build a Development Component, it needs to obtain these smaller Public Part archives from its archive pool.”
“That is not such a big advantage.” She said, plainly.
“Next, Public Parts allow you to structure the public entities of your Development Components based on some logic appropriate for your component. For example, for a Development Component ‘Bank’ you can create a Public Part ‘Accounts’ that contains interfaces which provide account related services of this component, and another Public Part ‘Loans’ that contains interfaces which provide loan related services. Thus, other Development Components can create references to exactly the Public Part they need based on the service they wish to use.”
“Okay,” she said. “So this makes things modular and reduces unnecessary dependencies. What else?”
“Further, you can restrict the usage of these Public Parts by creating an Access Control List where you specify that a Public Part X can be used by Development Components A, B and C – no one else.”
“That sounds useful!” she said.
“Finally, Public Parts facilitate minimal automatic re-builds on the Build Server when it receives a request to build a Development Component that was modified. When the entity - like a Java class - that was modified is a member of a Public Part, the Build Server automatically triggers the re-build of all other Development Components that use this Public Part. However, if the modified entity did not belong to any Public Part, then the Build Server builds only that Development Component.”
“That makes things clear” she said, and continued. “Now what about declaring usage dependencies explicitly – what is the advantage in that?”
“Here we’re touching upon some general benefits of such a model. A model that allows you to define components in a hierarchical fashion while keeping the dependencies explicit is a device that allows you to master complexity in a large system. Keeping dependencies explicit makes it possible to reduce dependencies – thus keeping the components loosely coupled – and it also allows us to detect cyclic dependencies and eliminate them.”
“Further,” I said, continuing with the issue of explicit dependencies, “the requirement that all Development Components explicitly declare their dependencies to each other confers advantages at different stages of the software lifecycle. At design time the IDE can read this dependency information and automatically download the dependent archives and create project references – the user does not have to worry about copying binaries from somewhere. At build time the Build Server uses this information to build dependent components automatically when a component is modified. At deployment time this information is used to generate run-time dependency information, which is then used at run time.”
“Can’t all this be done using the dependency information stored in the underlying technology?” She asked. “For example, Eclipse project files contain dependency information which can be used for the tasks you mentioned – isn’t it?”
“In principle, yes.” I replied. “But that would tie the implementation of these tools to specific technologies, instead of relying on a standard interface to access dependency information. By enforcing a standard like the SAP Component Model, we can build generic mechanisms that need not be changed whenever the technology underlying these components changes.”
“Ah!” she said, as if enlightened all of a sudden. “Now I understand what you meant when you said in the beginning that the Component Model offers a standard interface to common tasks. It seems to me like a prerequisite to developing this infrastructure you wrote about – without such a model, it would be difficult to provide generic infrastructure services like the Build Server etc.”
“Couldn’t have been put any better!” I said, relieved that my efforts had yielded some results.
“You also mentioned something about Software Components –what are these?” She asked.
“A Software Component is a container for Development Components - every Development Component must belong to a Software Component.” I replied.
“So we can group together Development Components in one area into a Software Component?”
“Yes.” I replied. “And these are units of delivery – a Software Component is installed as a whole.”
“Do these Software Components also have something like Public Parts?”
“No.” I said. “A Software Component does not adhere to the Black Box principle, and it does not have anything like Public Parts. However, you can declare dependencies across Software Components – for example, a Software Component ‘CRM’ can declare a usage dependency to a Software Component ‘Netweaver Infrastructure’ , and that would allow Development Components inside the ‘CRM’ Software Component to declare dependencies to Development Components inside ‘Netweaver Infrastructure’ – but not the other way around.”
“Okay. Is there a way to restrict access to specific Software Components only?” she asked.
“Yes – a Software Component can grant access to one or more Software Components, thus restricting the areas to which dependencies can be created. Additionally, a Development Component can grant access to certain Software Components, which means only the Development Components in those Software Components can declare a dependency to this Development Component.”
“When would something like that be useful?” she asked.
“When you have a Development Component which makes certain things Public – through a Public Part – but wants only other Development Components in its own area – its own Software Component – to use this Public Part. Such situations are common in a layered system where the certain framework components must be accessed only by other framework components and not the application components which use the framework.”
“It looks like we can create layers of the system based on these Software Components.” she said.
“Yes.” I said. “And these layers can be used to model transport landscapes and define routes of propagation in these landscapes – but this is different topic altogether.”
“You haven’t mentioned anything about reuse?” she asked.
“I thought that was obvious – creating dependencies between components implies reuse, doesn’t it?!”
“Of course, of course,” she nodded. “So a Development Component is the basic unit of reuse in this model. And what happens at runtime – what do these Development Components map to at runtime?”
“In its present form,” I replied, “the SAP Component model is independent of runtime environments. The model allowsus to define Development Component Types and Subtypes, which determine the mapping to runtime environments of Development Components. For example, a Development Component of type Java is for the Java runtime environment, and another of type J2EE Additional Library runs on a J2EE engine. Tomorrow, for example, we could have types that are relevant for the COM or .Net runtime.”
“Further,” I continued, “the model does not specify a runtime format for Development Components; the format of the underlying technology ( Java, J2EE, COM…etc ) is what holds at runtime. In this sense, the SAP Component model is a wrapper around existing models, and it brings them together under a common interface, thus allowing the SAP NetWeaver platform seamlessly interoperate with different technologies.”
“Okay, that makes things clear.” She replied. “Now what about the Component Build Server? Why don’t you tell me something about it?”
“Some other day. I’m already late for the presentation. Bye !”
As I walked back, I couldn’t help thinking that her curiosity knew no bounds. And at that instant, a name struck : Miss Inquisitive. Yes, that’s what she ought to be called, I decided.
