[Design of JBoss ESB] - Re: Virtual Registries?
by mark.little＠jboss.com
"driedtoast" wrote : Anyway getting back to my original reason for bringing this up....
|
| The concept would be this, for every framework to integrate it is hid behind a registry (yes a virtual one). So the bus would request a service from the registry and the registry would look at the framework to realize the service.
|
|
| For instance:
|
|
| | // pseudo code
| |
| | businessQueryMgr.findServices(....)
| | -> applicationContext.findBean(serviceName)
| | -> wrap in service object
| | -> add to BulkResponse
| | return service;
| |
| |
|
| The other idea is that maybe based on the service category the registry is determined by that instead of a specific reference per the service definition.
|
| So I could...
| register a registry to register registered bean of that registered registry!
|
| anonymous wrote :
| | service category=registry class
| |
|
| If we use the category the ESB would talk to its registry that would front a registry of registries
|
| :)
Take a look at the front-end code we use. It seems to me that what you're after (and the federated approach I mentioned earlier) can be handled there. One way (not necessarily the only way) would be to allow the registration of service-registry handlers/mappers and then the frontend code calls them to lookup the service. In pseudo-code:
client->registry_frontend.lookup(service)
registry_frontend.lookup (service)
{
// go through all registry service-name handlers
loop
{
if handler[loopiter].managestype(service)
return handler[loopiter].lookup(service);
}
return nosuchservicefound;
}
The mapping of handlers to types of service could be done dynamically and also with a static config file.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024635#4024635
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024635
19 years, 1 month
[Design of JBoss Build System] - Re: Build System Meeting Agenda Mar 01, 2007
by pgier
Notes from the meeting
Should we create some kind of automatic notification for releases? This could be done through a maven plugin that sends an email or generates an RSS feed.
How should we handle thirdparty jars in our repository? One way is to set up a separate repository just for thirdparty artifacts. Another way is to allow developers to add thirdparty stuff to the snapshot repository, and then copy the required files to the release repository when a release is performed.
I started looking at some maven scripts for app server from about 1 year ago. They are out of date, but I will see what I can use from them and add them to app server 5.0.
What needs to go into the distribution file for microcontainer? We talked about creating an assembly for microcontainer, but I'm not sure if there are any old releases similar to what we want now.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024634#4024634
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024634
19 years, 1 month
[Design of JBoss ESB] - Re: Virtual Registries?
by mark.little＠jboss.com
"driedtoast" wrote : Give a man a bucket for water and see how much he will spill....
|
| I should start threads like this more often.
|
| The concept of the virtual registry is that the registry itself is not published and may not be a physical registry. Registries and UDDI came about through people trying to get a grip on how to "manage" services.
|
| If we have a central "registry" than we know what is running when, leads people into talks about governance, policies... etc... This is also a bit of legacy from the Object Brokering days.
|
Governance and policy are things you need to be concerned about irrespective of your registry implementation or deployment configuration.
anonymous wrote :
| The registries value is to locate services and to register services. But what happens when you really don't want to "publish" a service to the world. I just want to use my instance and my instance alone not the registries.
|
At the moment we do tend to use the registry for all services (at least to get the initial handle), but that is certainly something we are going to address.
anonymous wrote :
| You get into these type of questions when you are deploying large scale systems across an organization. You may want to register a service for a bus that handles all the "public" traffic, but want to replace a service on a trial basis on a different instance that will essentially override one public service internally.
|
Agreed, and that's how I've seen UDDI implementations deployed before. When at HP we would have a couple of implementations, one for live services and one for testing purposes. We didn't have an ESB in those days, but the idea is applicable nonetheless.
anonymous wrote :
| If you had the notion of a virtual registry this would indicate that the bus is responsible for it's own services that are registered in the virtual registry and not published to the world.
|
I'm not sure the term "virtual registry" actually helps here. A federated registry architecture would be my preferred option, like DNS. How much backend implementation details you care to expose to the ultimate user (invoker) of the registry is something to discuss, but it doesn't have to be a lot. For instance, if you had a federated architecture and a nomenclature for service names that identified them as test or live entities, you could ensure that one instance of the registry maintained service "test/foo" whereas another maintained the live version "foo". From a front-end users perspective, as we discussed yesterday, whether "test/foo" and "foo" actually do reside in different registries isn't important. That's a backend implementation/deployment choice. In fact, exposing it to the frontend would be a bad idea as it's getting us towards close coupling.
anonymous wrote :
| In addition, you may want to have service clients/consumers that talk to a bus A that use most of the main registry entries, with just one variation maybe version a slightly different syntax, etc... Bus B would just use the registry entries without any changes.
|
Again, I think this can be hidden to the user and yet achieve the same result.
anonymous wrote :
| This way clients could be running their whole system against bus A for a certain variation in their process Service A location is still the same on each bus but maybe on Bus A the service version is different.
|
| Also realistically I hate to say this but the concept of using a registry in a live system is something that a lot of engineers don't like to count on. The reason is that the registry could be down which makes it a single point of failure.
|
As we discussed yesterday, there's a difference between the API the user interacts with and the backend implementation choice. There may be the concept of a single logical registry service, but it could be implemented using clustering or replication. That's the same approach you can use for all of the services.
anonymous wrote :
| The concept of auto-discover is an interesting debate that has happened for a while. If you ever design systems and infrastructure you pretty much know what is going to be there if something changes you would know and it wouldn't be a "dynamic" change.
|
| My thoughts are that we should be flexible with the fact that registries are great in principle, but let's not constrain ourselves to having a dependency on a global registry or a single registry. I might need to use a registry outside the company for some services in the bus, while the internal services are registered with a different registry.
|
And I think this can be hidden behind the client facade.
anonymous wrote :
| This is the idea of federation. Federation involves an external registry to aggregate or a whole infrastructure to provide federation which in itself is a "bus" like view geared toward managing entries and locations of services.
|
You can see I'm replying and reading your text as I come to it ;-)
anonymous wrote :
| So does an ESB worry about more than one registry? The answer is as services are being delivered and consumed by many companies and a bus is the "aggregator", "router" or whatever term you can generalize the bus too, it needs to be responsible for the services it manages regardless of how many registries are in the infrastructure or whether there is control over that.
|
| Look at the liberty alliance projects to look at how complicated the registries could become in the concept of federation. Instead why don't we view the bus as knowing about various registries and even taking into account that a registry could just be a concept and not a physical representation within the infrastructure "virtual".
|
| Make sense? Off my rocker?
|
If you take a look at some of the original architecture docs and presentations you'll see that the one example of federation of a service we have is based on federated registry. Obviously the idea was that it should be applied to any service, but registry was the important example.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024628#4024628
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024628
19 years, 1 month
[Design of JBoss ESB] - Re: Virtual Registries?
by driedtoast
Anyway getting back to my original reason for bringing this up....
The concept would be this, for every framework to integrate it is hid behind a registry (yes a virtual one). So the bus would request a service from the registry and the registry would look at the framework to realize the service.
For instance:
| // pseudo code
|
| businessQueryMgr.findServices(....)
| -> applicationContext.findBean(serviceName)
| -> wrap in service object
| -> add to BulkResponse
| return service;
|
|
The other idea is that maybe based on the service category the registry is determined by that instead of a specific reference per the service definition.
So I could...
register a registry to register registered bean of that registered registry!
anonymous wrote :
| service category=registry class
|
If we use the category the ESB would talk to its registry that would front a registry of registries
:)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024618#4024618
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024618
19 years, 1 month
[Design of JBoss ESB] - Re: Virtual Registries?
by driedtoast
Give a man a bucket for water and see how much he will spill....
I should start threads like this more often.
The concept of the virtual registry is that the registry itself is not published and may not be a physical registry. Registries and UDDI came about through people trying to get a grip on how to "manage" services.
If we have a central "registry" than we know what is running when, leads people into talks about governance, policies... etc... This is also a bit of legacy from the Object Brokering days.
The registries value is to locate services and to register services. But what happens when you really don't want to "publish" a service to the world. I just want to use my instance and my instance alone not the registries.
You get into these type of questions when you are deploying large scale systems across an organization. You may want to register a service for a bus that handles all the "public" traffic, but want to replace a service on a trial basis on a different instance that will essentially override one public service internally.
If you had the notion of a virtual registry this would indicate that the bus is responsible for it's own services that are registered in the virtual registry and not published to the world.
In addition, you may want to have service clients/consumers that talk to a bus A that use most of the main registry entries, with just one variation maybe version a slightly different syntax, etc... Bus B would just use the registry entries without any changes.
This way clients could be running their whole system against bus A for a certain variation in their process Service A location is still the same on each bus but maybe on Bus A the service version is different.
Also realistically I hate to say this but the concept of using a registry in a live system is something that a lot of engineers don't like to count on. The reason is that the registry could be down which makes it a single point of failure. The concept of auto-discover is an interesting debate that has happened for a while. If you ever design systems and infrastructure you pretty much know what is going to be there if something changes you would know and it wouldn't be a "dynamic" change.
My thoughts are that we should be flexible with the fact that registries are great in principle, but let's not constrain ourselves to having a dependency on a global registry or a single registry. I might need to use a registry outside the company for some services in the bus, while the internal services are registered with a different registry.
This is the idea of federation. Federation involves an external registry to aggregate or a whole infrastructure to provide federation which in itself is a "bus" like view geared toward managing entries and locations of services.
So does an ESB worry about more than one registry? The answer is as services are being delivered and consumed by many companies and a bus is the "aggregator", "router" or whatever term you can generalize the bus too, it needs to be responsible for the services it manages regardless of how many registries are in the infrastructure or whether there is control over that.
Look at the liberty alliance projects to look at how complicated the registries could become in the concept of federation. Instead why don't we view the bus as knowing about various registries and even taking into account that a registry could just be a concept and not a physical representation within the infrastructure "virtual".
Make sense? Off my rocker?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024617#4024617
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024617
19 years, 1 month
[Design of POJO Server] - Still have insufficient separation of metadata
by scott.stark＠jboss.org
Even after the attempt to cleanup the DeploymentUnit attachment transient vs trasient managed object attachments by putting non-serializable attachments into the transient bucket, while looking into JBMICROCONT-152 even serializable metadata is too aggregate to be able to make this distinction. For example, the ServiceMetaData contains ServiceInjectionValueMetaData which
| public class ServiceInjectionValueMetaData extends AbstractMetaDataVisitorNode
| implements ServiceValueMetaData, Serializable
| {
| private static final long serialVersionUID = 1;
|
| /** The dependency */
| private transient Object dependency;
|
| /** The property */
| private String property;
|
| /** The required state of the dependency */
| private ControllerState dependentState = ControllerState.INSTALLED;
|
This was not a valid transformation to a Serializable because the dependency cannot be restored, and its a neccessary attribute. So, the default attachment bucket is going to have to be the transient one. Only if a deployer knows its metadata can be used as a serializable transient managed object would it use the transient managed object bucket explicitly.
Generally it looks like the existing metadata is going to have to be refactored to allow for externalizable managed objects that can be persisted.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024558#4024558
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024558
19 years, 1 month